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 _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
