Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: add support to read and write .gpkg.zip and .shp.zip #527

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

theroggy
Copy link
Member

@theroggy theroggy commented Mar 24, 2025

Add support to read and write ".gpkg.zip" and ".shp.zip" files. PR also adds a basic test on ".shz".

resolves #449

@theroggy theroggy changed the title ENH: add support to read and write .gpkg.zip and.shp.zip ENH: add support to read and write .gpkg.zip and .shp.zip Mar 24, 2025
@theroggy theroggy added this to the 0.11.0 milestone Mar 24, 2025
@martinfleis
Copy link
Member

Can we also add .shz while we're at it?

@theroggy
Copy link
Member Author

Can we also add .shz while we're at it?

".shz" should already be fine I think. ".gpkg.zip" and ".shp.zip" gave issues because of the 2 suffixes used. Anyway I added ".shz" to a basic write/read test so there is at least minimal testing on it.

Do you know of issues with ".shz"?

@martinfleis
Copy link
Member

Not aware of issues. I just wasn't sure pyogrio picks the driver properly given it wasn't listed in the mapping.

@jorisvandenbossche
Copy link
Member

The goal of the actual code changes is essentially to avoid that we do any preprocessing of the path in case of it ending with .gpkg/shp.zip (i.e. prevent adding vsizip in front of it?), because that is the way that GDAL handles those best?

theroggy added a commit to geofileops/geofileops that referenced this pull request Mar 25, 2025
…le/layer operations (#673)

Following issues need to be solved upstream:
- [x] For to_file there seems to be an issue in pyogrio, PR:
geopandas/pyogrio#527

ref #674
@theroggy
Copy link
Member Author

The goal of the actual code changes is essentially to avoid that we do any preprocessing of the path in case of it ending with .gpkg/shp.zip (i.e. prevent adding vsizip in front of it?), because that is the way that GDAL handles those best?

Indeed...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

BUG/ fiona parity: error on writing zipped shapefile with .shp.zip
3 participants