Proposed features/Internal quality
| internal informations about osm data quality | |
|---|---|
| Status: | Abandoned (inactive) |
| Proposed by: | * |
| Tagging: | validate:*=continuously expending |
| Applies to: | linear, area, node, relation |
| Definition: | A set of code to ease controls on existing data |
| Rendered as: | <appearance> |
| Draft start: | 2008-11-24 |
| RFC start: | 2008-11-24 |
| Vote start: | |
| Vote end: | |
Contents |
proposed by
Petschge on the talk list and user:Sletuffe on the wiki
This is simplified version 2, more focused on validators tools than data information.
Rationale
We might have come to a point where there is many data in the database, but sometimes we don't know if it as been surveyed, if it is correct or if it needs some more work. And the current model of osm is to move arround, take a note on something and go back to the database to see if it match our note or not. So loosing an extra amount of time doing something that has allready been done.
Validation tools have been set up but sometimes, they don't know if an alerte should be raised or not, and that set of tags will help them
Example of problem
The first example that comes to my mind is name=*
When you come across a feature with no name=* you don't know what's really going on between :
- Does this feature have no name ?
- Didn't the mapper who tagged it know it's name ? (think of street tagged based on imagery)
Current solutions are :
- Tag it with something like name=__noname__ or noname=yes (etc etc) if you know it has no name (see Proposed features/Noname)
- Or set it's name
That could be a good solution, but it might polute the database in many places and would need to find a local solution for many other case.
The note=* tag solution is very good because it can explain anything to anyone with words, but we cannot take advantage of it in a computer aware process (think of a map showing all streets that have a name to add !)
Solution
Here I am proposing a global tag format to this problem to be extensible on a quite "normalized" way to many possible problem case. without need to find a new tag each time, by the fact that because it's under the validate: namespace, a mapper or validation tool will know it concerns a data about the data.
Having also a quick and efficient way (read : by a bot) to filter those tag out, remove them.
Additions to this tag would be first discussed and voted on a separte page and then added to the list of possible "validate" values
Applies to
Any object
Tag, Values and Usage
Here are the first I'm thinking of plus some that Petschge have added, but any new values are welcome to be discussed, I could start a vote on "nothing" but that would be just too virtual and of no use before someone propose some value.
- Do not ABUSE those tags, if you don't know, just don't use them, they are made for when you know that there is (no_ref, no_name, no_something)
- Do not use them just to shut up a validator.
| Proposal key /value | meaning |
|---|---|
| validate:no_name=yes | The object has no name, and a search has been done to confirm that. |
| validate:no_name=no_sign | There are no ways to find the name based on a local survey. No needs to go there again in a short term. |
| validate:no_name=ignore | Whatever the reason or value is, validators shouldn't complain about missing name. |
Other refused tags but still in use by some validators are here. I just want to go slowly on a minimum agreement Internal quality/Other tags to vote on later
Is all that just virtual ?
- Not any more, this tool I've created : Yet another validation tool for osm data supports some of them
- The maplint layer should soon support some of those features infos here
- Note that maplint recognizes validate:name-of-test=ignore since a couple of days, but offers no way to indicate "no sign" or other advanced annotation.
Deprecates
Because we could then merge all those kind of annotations in one set of tags
Related Discussions
Comments
please use the talk page for discussion
I would also apreciate a comment about the "noname layer" and "openstreetbug" developpers about implementing use of such a tag.
Voting
The old voting for version 1 is here Proposed features/Internal quality/old_votes it ended with a refuse. Time for version 2, voting it later.
