Re: Chris Little's comments on the BP - Issues 128 and 204

2016-02-18 10:05 GMT+01:00 Ed Parsons <eparsons@google.com>:

> Yes, I agree Chris, this is an artifact of the mass-market and
> professional communities having different needs.
>

It may be true that both have different needs, but I don't think the
prevelance of CRS84 is entirely based on needs. CRS84 achieved critical
mass on the web. This has probably because GPS was (and still is) the
dominant GNSS. And now people are more or less forced to use CRS84, because
it is the only CRS that is effectively supported by many standards and
products like GeoJSON or Leaflet. Even GeoSPARQL favours CRS84. So even if
you don't want to use CRS84 because it does not meet requirements, people
still use it anyway because circumstances force it.

I think the prevalance of CRS84 shows that there is a need for a simple
global CRS that uses longitude, latitude. I don't think that automatically
means that we should say that CRS84 is that CRS.

An aside: I do wonder how popular CRS84 is in countries where other GNSSs
are popular, like Russia or China. I guess this also touches upon a related
matter: do we want to present best practices to the entire world or just
the 'western' world?


>
> Almost without exception when you discover geospatial content in use on
> the web or on mobile you will be encountering data in CRS84, Google, Apple,
> Uber, Microsoft, OSM etc and products which embed these mapping platforms
> are using CRS84 despite some of the issues you quite correctly point out. I
> guess as long as you don't expect to take a uber across the international
> date line you will be OK, but seriously for most of these applications the
> limitations are just not relevant.
>

A point that I would like to make is that for current (monolithic)
applications the limitations may not be relevant, but in a global,
interoperable and durable web of data they could be.

Greetings,
Frans



>
> Ed
>
>
> On Thu, 18 Feb 2016 at 08:20 Jon Blower <j.d.blower@reading.ac.uk> wrote:
>
>> Hi Ed, Frans, all,
>>
>> I can see both sides of this. This email exchange highlights the
>> difference between the “average” spatial data on the web consumer and the
>> needs of the professional who wants to make better use of the web.
>>
>> I wonder if it’s worth teasing out some use cases where CRS84 is
>> generally considered adequate and some cases where it is not? In my own use
>> cases, CRS84 is usually fine (exact positional accuracy is often the least
>> of our worries!) but I’m sure there are many cases where it is considered
>> bad practice. IT would be useful to quantify the (horizontal and vertical)
>> positional inaccuracy that can result from use of CRS84, to help users
>> judge whether they can tolerate it.
>>
>> One constant area of pain is the discontinuity at 180 degrees. Services
>> and software are very inconsistent about how they handle data that span
>> this discontinuity. Many people (particularly those interested in the
>> Pacific Ocean!) have expressed a need for a CRS where the discontinuity is
>> defined elsewhere (or one in which the longitude axis values are explicitly
>> allowed to “wrap”).
>>
>> Polar science is another area where a cylindrical CRS is not ideal.
>>
>> Cheers,
>> Jon
>>
>>
>>
>>
>>
>> On 17 Feb 2016, at 14:44, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>>
>> Hello Ed,
>>
>> Basing requirements on what we observe on the web today could be risky.
>> I hope that with the Best Practices we can lay the foundations of a better,
>> more interoperable and more robust web in the future. Some things I think
>> we should consider in this case are:
>>
>>    - I believe the lack of a generally usable CRS impedes publication of
>>    professional geographical data. And there are other reasons why data
>>    providers need (our) best practices before publication of spatial data on
>>    the web becomes a viable option. So I think the 99% is a skewed proportion:
>>    Relatively simple, amateuristic data are easy to publish and use on
>>    the web nowadays. That could be the reason for seeing so much of it. For
>>    professional, serious data it is another matter.
>>    - Current provisioning of data in many cases may be on the web but is
>>    still monolithic in design: one database for one application. The idea of
>>    putting data on the web for everyone to use as they seem fit requires a
>>    higher level of data quality, among which is using a CRS that is not
>>    only usable for a specficic application.
>>    - Current provisioning of data on the web often does not consider
>>    durability of data. With an ever increasing coordinate error, using CRS84
>>    does not fit well with the idea of providing long lasting data.
>>    - A good generally usable CRS does not necessarily have to be
>>    something more complex than WGS84/CRS84. It could be something simpler.
>>
>> Regards,
>> Frans
>>
>> 2016-02-17 15:06 GMT+01:00 Ed Parsons <eparsons@google.com>:
>>
>>> No I disagree... For the vast majority of the current uses of spatial
>>> data on the web WGS84 is used without problem, as the GIS/Geospatial
>>> community we have still not accepted that we are the minority, the people
>>> with very specific use cases.. For 99% of the potential uses of spatial
>>> data on the web today WGS84 is fine.
>>>
>>> Ed
>>>
>>>
>>> On Wed, 17 Feb 2016 at 13:18 Frans Knibbe <frans.knibbe@geodan.nl>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> About the phrase " For the majority of applications a common global
>>>> CRS (WGS84) is fine": If we say it like that, it seems we are saying
>>>> that it is OK to use WGS84 as a default CRS. I think that would be the
>>>> wrong message. I think it should be only used in some very specific cases:
>>>> in which spatial resolution is higher than meter level and data are usable
>>>> for a limited time. For other cases, WGS84 or CRS84 should not be
>>>> recommended. In my mind, a best practice would be to *not* use
>>>> WGS84/CRS84 *unless* you are certain the data have a sufficiently low
>>>> spatial resolution and temporal validity.
>>>>
>>>> I think a general good practice for data publishing is not to make too
>>>> many assumptions on how data will be used (applications). Some applications
>>>> will not be hurt by wrongfully using WGS84, but you can not be sure that
>>>> other types of data usage will not suffer.
>>>>
>>>> In sessions last week, I have seen examples of geomerty encodings that
>>>> were all wrong. In combination with CRS84 extremely high coordinate
>>>> precisions were used and no temporal metadata were present. Lots of
>>>> antipatterns!
>>>>
>>>> Regards,
>>>> Frans
>>>>
>>>>
>>>>
>>>> 2016-01-14 18:55 GMT+01:00 Jeremy Tandy <jeremy.tandy@gmail.com>:
>>>>
>>>>> Thanks Chris - I've incorporated your suggestions in the Editors Draft
>>>>> and added your comments to the respective issues.
>>>>>
>>>>> Jeremy
>>>>>
>>>>> On Thu, 14 Jan 2016 at 16:20 Little, Chris <
>>>>> chris.little@metoffice.gov.uk> wrote:
>>>>>
>>>>>> Jeremy,
>>>>>>
>>>>>>
>>>>>>
>>>>>> A little late for the BPFPWD, but some text to address issues 128 and
>>>>>> 204. In American English.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>> Why
>>>>>>
>>>>>> The choice of CRS is sensitive to the intended domain of application
>>>>>> for the geospatial data. For the majority of applications a common global
>>>>>> CRS (WGS84) is fine, but high precision applications (such as precision
>>>>>> agriculture, digging holes in roads and defence) require spatial
>>>>>> referencing to be accurate to a few meters or even centimeters.
>>>>>>
>>>>>> One aspect is the confusion of precision and accuracy. Seven decimal
>>>>>> places of a latitude degree corresponds to about one centimeter. Whatever
>>>>>> the precision of the specified coordinates, the accuracy of positioning on
>>>>>> the actual earth's surface using WGS84 will only approach about a metre
>>>>>> horizontally and may have apparent errors of up to 100 metres vertically,
>>>>>> because of assumptions about reference systems, tectonic plate movements
>>>>>> and which definition of the earth's 'surface' is used.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Issue 128
>>>>>>
>>>>>> Add explanation of why there are so many CRSs.
>>>>>>
>>>>>> For example, North America and Europe are receding from each other by
>>>>>> a couple of centimeters per year, whereas Australia is moving several
>>>>>> centimeters per year north-eastwards. So, for better than one meter
>>>>>> accuracy in Europe, the European Terrestrial Reference System 1989 (ETRS89)
>>>>>> was devised and it is fixed with respect to the European tectonic plate.
>>>>>> Consequently, coordinates in the ETRS89 system will change by a couple of
>>>>>> centimetres per year with respect to WGS84.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Issue 204
>>>>>>
>>>>>> Need to clarify when and why people use different CRS's
>>>>>>
>>>>>> Even if a CRS, tied to a tectonic plate, is used, local coordinates
>>>>>> in some areas may still change over time, if the plate is rotating with
>>>>>> respect to the rest of the earth. Many existing useful maps pre-date GPS
>>>>>> and WGS84 based mapping, so that location errors of tens of metres, or
>>>>>> more, may exist when compared to the same location derived from a different
>>>>>> technology, and these errors may vary in size across the extent of a single
>>>>>> map.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Note
>>>>>>
>>>>>> The misuse of spatial data, because of confusion about the CRS, can
>>>>>> result in catastrophic results; e.g. both the bombing of the Chinese
>>>>>> Embassy in Belgrade during the Balkan conflict and fatal incidents along
>>>>>> the East Timor border are generally attributed to spatial referencing
>>>>>> problems.
>>>>>>
>>>>>> Intended Outcome
>>>>>>
>>>>>> A Coordinate Reference System (CRS) sensitive to the intended domain
>>>>>> of application (e.g. high precision applications) for the geospatial data
>>>>>> should be chosen.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> --
>>>
>>> *Ed Parsons*
>>> Geospatial Technologist, Google
>>>
>>> Google Voice +44 (0)20 7881 4501
>>> www.edparsons.com @edparsons
>>>
>>
>>
>> --
>
> *Ed Parsons*
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com @edparsons
>