RE: CRS best practices: Google Geocoding API [SEC=UNCLASSIFIED]

Hi Jeremy, Bruce, et.al.,

Sorry to come late to this and revive an old discussion, but I was on vacation for 10days and unplugged from the interwebs....

I think Jeremy's points here are good.  In the BP's themselves we do cover more or less most of the points Bruce raised in his original post.  But the way I understood Bruce's comments is that his issues were with the section 8 - "Coordinate Reference Systems (CRS)" in the intro of the doc.  This raises the question, do we have good alignment between this section and what we say in the BP's themselves - in tone and detail?  Bruce's comments still stand I think when viewed against Section 8 alone.

A couple other comments in relation to this discussion -

One place where WGS84 is most always appropriate for geo-spatial data is in the metadata.  In order to spatially index these data, locational reference information (bounding box and the like) should be stated in WGS84 in the metadata regardless of the CRS of the data being described.  This is a current best practice and a point of advise I think we miss in "Include spatial metadata in dataset metadata".

The point raised about raster data "avoiding computationally expensive re-projection for raster data" is important but a bit buried in the BP in my opinion.  (It is often this expense that determines the CRS a particular agency choses to dominantly use - they of course want their imagery to line up with their map, or in other words, the imagery becomes the basemap.) The first question I usually ask of someone seeking advise on publishing spatial data is, "What type of spatial data are you trying to publish?" because raster has particular issues that vector does not.  Other spatial data types also have different requirements as well of course.  If you are publishing point data only, adding location to data that may not otherwise be spatial, I think Ed's comments apply well. If not, then these more difficult issues raise by Bruce and others may well need to be addressed.

I see Ed's argument that most of the spatial data on the web is in WGS84 as a bit circular.  This may be the case for much of the currently available data, but isn't a major point of the SDWBP to aid in publishing more data on the web than  what is there currently?  One of the barriers to doing so for the huge volume of existing data would be a requirement that it be published in WGS84.  Several studies that I have seen over the years suggest that geospatial data is the most requested data by the open data community.  It is an open question whether WGS84 would be as ubiquitous on the web if these requested data were more available.

Finally, a point about geospatial vs. other spatial in the BP doc in general.  I do agree we need more precision in the doc in this regard.  My suggestion is, as a start, that to make it clear that where we are speaking specifically about geospatial data we use the term "geospatial" or similar throughout the doc.  Include the definition of "geospatial" early on and also in the glossary.

Cheers,
Byron
________________________________________
From: Jeremy Tandy [jeremy.tandy@gmail.com]
Sent: Wednesday, March 29, 2017 6:02 AM
To: Ed Parsons; SDW WG Public List; sdwwg@lists.opengeospatial.org
Subject: Re: CRS best practices: Google Geocoding API [SEC=UNCLASSIFIED]

Precision vs. accuracy: I think we have an outstanding action to clarify our perspective on this … I seem to recall that Andrea Perego offered to write a few lines. That said, I would encourage feedback on Best Practice 5: Describe the positional accuracy of spatial data [1] to make sure we have our base concepts right. Peter Parslow is undertaking a review task in this sprint.


There is more to a SRS that a way of defining a set of coordinates: we all agree here. What we’ve tried to do in section 8. Coordinate Reference Systems (CRS) [2] is introduce people to the concepts of ellipsoids, datums, projections etc. The WG agreed that we were _not_ trying to write a text book here; our goal is only to make people aware of these issues. Many Web developers aren’t even aware that they are making a [implicit] choice about use of WGS84, we want them to (at least) be aware that there are alternatives.


Helpful to point to some good references where non-specialist can learn about the issues surrounding CRSs: we point to a few resources, e.g. The True Size [3] and What’s the real size of Africa? [4] to illustrate some of the issues Bruce made with his diagrams. If the WG members can point me to a good (set of) learning resource(s) I will reference them as ‘additional reading’. But remember - we’re not trying to write a text book.


Avoid making complex domains appear simple: Agreed. This is what we were trying to achieve in Best Practice 3: Choose the coordinate reference system to suit your user's applications [5] - we’ve given 5 good reasons why WGS84 isn’t enough: including that your government tells you so, e.g. use ETRS89 in Europe, or Amersfoort RD in Netherlands; avoiding computationally expensive re-projection for raster data. Basically, the guidance says: “are you in any of these situations- if yes, get some [expert] help”. We are not helping people choose _which_ CRS to use in these situations; there are too many variations, and (as Bruce says) it takes a professional years to acquire the necessary knowledge. So, (1) if you’re not reading BP3 like I just said, please offer me some edited text, (2) if there are additional reasons where someone should look beyond WGS84, then please tell me (I’m the editor here - not the expert!)


Multiple representations; WGS84 as a complement: Best Practice 3: Choose the coordinate reference system to suit your user's applications [5] says publish in WGS84 _and_ something else if need be. Jon’s point about Web Mercator being the de facto “web standard” for raster data is well made. I will attempt to incorporate this.


No problem recommending WGS84 (sic) as long as the context is clear: Best Practice 17: State how coordinate values are encoded [6] is all about telling people how to state the CRS - and, thus, provide the context. Have I missed anything here. We’re saying that there is NO EXCUSE for not telling people what CRS you’re using. The green note box(es) even point out some of the problems you’ve all been identifying.


Emotive (sweeping) statements about WGS84 usage: Jon- you’re a politician right? I like your statement that “publishing in WGS84 will help people to integrate data with mass-market web mapping technologies”. Does anyone have a problem if I use this in place of the statement about WGS84 being most widely used.


Dealing with non-geographic coordinates (especially on other planetary bodies): we set out to cover “spatial data”. The reality is that we have had no support over the life of the working group to deal with anything other than _geo_spatial data (although we’ve recently added some bits about engineering CRS and relative positioning etc. - see Best Practice 9: Describe relative positioning [7]). So, we agreed (I think during the London F2F, Dec 2016) that non-geographic cases were sadly out of scope. This includes publishing data about things on other planets. That said, (1) it would be easy to add a comment in BP3 [5] indicating that when publishing data about other planets _of course_ WGS84 isn’t appropriate (but we wouldn’t go into details as to what _is_ appropriate), and (2) many of the best practices are still relevant.


I think I’ve captured all the concerns. Please tell me if I’ve missed anything?


If I can get consensus here, we’ll update the BP doc accordingly.


Jeremy



[1]: http://w3c.github.io/sdw/bp/#desc-accuracy

[2]: http://w3c.github.io/sdw/bp/#CRS-background

[3]: http://thetruesize.com/

[4]: http://edition.cnn.com/2016/08/18/africa/real-size-of-africa/

[5]: http://w3c.github.io/sdw/bp/#bp-crs-choice

[6]: http://w3c.github.io/sdw/bp/#bp-crs

[7]: http://w3c.github.io/sdw/bp/#relative-position

On Tue, 28 Mar 2017 at 11:21 Ed Parsons <eparsons@google.com<mailto:eparsons@google.com>> wrote:
cc'd to the lists

---------- Forwarded message ---------
From: Ed Parsons <eparsons@google.com<mailto:eparsons@google.com>>
Date: Tue, 28 Mar 2017 at 09:35
Subject: Re: CRS best practices: Google Geocoding API [SEC=UNCLASSIFIED]
To: Andy Mabbett <andy@pigsonthewing.org.uk<mailto:andy@pigsonthewing.org.uk>>


Hi Andy,

Your point re coordinate on other worlds is well made, I'm afraid we have had little input from experts in planetary science, would it be appropriate to say that largely best practice is to use the specific planetocentic coordinate systems  lat.long ?

Wikipedia is quite transparent i would say....

Ed


On Mon, 27 Mar 2017, 23:21 Andy Mabbett, <andy@pigsonthewing.org.uk<mailto:andy@pigsonthewing.org.uk>> wrote:
On 27 March 2017 at 11:54, Ed Parsons <eparsons@google.com<mailto:eparsons@google.com>> wrote:

> I would argue that much of the Geo expert community data published in CRS
> other than WGS84 is largely invisible on the web not accessible behind
> opaque service interfaces, so the claim that the vast majority of spatial
> data on the web is WGS84 holds true..

Returning to my point about coordinates on other globes (did anyone
see that? I've seen no responses), would you say those on Wikipedia
are "largely invisible on the web not accessible behind opaque service
interfaces"?

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

--

Ed Parsons FRGS
Geospatial Technologist, Google

+44 7825 382263<tel:07825%20382263> @edparsons
www.edparsons.com<http://www.edparsons.com/>

--

Ed Parsons FRGS
Geospatial Technologist, Google

+44 7825 382263<tel:+44%207825%20382263> @edparsons
www.edparsons.com<http://www.edparsons.com/>

This message contains information, which may be in confidence and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.

Received on Monday, 3 April 2017 14:02:55 UTC