Re: [Geotools-devel] handling of geometry crs

[Jody G. <jod...@gm...>]

Not sure that will work (leaving it to us) keep the conversation going. Reni what are you expecting the output to be like?
Are you expecting an srsName on everything?

My understanding of gml is that the srsName can be done somewhere earlier (say at the feature collection level), and only needs to be included as an override. I am not sure we would promote a MultiPolygon with each member having a different CRS as a good idea.

Are you sure this is something to worry about in practice?

Jody


On 29/07/2010, at 7:58 PM, <Rin...@cs...> <Rin...@cs...> wrote:

> You're right, I've seen the inconsistencies with userData used as a Map, and otherwise in different places.
> Anyway, I tried my idea for the simple fix, but it won't work, since it requires more changes in different bindings all over the place.
> The "fix" in  GML2EncodingUtils I suggested would only fix the top level attribute, i.e.:
> 
> <gml:MultiPolygon srsDimension="2" srsName="http://www.opengis.net/gml/srs/epsg.xml#3395">
> <gml:polygonMember>
> <gml:Polygon>
> <gml:exterior>
> <gml:LinearRing>
> <gml:posList>-222638.98158654713 664677.8261092183 111319.49079327357 664677.8261092183 111319.49079327357 331876.5342131213 -222638.98158654713 331876.5342131213 -222638.98158654713 664677.8261092183</gml:posList>
> </gml:LinearRing>
> </gml:exterior>
> </gml:Polygon>
> </gml:polygonMember>
> </gml:MultiPolygon> 
> 
> Polygon and LinearRing didn't get their srsName encoded since they didn't go through GML2EncodingUtils. 
> I'll leave this one to you guys to fix properly :)
> 
> Cheers
> Rini
> 
> -----Original Message-----
> From: Justin Deoliveira [mailto:jde...@op...] 
> Sent: Wednesday, 28 July 2010 12:07 AM
> To: Andrea Aime
> Cc: Angreani, Rini (CESRE, Kensington); jod...@gm...; geo...@li...
> Subject: Re: [Geotools-devel] handling of geometry crs
> 
> On 10-07-27 3:25 AM, Andrea Aime wrote:
>> Rin...@cs... wrote:
>>> Hi Justin,
>>> 
>>> I like your second idea, and it is actually similar to the patch Jody
>>> whipped up
>>> (http://jira.codehaus.org/secure/attachment/50280/GML2EncodingUtils.patch).
>>> 
>>> Since AbstractFeatureTypeBinding.getProperties() eventually calls
>>> GML2EncodingUtils.getProperties() anyway, we can make the changes
>>> there again. So, instead of checking for GeometryAttribute only, it
>>> also checks if value is a Geometry, and get the SRS from the type.
>>> What's wrong with using userData though?
>> 
>> For starters, it is a convention that was made up without discussing it.
>> It's not part of the GeoTools API, as a result only the bits that
>> were hand hacked to support it make the srs be encoded in GML.
>> To actually support it properly we'd have to modify all data stores
>> and all collection wrappers, and document that it needs to be supported
>> too.
>> 
>> As a second problem, it creates information redundance, which is
>> generally considered bad in IT circles because of extra storage
>> (not a problem in this case) and because of potential inconsistencies
>> between the various copy (the userdata could state a CRS other
>> than the attribute)
>> 
>> There is one case in which it cannot be avoided, which is, if an
>> attribute has no defined srs and all geometries can have their
>> own. Which seems pretty silly to me, won't be supported by most
>> storage formats, but unfortunately I fear it's also a case tested
>> by the WFS cite tests...
>> 
>> Btw, having a single default SRS can be limiting, a feature type
>> can legitimately have multiple columns in different srs.
>> That is something supported by spatial databases for example.
>> It's also a bit of a narrow use case though.
>> 
> 
> Agree with what Andrea said and there is the issue of the encoder 
> changing objects it does not own, which is bad practice as well. And 
> what do you do in the case of userdata already being set?
> 
> Anywas, it would work for now and is probably the simplest solution at 
> this point so I would probably push for that.
>> Cheers
>> Andrea
> 
> 
> -- 
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.