gap: a crop parcel is drawn but its crop can never be named #222

New issue

Closed

opened 2026-08-30 08:37:36 +00:00 by viberfox-agent · 0 comments

viberfox-agent commented

2026-08-30 08:37:36 +00:00

Collaborator

Found while QA-ing what #203 shipped (#217).

What I did

Stood in for cartopy's unwritten server/pipeline/brp.ts: pulled the RVO crop
register off the live PDOK OGC API for two z14 cells, wrote the exact tree
systems::crops fetches (/brp/coverage.json, /brp/14/<x>/<y>.json), served it
on loopback and pointed the client at it with CARTO_3DBAG_URL. Flew to the
Flevoland cell and looked at the fields.

What happened

The parcels draw, each crop in its own tone (crop_parcels=94 in --dump-state,
a visibly different picture from the flat green the same viewpoint drew before).
Then there is no way to find out what any of them is.

The register's headline fact is the crop: every feature carries gewascode
plus a name — 233 / "Tarwe, winter-", 1098 / "Peren. Aangeplant voorafgaande aan lopende seizoen.", 6660 / "Uien, gele zaai-". The wire carries the number,
cartopolis_geo::crops::rgb turns it into a colour, and the number is then
dropped. Nothing in the client names a crop: no legend, no hover, no proximity
prompt, no readout. The only user-visible trace of the whole layer is one
attribution line at the bottom of the Map layers panel.

So a player sees the countryside turn into a patchwork of fourteen pale tones and
has no way to learn what a single one means — while the same client will tell them
the house number of the building next door.

What a user would expect

The thing the map now knows to be readable. Any of:

the crop name in the proximity readout when standing on a parcel, next to where
the address readout already appears;
a small legend in the Map layers panel — the tone families are a short list;
the name in the place/search readout when a field is picked.

Where the seam is

crates/cartopolis/src/systems/map/crops.rs — WireParcel(usize, u32, Vec<Vec<(f64, f64)>>): category, code, rings. No name, and nothing asks the
extractor for one.
crates/geo/src/crops.rs — rgb(category, code) is the only consumer of the
code; ~60 codes are curated by hand there and each already has a comment naming
the crop family, so most of a code → name table exists as prose.
crates/cartopolis/src/systems/map/world_places.rs /
systems/player/interact.rs — where a "what am I standing on?" readout would
have to hang. CellPlaces keeps only a parcel count.

Two ways to close it: have the extractor send the register's own gewas string
per parcel (bytes: ~30 per parcel, against the ~40 KB a heavy cell already
costs), or ship a code → name table beside the tone table. The first stays
correct as the register adds codes each year; the second needs no wire change.

Found while QA-ing what #203 shipped (#217). ## What I did Stood in for cartopy's unwritten `server/pipeline/brp.ts`: pulled the RVO crop register off the live PDOK OGC API for two z14 cells, wrote the exact tree `systems::crops` fetches (`/brp/coverage.json`, `/brp/14/<x>/<y>.json`), served it on loopback and pointed the client at it with `CARTO_3DBAG_URL`. Flew to the Flevoland cell and looked at the fields. ## What happened The parcels draw, each crop in its own tone (`crop_parcels=94` in `--dump-state`, a visibly different picture from the flat green the same viewpoint drew before). Then there is no way to find out what any of them is. The register's headline fact is the **crop**: every feature carries `gewascode` plus a name — `233 / "Tarwe, winter-"`, `1098 / "Peren. Aangeplant voorafgaande aan lopende seizoen."`, `6660 / "Uien, gele zaai-"`. The wire carries the number, `cartopolis_geo::crops::rgb` turns it into a colour, and the number is then dropped. Nothing in the client names a crop: no legend, no hover, no proximity prompt, no readout. The only user-visible trace of the whole layer is one attribution line at the bottom of the Map layers panel. So a player sees the countryside turn into a patchwork of fourteen pale tones and has no way to learn what a single one means — while the same client will tell them the house number of the building next door. ## What a user would expect The thing the map now knows to be readable. Any of: * the crop name in the proximity readout when standing on a parcel, next to where the address readout already appears; * a small legend in the Map layers panel — the tone families are a short list; * the name in the place/search readout when a field is picked. ## Where the seam is * `crates/cartopolis/src/systems/map/crops.rs` — `WireParcel(usize, u32, Vec<Vec<(f64, f64)>>)`: category, code, rings. No name, and nothing asks the extractor for one. * `crates/geo/src/crops.rs` — `rgb(category, code)` is the only consumer of the code; ~60 codes are curated by hand there and each already has a comment naming the crop family, so most of a `code → name` table exists as prose. * `crates/cartopolis/src/systems/map/world_places.rs` / `systems/player/interact.rs` — where a "what am I standing on?" readout would have to hang. `CellPlaces` keeps only a parcel *count*. Two ways to close it: have the extractor send the register's own `gewas` string per parcel (bytes: ~30 per parcel, against the ~40 KB a heavy cell already costs), or ship a `code → name` table beside the tone table. The first stays correct as the register adds codes each year; the second needs no wire change.

viberfox-agent added the

qa-gap

label

2026-08-30 08:37:36 +00:00

viberfox-agent added this to the Viberfox project

2026-08-30 08:37:41 +00:00

viberfox-agent referenced this issue

2026-08-30 08:37:52 +00:00

cartopy: server/pipeline/brp.ts — the extractor half of the crop parcels #204

viberfox-agent referenced this issue

2026-08-30 08:38:52 +00:00

QA: what #203 shipped — RVO crop parcels (BRP), PDOK OGC API: is it worth wiring in? #217