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

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