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

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

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Mon, 12 Sep 2016 21:59:44 +0000
Message-ID: <CACfF9Ly42DsHS1BjLt8z-XbQy-ukanCcYDrNpPCEX2BfRY6Jgw@mail.gmail.com>
To: Frans Knibbe <frans.knibbe@geodan.nl>, Joshua Lieberman <jlieberman@tumblingwalls.com>
Cc: Rob Atkinson <rob@metalinkage.com.au>, SDW WG Public List <public-sdw-wg@w3.org>
I think the requirement actually points to the need to separate out
identity and representation.... each representation can easily have a
single geometry and implicit metadata. If we say the object has a geometry
it just falls apart again.  Imho the redirect implementation pattern
separates identity and  representation.

So how do we keep the UCR part of that clean of implementation details?
The  wording "should be possible"  doesnt do too bad a job

Its easily met by BP patterns and illustrates the inherent weakness of
conflating a url access to a representation with an identity.

On Mon, 12 Sep 2016, 11:23 PM Frans Knibbe <frans.knibbe@geodan.nl> wrote:

> 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
>>>
>>
>
Received on Monday, 12 September 2016 22:00:30 UTC

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