RE: UCR issue-76: a new requirement for multiple CRSs?

I do not see much of a problem of publishing in multiple projections.  Particularly if the choice is an option from the same dataservice.  There was a discussion awhile back that suggested that publishing in different CRS are analogous to publishing text in different languages.  I think this is a good analogy.  A similar approach can be used here.  It is worth noting that ISO 19115 supports the inclusion of multiple reference systems which means that one metadata record can support the multiple CRS versions of the same data.  Of course a service that provides this conversion, as Josh suggest, would even be better (note: this would not likely be a good option for raster data because of the heavy computation required).

The great value of supporting multiple projections in data you wish to publish is to allow a default WGS 84 version to be available.  Very often data is captured in a local preferred projected CRS.  This is because the purpose of the creation of these data is often done for the purpose of area or distance measurements, a task for which  geodetic coordinate values are not appropriate.  It is also because a great deal of data is captured from orthophoto imagery that is in a local projection for the same reason (note: because of the nature of raster orthoimagery, it must be stored in a projected CRS).

So sticking to Tufte’s 1st mandate of “First do no harm to the data”,  sharing the data in its native form, which will be compatible with other local data, is a good idea.  It is also a good idea to share the data in a default CRS by which it can be compared with other spatial data from any variety of sources - this is the most important value of WGS 84 (web Mercator, SRS 4326), in my opinion.  I could envision that there may be requirements to support additional projections for a variety of business reasons, but I am unsure how common this would be.

Web Mercator / WGS 84 as a default is good for allowing the comparison of data from disparate sources and it does a reasonable job of presenting data from the mid latitudes.  It is also relatively easy to convert WGS 84 geodetic coordinates to whatever projection you choose.  But it is pretty useless for any sort of measurement, not just precise ones.  I recently saw a news article that presented a map of the path planned for a cruise ship through the northwest passage above Canada.  Because this was a WGS 84 map the path appeared to be many times longer than in would actually be.  A polar projection would convey a much more accurate and meaningful view of the path to be taken.

The funny thing is that a knowledge of different CRS’s and their use is likely to be more useful to the webby wishing to use spatial data than it is to the majority of GIS professionals.  This is because the GIS professional usually works in only a couple of CRS’s appropriate to there area of interest.  A webby working with much more diverse data for a broader range of uses could have a greater need to understand the strengths and weaknesses of the CRS options available to support best use.  In the case of data journalism, the choice is often an aesthetic one of which best conveys the story they are trying to tell.  In font choice for the web there exist a dictum of never use Times New Roman.  For similar reasons I can easily envision that in the near future as the field matures there would be a similar one for web maps that says never use Web Mercator.  There is likely to be a choice that better conveys the message you are trying to get across.

So my recommendation would be that a data service offers data in a default CRS (EPSG::4326 for vector data, Web Mercator for raster data) and in the native CRS if different.  Support for additional CRS’s should be offered if needed.

Finally, I am not sure I understand the need for bounding boxes to be in multiple CRS.  I see these as typically stored in the metadata.  In the ISO 19115 standard they are stated as being Lat Long values without the need of CRS stated because precision of these values is not necessary.  Maybe I am missing something here.

Cheers,
Byron


From: Frans Knibbe [mailto:frans.knibbe@geodan.nl]
Sent: Tuesday, 13 September 2016 1:24 a.m.
To: Joshua Lieberman
Cc: Rob Atkinson; SDW WG Public List
Subject: Re: UCR issue-76: a new requirement for multiple CRSs?

Hello Josh,

Yes, publishing metadata related to geometry will be hard if geometric data are published with multiple CRSs. I think that counts as an argument for having the multiple CRSs BP requirement: Guidance is needed.

Looking ahead to possible best practices: probably some means of defining and identifying subsets in datasets is needed, and have metadata for the entire dataset next to metadata for a subset.

Greetings,
Frans




On 12 September 2016 at 14:52, Joshua Lieberman <jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>> wrote:
We did discuss this a few months ago in the context of multiple geometries per feature. I thought we agreed that having multiple CRS's and thus multiple coordinate strings and metadata values per geometry in addition to multiple geometries would be too complex. It would also make it more difficult to expose metadata such CRS, resolution, etc. from with geometry entities. The practice followed in most cases today is to have an interface, e.g. WFS, from which one requests a feature in the desired CRS. That feature representation then has geometry or geometries in one CRS. Given a first-class status for geometry, one could also find a feature on the Web and then request a geometry in the desired CRS. I don't see a great case for geometries floating around the Web carrying coordinate strings in multiple CRS's. The one case that is common is having 2 bounding boxes, one in the CRS of the geometry, and one in WGS84 to improve searching and indexing.

Josh
Joshua Lieberman, Ph.D.
Principal, Tumbling Walls Consultancy
Tel/Direct: +1 617-431-6431<tel:%2B1%20617-431-6431>
jlieberman@tumblingwalls.com<mailto:jlieberman@tumblingwalls.com>

On Sep 12, 2016, at 02:46, Rob Atkinson <rob@metalinkage.com.au<mailto:rob@metalinkage.com.au>> wrote:
Hi

I think it is an existing practice, but there may well be a range of possible implementations - and hence a best practice is relevant. Pretty much all requirements have some implementation examples or are "possible" so why would this particular one be not worth noting? Its certainly characteristic of spatial data. I would have thought the underlying value of a set of  Requirements is to make sure that we dont recommend oversimplifications that _stop_ things being possible, and the UC is a description of the context of such Requirements to make sure they are understood.  Conversely, requirements can make sure there are simplified default behaviours in a wealth of possibilities.

Rob

On Fri, 9 Sep 2016 at 22:05 Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:
Hello,

Discussion about UCR issue-70<https://www.w3.org/2015/spatial/track/issues/70> led to the idea that we might need an extra requirement for being able to work with geometry data with multiple CRSs. We can use this thread to discuss if that is a good idea. This new question is added to the tracker as issue-76<https://www.w3.org/2015/spatial/track/issues/76>.

Different CRSs serve different purposes, so making geometric data available with multiple CRSs is an existing practice. It seems to me that if such a practice is already possible and there are no problems, then there little need to make this an explicit requirement.

Are there examples where working with geometric data that have multiple CRSs is problematic? Such examples could work well to justify making this an explicit requirement. It could be that there are data formats or software that do not support the concept of a spatial thing being modelled by multiple geometries having different CRSs. In that case, it is really a problem that needs to be solved.

Anyway, please speak your mind.

Regards,
Frans


________________________________
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 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.