[Tagging] Map maintenance with StreetComplete - Preferred tagging

Jmapb jmapb at gmx.com
Sun Jul 26 20:00:53 UTC 2020


Hi Tobias, I've been giving this some thought. My conclusion is that
user validation of tags shouldn't be stored in the same database table
as the tags themselves. It's clear that as the map data ages, tag
validation is going to be a task with parallel and equal importance to
tagging itself, but with its own workflows and complexities. The
validation will have its own history separate from the tagging history,
and I believe it would be best to design the data model accordingly.

Using nodes as an example for the moment, I'd like to consider the
creation of a new table alongside node_tags, perhaps called
node_tag_validation. I imagine the fields would be:
  - node_id
  - user_id
  - tag key
  - current node version (to identify the current tag value being
validated -- or maybe just a copy of the current tag value, if that's
too cumbersome)
  - validation result (valid/invalid/unsure)
  - optional comment
  - timestamp

This would allow a map validator to:
  - confirm a tag or subset of tags, rather than the state of the entire
element
  - record agreement without updating the element
  - record unverifiability/disagreement/skepticism without changing or
deleting a tag (since sometimes there's middle ground between confirming
a certain tag and knowing that it's incorrect.)
  - weigh in on the validity/invalidity of the *absence* of a particular
tag, which can be just as important as evaluating the tags that are there.

It would also allow easy query of various users' judgement of a
particular tag over time, which would allow for more informed survey and QA.

This design would eliminate some of the potential problems that have
come up in this thread:
  - check date tags getting out of sync with tag values
  - overcrowding elements with check date tags, and the verifiability of
these tags (the validation history can have looser verifiability
requirements than the map data)
  - resistance to changesets that make no actual changes but simply
update a timestamp (and increment the version) to indicate new validation
  - debate over correct implementation of namespaces (eg
check_date:smoothness or smoothness:check_date)

Note that this table (or these tables, presuming one each for
node/way/relation) would not actually need to reside in the OSM database
itself, although that would make it easier if the goal were to share
among multiple QA projects, not just StreetComplete.

Thanks for your work!
Jason




More information about the Tagging mailing list