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
