Amending RFC 1 to make GDAL 2.5 the baseline for Fiona 2.0


Sean Gillies
 

Hi all,

The implications of the changes in GDAL 2.5 have finally dawned on me. I think we need to make 2.5 the baseline version of GDAL for Fiona 2.0 and then add shims to provide what is missing in GDAL versions 2.2-2.4: specifically the data-CRS axis order mapping.

Unless anyone objects, I will amend the RFC to state clearly that GDAL 2.5 will be the new baseline version.

--
Sean Gillies


Joris Van den Bossche
 

Sure!

Op di 23 apr. 2019 om 06:20 schreef Sean Gillies <sean.gillies@...>:

Hi all,

The implications of the changes in GDAL 2.5 have finally dawned on me. I think we need to make 2.5 the baseline version of GDAL for Fiona 2.0 and then add shims to provide what is missing in GDAL versions 2.2-2.4: specifically the data-CRS axis order mapping.

Unless anyone objects, I will amend the RFC to state clearly that GDAL 2.5 will be the new baseline version.

--
Sean Gillies


Joshua Arnott
 

I hadn't been following along with the GDAL 2.5 changes either. I agree with the proposal to make GDAL 2.5 the baseline for Fiona 2.0, with support for old versions (hopefully not too difficult!) added via the shims.

For those just catching up, I found this link helpful:

https://trac.osgeo.org/gdal/wiki/rfc73_proj6_wkt2_srsbarn


Alan Snow
 

Going to 2.5 sounds like a great way to go! I think that there are some significant changes there that make that a good choice. But, I think testing should be done with the earlier versions before committing to supporting them. There have been changes that might not backport well. For example, if you want to go with WKT2 as the new default, will it still work in the previous versions?


Howard Butler
 

We are strongly considering requiring GDAL 2.5+ when we release PDAL 2.0 this summer for similar reasons. PDAL and libLAS were using some older libgeotiff methods like OSRFixup that have since been removed, which makes for a few annoying #ifdefs. The larger challenge is coordinate system transformations are likely to behave differently at the edges of functionality depending on which version of the GDAL/PROJ stack that is linked if we supported both, and that is combined with our desire to hurry up already and start using the clean concourses of the new PROJ/GDAL architecture. 

PROJ had been targeting removal of proj_api.h to attempt to bring forward many of the laggards that have been using PROJ internals at its PROJ 7 release, but I think this is going to have to be at least delayed. The impacts for the packagers are still going to be quite punishing for a while on that topic. PROJ moved glacially forever, and people's attention has not caught up with its new pace.

Alan, as an aside, I finally got to do some Python while implementing a library for our Entwine Point Tile [1] point cloud format, and I was using the new pyproj with PROJ 6. Everything Just Worked(tm) pleasantly. A long time ago when I was developing lots of Python stuff, having a nicely organized library with those capabilities was the dream. Nice work!

Howard


On Apr 23, 2019, at 7:20 AM, Alan Snow <alansnow21@...> wrote:

Going to 2.5 sounds like a great way to go! I think that there are some significant changes there that make that a good choice. But, I think testing should be done with the earlier versions before committing to supporting them. There have been changes that might not backport well. For example, if you want to go with WKT2 as the new default, will it still work in the previous versions?


Sean Gillies
 


On Mon, Apr 22, 2019 at 10:20 PM Sean Gillies via Groups.Io <sean.gillies=gmail.com@groups.io> wrote:
Hi all,

The implications of the changes in GDAL 2.5 have finally dawned on me. I think we need to make 2.5 the baseline version of GDAL for Fiona 2.0 and then add shims to provide what is missing in GDAL versions 2.2-2.4: specifically the data-CRS axis order mapping.

Unless anyone objects, I will amend the RFC to state clearly that GDAL 2.5 will be the new baseline version.

--
Sean Gillies



--
Sean Gillies


Sean Gillies
 

Hi Alan,

I don't think we should switch to WKT2 yet. The goal here is to release a version of Fiona that works with GDAL 2.5 so the upgrade paths aren't blocked, even if we don't use all the new features of 2.5.


On Tue, Apr 23, 2019 at 6:20 AM Alan Snow <alansnow21@...> wrote:
Going to 2.5 sounds like a great way to go! I think that there are some significant changes there that make that a good choice. But, I think testing should be done with the earlier versions before committing to supporting them. There have been changes that might not backport well. For example, if you want to go with WKT2 as the new default, will it still work in the previous versions?



--
Sean Gillies


Alan Snow
 

Hi Howard,

I am happy to hear that pyproj works well for you! The point cloud format you linked to looks interesting - glad you posted it.

Best,
Alan


Alan Snow
 

Hi Sean,

I think a major version bump in Fiona would be a great opportunity to introduce breaking changes and new features to help guide the community to new (and hopefully improved) standards. But, I also understand the desire for backwards compatibility and to help users migrate over. One way to help users along with the migration would be to go the direction you have outlined, carrying along with it the burden and limitations of supporting the old and the new versions into the next major version. Another option would be to have a 1.9.x branch of Fiona to support GDAL 2.2-2.4 and backport new features developed in Fiona 2.x (GDAL 2.5+) where possible (also a burden). This would enable Fiona 2.x to fully migrate over to the new features in the GDAL 2.5 (which could arguably be a 3.0 release). There are also other options I am sure, just not currently in my brain :). That being said, either direction has its challenges, so I am supportive of either direction :+1:.

Best,
Alan


Alan Snow
 

Brain dump continued:
Another option would be to have pre-releases of Fiona 2.0 like what happened for rasterio 1.0 where users have to explicitly pin the pre versions. This would allow users to opt-in to the changes until GDAL 2.5 becomes more mainstream. Additionally, this would alleviate the burden of supporting older versions of GDAL in Fiona. But, depending on the timeline of when you want to release Fiona 2.0, this may or may not be desirable.