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

Just one comment, Jeremy.

Please be careful with terminology when discussing map projections in the document. Let me use an example:

"OSGB 1936 / British National Grid" (in EPSG: 27700) is a CRS, a projected CRS. It is not a map projection. A projected CRS is defined as a "coordinate reference system derived from a two-dimensional geodetic coordinate reference system by applying a map projection".

In this case the "two-dimensional geodetic coordinate reference system" is "OSGB 1936" (in EPSG: 4277) and the "map projection" is "Transverse Mercator" with a number of parameters (latitude_of_origin, central_meridian, scale_factor, false_easting, false_northing). A map projection is defined as a "coordinate conversion from an ellipsoidal coordinate system to a plane".

The definitions are from ISO 19111, but this is also consistent with the current definition for CRS in the BP glossary ("A coordinate-based local, regional or global system used to locate geographical entities.").

Likewise, "Web Mercator" (in EPSG: 3857, with the name "WGS 84 / Pseudo-Mercator") is a projected CRS, not a map projection.

Sorry if this sounds pedantic, but while we do not need to - and should not - discuss all this in the document we still should be consistent in the use of terms where we have existing definitions.

Clemens


On 30. Mar 2017, at 11:12, Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>> wrote:

Thanks Jon.

> except perhaps for the bit where you call me a politician

Ha! I meant only in the way that you've found good words to describe the point :-)

Regarding the conflation of CRS and Projection, I could try to update BP3 with something like what you suggested in your email text.

Before I make any changes, can the rest of the participants in this email thread confirm they're happy with my summary proposal & the minor amendment suggested here.

Jeremy

On Thu, 30 Mar 2017 at 09:59 Jon Blower <j.d.blower@reading.ac.uk<mailto:j.d.blower@reading.ac.uk>> wrote:

Hi Jeremy, Ed, all,



Firstly (responding to Ed’s request), I’m more than happy to join a meeting in which we discuss this stuff, if we can schedule a specific agenda item. (It’s hard in general for me to make the meetings but if there’s a slot scheduled I can make some time.)



Secondly, thanks very much Jeremy for this very helpful summary and for bringing us back to the BPs. I’m happy with your suggestions, (except perhaps for the bit where you call me a politician… ;-)



We might be causing ourselves some confusion by conflating coordinate reference systems with map projections (I do this all the time and I really shouldn’t). A map must have a projection, but CRSs are relevant even when we don’t have a map. In most web mapping systems, for instance, the underlying map projection is Web Mercator, but points are specified in WGS84 coordinates. The user (usually) doesn’t care, because the platform transparently lines everything up.



This highlights that the reasons for selecting a particular map projection (for images) might be different from the reasons for selecting a CRS (for expressing and geolocating points), even within the same application. I’m not sure what the implications of this are for our work, but I thought I’d highlight it.



Cheers,
Jon









From: Jeremy Tandy <jeremy.tandy@gmail.com<mailto:jeremy.tandy@gmail.com>>
Date: Tuesday, 28 March 2017 18:02
To: Ed Parsons <eparsons@google.com<mailto:eparsons@google.com>>, SDW WG Public List <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>, "sdwwg@lists.opengeospatial.org<mailto:sdwwg@lists.opengeospatial.org>" <SDWWG@lists.opengeospatial.org<mailto:SDWWG@lists.opengeospatial.org>>

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

Resent-From: <public-sdw-wg@w3.org<mailto:public-sdw-wg@w3.org>>
Resent-Date: Tuesday, 28 March 2017 18:03



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