locationtech
[BUG] wrong number of decimals when WKTReader used with a PrecisionModel
There is one decimal less than expected in geometries coordinates when WKTReader is used with a PrecisionModel. For exemple this code:
GeometryFactory geofactory = new GeometryFactory(new PrecisionModel(10000000));
Point point1 = geofactory.createPoint(new Coordinate(0.39452545497198344d, 0));
Geometry point2 = new WKTReader(geofactory).read(point1.toString());
System.out.println("point1: "+point1);
System.out.println("point2: "+point2);
will produce the following output: point1: POINT (0.39452545 0) point2: POINT (0.3945255 0)
This bug causes many issues when writting in a postgis DB and reading back geometries for comparison for exemple...
What version of JTS are you using?
In the current code I get the following:
point1: POINT (0.39452545 0)
point2: POINT (0.3945255 0)
This is showing one more decimal place than necessary for the original point, since the computation of maximum significant figures has some slight leeway to ensure precision is maintained (see comment here). But it shows exactly the precision specified for the point that is read from the WKT.
Also, technically the original point is not being created to spec. When using a fixed precision model, created coordinates should have their ordinates rounded to that precision model (e.g using PrecisionModel.makePrecise). This is not done automatically because the coordinates may already be rounded and so it is more efficient to leave this to the caller. Usually not rounding doesn't cause many problems, but it looks like this is a case where it does.
In any case, using WKT for data transfer is always risky, due to potential loss of precision. This usually shows up when using full precision, but as you have found it can cause problems even in fixed-precision.
I am using the latest version of JTS (I edited my previous comment as it had an error on the reported output wich was for a different value of the PrecisionModel scale than the one in the code sample) You are right, the problem is more with the WKTWriter than the WKTReader. The number of decimals is supposed to be the log10 of the scale as stated here. So the documentation and the actual behaviour are not consistant. Anyway, If the WKTWriter is printing one more decimal than the one actually expected by the PrecisionModel scale, then the behaviour of the WKTReader should be consistant and it should also read and store that extra decimal. Having two different behaviours when writting and reading the same object is always a poor design and source of issues As for using WKT for data transfer, this is the de facto default format used by postgis hence its usage. But the issue would have been exactly the same whatever the format used. You can perfectly store as much decimals in WKT as the maximum precision allowed by the java double used to store jts geometries coordinates (so you can use WKT without any loss of precision if you want to. This is only because I am transforming and comparing geometries that I have to perform some rounding but it has no link with the format used to transfer data between my java program and my DB storage).
I am using the latest version of JTS (I edited my previous comment as it had an error on the reported output wich was for a different value of the PrecisionModel scale than the one in the code sample) You are right, the problem is more with the WKTWriter than the WKTReader. The number of decimals is supposed to be the log10 of the scale as stated here. So the documentation and the actual behaviour are not consistant.
Perhaps. But you are responsible for ensuring that created geometry has coordinates that match the PrecisionModel you specify. What happens if you do this?
Anyway, If the WKTWriter is printing one more decimal than the one actually expected by the PrecisionModel scale, then the behaviour of the WKTReader should be consistant and it should also read and store that extra decimal.
I disagree. The WKTReader is behaving according to spec. Possibly the WKTWriter is not.
As for using WKT for data transfer, this is the de facto default format used by postgis hence its usage.
Not so. In fact PostGIS prefers to use WKB format, to avoid precision loss. For example, the default output format is WKB; to get WKT you have to use ST_AsText.
You can perfectly store as much decimals in WKT as the maximum precision allowed by the java double used to store jts geometries coordinates (so you can use WKT without any loss of precision if you want to.
Well, it's not so easy to do that. That's why WKB is safer to use.
This is only because I am transforming and comparing geometries that I have to perform some rounding but it has no link with the format used to transfer data between my java program and my DB storage).
Then I'm unclear as to what the problem is? Is there some chain of operations which is not working in JTS?