RE: Chris Little's comments on the BP - Issues 128 and 204

All,

On Friday, February 19, 2016 2:07 PM, Linda van den Brink wrote:

> My 5 cents based on reading this discussion, thinking about it and discussing
> it with colleagues… (by the way, I’m still waiting to hear from the Dutch
> specialists on coordinate reference systems…)

And here about 20 öre of personal thoughts about this discussion. I'm neither a geospatial expert nor a web developer, but somewhere inbetween...

> First of all, with the best practice in mind we want to base ourselves on
> practice, not on what we think is the best thing theoretically. We can’t ignore
> the widespread use of CRS84, somehow we have to address it. It’s proper
> and improper uses, you could say.

Yes. For someone who is new to geospatial data, all this talk about ellipsoids, CRSs (and the difference between CRS84 and WGS84) is confusing at best and incomprehensible at worst.

> Secondly we need to think of our audiences. I agree with Jon here, it’s mainly
> web developers and data providers. I assume that the data providers of
> spatial data are professionals and they know about the existence of different
> CRS and which one is most appropriate for their data. So for them it is no
> problem to specify the correct CRS for their data.

Yes and no. If the data provider is a national geodetic agency or something similar, I'd agree. But there are also many other government agencies (National Libraries come to my mind...) that have some geospatial data (e. g. places with attached geometries) that they want to publish and where _some_ staff have _some_ knowledge about geospatial issues but still struggle with getting everything right.

> Web developers, on the
> other hand, may very well not even know that different CRS exist. We can’t
> burden them with having to understand all this. Probably IF they publish
> spatial data it will be in CRS84.

Perhaps we can say that _it will likely be in CRS84_ but that in many cases it might not. If an average web developer pulls data from a French system and then re-publishes it, it definitely will _not_ be CRS84.

> I say let them have the convenience of a
> default CRS: If you don’t specify, it’s assumed to be CRS84. If you know it’s
> another CRS, you can specify.
> 
> Imagine if we said you must always specify a CRS. What do we think web
> developers would do when they encounter a CRS reference in spatial data? I
> think most would probably ignore it anyway, not knowing what it is. So that
> does not solve anything anyway.

Yes, I think most would ignore it and that is why I too suggest that we suggest the use of a default CRS.

Also, I think this is an issue of tool support. Ideally, the tool (JS-library or whatever) I use should simply consume the data and know how to deal with any specific information (such as CRS) and let the developer concentrate on getting the application logic right. In a way, the discussion about different formats (GeoJSON vs. WKT vs. ...) reminds a bit of the browser wars. Those were ultimately solved by a HUGE standardisation effort because everyone eventually realised that too many formats and too many vendor-specific extensions harm interoperability. In the case of HTML the actors were the W3C and the major browser vendors. In the case of geospatial it would probably be the OGC and the community of JS-for-geospatial library developers.

For data providers, we could have the following best practice:

[[
Publish your data using CRS84. If you -- e. g. during to local legislation -- are compelled to publish your data using another CRS, publish your data using that CRS, clearly stating in the dataset metadata which CRS you use and how it can be converted to other CRSs, and supply an additional distribution where the data is in CRS84. (or something along those lines).
]]

We could also add some text about why it's important to supply data using the default CRS (non-expert consumers not knowing that they might get their maps wrong etc.).

> Another thing is, in our testbed we have already found that complex geo
> features provided by base registries (ie authoritative data) are often very
> accurate – i.e. polygons with lots of coordinates. Especially when querying
> feature collections, this results in very large response payloads wasting
> bandwidth and causing slow response times. For web applications, these
> payload sizes are unacceptable and will cause applications to become slow or
> unresponsive. The testbed participants are suggesting that in many use
> cases, this level of precision and accuracy is unnecessary and they
> recommend simplification of the geometries. (see
> https://github.com/geo4web-testbed/topic3/wiki/Performance-%26-data-

> compactness for more detailed discussion)

Sounds a bit like a case for graceful degradation...

> So if we need to simplify geometries for many use cases on the web anyway,
> it doesn’t matter in those cases if CRS84 is used instead of a more accurate
> CRS.
> 
> I think the best practice would be something along these lines:
> - create and store the data with CRS84, or a more accurate and appropriate
> one given the location on earth;
> - publish the data on the web using CRS84
> - in case of big geometries, publish these in a simplified form;
> - provide metadata stating the geometries are simplified
> - provide an option to access the more accurate source data with the original
> CRS as well, for use cases where this is appropriate.

+1

> With regard to use cases, I think a lot of the time the use case for spatial data
> on the web is really simple: answering questions like where is this, what is
> near me, how do I get there etc. For this, high accuracy is not necessary. But
> high accuracy is necessary when, for example, the question is: where exactly
> are the borders of my property (land parcel)?

Best,

Lars

Received on Tuesday, 23 February 2016 09:05:18 UTC