Sounds good! Should I contact i...@osgeo.org? In addition, I think you can also create a project called sis-geotools yourself from here? https://gitbox.apache.org/boxer/ Then this project will be a sub-project of Apache SIS.
Thanks, Jia On Thu, Apr 11, 2024 at 3:50 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Hello Jia > > Thanks for your reply. Indeed, small steps is fine. For making the > following step more gradual: > > > We will start with upgrading GeoTools to a newer version that does not > > conflict with Apache SIS. Then replace ST_Transform with Apache SIS. > > The conflict was in "org.opengis" package names, which is owned by OGC > (GeoTools did a fork of OGC standard). They resolved this conflict by > renaming their "org.opengis" packages to something else. The consequence > for Sedona is that an upgrade of GeoTools followed by SIS would imply a > renaming of "org.opengis" to something else, then back to "org.opengis" > (but this time in compliance with OGC standard). > > Upgrading directly to SIS (the work that Furqaan started) would avoid > this back-and-forth package renaming, but may be risky because of > possible behavioral changes to manage all at once if the replacement is > a "all or nothing". > > There is a third approach that may be considered: create a new project > on GitHub (host organization to be determined, maybe OSGeo) where to > create OGC GeoAPI wrappers for GeoTools. This is possible now that > GeoTools no longer conflict with OGC standard. If there is a volunteer > for setting up the project (possibly by asking OSGeo if they would > accept to host the GitHub repository), I can volunteer for the actual > Java code. The advantages for Sedona would be: > > * Upgrade to latest GeoTools without renaming the > `org.opengis.referencing` packages (but it would be wrappers instead > of direct GeoTools API). > * Instances of the CoordinateReferenceSystem interface can be > implemented either by GeoTools or Apache SIS in the same JVM. It > should be possible to have the two libraries co-existing behind the > same API. So migration of the coordinate transformation services > (for example) would not need to be done all at once for the whole > Sedona project. > > Martin > >
