OK I found a workaround for the problem.

I wrote a simple method that projects the data from the CRS they are really
in, into the CRS defined by the EPSG code.

Here it is:

public void reproject(DataStore dataStore, String sourceName,
CoordinateReferenceSystem currentCRS, CoordinateReferenceSystem targetCRS)
throws IOException {
        SimpleFeatureSource sfs = dataStore.getFeatureSource(sourceName);
        SimpleFeatureType schema = sfs.getSchema();
        
        Transaction transaction = new DefaultTransaction("reproject");
        try {
            MathTransform transform = CRS.findMathTransform(currentCRS,
targetCRS, true);
            FeatureWriter<SimpleFeatureType, SimpleFeature> writer =
dataStore.getFeatureWriter(schema.getTypeName(), transaction);
            int i=0;
            while(writer.hasNext()) {
                System.out.println(i++ + ". ================");
                SimpleFeature feature = writer.next();
                Geometry geometry = (Geometry) feature.getDefaultGeometry();
                System.out.println(geometry);
                geometry = JTS.transform(geometry, transform);
                System.out.println(geometry);
                feature.setDefaultGeometry(geometry);
                writer.write();
            }
            writer.close();
            transaction.commit();
        } catch(IOException | FactoryException |
MismatchedDimensionException | TransformException e) {
            e.printStackTrace();
            transaction.rollback();
        }
    }

The arguments are as follows:
dataStore - the connection to postgis and oraclespatial
sourceName - the layer name that will be projected
currentCRS - the CRS that data geometry is stored in
targetCRS - the CRS the geometries will transform into

What I have noticed is that the transformation simply changed the order of X
and Y coordinates.
An example is here:
MULTILINESTRING ((6438680.67 6038236.779999999, 6438682.31 6038237.07,
6438682.78 6038236.880000001, 6438683.83 6038236.050000001))
MULTILINESTRING ((6038236.779999999 6438680.67, 6038237.07 6438682.31,
6038236.880000001 6438682.78, 6038236.050000001 6438683.83))

The first geometry was before the projection.

I think that geotools team should take a look at my example, because
something wrong is going on around those CRS definitions or their
transformations.
My udig uses geotools 9.0 and as I said before - the data looked fine there.

Best regards and thanks for help :)



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Problem-with-reference-systems-transformations-tp5156398p5157261.html
Sent from the geotools-gt2-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to