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.