Hi Martin, I have high respect for Apache SIS and we are fully onboard to replace GeoTools with Apache SIS. This is one of the reasons why we want to drop Java 8 support now. Furqaan already made good progress on the initial integration.
Currently, we just don't have enough hands in the community to drive this effort. But I will try to allocate some resources from Wherobots and any support from the Sedona community is highly appreciated. We will start with upgrading GeoTools to a newer version that does not conflict with Apache SIS. Then replace ST_Transform with Apache SIS. How does this sound? Thanks, Jia On Wed, Apr 10, 2024 at 10:15 AM Martin Desruisseaux < [email protected]> wrote: > Hello Jia and all > > Thanks for the report. I couldn't attend to the meeting (the link told > me that I needed a commercial zoom account, maybe I took the wrong > link). Items about crossing the anti-meridian (date line) and raster I/O > make me wonder if we could continue progress on integration of Apache > SIS in Sedona? There is licensing reasons, as Apache projects should not > depend on LGPL libraries (even if GeoTools is technically an optional > dependency, can Sedona provides most of its services without it?) But > there is also technical reasons. Sedona is trying to address some > difficult tasks. For example, handling the anti-meridian is easy with > points (just add or subtract 360°), but more difficult when computing > unions or intersections of envelopes (if longitude crosses 0° in one > envelope and 180° in the other envelope, none of the [−180° … +180°] and > [0° … 360°] range conventions will work; the calculation is more > complicated than just shifting one envelope). Anti-meridian is also a > difficult problem when resampling geometries or rasters: if the source > and target CRS are projected, we cannot easily add/subtract a value to > source/target coordinates. The shift happens somewhere in the middle of > the coordinate operation chain, and the action to do (add or subtract) > is not easy to determine. Resolving this problem requires some > integration between the "referencing" and the "coverage" modules. > > Apache SIS tries to address above-cited problems, and more (e.g. > multi-dimensional support). SIS is based on 25 years of experience and > on lessons learned from mistakes that we did in GeoTools when we wrote > its referencing and coverage modules 15 years ago. My concern is that > Sedona developments that are designed according GeoTools contraints may > become obstacles after an eventual migration to SIS. For example, SIS > can handle itself at least some parts of the anti-meridian problem, and > handling added by Sedona may interfere. Also, Sedona API added recently > such as BBOX with (minX, maxX, minY, maxY) fields would have possibly be > done differently if Sedona was built on top of a library supporting > multi-dimensional data from the ground. I'm concerned that, if there is > an interest for migrating to SIS, this task will become more and more > difficult as time passes, and design decisions that could have been more > generic (less 2D-restricted) will accumulate in Sedona. > > For a testimony from someone else who migrated from GeoTools to Apache > SIS, there is this blog: > > > https://www.int.com/blog/how-apache-sis-simplifies-hidden-complexity-coordinate-systems-in-ivaap/ > > Of course I would be happy to help as much as I can. > > Regards, > > Martin > >
