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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
