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