create-stac-collection: the bbox is the extent of the geometries

[ivorbosloper]

create-stac-collection transformed the corners of the source bbox to EPSG:4326. In a projected CRS those corners reach beyond the data, so the collection's bbox was too wide (for Saxony in EPSG:25833 about 0.08° on the west side). It now transforms the geometries and takes their extent, skipping the transform for data already in EPSG:4326.

• Found through Portolan's PTL-DAT-005 on the harmonized field data catalog, where the PMTiles (tippecanoe writes the true extent) disagreed with the declared bbox for every collection in a projected CRS.
• Transforming every geometry costs time on large files; the extent is only right that way.

🤖 Generated with Claude Code

[m-mohr]

How much weight/time does this add on top of especially larger files?

I feel like the small divergence can be okay if it adds too much overhead on top of writing and portolan might be overly rigurous here. Or we add a strict mode here as well 😅

[Copilot]

Copilot review overview

🟢 Approval recommended

No unresolved issues were identified, and regression coverage is included.

Review effort: Lite
Findings: None

What changed in this PR

Updates create-stac-collection to calculate accurate STAC bounding boxes from geometries transformed to EPSG:4326.

Changes:

• Computes geometry-based extents.
• Preserves the EPSG:4326 fast path.
• Adds regression coverage and changelog documentation.

File	Summary
vecorel_cli/​create_stac.py	Computes accurate geometry-based STAC extents.
tests/​test_create_stac.py	Tests projected-CRS bbox behavior.
CHANGELOG.md	Documents the correction.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ivorbosloper]

How much weight/time does this add on top of especially larger files?

I feel like the small divergence can be okay if it adds too much overhead on top of writing and portolan might be overly rigurous here. Or we add a strict mode here as well 😅

Yes. It's slower. Measured with 1M fake parcels in EPSG:25833 with about 17 vertices each: 0.03s now 1.7 seconds . The largest data set (France, 10M) would add 15-20secs.

• But it's only used when running create-stac-collection, not in a normal convert.
• The error is "big": Saxony is about 0.08°, roughly 5–6 km on the west side. It gets worse for wide areas and away from the central meridian. Portolan gives a warning because the declared bbox is wrong.

[m-mohr]

I guess that works, wasn't sure whether it may take much longer than a minute. I'd hope Japan works? Otherwise, I'm thinking we may want a switch to disable it.