R121's decoded-tile check needs a mapsrv-side MVT decoder (not a SQL acceptance test) #138

New issue

Closed

opened 2026-08-16 01:17:24 +00:00 by art · 1 comment

art commented

2026-08-16 01:17:24 +00:00

Owner

Part of the #115 plan and the #125 remainder: R121's decoded-tile half (docs/country-requirements.md R121: "Confirms stop_z, mvt_exclude and the attribute set at once") cannot be an importer acceptance test, because the check needs to parse the served MVT. MVT is protobuf; Postgres has no decoder and no protobuf extension, so a SQL test would have to reimplement the wire format in SQL — thousands of lines of varint parsing for a check that is meant to be cheap. #125 ships the stop_z half as the R30 floor/ceiling tests and scopes this half out with this reason.

Proposal: a Go test in mapsrv (or importer) that connects to the live DB, serves/decodes a tile per layer via the zxy_<layer> functions, and asserts the tile's keys equal the contract's mvt_exclude-adjusted attr_names. The pieces that exist: scripts/mvt-decode.py is the hand decoder (fields() walks the tile/layer/feature protobuf), and mapsrv's glyph test already decodes protobuf in Go (mapsrv/glyph_check_test.go decodeGlyph) — so the decoder pattern is established on both sides. Where it should live and how it gets run (a make target? part of mapsrv tests?) is the open question; the acceptance-test mechanism deliberately covers only SQL against the database, so this is a new, separate mechanism rather than an extension of it.

What the check would assert per shared layer: the tile's layer keys = attr_names minus mvt_exclude plus the machinery columns (geom, country). A leak (part_key on cover, rank on places) or a dropped attribute goes red.

Part of the #115 plan and the #125 remainder: R121's *decoded-tile* half (docs/country-requirements.md R121: "Confirms stop_z, mvt_exclude and the attribute set at once") cannot be an importer acceptance test, because the check needs to parse the served MVT. MVT is protobuf; Postgres has no decoder and no protobuf extension, so a SQL test would have to reimplement the wire format in SQL — thousands of lines of varint parsing for a check that is meant to be cheap. #125 ships the `stop_z` half as the R30 floor/ceiling tests and scopes this half out with this reason. Proposal: a Go test in mapsrv (or importer) that connects to the live DB, serves/decodes a tile per layer via the `zxy_<layer>` functions, and asserts the tile's keys equal the contract's `mvt_exclude`-adjusted `attr_names`. The pieces that exist: `scripts/mvt-decode.py` is the hand decoder (fields() walks the tile/layer/feature protobuf), and mapsrv's glyph test already decodes protobuf in Go (mapsrv/glyph_check_test.go decodeGlyph) — so the decoder pattern is established on both sides. Where it should live and how it gets run (a `make` target? part of mapsrv tests?) is the open question; the acceptance-test mechanism deliberately covers only SQL against the database, so this is a new, separate mechanism rather than an extension of it. What the check would assert per shared layer: the tile's layer keys = `attr_names` minus `mvt_exclude` plus the machinery columns (geom, country). A leak (part_key on cover, rank on places) or a dropped attribute goes red.

art commented

2026-08-16 05:38:01 +00:00

Author

Owner

#139 is a duplicate with more activity.

art closed this issue

2026-08-16 05:38:01 +00:00