- From: Ed Parsons <eparsons@google.com>
- Date: Thu, 18 Feb 2016 14:56:31 +0000
- 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>
- Message-ID: <CAHrFjcnQU3nVchaTFUQ4rupPURbkOimLhGXjKyp+-OhmO3Uaew@mail.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