Hello Martin and Jia
Le 22/12/2022 à 08:25, Jia Yu a écrit :
Martin Andersson 's suggestion makes sense to me. If Apache SIS
decides to provide Java 8 support in the long run, we can try to
replace GeoTools CRS transformation with Apache SIS.
It would be possible to backport SIS 1.4+ in a Java 8 branch. We did
something similar for Java 7 some years ago, so we have experience in
this process. But it is a significant effort (a few thousands lines of
code have changed after SIS 1.3 release candidate for taking advantage
of Java 11 methods in Math, NIO, Arrays, collections, TIFF tags, etc).
In order to evaluate if a Java 8 branch is worth, it may be desirable to
first test "Sedona on SIS" in a branch somewhere and see if it is
considered satisfying.
A little bit of context regarding GeoTools versus Apache SIS: from 2002
to 2009 I was the main author of GeoTools metadata, referencing and base
grid coverage classes excluding I/O (so GeoTIFF is an independent work).
Apache SIS metadata, referencing and grid coverage modules are
continuation of the work I started in GeoTools with bug fixes,
improvements and upgrades to newer ISO/OGC standards (e.g. GML and ISO
19162, a.k.a. "WKT 2"). Apache SIS has been used as a source of
inspiration for a major upgrade of the PROJ library [1].
Performance is one aspect, but accuracy is another important aspect. A
video from IOGP (creator of EPSG dataset) explains how a few tens of
centimeters error has cost them millions of dollars [2]. Not every
projects need high confidence, but some groups such as OSDU (Open
Subsurface Data Universe) require software to pass the GIGS tests
(Geospatial Integrity of Geoscience Software) [3] before to care about
performance. Apache SIS does not yet pass the full GIGS test suite or
implement all features shown in IOGP video, but we are working on that
in collaboration with peoples from GIGS and OGC working group.
Nevertheless Apache SIS and GeoTools performance of referencing services
should be similar since their code have the same roots. SIS got
improvements, but I did not measured their performance impact. But
anyway, performance depends a lot about how a library is used. The
accuracy mentioned in previous paragraph is not always needed, so we
should allow users to control the performance/accuracy tradeoff (still a
work in progress in SIS). Furthermore, transforming points is easy but
transforming geometries or rasters involve additional complexities. SIS
has some features such as Jacobian matrix which, when put in the hands
of a mathematically skilled developer, allows nice optimizations. This
is used by SIS for envelope and raster transformations.
In summary, if there is an interest, creating a "Sedona on SIS" branch
may take some time. The result would need to be evaluated before to
decide in there is a desire to put more effort, e.g. in a SIS Java 8 branch.
Regards,
Martin
[1]https://gdalbarn.com/ — search "SIS" on that page.
[2]https://www.youtube.com/watch?v=IKM-bR6SwVs
[3]https://gigs.iogp.org/
