Re: CRS best practices: Google Geocoding API [SEC=UNCLASSIFIED]

Hello Bruce,

Thanks for your comments, I will leave it to Jeremy to directly respond to
your points, however I would restate the context of this document... It is
aimed at non-specialist users who are looking to simply publish data about
locations on the web, we want to avoid the exact situation you suggest that
expert advice is needed each time to you need to  publish spatial data,
sounds like we need to further simplify and clarify...

One billion users of Google Maps and another billion users of Google Earth
would I suggest indicate that  WGS84 is the most used CRS ?

Ed


On Fri, 24 Mar 2017 at 06:10 Bruce Bannerman <bruce.bannerman@bom.gov.au>
wrote:

> Hi Jeremy,
>
> I was going to let this pass by to the keeper, having raised it many times
> before (and not wanting to join your BBQ  ;-)  ).
>
> I am slowly working through the latest Best Practice as I get time. The BP
> has come a long way and there is certainly some good work it it.
>
>
> However, I’m very uncomfortable with aspects of the current approach in
> the Best Practice regarding CRS and SRS in particular.
>
> Some comments:
>
>
>    - First para: *"you can express a location to within a few metres”*.
>    This statement ignores issues of precision and accuracy [1]. You can be as
>    precise as you like, but that does not make your data accurate. In relation
>    to the quoted text from the first paragraph, a precise coordinate
>    that purports to be within a few meters due to it’s coordinate precision
>    may in fact be inaccurate and perhaps kilometres away from that location.
>
>
>    - Second para: There is more to a SRS that a way of defining a set of
>    coordinates. We need to cover the mathematical representation of the area
>    covered by the SRS (the ellipsoid), the choice of projection to represent
>    ellipsoidal data within a two dimensional space, together with the
>    compromises that this brings to the data in representation of area, shape,
>    distance, bearing, scale, direction, etc.
>
>
>    - I note the statement *“(WGS 84) Coordinate Reference System is used
>    in almost all **cases where spatial data is published on the Web”*. I
>    find this statement dangerous and very difficult to believe!  Can the
>    author of the statement please cite the relevant studies that support this
>    claim?
>
>
>    - There may be serious implications for either using an incorrect SRS,
>    or assuming an incorrect SRS.   Spatial data is typically used to underpin
>    a wide range of decision making activities. Some of these decisions may
>    have significant consequences to people, property and life. As an example
>    of some of the potential impact of incorrectly combining data after
>    ignoring SRS issues, please see some example diagrams referred to below:
>
>
>    - [2] image to illustrate differences in Australian SRS (ellipsoids
>       and datums) - GDA94 and AGD66
>       - [3] image to illustrate differences in SRS (projections) -
>       Lambert Conformal Conic and UTM MGA Zone 50
>       - [4] image to illustrate differences in SRS (projections) -
>       Lambert Conformal Conic and VicGrid94
>       - [5] image to illustrate differences in SRS (ellipsoids, datum and
>       projections) - Lambert Conformal Conic and World Mercator
>
>
>    - As you will see from the diagrams, if someone is combining data from
>    different SRS, without accounting for the differences between those SRS,
>    then the results of an analysis in support of a decision making process,
>    together with that decision may well be flawed with potential consequences.
>
>
>    - Spatial professionals undertake substantial tertiary study and on
>    the job work experience in order to understand their profession. We cannot
>    expect that any lay person will be able to just pick it up e.g. By .reading
>    this BP.
>
>
>    - I suggest that a valuable piece of advice for the BP is to advise
>    readers to understand that there may be a limit to their understanding of
>    specific issues and to seek professional advice where appropriate. SRS may
>    be one such issue.
>
>
>    - I may have more comments on CRS and the BP, provided that I can get
>    suitable time to continue my review.
>
>
> Keep up the good work on this.
>
> Kind regards,
>
> Bruce
>
>
> [1]
> http://2.bp.blogspot.com/-s6ypcjPzxF0/UyaU9mOg6-I/AAAAAAAAAxs/MEU1FcozbZ0/s1600/accuracy+vs+precision.jpg
>
> [2] https://wiswiki.wmo.int/tiki-download_file.php?fileId=3465
>
> [3] https://wiswiki.wmo.int/tiki-download_file.php?fileId=3467
>
> [4] https://wiswiki.wmo.int/tiki-download_file.php?fileId=3468
>
> [5] https://wiswiki.wmo.int/tiki-download_file.php?fileId=3466
>
>
>
>
> From: Jeremy Tandy <jeremy.tandy@gmail.com>
> Date: Wednesday, 8 March 2017 at 04:40
> To: Byron Cochrane <bcochrane@linz.govt.nz>, SDW WG Public List <
> public-sdw-wg@w3.org>
> Subject: Re: CRS best practices: Google Geocoding API
> Resent-From: <public-sdw-wg@w3.org>
> Resent-Date: Wednesday, 8 March 2017 at 04:41
>
> 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 <%2B44%20%280%2920%207881%204501>
> www.edparsons.com @edparsons
>
> --
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501 <%2B44%20%280%2920%207881%204501>
> 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 <0800%20665463> 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.
>
> --


*Ed Parsons *FRGS
Geospatial Technologist, Google

+44 7825 382263 @edparsons
www.edparsons.com