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,

From: andrea.a...@gmail.com [mailto:andrea.a...@gmail.com] On Behalf Of Andrea 
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?

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: 
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/


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.


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);
                "geographic: " + CRS.getAxisOrder(geographic) + " projected:
" + CRS.getAxisOrder(projected) + " " +

    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,
                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,
                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]));

                    xComponent[i] + " \t" + yComponent[i] + " \t" + point.y
+ " \t" + point.x + " \t" + Math.round(point.y) + " \t" +

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

Andrea Aime
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V 
for more information.

Ing. Andrea Aime 
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

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.

Attachment: 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

Reply via email to