Re: BP8 (web friendly geometries) - compactness, compression, simplification [SEC=UNCLASSIFIED]

Hey Josh. Does it get boring being right all the time? ... +1 regarding
comment about scale.

On Tue, 14 Mar 2017 at 13:02 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

> I hope we can also include the primary basis for simplification, which is
> scale. Searching for a Starbucks on a city scale, 3m is ok. Providing
> street level directions, not so much.
>
> Josh
>
> On Mar 14, 2017, at 04:53, Linda van den Brink <l.vandenbrink@geonovum.nl>
> wrote:
>
> Thank you Bruce, I think this is good guidance to include in the BP. We
> should definitely help the readers decide whether simplifying geometries is
> a good thing for them or not. BTW I think there are more cases were
> simplified geometries are fine e.g. simple questions like ‘where is the
> nearest Starbucks’ – in that case it doesn’t matter so much if the geometry
> is , say, 3m inaccurate.
>
>
>
> I’ll add a note to the backlog to make sure this is addressed in the next
> sprint.
>
>
>
> *Van:* Bruce Bannerman [mailto:bruce.bannerman@bom.gov.au
> <bruce.bannerman@bom.gov.au>]
> *Verzonden:* maandag 13 maart 2017 23:24
> *Aan:* Linda van den Brink; Bruce Bannerman; Jeremy Tandy; Clemens Portele
> *CC:* andrea.perego@ec.europa.eu; SDW WG Public List
> *Onderwerp:* Re: BP8 (web friendly geometries) - compactness,
> compression, simplification [SEC=UNCLASSIFIED]
>
>
>
> Hi Linda,
>
>
>
> Another aspect that I thought of over the weekend, relates to what we
> consider the use of the spatial data to be.
>
>
>
> Taking a previous example that Jeremy provided, that of clustering [1]:
>
>    - If we just want a pretty picture (cartographic) output, then a
>    generalised display is OK.
>
>
>    - However, if we need to undertake some spatial analysis where it is
>    important to get the results for every feature in an area of interest to
>    use as input into an algorithm. Then the generalisation is *not OK*.
>
> An approach that just assumes that any output is for cartographic purposes
> will cause big issues in the future and hamstring our ability to
> effectively use spatial information for analytic purposes in support of
> decision making.
>
>
>
> Again, perhaps I’m misreading the intent of this Best Practice.
>
>
>
> Bruce
>
>
>
> [1]
> https://github.com/geo4web-testbed/topic3/wiki/Performance-%26-data-compactness
>
>
>
> *From: *Linda van den Brink <l.vandenbrink@geonovum.nl>
> *Date: *Saturday, 11 March 2017 at 00:11
> *To: *Bruce Bannerman <bruce.bannerman@bom.gov.au>, Jeremy Tandy <
> jeremy.tandy@gmail.com>, Clemens Portele <
> portele@interactive-instruments.de>
> *Cc: *"andrea.perego@ec.europa.eu" <andrea.perego@ec.europa.eu>, SDW WG
> Public List <public-sdw-wg@w3.org>
> *Subject: *RE: BP8 (web friendly geometries) - compactness, compression,
> simplification [SEC=UNCLASSIFIED]
>
>
>
> Hi all,
>
>
>
> Well, I do think that it is useful to supply simplified geometries in some
> way, in a lot of common cases. And as Clemens said it can be considered
> best practice & OGC WFS will support it, which is good news (I didn’t know
> this yet)!
>
>
>
> I like the part where you can negotiate a service for a simplified
> geometry.
>
>
>
> In my opinion we should add something on this topic to BP8, BUT also add a
> note containing a warning about the possible unexpected consequences Bruce
> is talking about. We don’t want people to get into legal conflicts or
> self-driving cars running into buildings because of a simplified geometry…
>
>
>
> I wrote a snippet a while ago on the wiki which we could maybe reuse. It’s
> in the second part of the BP Narrative 2[1] page.
>
>
>
> [1]:
> https://www.w3.org/2015/spatial/wiki/BP_Narrative_2#.283.29_Publish_flooding_forecast_data_as_vector_dataset_and_identify_the_administrative_areas_.28.3F.29_that_the_flooding_is_predicted_to_impact
>
> My suggestion to Andrea is to insert a Note as a place holder into this
> iteration of the BP and to add the substantial content during the next
> sprint.
>
>
>
> Linda
>
>
>
> *Van:* Bruce Bannerman [mailto:bruce.bannerman@bom.gov.au
> <bruce.bannerman@bom.gov.au>]
> *Verzonden:* donderdag 9 maart 2017 23:09
> *Aan:* Jeremy Tandy; Clemens Portele
> *CC:* andrea.perego@ec.europa.eu; Linda van den Brink; SDW WG Public List
> *Onderwerp:* Re: BP8 (web friendly geometries) - compactness,
> compression, simplification [SEC=UNCLASSIFIED]
>
>
>
> Hi everyone,
>
>
>
> I suggest that we be very careful about recommending arbitrary
> generalisation of vector features in order to support a network
> transmission issue.
>
>
>
> This is another area of misuse of spatial data. It may not be what the end
> user needs, or is expecting and may have unexpected consequences. One
> example would be a legal definition of a land boundary, such as a State
> boundary. Conflict has arisen in the past over different interpretations of
> borders.
>
>
>
> Network speeds will eventually increase, reducing the perceived impact of
> network transmission issues.
>
>
>
> There are also data structures that were designed to address this, such as
> topology, vector tiles, or even a raster representation of the feature.
>
>
>
> Developers also need to be smart about how they develop applications, e.g.
> rather than download all of the vector data to the local device in order to
> do some processing, download an image representation via say a WMS, do the
> processing on the server via say a WPS and display the results of the
> analysis as required.
>
>
>
> I’m assuming that OGC services are still considered best practice. I must
> apologise as I haven’t been following SDDWG developments very closely
> lately.
>
>
>
> We don’t need to reinvent the wheel here.
>
>
>
> For those of you who are recommending the use of an API, please make sure
> that these recommendations relate to an Open API. Most of us don’t want to
> be locked into a specific vendor’s product line. If you are interested, OGC
> is in the process of getting some momentum behind this discussion.
>
>
>
> Kind regards,
>
>
>
> Bruce
>
>
>
>
>
> *From: *Jeremy Tandy <jeremy.tandy@gmail.com>
> *Date: *Friday, 10 March 2017 at 05:07
> *To: *Clemens Portele <portele@interactive-instruments.de>
> *Cc: *"andrea.perego@ec.europa.eu" <andrea.perego@ec.europa.eu>, Linda
> van den Brink <l.vandenbrink@geonovum.nl>, SDW WG Public List <
> public-sdw-wg@w3.org>
> *Subject: *Re: BP8 (web friendly geometries) - compactness, compression,
> simplification
> *Resent-From: *<public-sdw-wg@w3.org>
> *Resent-Date: *Friday, 10 March 2017 at 05:29
>
>
>
> Thanks Clemens!
>
> Andrea - I suspect you're already pressed to get the existing edits for
> BP8 done in time for Delft. So long as we know _what_ we need to add, the
> edits that Clemens & I suggest could be pushed to the March-April sprint.
>
> Jeremy
>
> On Thu, 9 Mar 2017 at 18:01, Clemens Portele <
> portele@interactive-instruments.de> wrote:
>
> I agree, Jeremy.
>
>
>
> Related to generalising geometries with Douglas-Peucker or similar, this
> is also something that can be easily supported via a data acess API by
> specifying a parameter that expresses the resolution of the map used to
> display the data in the client. The next version of WFS will support it
> ([1] is the public change request) and ArcGIS supports it for some time
> [2], too. In my view, this capability can be considered a best practice. If
> we have text about this in BP8, maybe we could add a reference to it in
> BP11.
>
>
>
> The WFS implementation of my company also supports such a capability, but
> currently we use a custom HTTP header as a work-around as the WFS query
> schema does not support this yet.
>
>
>
> Vector tiling is another possible approach to packaging a spatial dataset
> more "Web-friendly", if map display of the dataset is the main focus. The
> de-facto standard is [3].
>
>
>
> Clemens
>
>
>
> [1] https://portal.opengeospatial.org/files/?artifact_id=43079
>
> [2]
> https://blogs.esri.com/esri/arcgis/2011/06/13/feature-layers-can-generalize-geometries-on-the-fly/
>
> [3] https://github.com/mapbox/vector-tile-spec
>
>
>
> On 9 Mar 2017, at 17:38, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
>
>
> Hi Andrea - it just occurred to me that we're missing a topic in BP8
> concerning making geometries "friendly" for the Web.
>
>
>
> It's not just about the format(s) we use, it's also about providing
> geometry objects that are of a size that user agents can handle. (this [1]
> example provides a nice illustration)
>
>
>
> I recall that the Geonovum testbed topic 3 covered this issue; see here [2]
>
>
>
> What do you (& others) think?
>
>
>
> Jeremy
>
>
>
> [1]: https://bost.ocks.org/mike/simplify/
>
> [2]:
> https://github.com/geo4web-testbed/topic3/wiki/Performance-%26-data-compactness
>
>
>
>