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

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] 
> 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] 
> 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
>