Please discuss the various options for how to tag something that has no name here
I know, it was not for discussion, but I would prefer unnammed=yes. It has not the problem with no=yes and is exact the thing we want to describe. There is no official wayname. --Krasnoj 15:29, 21 September 2008 (UTC)
The only thing that can be determine "on the ground" is whether a way has a signposted name (or not). The way may have a "real" name, but the local highway authority hasn't spent money providing a sign. There's no point going to see a road that has no signed name. There may be a point in asking locals, or consulting NPE, etc. I think it's worth capturing the difference. --Ndm 16:16, 21 September 2008 (UTC)
Recast this as unsigned_way -- so that it defaults to "no" (when empty) --Ndm 20:41, 21 September 2008 (UTC)
This may be true for the UK, but in many countries there are a *lot* of unnamed streets, bus stops, everythings, that just have no official name and sometimes not even a local one. People orientate themselves using landmarks and so forth. So we should have a tag indicating that the feature simple has no name (unsigned is different). --Peter.doerrie 12:44, 19 March 2009 (UTC)
- I prefer this option since it's similar to the name in a different language (eg name:fr=*) and because it's general enough to apply to other tags. Rorym 14:09, 21 September 2008 (UTC)
- I also prefer this option, but I do not consider it a “pro” that it shares the syntax with something completely different. Also, what is expected to happen when both name=xyz and name:absent=yes are set? --Tordanik 14:43, 21 September 2008 (UTC)
- I've clarified the proposal for what should happen if name=* and name:absent=yes are both set. It's nothing something we can enforce at the API/data level. But there are many ways to enter incorrect data into the data model (such as tagging something bridge=yes and tunnel=yes).
- Of course you’re right – there are lots of other possible inconsistencies. Still, defining expected behavior is preferable imo, thus I like the proposal even more with your addition. --Tordanik 16:27, 21 September 2008 (UTC)
- +1 for this proposal. --Eimai 15:07, 21 September 2008 (UTC)
- I favor this proposal. --TigerDuck 19:50, 22 June 2009 (UTC)
I support the idea to have tags that are only for the validity test software, just as we have tags for the renderer (like osmarender:rendername:no). I would prefer to have these keys starting with a special character, so they can be filtered out easily and reduce the amout of data if not needed, e.g. on mobile devices with little RAM. On the other hand I would like to have maxspeed=unlimited or maxspeed=none as an ordinary value, not as a test ignore feature. Any ideas how to handle this difference? --Lulu-Ann 13:42, 22 September 2008 (UTC)
In my opinion the need to have a list of standard tests with defined behaviour is not a "con" but a "pro", because this list would also describe what we like to see our data look like (And thus defining quality data). There is also already a list of tests and test names for the maplint layer and the JOSM validator on the wiki. See Maplint/Tests and JOSM/Validator.
The example of Ireland has nothing directly to do with the proposed tag. It is a general problem of how the street name test defines no-name. The other suggested options for this proposal would also have problems with the Ireland example (Tagging a road with name:gy="name" with noname="yes" to indicate that it has no plain name tag?). The advantage of the test_ignore tag is that it only specifies which tests should not be run on the tagged object; it does not matter what the test actually tests. If a bilingual country needs more than one test (e.g. testing general existence of name:* tags and of specific combinations) to verify the quality of the data, objects which intensionally fail on one or even all of the tests can easily be excluded from the relevant tests. --Xoff 21:23, 22 September 2008 (UTC)
Special value for name
I really like this proposal because it is the only way to be consistent. But, please, remove the value FIXME which has nothing to do here : "FIXME" means "I don't know" where this discussion is about "I'm sure that this way has no name". Personally, I have a preference for __none__ because it's a convention for magic key words in software programming but I could understand that it is hurting some people. Pieren 09:28, 8 October 2008 (UTC)
Going even further
I won't support options that are only named focused. It might seams to be our primary problem since the arrival of the noname verification layer, but IMHO there are many other problem we could deal with in an extensible way about verification tools and enhancement tools. About missing tags, the one that comes closer to what I have in mind is "test_ignore=X;Y;Z;A" but I would extend it right now to cover other missing stuff that can happen with a way.
First is, we are creating one more tag that is "useless" to the end user, so that's one more tag to filter out, one more tag which "polute" your JOSM or POTLATCH interface. Because the "note=*" tag allready exist for that purpose : "A note to yourself or to other mappers"
So "note=*" could be use to store inter-mappers information, that could also be processed by the "noname" renderer ( or keep another tag for that if you really want such as test_ignore= or internal_problems= or fixme= but one and only one we have to agree with ) In it, we could then create a list of possible defined codes to be understandable by a human AND by a program ( code separation could be ";" or whatevere comes out from the endless Proposed_features/Value_separator proposal, and codes inside are all optional and unlimited ) Example on a street :
- note=Still a lot of work;name_unknown;no_ref;bad_gps;end_reached;other_streets;....
Those codes are example, we could easily, create more clever codes, but you see the point because you allready understood what was missing in my example street, don't you ?
PS: in the end, the noname layer could still works the way it works, plus adding some more tests, and search for the "noname" string in "note=*" to don't show false positive.
PS2: mkgmap could be updated with a clever "mapper renderer special option" to show errors on a map and help you choose where to direct your bike in a correction process in mind.
I dream of a name shown on my Garmin 60cx like ( for my example ) : street [UN-NR-BG-END-STREET] ( Yes ! the screen of a 60cx if small ! ) Sletuffe 10:27, 23 September 2008 (UTC)
Of course, for the lazy guys I'm a part of, a general "fixme" code could be added to the list to say "there is something in that street to fix" that could trigger the noname layer or the openstreetbug to show there is something to fix Sletuffe 10:41, 23 September 2008 (UTC)
I like the idea of having structured tags describing the quality of the data, but I think it is not a very good idea to handle all possible values with one tag. This will probably just end up to be one big mess of hundred different values, and become completely unmanageable when we add numeric accuracy measures. I also think it is very important to have a note tag which allows for free form text comments, because there are always things so special that you cannot express them in a structured way. --Xoff 21:43, 7 October 2008 (UTC)
I changed my mind on the talk-fr list about that, re-using "note" for that is a bad idea, someone told me not to mix computer and human stuff. I am almost going to write a proposal for my new idea, but before that I'll expose the concept here :
We decide of a common tag not public, to be used between mappers and usable by special renderers ( GPS, online, whatever ) to help mappers know where their efforts have to be focussed
The idea is one tag called "for_mappers" or "internal" or anything easy to remember and fast to write that we can use on nodes, area, ways or relations a infinite number of time.
A wiki page (continously evolving on demand and vote ) would give all possible value for that tag
- internal=FIXME ( the lazy value's guys ! )
Sletuffe 19:14, 8 October 2008 (UTC)
Here is my proposal based on my last upper thoughts : Proposed_features/internal_informations_between_mappers Sletuffe 09:08, 13 October 2008 (UTC)