Re: CRS best practices: Google Geocoding API

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