Re: CRS best practices: Google Geocoding API

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 <mailto: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 <mailto:jeremy.tandy@gmail.com>> wrote:
> Hmmm.
> 
> schema.org <http://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 <mailto: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 <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 <mailto: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 <https://developers.google.com/maps/documentation/geocoding/intro> 
> -- 
> Ed Parsons FRGS
> Geospatial Technologist, Google
> 
> Google Voice +44 (0)20 7881 4501 <tel:%2B44%20%280%2920%207881%204501>
> www.edparsons.com <http://www.edparsons.com/> @edparsons
> 
> -- 
> Ed Parsons FRGS
> Geospatial Technologist, Google
> 
> Google Voice +44 (0)20 7881 4501 <tel:%2B44%20%280%2920%207881%204501>
> www.edparsons.com <http://www.edparsons.com/> @edparsons
>