Sorry for the late reply. The holidays and an endless stream of colds kept me busy.
I think that Sedona and SIS joining forces would be great. But maybe the timing isn't right. I don't think a maintenance branch is going to work. Once the big data community drops java 8, in a few years, and Sedona is ready to upgrade SIS you will already be several java releases ahead and we'll be stuck on a new maintenance branch. If you are interested in joining the big data community I would advice you to look into multi release jars and be very conservative when it comes to bumping minimum java version. Multi release jars would not only help you with backwards compatibility. It would also help you take advantage of new java features, for those running on newer runtimes, before you bump the minimum java version. For instance jackson runs on java 8 but supports records on new java runtimes. All from the same build and jar file. Br, Martin Andersson Den tors 22 dec. 2022 kl 12:21 skrev Martin Desruisseaux < [email protected]>: > 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/ >
