Cool I think you have found the heart of the problem :-)

We would like the encoder to pull out two values the geometry and the crs. 

Any way we can modify it to ignore GeometryAttribute and provide our own 
binding for GeometryAttribute?
Or pull out two values (the geometry and crs)?

If you have to as an quick hack you could stuff the crs into the geometry at 
this stage (but that is a little sad as the library would then be using 
Geometry user data for our own internal needs; and wrecking the value as passed 
into the encoder).

Jody

On 19/07/2010, at 8:09 PM, Rini Angreani wrote:

> 
> Hi Jody,
> 
> I think I understand the problem better now. 
> In GML2EncodingUtils.AbstractFeatureType_getProperties():
> 
>                    if (property instanceof ComplexAttribute) {
>                        // do not unpack complex attributes as these may
> have their own bindings, which
>                        // will be applied by the encoder
>                        value = property;
>                    } else {
>                        // non-complex bindings are unpacked as for simple
> feature case
>                        value = property.getValue();
>                    }
> 
> The value being passed to the binding is the property value (including
> geometries) unless it's a complex attribute, since it might have its own
> attributes from the schema.
> This makes sense to me, since srsName actually belongs to the geometry type
> (AbstractGeometryType) in the schema, it doesn't belong to the geometry
> attribute that holds it. 
> Therefore passing the geometry to the binding to extract the properties is
> correct.. and the only way to store CRS for Geometry objects is in the
> userData. This is based on my observation though, I might be wrong.  Perhaps
> someone can clarify?
> 
> 
> -- 
> View this message in context: 
> http://osgeo-org.1803224.n2.nabble.com/handling-of-geometry-crs-tp5300380p5311402.html
> Sent from the geotools-devel mailing list archive at Nabble.com.
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to