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