Skip to content

Add Geomermaids OSM daily exports to distribution examples - #296

Open
gsueur wants to merge 1 commit into
opengeospatial:mainfrom
gsueur:add-geomermaids-osm-exports
Open

Add Geomermaids OSM daily exports to distribution examples#296
gsueur wants to merge 1 commit into
opengeospatial:mainfrom
gsueur:add-geomermaids-osm-exports

Conversation

@gsueur

@gsueur gsueur commented Jul 22, 2026

Copy link
Copy Markdown

Adds the Geomermaids OSM daily exports to the list of GeoParquet data distribution examples in distributing-geoparquet.md.

These are daily OpenStreetMap exports published as GeoParquet v2.0, with Hilbert sorting and spatial partitioning, hosted at https://parquetry.geomermaids.com/. They serve as a real-world example of the distribution best practices described in this document.

@gsueur
gsueur force-pushed the add-geomermaids-osm-exports branch from b3426d6 to 5a30f46 Compare July 22, 2026 11:07
@cholmes

cholmes commented Aug 13, 2026

Copy link
Copy Markdown
Member

Sorry for the slow response! Thanks for the contribution. I'm slammed right now, but will try to find some time in the next couple weeks to do at least a minimal bit of review on the OSM exports.

@gsueur

gsueur commented Aug 13, 2026

Copy link
Copy Markdown
Author

sure, no worries

@cholmes

cholmes commented Aug 13, 2026

Copy link
Copy Markdown
Member

Managed to find some time to check. It looks great! Though it does make me want to update the spec and best practices to articulate the benefits of adding bbox column to geoparquet 2.0. In gpio I give warnings now. So once we get it so that's in the spec I think it makes sense to merge in. I think there's rough consensus to add bbox covering back into the spec as optional, so I'll try to make that PR soon (or feel free to go for it with any of this). Thanks!

@gsueur

gsueur commented Aug 13, 2026

Copy link
Copy Markdown
Author

I don't know if it really needs to go down into the specs, but for remote usage on files > 500MB it definitely helps to hard prune on the bbox column. So it's not all use cases and probably better implementation of 2.0 on the reader side will help too. With my GeoPQ-Workbench I have no issue working with 2.0 remote files up to 3-4GB !

@cholmes

cholmes commented Aug 14, 2026

Copy link
Copy Markdown
Member

Yeah, I think it's worth having in the spec just so that if people want to do it then it's clearly an option for 2.0 and not some undocumented thing. I think we can have the best practices doc discuss what are the use cases where you'd actually want to use it. Your input here and anything more you want to put in is great - we can just say where it helps, and also the tradeoffs with it (ie increasing the overall size of your data).

@gsueur

gsueur commented Aug 14, 2026

Copy link
Copy Markdown
Author

Wrote up the bbox covering case in #297, with size and timing numbers from these files. Happy to keep this PR open until the spec side lands.

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.

2 participants