Re: Replace LGPL dependencies by Apache ones?

[Martin Andersson <u....@gmail.com>]

Sorry for the late reply. The holidays and an endless stream of colds kept
me busy.

I think that Sedona and SIS joining forces would be great. But maybe the
timing isn't right.

I don't think a maintenance branch is going to work. Once the big data
community drops java 8, in a few years, and Sedona is ready to upgrade SIS
you will already be several java releases ahead and we'll be stuck on a new
maintenance branch.

If you are interested in joining the big data community I would advice you
to look into multi release jars and be very conservative when it comes to
bumping minimum java version.

Multi release jars would not only help you with backwards compatibility. It
would also help you take advantage of new java features, for those running
on newer runtimes, before you bump the minimum java version.

For instance jackson runs on java 8 but supports records on new java
runtimes. All from the same build and jar file.

Br,
Martin Andersson


Den tors 22 dec. 2022 kl 12:21 skrev Martin Desruisseaux <
martin.desruisseaux@geomatys.com>:

> Hello Martin and Jia
>
> Le 22/12/2022 à 08:25, Jia Yu a écrit :
>
> > Martin Andersson 's suggestion makes sense to me. If Apache SIS
> > decides to provide Java 8 support in the long run, we can try to
> > replace GeoTools CRS transformation with Apache SIS.
> >
> It would be possible to backport SIS 1.4+ in a Java 8 branch. We did
> something similar for Java 7 some years ago, so we have experience in
> this process. But it is a significant effort (a few thousands lines of
> code have changed after SIS 1.3 release candidate for taking advantage
> of Java 11 methods in Math, NIO, Arrays, collections, TIFF tags, etc).
> In order to evaluate if a Java 8 branch is worth, it may be desirable to
> first test "Sedona on SIS" in a branch somewhere and see if it is
> considered satisfying.
>
> A little bit of context regarding GeoTools versus Apache SIS: from 2002
> to 2009 I was the main author of GeoTools metadata, referencing and base
> grid coverage classes excluding I/O (so GeoTIFF is an independent work).
> Apache SIS metadata, referencing and grid coverage modules are
> continuation of the work I started in GeoTools with bug fixes,
> improvements and upgrades to newer ISO/OGC standards (e.g. GML and ISO
> 19162, a.k.a. "WKT 2"). Apache SIS has been used as a source of
> inspiration for a major upgrade of the PROJ library [1].
>
> Performance is one aspect, but accuracy is another important aspect. A
> video from IOGP (creator of EPSG dataset) explains how a few tens of
> centimeters error has cost them millions of dollars [2]. Not every
> projects need high confidence, but some groups such as OSDU (Open
> Subsurface Data Universe) require software to pass the GIGS tests
> (Geospatial Integrity of Geoscience Software) [3] before to care about
> performance. Apache SIS does not yet pass the full GIGS test suite or
> implement all features shown in IOGP video, but we are working on that
> in collaboration with peoples from GIGS and OGC working group.
>
> Nevertheless Apache SIS and GeoTools performance of referencing services
> should be similar since their code have the same roots. SIS got
> improvements, but I did not measured their performance impact. But
> anyway, performance depends a lot about how a library is used. The
> accuracy mentioned in previous paragraph is not always needed, so we
> should allow users to control the performance/accuracy tradeoff (still a
> work in progress in SIS). Furthermore, transforming points is easy but
> transforming geometries or rasters involve additional complexities. SIS
> has some features such as Jacobian matrix which, when put in the hands
> of a mathematically skilled developer, allows nice optimizations. This
> is used by SIS for envelope and raster transformations.
>
> In summary, if there is an interest, creating a "Sedona on SIS" branch
> may take some time. The result would need to be evaluated before to
> decide in there is a desire to put more effort, e.g. in a SIS Java 8
> branch.
>
>      Regards,
>
>          Martin
>
> [1]https://gdalbarn.com/  — search "SIS" on that page.
> [2]https://www.youtube.com/watch?v=IKM-bR6SwVs
> [3]https://gigs.iogp.org/
>

Re: Replace LGPL dependencies by Apache ones?

[Martin Desruisseaux <ma...@geomatys.com>]

Hello Martin

Indeed, we use multi-release JAR files for other projects. But in Apache 
SIS case, upgrade from Java 8 to 11 implies changes pervasive enough to 
make uncertain that multi-release JAR would be easier than a branch. But 
anyway, the decision to bump the minimum Java version is up to the 
community, which includes the users. If a user (could be Sedona) objects 
against a future bump, this is taken in account.

One thing about the timing is that a migration (if desired) may require 
more work as time passes. For example a recent request on this mailing 
list was about fetching values in a GeoTIFF file. Apache SIS already 
supports that on GeoTIFF and netCDF among others, handling the CRS 
issues, in N-dimensions when the format supports it, and efficiently on 
large files when the format supports tilings (geospatial softwares do 
some big data on their own since they work with space agencies). Work 
developed on top of a different library would probably be done 
differently, making an eventual migration more unlikely.

Whether a migration would be desirable or not depends on the technical 
merits of libraries, but also licensing is maybe not a negligible 
aspect. Given that Sedona is all about bringing geospatial 
functionalities to Spark, it seems a little bit surprising that 
"referencing by coordinates" services and "grid coverages" (a.k.a. 
rasters) are not core to Sedona?

But anyway, I understand that for making a migration proposal receivable 
for consideration, we need a prototype that can be evaluated for 
functionalities and performances. I will not have the time to work on a 
Sedona branch for the next few months however (especially if acceptance 
is uncertain), but maybe in spring some experiment would be possible.

     Martin


Le 18/01/2023 à 15:37, Martin Andersson a écrit :

> I think that Sedona and SIS joining forces would be great. But maybe the
> timing isn't right.
>
> I don't think a maintenance branch is going to work. Once the big data
> community drops java 8, in a few years, and Sedona is ready to upgrade SIS
> you will already be several java releases ahead and we'll be stuck on a new
> maintenance branch.
>
> If you are interested in joining the big data community I would advice you
> to look into multi release jars and be very conservative when it comes to
> bumping minimum java version.
>
> Multi release jars would not only help you with backwards compatibility. It
> would also help you take advantage of new java features, for those running
> on newer runtimes, before you bump the minimum java version.
>
> For instance jackson runs on java 8 but supports records on new java
> runtimes. All from the same build and jar file.