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

I dont think this is a huge problem - anyone in that situation should just
be using "truth in advertising" - letting people know what they are using -
e.g. a GPS coordinate. The BP should just give a workable default. Most
people with point data will be covered by a sensible bottom line.  People
with more complex geometries are more likely to have some sort of service -
unless they have drawn something on a map and we can ask them to identify
that map!





On Tue, 13 Sep 2016 at 17:02 Ed Parsons <eparsons@google.com> wrote:

> Sorry to sound like a broken record, remember the intending audience here
> are mostly non experts who...
>
>
>    - Are unlikely to have datasets with multiple geometry representations
>    - Are unlikely to have the capability to reproject data to different
>    CRS
>    - Are actually unlikely to have access to a WxS capable of offering
>    multiple endpoints
>
>
> Of course existing SDI publishers the other smaller audience for the BP
> may need to do these things, and here the requirement is to document what
> they are doing using the appropriate metadata which they are very good a
> doing usually ! - My point is which should not set such a high bar in the
> BP to publish spatial data.
>
> Ed
>
>
>
> On Tue, 13 Sep 2016 at 02:24 Rob Atkinson <rob@metalinkage.com.au> wrote:
>
>>
>> And to close the loop - if we take the existence of services offering
>> multiple representations as an underlying requirement (and by implication
>> the ability to reference these), then its a Best Practice (not a
>> requirement) to offer the native highest-fidelity data _and_ WGS84, _and_
>> probably any other form suited for the intended use of that data - such as
>> a local project supporting distance or area measurements .  The
>> requirements are
>>
>> 1) it is possible to refer to representations of an object provided by
>> multiple services or parameterised service calls
>> 2) it is possible to represent spatial aspects of a thing in multiple CRS
>>
>> and whilst 1 automatically satisfies 2, but is only an implementation
>> choice, so we need both requirements IMHO.
>>
>> Rob
>>
>>
>> On Tue, 13 Sep 2016 at 08:48 Byron Cochrane <bcochrane@linz.govt.nz>
>> wrote:
>>
>>> 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> 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
>>>
>>> jlieberman@tumblingwalls.com
>>>
>>>
>>> On Sep 12, 2016, at 02:46, Rob Atkinson <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> 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.
>>>
>> --
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com @edparsons
>