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
