Skip to content

Flag OSM-only features whose brand/operator/network Wikidata ID ATP tracks elsewhere #682

Description

@brawer

Idea

Emit OSM-only rows in conflated.parquet (empty atp side) for OSM features whose brand:wikidata/operator:wikidata/network:wikidata is one AllThePlaces actually has data for elsewhere -- a sharper "might be worth a mapper's look" signal than emitting every unmatched OSM feature would be.

Motivation

If alltheplaces.zip has a place with brand:wikidata=Q564213 (Tchibo), and OSM has a shop node/way tagged brand:wikidata=Q564213 near that location that didn't get matched by conflate(), that's an interesting mismatch: it might mean a store closed (per the brand's own website, as scraped by ATP) but is still mapped in OSM as if it exists -- worth a human mapper checking it out.

This can't be done blindly for every unmatched OSM feature -- ATP will never have data for every tree, hydrant, bench, etc. in the world, so most unmatched OSM features are unmatched for a completely mundane reason (out of ATP's scope), not because they're stale. Restricting to brands/operators/networks ATP actually tracks keeps the signal meaningful instead of just dumping the planet.

What already exists

src/atp/wikidata_ids.rs (collect_wikidata_ids, added in #681) already computes the set of Wikidata IDs referenced by ATP data (via wikidata/brand:wikidata/operator:wikidata/network:wikidata tags) and writes it to workdir/alltheplaces.wikidata-ids as a U64Set, as its own cheap pipeline step (a plain tag scan, no geographic computation -- much cheaper than the old build_coverage, which this replaced). It runs on every pipeline invocation today, but nothing consumes its output yet.

What's still needed

  • In conflate(), for OSM features that don't match any ATP feature: check whether the OSM feature's own brand:wikidata/operator:wikidata/network:wikidata is in alltheplaces.wikidata-ids, and if so, emit a conflated.parquet row with an empty atp side and the OSM feature populated.
  • Decide how downstream consumers (suggest_edits, tile layers, whatever eventually reads these OSM-only rows) should treat them -- they're not "suggested edits" in the tag-diff sense EditSuggester handles today; they're closer to "flagged for human review," a different kind of output.
  • Probably worth a dedicated tile layer / GeoJSON output distinct from shops.jsonl's edit suggestions, since the semantics differ (this isn't proposing a specific tag change, just surfacing a discrepancy).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions