W3C home > Mailing lists > Public > public-sdw-wg@w3.org > March 2017

Re: CRS best practices: Google Geocoding API

From: Jeremy Tandy <jeremy.tandy@gmail.com>
Date: Tue, 07 Mar 2017 17:40:29 +0000
Message-ID: <CADtUq_37hRu0e9WGaKH1jHcEW2u9Oz+YTZ6ghp_wYkCg10ovng@mail.gmail.com>
To: Byron Cochrane <bcochrane@linz.govt.nz>, SDW WG Public List <public-sdw-wg@w3.org>
Hi Byron. Thanks for this feedback. I completely agree :)

Hopefully BP17 [1] is clear on this now - see the note at the top of the
"Possible Approach" section.

Jeremy

[1]: http://w3c.github.io/sdw/bp/#bp-crs

On Tue, 7 Mar 2017 at 00:31 Byron Cochrane <bcochrane@linz.govt.nz> wrote:

> A BBQ! I got to get in on this . . .
>
>
>
> First off, I feel a bit uncomfortable to say “then [it's safe to] assume”
> .  Because it often isn’t as I think is Bart’s point.  Something more along
> the line of “best guess is” is better.  Then emphasize that best practice
> is that CRS with lat/long (or coordinate) order and units of measurement
> needs to be clearly stated.
>
>
>
> I want to second everything Josh stated.  I would hope that the point of
> Best Practices is to raise the bar (within reasonable  limits) and not
> stamp current common practice as best practice.  The fact that most current
> web developers only care about lat/long does not mean this is right and
> best.  It is in IMHO the main issue, in this BP, that needs to be
> addressed.  Part of the problem is that most of the general public,
> including developers, have popularly come to view the 2D Mercator view of
> the world as true when in fact it is a hugely distorted one.  Some basic
> knowledge about CRS is advantageous to data providers and web developers in
> order to encourage better use of spatial data.
>
>
>
> This is not at all to say that only geo professionals are qualified to use
> spatial data.  Basic knowledge is within reach of anyone.  I hope we
> provide some in the SDWBP.  If we also provide pointers as to where to
> learn more, all the better.  This leads to more capable developers being
> able to create more useful and user friendly products.  There are always
> tradeoffs when selecting a CRS.  That is the basic message I wish to convey
> to the more general developers, even if we only do that in a cursory way.
>
>
>
> Cheers,
>
> Byron
>
>
>
>
>
> *From:* Jeremy Tandy [mailto:jeremy.tandy@gmail.com]
> *Sent:* Saturday, 4 March 2017 6:19 a.m.
> *To:* Bart van Leeuwen
> *Cc:* Ed Parsons; SDW WG Public List
>
>
> *Subject:* Re: CRS best practices: Google Geocoding API
>
>
>
> To be fair, the Google Geocoding API (which was where I started) uses
> latitude and longitude - so at least it's obvious that the coordinate
> position is some form angular measurement for anywhere on the Earth.
>
>
> Jeremy
>
> On Fri, 3 Mar 2017 at 17:14, Bart van Leeuwen <bart_van_leeuwen@netage.nl>
> wrote:
>
> The problem with this definition is that the term "world view" is rather
> ambiguous.
> I know a lot of Dutch public servants in geospatial related fields who's
> world view is no bigger then the 300x300km dutch CRS.
> They assume the RD CRS as their "world view" making all wgs84 ( especially
> the negative numbers ) utterly confusing.
>
> As much as I understand that the 'world view' of web developers is WGS84
> assuming it for our audience might actually turn up the heat :)
>
> My 2 cents.
>
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen
>
>
> twitter: @semanticfire
> tel. +31(0)6-53182997 <+31%206%2053182997>
> Netage B.V.
> http://netage.nl
> Esdoornstraat 3
> 3461ER Linschoten
> The Netherlands
>
>
>
>
> From:        Jeremy Tandy <jeremy.tandy@gmail.com>
> To:        Ed Parsons <eparsons@google.com>, SDW WG Public List <
> public-sdw-wg@w3.org>
> Date:        03-03-2017 17:22
> Subject:        Re: CRS best practices: Google Geocoding API
> ------------------------------
>
>
>
>
> Fair enough.
>
> I suppose that if we write stuff in the BP document like this, we're
> documenting what is actually happening.
>
> There's a risk that we end up encouraging people to be lazy and not bother
> to think about CRS. But then, if they're in the <*rest of the world view
> "that I just need to use Lat & Long - Period :-)"*>TM then they will
> probably not even have considered that this is an issue in the first place.
> At least this advice is consistent with geospatial data collected from the
> vast majority of [consumer] devices on the planet - because they're using
> GPS.
>
> Jeremy
>
> On Fri, 3 Mar 2017 at 16:16 Ed Parsons <eparsons@google.com> wrote:
> I think the first part is OK, the vertical datum part is less common and
> as a result it's more difficult to make a similar assumption.
>
> Ed
>
>
> On Fri, 3 Mar 2017 at 16:11 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> Hmmm.
>
> schema.org documents go to the trouble of saying "WGS 84" (although they
> don't describe the units either).
>
> So (as much as most of the Geo-establishment will flame me for it) should
> we be saying:
>
> "If neither your data nor the specification to which your data conforms to
> defines the coordinate reference system used, then [it's safe to] assume
> that the data with coordinate pairs uses longitude and latitude, defined in
> decimal degrees, and data with coordinate positions that have three values
> is longitude, latitude and elevation, defined in decimal degrees, decimal
> degrees and meters above sea-level. In both cases, the WGS 84 [geodetic]
> datum is assumed."
>
> Let the barbecue begin.
>
> Jeremy
>
>
> On Fri, 3 Mar 2017 at 16:02 Ed Parsons <eparsons@google.com> wrote:
> I think you are experiencing the rest of the world view "that I just need
> to use Lat & Long - Period :-)"
>
> The use of WGS84 is documented here
> https://developers.google.com/maps/documentation/javascript/maptypes if
> you go looking for it, must I would argue that most mainstream web
> developers don't need to know..
>
> btw this is also quite a nice explanation of tile based spatial indices
> ;-)
>
> Ed
>
>
>
> On Fri, 3 Mar 2017 at 15:14 Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
> Hi Ed- in the introductory material you wrote about CRS you make a
> reference to the Google Geocoding API [1], in that its responses explicitly
> state Lat and Long rather than a coordinate pair of ambiguous order.
>
> Lat and Long are, by definition, angular measurements. OK - got that.
>
> But parsing through the API documentation, I can't see any reference to
> the units or datum which is used.
>
> Being a human, I'm prepared to guess that these are decimal degrees
> (because they look like floating point numbers). Easy for machines to
> figure that out too.
>
> As a human, I'm also prepared to guess that the API uses the WGS84. But
> that is a tricky leap for machines to work out.
>
> Does the API documentation say "WGS84" anywhere? If so, can you point me
> to it so I can refer to this explicitly? And if not, can you either justify
> why it doesn't matter, or get your colleagues to update the documentation
> (and then send me a link!).
>
> (I think that we've all agreed that it's dangerous to _assume_ a CRS :-) )
>
> Thanks, Jeremy
>
> [1]: https://developers.google.com/maps/documentation/geocoding/intro
> --
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com @edparsons
>
> --
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com @edparsons
>
>
> ------------------------------
> This message contains information, which may be in confidence and may be
> subject to legal privilege. If you are not the intended recipient, you must
> not peruse, use, disseminate, distribute or copy this message. If you have
> received this message in error, please notify us immediately (Phone 0800
> 665 463 or info@linz.govt.nz) and destroy the original message. LINZ
> accepts no responsibility for changes to this email, or for any
> attachments, after its transmission from LINZ. Thank You.
>
Received on Tuesday, 7 March 2017 17:41:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 March 2017 17:41:13 UTC