Updates 202606

[nmandery]

fixes #86

Requires readthedocs/readthedocs-builder#11

[regislon]

Hi @nmandery — I just took the opportunity of having Fable 5 back to dig a little into this PR and the migration work you did here. First of all: really nice job, this is a big update and it reads very cleanly — and CI is green across the board. While going through it I spotted a few small things that might be worth a look, roughly by severity:

1. cells_to_wkb_polygons output changed from LargeBinary to Binary (i32 offsets).
In geoarrow-array 0.8, WkbArray is an alias for GenericWkbArray<i32>, so the new let out: WkbArray = ... (and the to_wkb_polygons call it forces) produces i32 offsets, while main used WKBArray<i64>. Verified by building this branch vs 0.22.0 from PyPI:

cells = geometry_to_cells(shapely.Point(8.9, 47.2), 8)
cells_to_wkb_polygons(cells).type
# 0.22.0:  arro3.core.DataType<LargeBinary>
# PR readthedocs/readthedocs.org#90:  arro3.core.DataType<Binary>

Besides the dtype change, WKB payloads > 2 GiB (~16M hexagon polygons) would panic on offset overflow, and it's inconsistent with cells_to_wkb_points / vertexes_to_wkb_points / directededges_to_wkb_linestrings, which still use <i64>. Suggested fix: GenericWkbArray<i64> (or the LargeWkbArray alias).

2. Empty geometries now yield nulls instead of empty cell lists. geo_traits::to_geo::ToGeoGeometry::try_to_geometry returns None for empty geometries, and from_geoarrow.rs maps that to Ok(None) → null entry, where main returned a valid empty list (and some POINT EMPTY-style WKB previously raised an error). If intentional, it may deserve a CHANGES.rst note since wkb_to_cells(..., flatten=False) list semantics change.

3. The .expect("wkbarray") calls are now reachable. The WKB conversion error type changed from Infallible to a real error, so the pre-existing expects in the four *_to_wkb_* functions became live panic paths — worth converting to into_pyresult()?.

4. Minor: the WKB output field name changed from "geometry" to "" (extension_field() → data_type().to_field("", true)); geozero is bumped but appears to have no remaining usages and could be dropped; rasterh3 0.12 (2026-06-26) was released just after this branch and contains antimeridian/resolution-search fixes; crates/h3arrow/CHANGES.md has no entry for the 0.5.0 bump.

If you don't mind, I can propose these improvements directly in the PR, and you can validate them later on.

[nmandery]

Hi @regislon Thanks for looking into this - these are all valid findings. Please just go ahead and start a PR to address these.

For some of the issues like point 3 and the rasterh3 upgrade I also have started to prepare fixes, but so far that is not finished.

[keewis]

some small nits, otherwise this looks good to me (and tests pass). Shall we merge this now and follow up with smaller PRs afterwards?

[keewis]

@nmandery, my suggestions here are purely aesthetical (I guess), so feel free to merge whenever you feel this is ready.

How do we proceed with #94? Should we convert both into stacked PRs?

[nmandery]

Your suggestions are perfectly valid and I would also prefer to have them addressed.

Not having worked with stacked PRs before, I would simply merge #94 into #90 and then into main.

[keewis]

@nmandery, I've added the small changes I've suggested in the reviews. Should CI pass, I'll merge this in a week and release afterwards (though if you have the time feel free to merge and optionally release yourself).

[keewis]

thanks again!