Dear Martin, Thanks for your suggestion!
1. I am interested in exploring replacing geotools with Proj4J or Apache SIS if this replacement can serve this purpose: this library can be shipped together in Sedona binary (Maven 'compile' scope) and users no longer need to manually add another dependency like the geotools-wrapper [1]. Given this purpose, I can see there are a few features that Apache SIS lacks. Please correct me if I am wrong since you are an expert of Apache SIS. (1) Compatibility with both Java 8 and Java 11. SIS only works for Java 11 however many Sedona users are still on Java 8. We have no plan to get rid of Java 8 support any time soon. (2) Support of ESRI shapefile read. (3) Support of GeoTiiff read and write. SIS supports GeoTiiff read but Sedona also writes result to GeoTiiff. (4) Apache SIS also does not ship EPSG dataset in its binary meaning that the users still have to manually add another dependency. 2. Sedona pom files are kind of very complicated since we have modules for both Spark and Flink. The core logic is: (1) The root pom does not have any compile-scope dependencies. All these dependencies are just for development purposes. We never package Spark and Flink dependency because expect users to add Spark, Flink dependencies on their own. (2) If it is really necessary, dependencies that need to be shipped in Sedona binary are put in the corresponding child module pom under 'compile' scope. (3) There are a few exceptions: JTS, jts2geojson, GeoTools [2]. We don't ship them in binary because these libraries are very commonly used in GIS applications. Packaging them to Sedona might end up polluting the user's environment. (4) Sedona has a special module called sedona-python-adapter which is designated for non-JVM world users (Python and R). In this module, we package all dependencies in compile scope since these users usually don't know much about Maven packaging. However, geotools is excluded due to the license issue. 3. If you think using SIS can serve the purpose mentioned above, you can create a fork of Sedona and work on it. Then you can create a PR on Sedona and the CI will automatically test the code. Thanks, Jia [1] https://sedona.apache.org/setup/maven-coordinates/#use-sedona-fat-jars [2] https://sedona.apache.org/setup/maven-coordinates/#use-sedona-and-third-party-jars-separately On Wed, Dec 14, 2022 at 2:26 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Hello all > > To follow-up on this question, is there an interest for experimenting a > replacement of GeoTools dependency (LGPL license) by Apache SIS? (not > knowing in advance if the experiment would be conclusive or not). If > yes, where should be the branch? > > Regarding dependencies, by looking at the root pom.xml file [1] I'm a > little bit confused. All non-test dependencies are declared with > <scope>${dependency.scope}</scope> where the ${dependency.scope} > property is set to "provided" be default. This pom.xml file seems to > implement an "all or nothing" behavior regarding dependency scope > management. I would have expected the default scope ("compile") for a > set of dependencies that are essential to Sedona working, and the > "provided" scope for optional dependencies. Are all the dependencies > really optional? > > I think that the NOTICE file needs to list the licenses of dependencies. > Maybe [3] can be used as a source of inspiration? Note that gt-epsg is > under EPSG Terms of use, not only LGPL. A similar issue raised for > Apache Calcite goes deeper in this topic and how it can be resolved [4]. > > I mention those licensing topics because I guess they are the reason for > the way dependencies are declared in the root pom.xml, and if I create a > branch for experimenting some dependencies replacement, understanding > their purposes would be better. > > Thanks, > > Martin > > [1] > https://github.com/apache/incubator-sedona/blob/sedona-1.3.1-incubating-rc1/pom.xml > [2] > https://github.com/apache/incubator-sedona/blob/sedona-1.3.1-incubating-rc1/NOTICE > [3]https://github.com/apache/sis/blob/master/NOTICE > [4]https://github.com/locationtech/proj4j/issues/90 >
