Proposal:Noname

Noname
Proposal status:	Abandoned (inactive)
Proposed by:	Rorym
Draft started:	2008-09-21

Tools like the NoName layer give an indication of mapping progress, by highlighting streets where we haven't gathered the name yet. But what if a street really doesn't have a name?

Motivation

There are some features (eg roads) that nearly always have a certain tag (eg name=*). The absence of those tags usually means the mapping is incomplete. However sometimes roads don't have a name. OpenStreetMap is an evolving project and is not finished yet, so there needs to be a way to record that the absence of a name tag is not a flaw in OpenStreetMap.

This is a topic that comes up frequently on the mailing lists, eg: [1], [2]

Summary

There is no clear consensus on how to map streets with no name among the OpenStreetMap project. These tag proposals will help to distinguish unnamed roads because the name was unknown (then just add the tag "name" when you know it) with roads that have really and officially no name at all.

Options

There are a few options for recording this. Please edit this section to flesh out the options and add your own options, please use the talk page for discussion. First we need to decide which option fits best and then propose that for voting.

unsigned=yes

Adds a new top level tag unsigned=*, with two possible boolean values. unsigned=yes, which means that this feature (way) does not have a name sign. There is minimal useful case for unsigned=no, i.e. that there is signage present. However, even if the name=* tag is present, then unsigned=yes may be useful - if the name has been determined other than from a sign, e.g. local knowledge, NPE, etc.

Pros

• This would allow us to enter the data for ways which have official designations but which to not have signs for that official designations in place (i.e., Interstate 296 in Michigan, and the unsigned state routes in GA, USA in the 400-499 range). (Perhaps this tag needs to be created specifically for such scenarios.)

Cons

• "Unsigned" could apply to anything. The link with the fact that it's the street name sign that's missing isn't obvious.
• Just cause something is unsigned doesn't mean it has no name. Something that has a sign clearly has a name, but we're still stuck in cases where there is no sign and no name vs there is no sign and there is a name.

noname=yes

Adds a new top level tag noname=*, with one possible value, noname=yes, which means that this feature does not have a name. There is no useful case for noname=no, since if the name=* tag is present, then noname=no is implied. If a feature has a name=* and noname=yes, then the name tag takes preference and the feature has a name (specified by the name tag). The noname=yes tag should be regarded as a bug in this case and can be removed.

Pros

• currently the only supported tag in maplint. (Along with validate:residential-without-name=ignore)
• Calling it 'noname' makes clear the connection with the 'NoName' map layer.
• Intuitive and widely used (taginfo)

Cons

• The wording makes some people think of 'no=yes'.
• The concept does not prevent setting name=* and noname=yes at the same time. But Maplint could test this.
• It doesn't make a distinction between features which have no name, and those which have no sign indicating a name. (However, one could use both noname and unsigned; unsigned=yes if there is no street sign, and only add noname=yes if it is definitely established that the street does not have a name.)

unnamed=yes

Adds a new top level tag unnamed=*, with one possible value, unnamed=yes, which means that this feature does not have a name. There is no useful case for unnamed=no, since if the name=* tag is present, then unnamed=no is implied. If a feature has a name=* and unnamed=yes, then the name tag takes preference and the feature has a name (specified by the name tag). The unnamed=yes tag should be regarded as a bug and can be removed.

Pros

• noname=yes makes people think of 'no=yes', but unnamed=yes does not have such a confusion.

Cons

• The concept does not prevent setting name=* and noname=yes at the same time. But Maplint could test this.
• This value isn't explicit about: does the feature has not a name, or does the feature has no local sign to find it's name Sletuffe 14:20, 24 November 2008 (UTC)

T:absent = yes

More of a general scheme than a new top level tag. In this case, a new top level tag name:absent=* with one possible value name:absent=yes, which means that this feature does not have a name. There is no useful case for name:absent=no, since if the name=* tag is present then name:absent=no is implied. If a feature has a name=* and name:absent=yes, then the name tag takes preference and the feature has a name (specified by the name tag). The name:absent=yes tag should be regarded as a bug and can be removed.

This can be used by any top level tag, to mean that this tag is normally present for this feature, but in this special case is not defined. Example:

• a multi-denominational christian church could be tagged: amenity=place_of_worship, religion=christian, denomination:absent=yes
• A bus stop (amenity=bus_stop) with no fixed operator, could be tagged amenity=bus_stop, operator:absent=yes

Pros

• Similar scheme to the popular language tags, eg name:fr=*
• General to all top level tags
• Can be generalised to missing language specific tags, eg name:en:absent=yes for features that have no English name, but one would assume had an English name (like in Gaeltacht areas).

Cons

• The concept does not prevent setting name=* and name:absent=yes at the same time. But Maplint could test this.

missing_tags=name;...

A new top level tag, missing_tags=*, which lists a semi-colon separated list of top level tags that are not present. If a feature has name=* and missing_tags=name, then the name tag takes preference and the feature has a name (specified by the name tag). The missing_tags=name tag should be regarded as a bug and can be removed.

Cons

• This is a multi-value tag. There is no cross community decision on how to tag these. See Proposed_features/Value_separator
• The concept does not prevent setting name=* and missing_tags=name at the same time. But Maplint could test this.
• This does not solve the problem. Unless there is missing_tags=no, one would have to map every other way in the whole OSM so that the absence of this tag really means that this way has no name. Also, one would have to be omniscient to tell if there are really no tags missing. If you know that something's missing, adding a note=*=* makes more sense to point out non obvious stuff (i.e. it's not useful to tag every 2nd road with missing_tags=surface)

Special value for name

Reserve a special value for the name tag to represent that there is no name for the tag, eg name=__none__.

Possible values:

• blank
• __none__
• none
• \none
• None (taginfo)

Pros

• It's impossible to get inconsistent. The feature either has a name or it is explicitly marked as unnamed
• It's really easy, quick, and any idiot can do it!

Cons

• Rendering softwares need to explicitly take it into account. Otherwise a street with a strange name appears (likewise for other types of software using the data) [but if it's the default software will take care]
• If there is an actual feature called "none" (or whatever the value is), then the map is unable to represent this. Clearly there aren't many roads in the world called "none", and even fewer called "__none__" or "\none", but there may still be reasons for wanting to set these as actual name values. ["__none__" is more comprehensible, then just an escape character as "\" will allow to name those objects]
• The absence of a feature is usually indicated by not adding the relevant tag. E.g. instead of tagging roads without cyclelanes with cyclelane="no" they do not get a cyclelane tag at all. Having a special none value for street names would break with this convention.

Empty value for name

If a feature does not have a name, then set the name tag to "", eg name=*

Pros

• It's impossible to get inconsistent. The feature either has a name or it is explicitly marked as unnamed

Cons

• None of the current editors support setting an empty value for a tag ([3])
• An empty string for a value looks confusing and might get deleted as 'empty data'

test_ignore=[street_has_name]

A list of tests which will fail on this object and should therefore not run to prevent false alarms. This provides a general solution to problems arising from quality assurance tests which might fail on some objects, because they are somehow exceptional. The test_ignore-tag would provide a way of specifying that someone checked that it is okay for a particular test to fail (i.e. the every-street-needs-a-name-test).

Apart from introducing the new tag it would be advisable to keep a list of tests and test names on the wiki.

Pros

• It explicitly solves the problem which motivated this proposal: Validators which complain about missing street names.
• It is a solution for a whole class of similar problems (i.e. other things validators complain about).
• It does not introduce the idea of mapping absent features into osm.

Cons

• This is a multi-value tag. There is no cross community decision on how to tag these. See Proposed_features/Value_separator.
• It's more complicated to understand than other proposals. It's not immediatly obvious what this tag does. If Joe Newbie looks a road and it's tagged "unnamed=yes" or "name:absent=yes" or "noname=yes", then he can reasonable deduce that the road has no name. Many people might see "test_ignore=street_has_name", and not know what it means.
• Requires us to then agree on standard tests and what they mean. What is the 'street_has_name' test? Ireland is a bilingual country, so in theory if a street that has only name=* tag and is missing the name:ga=* tag, then it's name is not complete. But that only applies to Ireland.
• The concept does not prevent setting name=* and test_ignore=street_has_name at the same time. But Maplint could test this.

validate:no_name=*

As described here : Proposed_features/Internal quality it includes general meta-informations on the data in the validate: namespace. and propose as a solution :

• validate:no_name=yes The object has no name, and a search has been done to confirm that.
• validate:no_name=no_sign There is no way 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.

This value is already used on a noname renderer alternative : Yet_another_validation_tool_for_osm_data