W3C home > Mailing lists > Public > public-sdw-wg@w3.org > February 2016

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

From: Ed Parsons <eparsons@google.com>
Date: Thu, 18 Feb 2016 14:56:31 +0000
Message-ID: <CAHrFjcnQU3nVchaTFUQ4rupPURbkOimLhGXjKyp+-OhmO3Uaew@mail.gmail.com>
To: George Percivall <gpercivall@opengeospatial.org>
Cc: Jon Blower <j.d.blower@reading.ac.uk>, Frans Knibbe <frans.knibbe@geodan.nl>, SDW WG <public-sdw-wg@w3.org>, Chris Little <chris.little@metoffice.gov.uk>, Jeremy Tandy <jeremy.tandy@gmail.com>
I do accept there are exceptions... what is your estimate of the % of
spatial data on the web that is not CRS84 ?

Ed


On Thu, 18 Feb 2016 at 13:23 George Percivall <gpercivall@opengeospatial.org>
wrote:

> Ed,
>
> I agree that mass-market and professional communities have different
> needs.  Jon’s suggestion for use cases to show that difference is a good
> one.
>
> I disagree with this statement:
>
> Almost without exception when you discover geospatial content in use on
> the web or on mobile you will be encountering data in CRS84,
>
>
> There are many professional use cases that run on the web and mobile.
>
> George
>
>
>
>
>
> On Feb 18, 2016, at 4:05 AM, Ed Parsons <eparsons@google.com> wrote:
>
> Yes, I agree Chris, this is an artifact of the mass-market and
> professional communities having different needs.
>
> 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.
>
> 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
>
>
> --

*Ed Parsons*
Geospatial Technologist, Google

Google Voice +44 (0)20 7881 4501
www.edparsons.com @edparsons
Received on Thursday, 18 February 2016 14:57:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:20 UTC