On 20/07/2010, at 6:50 PM, <[email protected]> <[email protected]> wrote:
> 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 :( Okay so we are at least talking at the right level now correct? We are focused on GeometryAttribute and not just on the JTS Geometry objects. Right; this is something that we would use when creating a new GeometryAttribute. Usually we just copy the attribute values when creating a new feature. When reprojecting a feature we need to copy the attribute values; unless it is a Geometry Attribute. When creating a new GeometryAttribute we need to: a) use JTS utility class to transform the coordinates of the origional Geometry; and then construct a new Geometry with the copy b) when creating new GeometryAttribute we use our new Geometry; and the target CRS The idea is that both the inputs and the outputs need to meet the same contract: a GeometryAttribute with a value of JTS Geometry and a coordinate reference system matching the one declared by their feature type. I kind of suspect that for simple feature content the CRS is not even stored in the GeometryAttribute but is instead lookup as part of the FeatureType definition? > 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 think that has already been done when the target feature type was defined. > 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(): This is what is in question; is GeometryAttribute.getDescriptor() implemented as ... return crs; // ie an instance variable return (CoordinateReferenceSystem) geometry.getUserData(); // ie an assumption return descriptor.getCoordianteReferenceSystem(); // ie immutable only returning the declared CRS with no chance of override) > 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. I think you are confusing the origional feature type with the target feature type you are constructing. When we are creating a GeometryAttribute for our newly feature we are creating against the target feature type that has the correct CRS declared. > 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) This is not desired; the work was already done when the target feature type was created. > - my original changes in ReprojectFeatureReader to take the reprojected CRS > to pass to the transformer. This was only required to set the user data. > - changes in the encoder side to rely on the GeometryAttribute CRS instead of > the userData. Yes this is the goal. > All these things made my original patch looks simple :) Shall we just stick > with it? I think we need an IRC session; as we are starting to lose the forest for the trees. Jody ------------------------------------------------------------------------------ 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
