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

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