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

Hi Rob,

I was just trying to make sure we won't dilute the UCR document with
requirements that already have been met. For example. being able to store
spatial data on a hard disk is a requirement, but there is little sense in
making that an explicit requirement. But what you say is true: Even if
something is not too hard to do, but can be done in different ways there
still is a need for guidance.

I notice that the Dutch Base Registry use case
<http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#DutchBaseRegistry>
is
very much about this requirement, so I don't think we will need more use
cases in the UCR document to support this requirement.

Regards,
Frans





On 12 September 2016 at 08: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
>>
>