Re: CRS best practices: Google Geocoding API

+1


On Fri, 3 Mar 2017 at 16:47 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

> Ok, turning up the gas…
>
> Simple as possible but not simpler: there are widespread practices on the
> Web that are simply not best practices. Not documenting CRS and presuming
> that long-lat can be treated as cartesian are indeed widespread practices
> and some of the time the perpetrators are bailed out by fuzzy use cases and
> software that takes care of projections. We may not be able to prevent this
> practice, but we should point out that CRS / coordinate order ambiguity
> leads sooner or later to serious and avoidable errors, while ignorance of
> geoids and map projections leads to broken applications. These practices
> will also become less and less tenable as new applications such as AR
> require higher data precision and accuracy. So I hope that we can advise
> that 1) it’s best to document the CRS / coordinate order and 2) long-lat
> may be fine for data exchange but it’s best to understand that
> transformation somewhere is usually involved for either display or
> computation.
>
> …back to simmer.
>
> —Josh
>
> On Mar 3, 2017, at 11:21 AM, Jeremy Tandy <jeremy.tandy@gmail.com> wrote:
>
> 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
>
>
>