GeoLatte / geolatte-geom

A geometry model that conforms to the OGC Simple Features for SQL specification.
Other
132 stars 63 forks source link

Incompatibility between geolatte-geom 1.6.0 and jts-core 1.17.0 #111

Closed arcolf closed 3 years ago

arcolf commented 3 years ago

On 2. July 2020 JTS released the version 1.17.0 of the module jts-core. This version is automatically pulled in by geolatte-geom 1.6.0 (and at least 1.5.0) due to the usage of the version range [1.16.0,) in pom.xml.

Unfortunately there seems to be an incompatible change in JTS 1.17.0 which causes an exception in geolatte-geom 1.6.0. The following code

GeometryFactory geoFactory = new GeometryFactory();

LinearRing extRing = geoFactory.createLinearRing(new Coordinate[] {
    new Coordinate(0.0, 0.0),
    new Coordinate(1.0, 0.0),
    new Coordinate(1.0, 1.0),
    new Coordinate(0.0, 0.0)
});

Polygon polygon = geoFactory.createPolygon(extRing);

Geometry<?> geo = JTS.from(polygon);

produces the exception:

java.lang.NoSuchMethodError: org.locationtech.jts.geom.Polygon.getExteriorRing()Lorg/locationtech/jts/geom/LineString;
    at org.geolatte.geom.jts.JTS.from(JTS.java:307)
    at org.geolatte.geom.jts.JTS.from(JTS.java:165)
    at org.geolatte.geom.jts.JTS.from(JTS.java:139)

The cause is that in version 1.17.0 of JTS the class org.locationtech.jts.geom.Polygon returns a LinearRing instead of a LineString in the method getExteriorRing.

A temporary fix for applications using geolatte-geom is to exclude the transitive dependency org.locationtech.jts:jts-core from org.geolatte:geolatte-geom and include org.locationtech.jts:jts-core:1.16.1 as separate dependency.

hlavki commented 3 years ago

Another example:

import org.geolatte.geom.C2D;
import org.geolatte.geom.Geometries;
import org.geolatte.geom.JTSGeometryOperations;
import org.geolatte.geom.Point;
import org.geolatte.geom.crs.CrsRegistry;
import org.geolatte.geom.crs.ProjectedCoordinateReferenceSystem;

public class Main {

    private static final ProjectedCoordinateReferenceSystem EPSG_3785 = CrsRegistry.getProjectedCoordinateReferenceSystemForEPSG(3785);

    public static void main(String[] args) throws Exception {
        double lon = 14.4004917;
        double lat = 50.0569217;
        double distance = 1.7991243525909887E-4;
        Point<C2D> geometry = Geometries.mkPoint(new C2D(lon, lat), EPSG_3785);
         JTSGeometryOperations.Default.buffer(geometry, distance);
    }
}
hlavki commented 3 years ago

@arcolf I don't think that problem is in LinearRing because it extends LineString. It looks like geolatte-geom jar corrupted, becuase I did test where I copy JTS.java to my project and it works.

simonparadies commented 3 years ago

It seems it depends on what JTS version Geolatte is compiled against. If compiled against JTS 1.17.0 and using the resulting jar in a third-party project that excludes JTS 1.17.0 in favor of 1.16.1, the error described will occur. If compiled against 1.16.1 (i.e. excluding the JTS 1.17.0 in favor of the 1.16.1 dependency), the resulting jar will not cause the error if 1.16.1 is used explicitly by a third-party project. That seems very bad to me as compatibility of Geolatte with older JTS versions effectively depends on its build time (i.e. is JTS >= 1.17.0 or below in path during build time). I therefore plead to fix the JTS version used by Geolatte. In my case, 1.16.1 would be better since 17.0. seems to have an issue with geodb in my project…

idkw commented 3 years ago

I have added the PR above : https://github.com/GeoLatte/geolatte-geom/pull/117 to compiles against the newer version of jts-core and fix this bloccking issue. Can it be merged and released under 1.6.1 fix version ? Currently 1.6.0 is broken because of this issue :/ Thanks !

maesenka commented 3 years ago

After reviewing the issue, I've decided to release 1.6.1 with dependency on JTS 1.16.0. The cause of the problem is that there is a binary incompatibility between 1.16 and 1.17. Removing the version range fixes the issue. For reasons such as mentioned by simonparadies I think it is best to release 1.16.1 against the earliest compatible JTS version, and 1.7.0 against the JTS 1.17

idkw commented 3 years ago

Ok I'm fine with that thank you, is the geolatte 1.7.0 version which will include JTS 1.17.1 scheduled to be released soon after geolatte 1.16.1 ?

idkw commented 3 years ago

Also because it seems to be a breaking changes for other people maybe this would be a 2.0.0 ?

maesenka commented 3 years ago

I'm trying to get some other changes in 1.7 but I won't keep you waiting too long.

I'll think about the version number. I don't have a strict policy of semantic versioning, and would rather keep the 2.0.0 from some major changes that I'm planning.

maesenka commented 3 years ago

Geolatte-geom 1.6.1 is released

idkw commented 3 years ago

@maesenka Sorry to bother again, did you manage to release a 1.7 version with the dependency on JTS 1.17.x + ?

maesenka commented 3 years ago

No, not yet. I won't keep you waiting for too long now.

idkw commented 3 years ago

@maesenka Sorry to bother you once again. When can the fix version be released ? If you need help we can maybe have a chat and unblock the situation or delegate the task to another maintainer ? Thanks

maesenka commented 3 years ago

I'm in the process of releasing 1.7 (against jts-core 1.17). As luck would have it, OSSRH is having problems just now.

maesenka commented 3 years ago

FYI: Version 1.7 has been released, and is available from maven central

jodygarnett commented 3 years ago

We also released https://github.com/locationtech/jts/releases/tag/jts-1.18.0 recently.

We are sorry about the API regression and released 1.17.1 as quick as we could.

maesenka commented 3 years ago

Hi @jodygarnett, I know about the 1.18 release. I'm going to make a new release by end of the month that depends on 1.18.

jodygarnett commented 3 years ago

Okay, and if there is anything we can do when you find something like this please speak up. It is now (finally) easy for us to make a new point release if we run into issues like this.