You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sedona.apache.org by Jia Yu <ji...@apache.org> on 2024/04/01 19:41:21 UTC
[ANNOUNCE] Sedona monthly office hour: April 9th (Tuesday): 8 - 9 am Pacific Time
Dear all,
🎉🎉🎉 The next monthly office hour is on April 9th (Tuesday) from 8 to 9
am Pacific Time. We will cover Project Updates, a Focus Topic Presentation,
an Open Discussion and Q&A, and information on the Roadmap and Future
Plans. It's an excellent opportunity for the community to engage and
contribute to Apache Sedona's development.
In this office hour, the following topics will be covered:
1. Apache Sedona 1.6.0 release timeline
2. Implementation of GeoParquet spec 1.1.0
3. Shapely 2.0 integration for vector data
4. Rasterio and numpy integration for raster data
5. Drop Java 8 support
For details and to join, please import the event to your calendar:
https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=NjI0cWgwcTZndnI1anAzYnFrNHY5Y2wyaTRfMjAyNDA0MDlUMTUwMDAwWiBjX2VmN2Q1NGY1MzA4YTRiN2YyNWFjMzNkMGY3ZWViNTRhM2E3ZjExNWI2ODlmYWY0ZDgyNDI1ZjNjYjVlZGU5MzVAZw&tmsrc=c_ef7d54f5308a4b7f25ac33d0f7eeb54a3a7f115b689faf4d82425f3cb5ede935%40group.calendar.google.com&scp=ALL
To join Zoom Meeting
https://wherobots.zoom.us/j/91596329826
Passcode: 508995
Thanks,
Jia
Re: [ANNOUNCE] Sedona monthly office hour: April 9th (Tuesday): 8 - 9 am Pacific Time
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-04-12 à 02 h 04, Jia Yu a écrit :
>
> Sounds good! Should I contact info@osgeo.org?
>
That would be appreciated!
> 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.
>
The projet would have a strong (non-optional) dependencies to GeoTools,
which is not allowed for an Apache project because of LGPL license. I
think that OSGeo would be a better home, if they agree. Furthermore,
there is already a GeoAPI-PROJ binding there [1].
Note that the project would not be named "sis-geotools", but rather
"geoapi-geotools" or "geotools-geoapi" or something similar. GeoAPI is
implementation neutral, so this project would not depend on SIS. We
would have two projects (GeoTools and SIS) implementing the same set of
interfaces (GeoAPI), so the interoperability between the two projects
would happen at the GeoAPI level.
   Martin
[1]https://github.com/OSGeo/PROJ-JNI
Re: [ANNOUNCE] Sedona monthly office hour: April 9th (Tuesday): 8 - 9 am Pacific Time
Posted by Jia Yu <ji...@apache.org>.
Sounds good! Should I contact info@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.desruisseaux@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
>
>
Re: [ANNOUNCE] Sedona monthly office hour: April 9th (Tuesday): 8 - 9 am Pacific Time
Posted by Martin Desruisseaux <ma...@geomatys.com>.
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
Re: [ANNOUNCE] Sedona monthly office hour: April 9th (Tuesday): 8 - 9 am Pacific Time
Posted by Jia Yu <ji...@apache.org>.
Hi Martin,
I have high respect for Apache SIS and we are fully onboard to replace
GeoTools with Apache SIS. This is one of the reasons why we want to drop
Java 8 support now. Furqaan already made good progress on the initial
integration.
Currently, we just don't have enough hands in the community to drive this
effort. But I will try to allocate some resources from Wherobots and any
support from the Sedona community is highly appreciated.
We will start with upgrading GeoTools to a newer version that does not
conflict with Apache SIS. Then replace ST_Transform with Apache SIS.
How does this sound?
Thanks,
Jia
On Wed, Apr 10, 2024 at 10:15 AM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> 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
>
>
Re: [ANNOUNCE] Sedona monthly office hour: April 9th (Tuesday): 8 - 9 am Pacific Time
Posted by Martin Desruisseaux <ma...@geomatys.com>.
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
Re: [ANNOUNCE] Sedona monthly office hour: April 9th (Tuesday): 8 - 9 am Pacific Time
Posted by Jia Yu <ji...@apache.org>.
Dear all,
It was nice talking to many members in the community during the office hour
today! Here is the meeting notes and recording today:
https://docs.google.com/document/d/1goh-g1PaF_KO8XQn3YP_Xm8XtLtmudnkB20aUj0JiZw/edit?usp=sharing
Thanks,
Jia
On Mon, Apr 1, 2024 at 12:41 PM Jia Yu <ji...@apache.org> wrote:
> Dear all,
>
> 🎉🎉🎉 The next monthly office hour is on April 9th (Tuesday) from 8 to 9
> am Pacific Time. We will cover Project Updates, a Focus Topic Presentation,
> an Open Discussion and Q&A, and information on the Roadmap and Future
> Plans. It's an excellent opportunity for the community to engage and
> contribute to Apache Sedona's development.
>
> In this office hour, the following topics will be covered:
> 1. Apache Sedona 1.6.0 release timeline
> 2. Implementation of GeoParquet spec 1.1.0
> 3. Shapely 2.0 integration for vector data
> 4. Rasterio and numpy integration for raster data
> 5. Drop Java 8 support
>
> For details and to join, please import the event to your calendar:
> https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=NjI0cWgwcTZndnI1anAzYnFrNHY5Y2wyaTRfMjAyNDA0MDlUMTUwMDAwWiBjX2VmN2Q1NGY1MzA4YTRiN2YyNWFjMzNkMGY3ZWViNTRhM2E3ZjExNWI2ODlmYWY0ZDgyNDI1ZjNjYjVlZGU5MzVAZw&tmsrc=c_ef7d54f5308a4b7f25ac33d0f7eeb54a3a7f115b689faf4d82425f3cb5ede935%40group.calendar.google.com&scp=ALL
>
> To join Zoom Meeting
> https://wherobots.zoom.us/j/91596329826
> Passcode: 508995
>
> Thanks,
> Jia
>