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

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