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

Hi Linda, all,

Please see my comments inline...

2016-02-19 14:06 GMT+01:00 Linda van den Brink <l.vandenbrink@geonovum.nl>:

> Hi all,
>
>
>
> My 5 cents based on reading this discussion, thinking about it and
> discussing it with colleagues… (by the way, I’m still waiting to hear from
> the Dutch specialists on coordinate reference systems…)
>

Have the Dutch specialist spoken out? In a document by Dr. van der Marel of
the Delft University of Technology I read "The use of WGS84 should be
avoided for applications other than for hiking, regular navigation, and
other non-precision applications. The WGS84 is not suited for applications
requiring decimeter, centimeter or millimeter accuracy".

I think that data publishers should not make too many assumptions on how
their data will be used, which I think means they should be very cautious
in providing CRS84 data, or only CRS84 data.

>
>
> First of all, with the best practice in mind we want to base ourselves on
> practice, not on what we think is the best thing theoretically. We can’t
> ignore the widespread use of CRS84, somehow we have to address it. It’s
> proper and improper uses, you could say.
>

It is good of you to emphasize that our best practices should be based on
observations of practice, not on theory. But what if we observe that there
is a single practice, and it is not a very good one? Can we honestly
recommend that practice as a best practice?

>
>
> Secondly we need to think of our audiences. I agree with Jon here, it’s
> mainly web developers and data providers. I assume that the data providers
> of spatial data are professionals and they know about the existence of
> different CRS and which one is most appropriate for their data. So for them
> it is no problem to specify the correct CRS for their data.
>

Well, I consider myself a professional and I do have problems specifying or
even picking the correct CRS for web data.


> Web developers, on the other hand, may very well not even know that
> different CRS exist. We can’t burden them with having to understand all
> this. Probably IF they publish spatial data it will be in CRS84. I say let
> them have the convenience of a default CRS: If you don’t specify, it’s
> assumed to be CRS84. If you know it’s another CRS, you can specify.
>

I think that non-experts publish their data in CRS84, implicitly or
explicitly, just because it is the default CRS of the standards they use.
What those non-experts (and probably the developers of simple web standards
too) would like to express is that the coordinates are degrees of longitude
and latitude, nothing more. But currently there is no way of saying just
that. So CRS84 is used, and in many cases that introduces errors or
possibilities of misuse in the data.

>
> Imagine if we said you must always specify a CRS. What do we think web
> developers would do when they encounter a CRS reference in spatial data? I
> think most would probably ignore it anyway, not knowing what it is. So that
> does not solve anything anyway.
>

I think it would be good to have a default. But I doubt that that default
should be CRS84.

>
>
> Another thing is, in our testbed we have already found that complex geo
> features provided by base registries (ie authoritative data) are often very
> accurate – i.e. polygons with lots of coordinates. Especially when querying
> feature collections, this results in very large response payloads wasting
> bandwidth and causing slow response times. For web applications, these
> payload sizes are unacceptable and will cause applications to become slow
> or unresponsive. The testbed participants are suggesting that in many use
> cases, this level of precision and accuracy is unnecessary and they
> recommend simplification of the geometries. (see
> https://github.com/geo4web-testbed/topic3/wiki/Performance-%26-data-compactness
> for more detailed discussion)
>
>
>
> So if we need to simplify geometries for many use cases on the web anyway,
> it doesn’t matter in those cases if CRS84 is used instead of a more
> accurate CRS.
>

I am all for providing different generalization levels of geometries. But
should the original, most detailed geometry be hidden from the web because
there is no appropriate CRS to publish it with? Besides, the error
introduced by assigning CRS84 to a geometry increases with time, so it is
hard to say when coordinates are imprecise enough to warrant using CRS84.

>
>
> I think the best practice would be something along these lines:
>
> -          create and store the data with CRS84, or a more accurate and
> appropriate one given the location on earth;
>
> -          publish the data on the web using CRS84
>
> -          in case of big geometries, publish these in a simplified form;
>
> -          provide metadata stating the geometries are simplified
>
> -          provide an option to access the more accurate source data with
> the original CRS as well, for use cases where this is appropriate.
>
>
>
> With regard to use cases, I think a lot of the time the use case for
> spatial data on the web is really simple: answering questions like where is
> this, what is near me, how do I get there etc. For this, high accuracy is
> not necessary. But high accuracy is necessary when, for example, the
> question is: where exactly are the borders of my property (land parcel)?
>

Again this observation could be biased: perhaps we see mostly simple needs
and applications on the web. But is this because all needs are really
simple? Or is it because more sophisticated applications are not possible
yet because of limitations in data availability?

Regards,
Frans

>
>
> Linda
>
>
>
> *Van:* Jon Blower [mailto:j.d.blower@reading.ac.uk]
> *Verzonden:* vrijdag 19 februari 2016 13:24
> *Aan:* Frans Knibbe
> *CC:* Ed Parsons; SDW WG; Chris Little; Jeremy Tandy
> *Onderwerp:* Re: Chris Little's comments on the BP - Issues 128 and 204
>
>
>
> Hi Frans,
>
>
>
> (graceful handling of the 180º discontinuity). Do you think such a
> requirement should be included in the UCR document?
>
>
>
> Yes, possibly - it’s a tough question though that impacts on both data
> formats and APIs. It’s been a problem for a long time, but with no
> consistent solution identified.
>
>
>
> Polar science is another area where a cylindrical CRS is not ideal.
>
>
>
> But CRS84 is not cylindrical?
>
>
>
> Sorry yes, you’re right. I meant that typically when we plot CRS84 we use
> an equidistant cylindrical projection (or Mercator), both of which are bad
> options for polar data. There is also an issue of interpreting polygons
> that go around the poles and the 180/-180 discontinuity. A polar projection
> of some kind would usually be a better option for recording coordinates
> (the NSIDC in the US has some useful resources on this I think).
>
>
>
> Cheers,
>
> Jon
>
>
>
>
>
>
>
> On 19 Feb 2016, at 12:00, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
>
>
>
>
>
>
> 2016-02-18 9:20 GMT+01:00 Jon Blower <j.d.blower@reading.ac.uk>:
>
> Hi Ed, Frans, all,
>
>
>
> [snip]
>
>
>
> 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”).
>
>
>
> This is a remark I find interesting as a UCR editor, because it looks like
> a requirement for spatial data on the web (graceful handling of the 180º
> discontinuity). Do you think such a requirement should be included in the
> UCR document?
>
>
>
> Polar science is another area where a cylindrical CRS is not ideal.
>
>
>
> But CRS84 is not cylindrical?
>
> Could polar science have specific requirements that should be recorded in
> the UCR document?
>
>
>
> Greetings,
>
> Frans
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>