Parse OSM relations in the bake #8

Closed
opened 2026-10-17 20:40:00 +00:00 by sermuns · 3 comments
Owner

liuverse-fetch-map/src/osm.rs parses an OsmMap with only node and way
elements. The campus extract carries 114 relations that are dropped entirely,
because the struct has no relation field:

 37  route                     17  restriction           12  multipolygon/grass
 12  route_master              10  public_transport        3  boundary
  3  multipolygon (other)       2  multipolygon/forest     2  superroute
  1  multipolygon/golf_course  1  disc_golf_course        1  multipolygon/park
  1  multipolygon/wood         1  network                 1  site
  1  type=site                1  destination_sign

Nine of the multipolygon relations are buildings -- I-huset, D-huset,
Fysikhuset, A-huset, B-huset, C-huset, Angstromhuset, Odalmannens
lantbruksmuseum, Terra -- and their member ways are untagged: no building=*
on any outer ring, so buildings_of (osm.rs:265) skips them. They are only
present today where MazeMap happens to publish the same hall under a different
survey.

This issue is the mechanism only: add OsmRelation { id, tags, members } to
OsmMap (an OsmMember carrying kind / ref / role, as the XML serves
them), and assemble rings for type=multipolygon -- outer members minus inner
ones, selected by role. Nothing is added to BakedWorld here.

Follow-up issues build the courses, routes, bus lines and boundaries on top of
it.


Related

  • #29 bus and national-trail routes
  • #30 district boundaries
  • #35 the site relation
  • #41 Bla havet is a multipolygon
  • #46 the allotment relation
  • #50 destination signs
  • #51 the tag census this came from
`liuverse-fetch-map/src/osm.rs` parses an `OsmMap` with only `node` and `way` elements. The campus extract carries **114 relations that are dropped entirely**, because the struct has no `relation` field: ``` 37 route 17 restriction 12 multipolygon/grass 12 route_master 10 public_transport 3 boundary 3 multipolygon (other) 2 multipolygon/forest 2 superroute 1 multipolygon/golf_course 1 disc_golf_course 1 multipolygon/park 1 multipolygon/wood 1 network 1 site 1 type=site 1 destination_sign ``` Nine of the `multipolygon` relations are buildings -- I-huset, D-huset, Fysikhuset, A-huset, B-huset, C-huset, Angstromhuset, Odalmannens lantbruksmuseum, Terra -- and their member ways are **untagged**: no `building=*` on any outer ring, so `buildings_of` (`osm.rs:265`) skips them. They are only present today where MazeMap happens to publish the same hall under a different survey. This issue is the mechanism only: add `OsmRelation { id, tags, members }` to `OsmMap` (an `OsmMember` carrying `kind` / `ref` / `role`, as the XML serves them), and assemble rings for `type=multipolygon` -- outer members minus inner ones, selected by `role`. Nothing is added to `BakedWorld` here. Follow-up issues build the courses, routes, bus lines and boundaries on top of it. --- **Related** - #29 bus and national-trail routes - #30 district boundaries - #35 the `site` relation - #41 Bla havet is a multipolygon - #46 the allotment relation - #50 destination signs - #51 the tag census this came from
Author
Owner

This is the right shape: parser and ring assembly only, no BakedWorld changes, multipolygon outers minus inners. It unblocks #29, #30, #35, #41 and #46 without committing to any of them, and the nine building relations are a real correctness fix on their own. Do this before the features that depend on it.

This is the right shape: parser and ring assembly only, no `BakedWorld` changes, multipolygon outers minus inners. It unblocks #29, #30, #35, #41 and #46 without committing to any of them, and the nine building relations are a real correctness fix on their own. Do this before the features that depend on it.
Author
Owner

The mechanism is in, for the case the shuttle needed.

PR #105 adds relation to the OsmMap the bake reads: an OsmRelation with its tags and its members, each member carrying its type, reference and role, which is what the XML serves. The relation ids are not kept, because nothing needed them yet.

What it is used for so far is the campus shuttle's routes (#28, #29): route=bus relations of the campus's own shuttle network become BakedRoutes with the line they drive and their stops.

What is still open here is the rest of the list, and the part that matters most for the campus is the buildings: nine of the multipolygon relations are halls — I-huset, D-huset, Fysikhuset, A-huset, B-huset, C-huset, Angstromhuset, Odalmannens lantbruksmuseum, Terra — whose member ways carry no building=* tag, so buildings_of skips them and they are only present today where MazeMap happens to publish the same hall under a different survey. Assembling rings for them needs outer members minus inner ones, selected by role, which is what this issue describes.

Refs #105

The mechanism is in, for the case the shuttle needed. PR #105 adds `relation` to the `OsmMap` the bake reads: an `OsmRelation` with its tags and its members, each member carrying its type, reference and role, which is what the XML serves. The relation ids are not kept, because nothing needed them yet. What it is used for so far is the campus shuttle's routes (#28, #29): `route=bus` relations of the campus's own shuttle network become `BakedRoute`s with the line they drive and their stops. What is still open here is the rest of the list, and the part that matters most for the campus is the buildings: nine of the `multipolygon` relations are halls — I-huset, D-huset, Fysikhuset, A-huset, B-huset, C-huset, Angstromhuset, Odalmannens lantbruksmuseum, Terra — whose member ways carry no `building=*` tag, so `buildings_of` skips them and they are only present today where MazeMap happens to publish the same hall under a different survey. Assembling rings for them needs outer members minus inner ones, selected by `role`, which is what this issue describes. Refs #105
Author
Owner

Both halves of this issue mechanism have been implemented, so closing as implemented.

  • The parser is in. osm.rs parses OsmRelation { id, tags, members } with the member kind/ref/role that the XML provides (789e48b, PR #105).
  • Ring assembly is in. relation_building assembles the footprint of a type=multipolygon relation carrying a building tag: member_ring for outer, member_rings for inner holes, selecting by role. buildings_of bakes it as a shell whose tags come from the relation, so the halls with untagged member ways — I-huset, D-huset, Fysikhuset, A through C-huset, Angstromhuset, Terra and the rest — finally appear even when MazeMap does not publish them (d8606a0).

The mechanism is already carrying two features: the shuttles that became BakedRoute (routes_of), and the relation buildings above. The remaining consumers (#30, #35, #41, #46, #50) are each their own problem.

Refs #105

Both halves of this issue mechanism have been implemented, so closing as implemented. - **The parser is in.** `osm.rs` parses `OsmRelation { id, tags, members }` with the member kind/ref/role that the XML provides (`789e48b`, PR #105). - **Ring assembly is in.** `relation_building` assembles the footprint of a `type=multipolygon` relation carrying a `building` tag: `member_ring` for `outer`, `member_rings` for inner holes, selecting by role. `buildings_of` bakes it as a shell whose tags come from the relation, so the halls with untagged member ways — I-huset, D-huset, Fysikhuset, A through C-huset, Angstromhuset, Terra and the rest — finally appear even when MazeMap does not publish them (`d8606a0`). The mechanism is already carrying two features: the shuttles that became `BakedRoute` (`routes_of`), and the relation buildings above. The remaining consumers (#30, #35, #41, #46, #50) are each their own problem. Refs #105
Sign in to join this conversation.
No description provided.