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

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
>