No worries; I thought of a simpler fix that may work out for all concerned.
In GML2EncodingUtils add ..
else if( propety instanceof GeoemtryAttribute ){
Geometry geometry = (Geometry) property.getValue();
CoordinateReferenceSystem crs =
geoemtry.getDescriptor().getCoordianteReferenceSystem();
geometry.setUserData( crs );
value = geometry;
}
This would be the minimal that would ensure the encoder always has the
correct CRS from the feature model; it is still a bit of a hack, and
would clobber any values the user had stored in the geometry.
We can update the javadoc for that encoder method (that the user data
needs to be a CRS).
The other option is to make the decision up front that the CRS should
be stored in geometry user data. In which case we have 36 cases in the
library to check and make consistent.
Jody
On Wed, Jul 21, 2010 at 11:05 PM, <[email protected]> wrote:
> Hi Jody,
>
> Ah, I see how the CRS gets updated in the geometry attribute now.
> However, for complex features, it doesn't even go through
> ReprojectingFeatureCollection, that's why the schema doesn't get recreated
> with the new CRS.
>
> My stack trace starts from ContentFeatureCollection, then
> ContentFeatureSource(line 499):
>
> if ( !canReproject() ) {
> if (query.getCoordinateSystemReproject() != null) {
> try {
> reader = new ReprojectFeatureReader(reader,
> query.getCoordinateSystemReproject());
> } catch (Exception e) {
> if(e instanceof IOException)
> throw (IOException) e;
> else
> throw (IOException) new IOException("Error occurred
> trying to reproject data").initCause(e);
> }
> }
> }
>
> It creates ReprojectFeatureReader, which creates the transformer without
> touching the schema.
>
> The code that assumes userData as CRS is in
> GeometryCoordinateSequenceTransformer.transform(Geometry) line 138:
>
> if (crs != null) {
> transformed.setUserData(crs);
> }
>
> My original patch actually checked if it's a map or not, to be consistent
> with GML2EncodingUtils. I removed it though, as from my observation when
> stepping through the code, it's never a map?
>
> Original patch included GeometryCoordinateSequenceTransformer (that is
> commented out below):
>
> if ((g.getUserData() == null) || g.getUserData() instanceof
> CoordinateReferenceSystem) {
> //set the new one to be the target crs
> if (crs != null) {
> transformed.setUserData(crs);
> }
> // } else if (g.getUserData() instanceof Map) {
> // Map userData = (Map)g.getUserData();
> // userData.put(CoordinateReferenceSystem.class, crs);
> }
>
> It's then called in GML2EncodingUtils which traces back to
> AbstractGeometryTypeBinding.getProperty(), like you said.
>
> Hmm.. maybe the problem is that it should always use
> ReprojectFeatureCollection?
>
> I'll write a separate email to Justin re: the binding, since I'm not sure how
> to do it correctly.
> Thanks for all your help so far.
>
> Cheers
> Rini
>
>
>
>
>
> ________________________________________
> From: Jody Garnett [[email protected]]
> Sent: Wednesday, 21 July 2010 9:03 AM
> To: Angreani, Rini (CESRE, Kensington)
> Cc: [email protected]
> Subject: Re: [Geotools-devel] handling of geometry crs
>
> Reni here is the code that creates the target feature type ...
>
> public ReprojectingFeatureCollection(
> SimpleFeatureCollection delegate,
> CoordinateReferenceSystem source,
> CoordinateReferenceSystem target) {
> ..
> SimpleFeatureType schema = delegate.getSchema();
> this.schema = reType(schema, target);
> ...
> }
>
> So schema will always have the correct coordinate reference system at
> the end of the day ... ReprojectingFeatureCollection is written
> correctly.
>
> So the question for me is what code is making use of the assumption
> that Geometry.getUserData() is a coordiante reference system...
>
> SQLServerDialect.decodeGeometryEnvelope(ResultSet, int, Connection)
>
> GMLComplexTypes: <--- this is probably where you are having trouble
> Reni? I actually looks like this code assumes use data is a String (ie
> srsName)
> - encode(Element, GeometryCollection, PrintHandler)
> - encode(Element, LineString, PrintHandler)
> - encode(Element, MultiLineString, PrintHandler)
> - encode(Element, MultiPoint, PrintHandler)
> - encode(Element, MultiPolygon, PrintHandler)
> - encode(Element, Object, PrintHandler, Map)
> - encode(Element, Object, PrintHandler, Map)
> - encode(Element, Point, PrintHandler)
> - encode(Element, Polygon, PrintHandler)
>
> GML2EncodingUtils: // seems to check for an instanceof
> CoordianteReferenceSystem or a Map? This in conflict with
> GMLComplexTypes above that expects a String.
> - getCRS(Geometry) // so this traces back to
> GMLAbstractGeometryCollectionBaseTypeBinding and
> AbstractGeometryTypeBinding being written against a value rather then
> an attribute
>
> JDBCFeatureReader:
> - next(); // this is putting the CoordinateReferenceSystem into the geometry
>
> Etc...
>
> So as you can see we are using Geometry userData where we should be
> using GeometryAttribute.getDescriptor().getCoordianteReferenceSystem().
>
> Indeed user data is used for:
> - String
> - CoordianteReferenceSystem
> - java.util.Map
> - Integer
> - other (provided by client code)
>
> So we need a decision on what to do - which is why we are on the devel
> list and not commenting on your bug report. Next step is to describe
> some options to clean this up and ask the devel list what to do if we
> cannot sort out something clean and consistent.
>
> 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
