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

Hello all,

Issue-76 was closed at the Lisbon F2F meeting. As a result, I have just
added a new requirement to the UCR doc: Multiple CRSs
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MultipleCRS>
.

Have a good day,
Frans

On 14 September 2016 at 08:03, Ed Parsons <eparsons@google.com> wrote:

> Hi Byron, Sure we have often used Starbucks publishing their store
> locations as a example, or the global location of fishing trawlers. We have
> also identified the organisers of a village fete building a website. Of
> course the emergency scenario used as the narrative of the BP provides many
> different personas...
>
> Ed
>
>
> On Tue, 13 Sep 2016 at 23:15 Byron Cochrane <bcochrane@linz.govt.nz>
> wrote:
>
>> Ed,
>>
>>
>>
>> If people you speak of capture their data in EPSG::4326 then there would
>> likely be no need for the publish in multiple CRS.  If they capture it in a
>> different CRS I would think it best practice to serve it in EPSG::4326 in
>> addition to the native CRS, would it not?  Otherwise the end user, say a
>> web developer who is likely to be less skilled in spatial operations than
>> the publisher, would need to reproject the data.  I thought we were trying
>> to avoid this requirement on the end user?
>>
>>
>>
>> Offering data in multiple projections can be done with a download service
>> rather than a WxS.  This is the case in the LINZ Data Service (although WxS
>> is available for many datasets as well.)
>>
>>
>>
>> Perhaps my confusion stems from an unclear view on just who the intended
>> audience is.  If you could draw me a better picture, a couple personas, of
>> who these non-experts wishing to publish spatial data are, it would be
>> helpful.
>>
>>
>>
>> Cheers,
>>
>> Byron
>>
>>
>>
>> *From:* Ed Parsons [mailto:eparsons@google.com]
>> *Sent:* Tuesday, 13 September 2016 7:02 p.m.
>> *To:* Rob Atkinson; Byron Cochrane; Frans Knibbe; Joshua Lieberman
>> *Cc:* SDW WG Public List
>>
>>
>> *Subject:* Re: UCR issue-76: a new requirement for multiple CRSs?
>>
>>
>>
>> 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
>>
> --
>
> *Ed Parsons *FRGS
> Geospatial Technologist, Google
>
> Google Voice +44 (0)20 7881 4501
> www.edparsons.com @edparsons
>