Skip to content

Design: OSM way/relation ingestion and sub-place hierarchy #101

Description

@koinsaari

Goal

Design and implement ingestion of OSM ways and relations (polygons) — large venues like malls, hospitals, universities, parks — and wire them into the parent_id hierarchy so enclosed OSM nodes become sub-places.

Tracking under #10.

Context

Current ingestion only processes OSM nodes. Ways and relations are skipped entirely. This means:

  • A mall exists in OSM as a way (polygon), not a node — it is absent from places today.
  • Individual shops inside that mall exist as nodes and are ingested — but with parent_id = NULL, as if they were standalone.
  • The 3-level rank system (1=Landmark, 2=Establishment, 3=Feature) is derived purely from category + tags, with no awareness of spatial containment.

Decisions already made

  • Schema is ready: geometry JSONB, parent_id UUID REFERENCES places(id) both exist.
  • Way ingestion auto-assigns parent_id via spatial containment — ingestion does the spatial join, not the API.
  • This is additive: existing Wheelmap external_ids attached to node-places are unaffected when parent_id is later set on those nodes.
  • The retroactive containment sweep (assign parent_id to nodes already in DB that fall inside a newly ingested way) must be idempotent.

Open questions

  • Rank for contained nodes: should a shop node spatially inside a mall way be demoted from rank 2 → 3? Or does rank stay category-derived and clients filter by parent_id? Decide before implementing.
  • Geometry representation: ways are polygons — store as GeoJSON in geometry JSONB, or add a PostGIS GEOMETRY column? The existing geometry JSONB column was added speculatively; evaluate whether PostGIS native type is worth the migration cost.
  • Relation handling: OSM relations (multipolygons, e.g. large parks) — in scope for this issue or a follow-up?
  • Deletion: when a way is deleted in an OSM diff, do its former child nodes get parent_id cleared, or stay associated?
  • Rank constraint: current CHECK (rank IN (1, 2, 3)) covers the node world. If contained nodes get a 4th rank level, migration needed — trivial pre-production, needs a plan post-production.

Out of scope

  • Non-OSM sources for polygon data.
  • Moderation or review UI for auto-assigned parent relationships.
  • Manual parent_id override via API (already works today).

Acceptance

  • OSM way polygons ingested as places rows with geometry populated.
  • Existing nodes spatially inside ingested ways have parent_id set (retroactive sweep + ongoing).
  • Rank behavior for contained nodes is explicitly decided and documented.
  • At least one integration test covering a small way fixture with enclosed nodes.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions