Hello Jia
Thanks for the reply.
Le 04/02/2026 à 07:13, Jia Yu a écrit :
Thanks for reaching out. I think it is a great idea to test this out.
But we do need some volunteers now since we are short staffed. Our
last attempt of migrating from GeoTools to Apache SIS wasn't
successful due to various dependency issues and regression compared to
GeoTools.
Regarding dependencies issues, I presume that this is referring to the
conflict in the `org.opengis` packages. I would like to remind that
"OpenGIS" is a registered name protected by trademark laws, and OGC
never authorized GeoTools to use this package name as if it was its own.
It was a GeoTools legal and ethical (they forked an OGC project without
renaming packages) issue fixed two years ago, not an Apache SIS issue.
Regarding regressions compared to GeoTools, I wasn't aware of them.
Since the developers of Apache SIS referencing module were the
developers of about 90% of the GeoTools referencing module until 2010,
and since GeoTools referencing module got few evolution since 2010, I'm
very confident that we can either fix any regression or show that the
issue was in GeoTools if we are notified about them. Reports on a public
mailing list would be greatly appreciated.
On the other hand, I've ported the entire Proj4js library to Java
(https://github.com/jiayuasu/proj4sedona) and it supports proj,
projjson, WKT1/WKT2, proj CDN for grid file downloads which are
critical to Sedona since Parquet and Iceberg have adopted projjson. My
local Sedona branch already has this integrated into Sedona and shows
good performance and better accuracy.
Isn't Proj4JS derived from Proj.4, which was an early-binding
implementation (i.e., based on `TOWGS84` parameters embedded in CRS
definitions)? I just browsed the code quickly and it seems to use WGS84
as a universal hub. This is discouraged by EPSG, and the inexactitude of
this approach was demonstrated there:
https://www.geomatys.com/en/2017/09/20/proj-4-versus-apache-sis-an-accuracy-comparison/
It was a Proj.4 defect which was fixed in PROJ 6, but to my knowledge
Proj4J and Proj4JS did not followed this architectural change. As
another way to approach the problem, does Proj4JS passes the Geospatial
Integrity of Geoscience Software (GIGS) tests?
https://gigs.iogp.org/
The danger of all libraries derived from Proj.4 (before the fix in PROJ
6) is that they give an illusion of accuracy with no indication about
the real accuracy. When using a Proj.4 operation, nothing tells the
users whether the operation has a centimetric precision or a 10 meters
error. This risk is amplified by their early-binding architecture. They
do not said neither in which geographic area the operation is valid. The
maintainers of the EPSG geodetic dataset published a video explaining
some of the complexity of modern geodesy, with an example of how a small
misunderstanding of geodesy has cost millions of dollars:
https://www.youtube.com/watch?v=IKM-bR6SwVs
I plan to first introduce proj4sedona into Sedona and mark it as an
experimental feature. If someone can help me bring in Apache SIS
support, that would be great.
We would be glad to help in the form of fixing any issue reported
against Apache SIS. Another possible help is that, regarding ProjJSON
support, this work does not need to be done inside Apache SIS. We have
already demonstrated with the CRS-JSON prototype that a single binding
can work with any OGC GeoAPI implementation, which includes Apache SIS,
Proj4J, PROJ-JNI and GeoTools (through the GeoTools - GeoAPI wrappers):
https://github.com/Geomatys/CRS-JSON-Encoding
We can contribute in the form of creating a copy of this project and
adapt it to ProjJSON. But given that we are also short staffed, we would
need a Sedona contributor for doing the part of the work which is on
Sedona's side.
Regards,
Martin
