Hi Jody,
I thought of creating my own binding as well, etc. After playing around with
this today, and came up with a dodgy patch on the binding side, I realised we
still need my original patch anyway (and more). I tried it on my test and it
doesn't work :(
The problem is the JTS tranformer (GeometryCoordinateSequenceTransformer) only
transforms the coordinates of the Geometry object.
We have no access to the GeometryAttribute at that point, so we can't update
the CRS (which comes from the type anyway, so I don't think we can update it
even if we have access to it?). I think that's why it was only updating
Geometry userData at the first place.
I can change the transformer so it takes GeometryAttribute as a parameter
instead of Geometry though, but that would mean more changes.
GeometryAttribute.getDescriptor() ->
GeometryDescriptor.getCoordinateReferenceSystem():
public CoordinateReferenceSystem getCoordinateReferenceSystem() {
return getType().getCoordinateReferenceSystem();
}
The type would've gotten the CRS from the database, i.e. the original CRS, and
it wouldn't be updated with the reprojected CRS.
Even if we can update this, this means we need:
- changes in GeometryCoordinateSequenceTransformer.transform() to update the
geometry attribute CRS (which is probably not possible)
- my original changes in ReprojectFeatureReader to take the reprojected CRS to
pass to the transformer.
- changes in the encoder side to rely on the GeometryAttribute CRS instead of
the userData.
All these things made my original patch looks simple :) Shall we just stick
with it?
Thanks
Rini
-----Original Message-----
From: Jody Garnett [mailto:[email protected]]
Sent: Monday, 19 July 2010 7:32 PM
To: Angreani, Rini (CESRE, Kensington)
Cc: [email protected]
Subject: Re: [Geotools-devel] handling of geometry crs
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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
