I may have another answer to your question (since the X and Y co-ordinates
were just swapped).
Here are the docs:
* http://docs.geotools.org/latest/userguide/library/referencing/order.html
TLDR: Scientists and Sailors measure location lat/lon order based on more
accurate measurement first. Computer scientists use lon/lat order (since it
is similar to x/y order they are comfortable with).
This is a problem with our industry (rather than simply geotools) and uDig
makes use of the global setting described in the above docs.
Jody Garnett
On Wed, Aug 20, 2014 at 2:06 AM, mroguski <mrogu...@megabit.com.pl> wrote:
> 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
>
------------------------------------------------------------------------------
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
