Hi Andrea, finally I found out what went wrong:
GeoTools picks up the most accurate one from the EPSG database – but in this case, the most accurate was not the one which is valid for the whole area. You can get an overview on https://epsg.io/31467 3.0 m accuracy is for the whole area, 2.0 m accuracy is only valid for the eastern part of Germany. Geotools picks the 2.0 m accuracy. As you write, this is a consistent behavior and without other parameters it is acceptable and in most cases a good choice. But I found out that the TOWGS84 parameters in the WKT seems to be completely ignored, even if I set up the WKT explicitly with these parameters in the target CRS. Is this by design - perhaps only for the other direction (as the name implies: TO WGS84)? My workaround was to set up and use my own MathTransform: DefaultMathTransformFactory factory = new DefaultMathTransformFactory(); MathTransform transform = factory.createFromWKT("CONCAT_MT[PARAM_MT[\"Ellipsoid_To_Geocentric\", \n" + " PARAMETER[\"dim\", 2], \n" + " PARAMETER[\"semi_major\", 6378137.0], \n" + " PARAMETER[\"semi_minor\", 6356752.314245179]], \n" + " PARAM_MT[\"Position Vector transformation (geog2D domain)\", \n" + " PARAMETER[\"dx\", -598.1], \n" + " PARAMETER[\"dy\", -73.7], \n" + " PARAMETER[\"dz\", -418.2], \n" + " PARAMETER[\"ex\", -0.202], \n" + " PARAMETER[\"ey\", -0.045], \n" + " PARAMETER[\"ez\", 2.455], \n" + " PARAMETER[\"ppm\", -6.7]], \n" + " PARAM_MT[\"Geocentric_To_Ellipsoid\", \n" + " PARAMETER[\"dim\", 2], \n" + " PARAMETER[\"semi_major\", 6377397.155], \n" + " PARAMETER[\"semi_minor\", 6356078.962818189]], \n" + " PARAM_MT[\"Transverse_Mercator\", \n" + " PARAMETER[\"semi_major\", 6377397.155], \n" + " PARAMETER[\"semi_minor\", 6356078.962818189], \n" + " PARAMETER[\"central_meridian\", 9.0], \n" + " PARAMETER[\"latitude_of_origin\", 0.0], \n" + " PARAMETER[\"scale_factor\", 1.0], \n" + " PARAMETER[\"false_easting\", 3500000.0], \n" + " PARAMETER[\"false_northing\", 0.0]]]"); This worked finally. Captivated by this topic, I tried another transformation using a grid shift file (here: BETA2007.gsb) , because it was described as the most accurate one (1 m accuracy). It worked with CRS.findMathTransform(...), but finding out where the grid shift file has to be located was a challenge - I found the solution in a 5 year old email in a mailing list archive. The gsb file resource has to be located in org.geotools.referencing.factory.gridshift! I think this should be better documented, perhaps in the FAQ, userguide or Javadoc. Kind regards, Jessica From: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] On Behalf Of Andrea Aime Sent: Monday, February 19, 2018 4:18 PM To: Alten, Jessica-Aileen <jessica-aileen.al...@liag-hannover.de> Cc: geotools-gt2-users@lists.sourceforge.net Subject: Re: [Geotools-gt2-users] Coordinate transformation - can I trust the results of geotools? Hi, I looked at this mail a few times but I'm not sure what to answer. The library is work well enough for us right now, and we haven't had particular complaints about accuracy. Often meters of error are related to usage of a sub-optimal set of Bursa-Wolf parameters (the EPSG database has several, region based, but GeoTools can only use one, and picks the most accurate one, favoring the largest area in case there are multiple). Also, the EPSG database in use is outdated, but we failed so far to find sponsoring for an upgrade (it's more than just a DB upgrade, requires reviewing the changesets, eventually updating parameter names, datum aliases for ESRI compability, dumping it in WKT for the epsg-wkt module, and so on). Of course, it could also be numerical issues in the current code... If you are interested in contributing code improvements we have a page here: http://docs.geotools.org/latest/developer/procedures/contribute.html It's also possible to have others verify the code and improve it for you, see this page (valid also for GeoTools): http://geoserver.org/support/ Cheers Andrea On Thu, Feb 8, 2018 at 3:07 PM, Alten, Jessica-Aileen <jessica-aileen.al...@liag-hannover.de> wrote: Hi all, I have a problem with coordinate transformation results (EPSG:4326 to EPSG:31467) - geotools (18.2) results in northing deviates from most results of other transformation libraries I tried by around 1-2 meters. I.e. https://epsg.io/transform#s_srs=4326&t_srs=31467&x=9.0000000&y=50.0000000 . I know the results are quite accurate and for maps sufficient enough, but the results of other libraries (gdal, a homegrown library and others) are more closely spaced, geotools deviates "systematically". For a quick check you can try it with lon 9° lat 50°. Can anybody explain this difference and give some clues what can be done? No, gt-epsg-wkt is not in the classpath and I am aware of numerical accuracy and different more or less precise calculation methods. Regards, Jessica Here is what I tried: import com.vividsolutions.jts.geom.Coordinate; import org.geotools.geometry.jts.JTS; import org.geotools.referencing.CRS; import org.opengis.referencing.FactoryException; import org.opengis.referencing.crs.CoordinateReferenceSystem; import org.opengis.referencing.operation.MathTransform; import org.opengis.referencing.operation.TransformException; public class Test4 { final MathTransform transform; public Test4() throws FactoryException { CoordinateReferenceSystem geographic = CRS.decode("EPSG:4326"); CoordinateReferenceSystem projected = CRS.decode("EPSG:31467"); transform = CRS.findMathTransform(geographic, projected, false); System.out.println( "geographic: " + CRS.getAxisOrder(geographic) + " projected: " + CRS.getAxisOrder(projected) + " " + transform.getClass().getCanonicalName()); } public Coordinate transform(Coordinate coordinate) throws TransformException { return JTS.transform(coordinate, null, transform); } public static void main(String[] args) throws FactoryException, TransformException { double[] xComponent = {50.0, 49.31697225, 48.01593456, 53.56584087, 49.46711705, 49.46359125, 49.46790631, 49.47109095, 49.45559285, 49.47497621, 52.17121958, 49.27232523, 49.40419504, 49.39821486, 49.16149286, 49.15742017, 49.11177234, 49.11076685, 49.47711921, 49.47908686, 49.2772704}; double[] yComponent = {9.0, 8.51894939, 9.47737743, 9.82497393, 7.63700611, 7.64303598, 7.65064303, 7.65386702, 7.64339468, 7.6400998, 10.63546034, 7.59703019, 7.67746683, 7.68134721, 7.61524541, 7.62056884, 7.72511502, 7.72363407, 8.14619403, 8.16198793, 7.90487983}; Test4 transformer = new Test4(); for (int i = 0; i < xComponent.length; i++) { Coordinate point = transformer.transform(new Coordinate(xComponent[i], yComponent[i])); System.out.println( xComponent[i] + " \t" + yComponent[i] + " \t" + point.y + " \t" + point.x + " \t" + Math.round(point.y) + " \t" + Math.round(point.x)); } } } ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it AVVERTENZE AI SENSI DEL D.Lgs. 196/2003 Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003. The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
