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
>>
>