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