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

Another +1 to Jon's comment from me.

Some additional remarks:

   - It would be good to be very conscious of when to use either the term
   'spatial data' or the term 'geographical data' in the document. For the
   geographically orientated (all of us in the group?) the concepts may mean
   the same, for others they could not. Objectively, geographical data is a
   (small?) subset of spatial data.
   - The majority of geographical data I work with does not use WGS84, but
   a national grid that uses flat plane coordinates in metres. It's very
   practical for many types of usage.
   - Geographers in Europe are encouraged/obliged to use ETRS89 for
   spherical geographical coordinates, not WGS84.
   - If we somehow advise the use of WGS84 in certain circumstances (I
   think it serves wel as an additional convenience CRS next to an original
   CRS), people should also be made aware of its limitations. For example,
   that using WGS84 for high precision data requires temporal data next to the
   spatial data.

Greetings,
Frans


On 27 March 2017 at 12:10, <Simon.Cox@csiro.au> wrote:

> What Jon says.
>
> +1
>
>
>
> *From:* Jon Blower [mailto:j.d.blower@reading.ac.uk]
> *Sent:* Monday, 27 March, 2017 20:03
> *To:* Ed Parsons <eparsons@google.com>; Bruce Bannerman <
> bruce.bannerman@bom.gov.au>; Jeremy Tandy <jeremy.tandy@gmail.com>; Byron
> Cochrane <bcochrane@linz.govt.nz>; SDW WG Public List <
> public-sdw-wg@w3.org>
>
> *Subject:* Re: CRS best practices: Google Geocoding API [SEC=UNCLASSIFIED]
>
>
>
> Hi all,
>
>
>
> I think this debate shows we need to be careful about we phrase our key
> recommendations. I would agree with Bruce that the statement:
>
>
>
> *“(WGS 84) Coordinate Reference System is used in almost all cases where
> spatial data is published on the Web”*
>
>
>
> is overly strong and invites controversy unnecessarily. (How do we measure
> “almost all cases” anyway – by data storage? By data transferred? By number
> of “hits”? By number of datasets? They would all likely give different
> answers.) There are huge volumes of satellite imagery freely available on
> the web that are not published in WGS84, although equally they are not
> aimed at a typical “Google Maps” user. Then there are huge archives of
> weather, climate and astronomical data, all of which are spatial, and are
> not usually WGS84 either. Google Maps (and Bing, etc) have huge numbers of
> users/hits, but that doesn’t mean that they represent “almost all cases” of
> data *publication*.
>
>
>
> I think we’ve had this debate before, but I’d be more comfortable with
> statements like:
>
>
>
> “WGS84 is the most common CRS in mass-market spatial applications such as
> X, Y and Z. Publication of data in this CRS will make it easier to reach a
> wide audience of non-specialists, but publishers must be aware of the
> implications of doing so [for applications in which high accuracy is
> required].”
>
>
>
> It would also be helpful to point to some good references where
> non-specialist can learn about the issues surrounding CRSs (Perhaps we are
> doing that already?)
>
>
>
> We must be very careful to distinguish cases in which we are giving advice
> with a view to *widening the audience for spatial data*, and cases in
> which we are giving advice to spatial professionals who want to use the Web
> to *share data with each other*.
>
>
>
> All the best,
>
> Jon
>
>
>
>
>
>
>
> *From: *Ed Parsons <eparsons@google.com>
> *Date: *Monday, 27 March 2017 08:56
> *To: *Bruce Bannerman <bruce.bannerman@bom.gov.au>, Jeremy Tandy <
> jeremy.tandy@gmail.com>, Byron Cochrane <bcochrane@linz.govt.nz>, SDW WG
> Public List <public-sdw-wg@w3.org>
> *Subject: *Re: CRS best practices: Google Geocoding API [SEC=UNCLASSIFIED]
> *Resent-From: *<public-sdw-wg@w3.org>
> *Resent-Date: *Monday, 27 March 2017 08:57
>
>
>
> Hi Bruce,
>
>
>
> I think we are just going to disagree re the context of the document, to
> use your medical analogy we are aiming to produce the equivalent of your
> local pharmacy, not the university teaching hospital.
>
>
>
> My point re the Google products was not a flippant one, you could of
> course include BIng, OpenStreetMap, Facebook, Twitter, Flickr, Whatsap,
> Apple Maps, iMessage -the users of which all produce and consume spatial
> data represented using WGS84.  We are now clearly in the age where the
> majority of spatial data on the web is not produced by experts alone.
>
>
>
> Of course there are datasets and applications that use local projected CRS
> of the web, but compared to these consumer services I would imagine they
> represent a very small proportion... Of course I may be completely wrong
> and I'd be interested in your counter argument of this point ?
>
>
>
> Ed
>
>
>
>
>
>
>
> On Sun, 26 Mar 2017 at 23:08 Bruce Bannerman <bruce.bannerman@bom.gov.au>
> wrote:
>
> Hi Ed,
>
>
>
> Thanks for your comments.
>
>
>
> I do understand the context of this document.
>
>
>
> There are many sites with similar goals of making complex domains *
> *appear** simple, e.g. self help medical diagnosis, and do it yourself
> building renovation.
>
>
>
> Neither approach will help the user if they mis-diagnose a terminal
> illness, or remove a load bearing wall in ignorance.
>
>
>
> There is a time and a place for professional advice and we should not
> trivialise it.
>
>
>
> By all means, make the document as easy to use as possible, but do not
> trivialise these types of spatial issues and add the appropriate warning to
> seek professional advice.
>
>
>
>
>
> Regarding your second point regarding Google Earth/Maps:
>
>    - These numbers are truely impressive. Well done to Google.
>    - However, there is a vast difference between the number of users of a
>    product, and the amount of spatial data on the web. I stand by my comments.
>
>
>
> Kind regards,
>
>
>
> Bruce
>
>
>
>
>
> *From: *Ed Parsons <eparsons@google.com>
> *Date: *Friday, 24 March 2017 at 19:08
> *To: *Bruce Bannerman <bruce.bannerman@bom.gov.au>, Jeremy Tandy <
> jeremy.tandy@gmail.com>, Byron Cochrane <bcochrane@linz.govt.nz>, SDW WG
> Public List <public-sdw-wg@w3.org>
> *Subject: *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
>
> *Error! Filename not specified.*
> twitter: @semanticfire
> tel. +31(0)6-53182997 <+31%206%2053182997>
> Netage B.V.
> http://netage.nl
> Esdoornstraat 3
> 3461ER Linschoten
> The Netherlands
> *Error! Filename not specified.*
>
>
>
> 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 <07825%20382263> @edparsons
> www.edparsons.com
>
> --
>
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> +44 7825 382263 <+44%207825%20382263> @edparsons
> www.edparsons.com
>