Proposal:Internal informations between mappers
| internal informations between mappers | |
|---|---|
| Proposal status: | Abandoned (inactive) |
| Proposed by: | sletuffe |
| Tagging: | internal:*=continuously expending |
| Applies to: | linear, area, node, relation |
| Definition: | A set of code to ease controls on existing data |
| Statistics: |
|
| Draft started: | |
| Proposed on: | 2008-10-13 |
| RFC start: | 2008-10-13 |
| Vote start: | * |
| Vote end: | * |
replaced
Here is a new proposal, much like this one to replace it, that propose to help data validation and tests, and knowledge of quality of tags Internal quality
- So this proposal is about to be ABANDONNED Sletuffe 09:40, 25 November 2008 (UTC)
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.
Examples of problem
The two first examples that comes to my mind are the name=* and the oneway=* tags, but there could be many other case.
When you come across a feature with no tag name=* or with no tag oneway=* you don't know what's really going on between :
- Does this feature has no name and is a two way street
- Does the person who tagged it didn't know it's name or if it was a oneway street ( think of street tagging based on yahoo imagery )
Current solutions proposed are :
- Tag it with name=__noname__ and oneway=no if you know it has no name and is a two way street
- Or set it's name and set a oneway=yes
- set a note=* to explain to others what is the case here
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 anithing 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 solution 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 internal: namespace, a mapper will know it concerns a internal information.
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 "internal" values
Applies to
Any object
Tag, Values and Usage
Here are the first I'm thinking of, 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.
An object in the database can have from no to many internal tags as needed
New proposal as of Sletuffe 17:21, 11 November 2008 (UTC)
| Proposal | meaning : |
|---|---|
| internal:name=noname | The object as noname, and a search has been done to confirm that. |
| internal:name=noname_sign | There are no way to find the name based on a local survey. No needs to go there again in a short term. |
| internal:trace=bad_gps | The GPS track used to tag this object was poor. |
| internal:my_own=yes | A way in a local survey for you and who wants to enlight what's left ! Explanation on the talk page |
This proposal used to have a key for oneway tag and for fixme tag, but it has been shown to my attention that
- fixme=* allready exists
- the oneway case could be handeld by oneway=no
Also I would prefer to incorporate them into one ony namespace, since they are wildly use, there is no urge to do so.
Is all that just virtual ?
Well since now, not any more, this tool I've created can enlight no name, no oneway and fixme Sletuffe 17:26, 11 November 2008 (UTC) -- Not anymore
Possible conflict
One question always asked about the noname proposal is : who is to trust ?
What to do/think when we have something like :
- highway=residential
- name=Hell street
- internal:name=noname
Well, whatever the truth is, there is an error, either the internal tags shouldn't be there, either the name and oneway tags are wrong.
In this case, a mappers rendering tool should enlight that street to ask for a survey and proper action.
Deprecates
Because we could then merge all those kind of anotations in one set of tags
Related Discussions
Comments
please use the discussion page
I would also apreciate a comment about the "noname layer" and "openstreetbug" developpers about implementing use of such a tag.
Voting
not yet