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

@ByronCinNZ : I've updated BP13 (dataset metadata) to indicate that
geometries used in spatial metadata should use WGS 84. See PR 787 [1] for
details. Jeremy

[1]: https://github.com/w3c/sdw/pull/787

On Wed, 3 May 2017 at 22:49 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:

> Hi - I've attempted to incorporate the gist of discussion in an update to
> the BP document; see PR 786 [1] for details.
>
> Jeremy
>
> [1]: https://github.com/w3c/sdw/pull/786
>
> On Thu, 6 Apr 2017 at 11:21 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
>> Thanks again. I'll revert that commit then. Cheers. Jeremy
>>
>> On Thu, 6 Apr 2017 at 11:14 Clemens Portele <
>> portele@interactive-instruments.de> wrote:
>>
>>> Hi Jeremy,
>>>
>>> you could have left the two cases of "map projection" (which is a term
>>> defined in ISO 19111, "projection" is not) as they were since they were
>>> using the term properly, i.e. they were not used as a synonym for
>>> "projected CRS", but were refering to coordinate conversions from a
>>> geodetic CRS to a projected CRS.
>>>
>>> Thanks,
>>> Clemens
>>>
>>>
>>> On 6. Apr 2017, at 05:52, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>>>
>>> Hi Clemens - just a quick aside in this bigger thread ...
>>>
>>> I've removed the two references to "map projections" (this is included
>>> in PR 666 [1], the last commit) - instead just using the term
>>> "projections". Also, both EPSG:27700 and EPSG:3857 these are referred to as
>>> a projected CRS.
>>>
>>> Can you confirm that my terminology is now correct - or else point
>>> directly to the changes that need to be made.
>>>
>>> Thanks, Jeremy
>>>
>>> [1]: https://github.com/w3c/sdw/pull/666
>>>
>>> On Thu, 30 Mar 2017 at 11:37 Clemens Portele <
>>> portele@interactive-instruments.de> wrote:
>>>
>>> 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> 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>
>>> 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>
>>> *Date: *Tuesday, 28 March 2017 18:02
>>> *To: *Ed Parsons <eparsons@google.com>, SDW WG Public List <
>>> public-sdw-wg@w3.org>, "sdwwg@lists.opengeospatial.org" <
>>> SDWWG@lists.opengeospatial.org>
>>>
>>>
>>> *Subject: *Re: CRS best practices: Google Geocoding API
>>> [SEC=UNCLASSIFIED]
>>>
>>> *Resent-From: *<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> wrote:
>>>
>>> cc'd to the lists
>>>
>>> ---------- Forwarded message ---------
>>> From: Ed Parsons <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>
>>>
>>>
>>>
>>> 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>
>>> wrote:
>>>
>>> On 27 March 2017 at 11:54, Ed Parsons <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 <07825%20382263> @edparsons
>>> www.edparsons.com
>>>
>>> --
>>>
>>>
>>> *Ed Parsons *FRGS
>>> Geospatial Technologist, Google
>>>
>>> +44 7825 382263 <+44%207825%20382263> @edparsons
>>> www.edparsons.com
>>>
>>>
>>>
>>>