W3C home > Mailing lists > Public > public-sdw-wg@w3.org > September 2016

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

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Mon, 12 Sep 2016 15:23:31 +0200
Message-ID: <CAFVDz42G-8eErhxD0M_0SOgz3323G0cVZz95Hk3HaL-+By8Jkw@mail.gmail.com>
To: Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: Rob Atkinson <rob@metalinkage.com.au>, SDW WG Public List <public-sdw-wg@w3.org>
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.


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
Received on Monday, 12 September 2016 13:24:02 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:26 UTC