1.9b1

[sgillies]

The fist 1.9 beta release is ready for early testing. All of the features planned for 1.9.0 are in this release.

The binary wheels on PyPI include GDAL 3.5.3, GEOS 3.11.1, and PROJ 9.0.1. To try the wheels, run pip install --pre fiona.

New features

• Add listdir and listlayers method to io.MemoryFile (resolving Add methods to list and access multiple datasets within a zip file #754).
• Add support for TIN and triangle geometries (Support GeometryCollection containing TIN or Triangle geometries #1163).
• Add an allow_unsupported_drivers option to fiona.open() (Add allow_unsupported_drivers option to fiona.open #1126).
• Added support for the OGR StringList field type (ENH: Add support for reading string lists #1141).

Changes and bug fixes

• Missing and unused imports have been added or removed.
• Make sure that errors aren't lost when a collection can't be saved properly (Fiona *silently* fails to write to s3 when bucket doesn't exist. #1169).
• Ensure that ZipMemoryFile have the proper GDAL name after creation so that we can use listdir() (fiona.listlayers doesn't work on MemoryFile or ZipMemoryFile (but does on '/vsizip/' + zipmemfile.name) #1092).
• The fiona._loading module, which supports DLL loading on Windows, has been moved into init.py and is no longer used anywhere else (Remove _loading, copy into __init__ #1168).
• Move project metadata to pyproject.toml (Move project metadata to pyproject.toml; add build-backend #1165).
• Update drvsupport.py to reflect new format capabilities in GDAL 3.6.0 (Add gdal 3.5 and 3.6 to CI, update proj/gdal install scripts to use cmake, update drvsupport #1122).
• Remove debug logging from env and _env modules.

---

This discussion was created from the release 1.9b1.

[jorisvandenbossche]

I was looking into the fiona.model related deprecation warnings that are introduced in Fiona 1.9 in context of geopandas' read_file/to_file functions: geopandas/geopandas#2696

That PR updates geopandas' code to be compatible with future fiona (based on the warnings), but it made me wonder: is this needed for this case of passing data to fiona?
I understand that accessing the features/geometries as dict is deprecated, so fiona can expose a custom object (avoiding a direct conversion to a python dict). But that seems mostly important for reading? When writing data (passing features/geometries to fiona), fiona could still provide the user convenience to be able to pass a dictionary, instead of having to convert this to a Feature/Geometry object manually?

To be clear: it's a small and easy change in geopandas, so no problem at all for geopandas if it is decided that Fiona wants to be strict and only accept its own Feature/Geometry object.
But for a direct user of fiona, it could be nice to still support the __geo_interface__-like objects out of the box? (https://gist.github.com/sgillies/2217756)

[sgillies]

@jorisvandenbossche I'm taking a look at it. Accepting __geo_interface__ providers makes sense and shouldn't be hard to do.