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

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