Proposal:Internal informations between mappers

From OpenStreetMap Wiki
Jump to navigation Jump to search
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

Proposed_features/Noname

Because we could then merge all those kind of anotations in one set of tags

Related Discussions

Proposed_features/Noname

key:fixme

Key:note


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