Hello Jia
Le 15/12/2022 à 02:26, Jia Yu a écrit :
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.
Yes, Apache SIS is of course under Apache license except the EPSG
dataset which needs to be added explicitly by the user. More on it in
item (4).
(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.
All SIS versions up to SIS 1.3 (to be released soon) are compatible with
Java 8. The next version (SIS 1.4) will indeed require Java 11, but
maybe SIS 1.3 would be sufficient until Sedona can upgrade? If needed,
we can do some patch releases of SIS 1.3 for bug fixes.
(2) Support of ESRI shapefile read.
True, this part is missing. This work started years ago by a contributor
but is not finished.
(3) Support of GeoTiiff read and write. SIS supports GeoTiiff read but
Sedona also writes result to GeoTiiff.
True, GeoTIFF write capability is missing (planed but not done yet).
TIFF World File could be used to mitigate this lack, but I admit it is
not as nice.
(4) Apache SIS also does not ship EPSG dataset in its binary meaning
that the users still have to manually add another dependency.
Yes, but EPSG Terms of Use have been classified as a Category X license
by Apache [1] and no library can ship those data without EPSG Terms of
Use [2] — doing otherwise is called "relicensing", and no-one can do
that except the copyright owner. The libraries that bundle EPSG data
without EPSG terms of use are not legally correct. Proj4J just fixed
this problem recently with a separated JAR, similar to what SIS does
[3]. SIS provides different ways that the user can choose for adding
EPSG data [4].
2. Sedona pom files are kind of very complicated since we have modules
for both Spark and Flink. The core logic is: (…snip…)
Thanks for the explanation. Indeed, I understand a little bit more now.
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.
It is hard to know how well it serves the purpose without trying. With
SIS 1.3 there would be lost of functionalities on one hand (GeoTIFF
writer and Shapefile) but some new functionalities on the other hand.
The coordinate transformation services provided by SIS are more
advanced, and I would also be curious to know how the GeoTIFF reader
compares. But I'm not sure that a CI automatic tests would be successful
without some PMC decision about altered functionalities. What I do not
know is how critical they would be for Sedona.
Martin
[1]https://issues.apache.org/jira/browse/LEGAL-183
[2]https://epsg.org/terms-of-use.html
[3]https://github.com/locationtech/proj4j/issues/90
[4]https://sis.apache.org/epsg.html
