From OpenStreetMap Wiki
Jump to: navigation, search

Discuss Verifiability here:

problem with concept

If OSM were to define height=average as "ten to 30 meters" and height=tall as "greater than 30 meters", then those values would become verifiable.

This applies to any tag whatsoever -- as long as the definition of any value is verifiable, the tag is verifiable. For this reason, the idea of requiring verifiability before using a tag is pointless. --Hawke 21:08, 12 February 2009 (UTC)

Well yes. We can do things like defining a value as meaning "greater than 30 meters", and that value will therefore become verifiable, against the definition. It is preferable however to come up with tag values which are inherently verifiable in and of themselves. For this reason nobody would seriously suggest height=average or height=tall as a sensible value, when clearly we can use a measurement in metres, and be free of ambiguity or the need to refer to wiki definitions.
The interesting point comes when we talk about new tagging ideas where there is no clear way of measuring the value. In those cases a tag value might be unclear, even after defining it as fully as possible on a wiki page. We are then probably talking about a tag which is not verifiable, and therefore goes against this policy.
I like the principle of this policy although I think there are examples within even our most longstanding tags which could be regarded as in breach of the policy. The world just isn't that black n white.
-- Harry Wood 12:00, 13 February 2009 (UTC)
Agree with Harry that grouping values is probably a bad idea - if the end-user needs them grouped, they can do so themselves. Ultimately, we may have some tags existing that make definitions, such as highway=*, but those are defined based on existing terms of art, and don't redefine existing concepts, so we can probably get away with it. The key thing to bear in mind here is that even though we use some bad tags, that is not an excuse to create more bad tags. Crap solutions are crap, and any argument that a particular idea is less crap than the others is not a good one - our tags should stand or fall on their own merits. Chriscf 15:38, 13 February 2009 (UTC)
It may be that grouping values is a bad idea. However, grouped values are not unverifiable just because they're grouped, as you seem to imply. Hawke's contribution was quite appropriate in an article on verifiability. Please take the discussion on whether grouping is good or bad to Grouping tag values. Robx 16:33, 13 February 2009 (UTC)
The contribution was not appropriate. User:Hawke has an agenda in trying to find reasons to include the irreparably broken and by definition unverifiable concept at Key:smoothness. Chriscf 16:38, 13 February 2009 (UTC)
User:Hawke's motivation is hardly a good argument for removing an appropriate input to the matter of verifiability. Robx 16:53, 13 February 2009 (UTC)
It wasn't an apropriate input. It skirted the issue entirely. Chriscf 17:06, 13 February 2009 (UTC)
It's a bit of a weird example, because (actually for the same reasons of verifiability) we prefer to record building heights as a numerical value, and nobody would actually suggest that we have a height=average height=tall tags. Hawke wasn't suggesting that. He was just saying that if we did want such tags, then we could make them more verifiable by documenting. ...Which is true. I've refactored the page to reflect that. -- Harry Wood 17:22, 13 February 2009 (UTC)
I've changed the example to one which is slightly less contrived, and which does not involve poor tagging practice. We have better ways of determining height, whereas improving our waterway classification in the same way would be impractical. Chriscf 17:39, 13 February 2009 (UTC)
Thanks for that, your new example is much better. Harry Wood was exactly right about my intentions. --Hawke 19:50, 13 February 2009 (UTC)

Problematic tags list

I just don't understand why you've targeted smoothness=* so specifically when there are so many others that it's clear from "Problematic Tags" that the very first statement on this page ("Verifiability is an important concept to OpenStreetMap") is pure fiction, at least historically, and just because you've suddenly written about verifiability (good idea though it is) does not instantly invalidate any non-verifiable tags merely on your say-so. --Hawke 19:50, 13 February 2009 (UTC)

Those other tags have been around for a long time. Smoothness is a recent invention. Like I keep saying, and you keep ignoring, the mere fact that we have stupid and broken tags already does not mean that it is okay to use more stupid and broken tags. Chriscf 15:37, 15 February 2009 (UTC)
However, "stupid and broken tags" is a subjective POV, tags can be "further defined", with reason and logic. OSM is all about being creative... but it is also about working with the community. So for new ideas (and i am at fault here) Ideas should be 1st expressed on the 'talk' page, and 'facts' expressed on the 'wikipage'. Introducing the idea on the talk-discussion list. Perhaps we need to create a detailed 'Welcome' message for new users, explaining how the project works? --acrosscanadatrails 23:02, 15 February 2009 (UTC)
In the case at hand, the stupidity and brokenness are not in dispute among those users known to possess a working brain. Chriscf 15:47, 26 February 2009 (UTC)
The "problematic tags" list seems to have become... problematic. I can see Hawke's point of view, that many tags are not all that verifiable. I have attempted to explain some shades-of-grey in this section, and reflect a more balanced point of view, but editing this section to list all the highway tags is silly. Please try to use the wiki sensibly. Don't give up on the idea that we could actually reach agreement. -- Harry Wood 11:22, 18 June 2009 (UTC)

Wikipedia definition

Would it be worth adding the Wikipedia definition? And perhaps should also be mentioned? As the OSM Community also (unofficially) adopts this policy. --acrosscanadatrails 01:44, 13 February 2009 (UTC)

Wikipedia verifiability is mostly about that your information can be verified in external sources, which is most certainly not what we encourage people to do here - we positively encourage original research (such that our data can be free). What this page is about is rendering the human element irrelevant - a tag whose value changes depends on who is looking at it is pretty much useless to anyone. Mapping data is about facts, value judgments are left to end-users who are capable of making them (and therefore don't need us to do it for them). Chriscf 15:26, 13 February 2009 (UTC)


I'm not convinced that this belongs here. At the top, the transition between grade1 and grade2 is clear: either a length of track is paved or it isn't, and I believe there is a difference between gravel and hardcore (though someone in construction will have a clearer idea). The only problematic boundary there is that between grade3 and grade4 (i.e. even mix of soft/hard vs. mostly soft with some hard). Of course, tracktype is years old, and in the analogy is the pollution rather than the sewage. OTOH, discouraging people from using existing bad tags may be a good thing. Chriscf 17:03, 13 February 2009 (UTC)

Well it's a scale of discrete values, and as such necessarily has a verifiability problem. There's a basically continuous spectrum of track types. Think of a paved track degrading over time -- at some point it's clearly not paved anymore, so at some point in between, it must make the jump from grade1 to grade2). Then let it fall into disuse -- at what point is it sufficiently overgrown with grass to make it grade5? Also, from my own mapping, I've often run into tracks where I wasn't at all sure which tracktype to assign.
The sensible answer to all this is of course not to worry: For a well-defined scale of not-too-many values, it's clear that it's one of say value3 or value2, so you just pick value2, and everyone knows it's far enough away from value4 for practical purposes. Robx 17:38, 13 February 2009 (UTC)
It's a scale of discrete values that are mostly well-defined. I'm sure that in this case we're agreed but at opposite perspectives - a glass holding 50% of its capacity is both half-full and half-empty. The important part isn't to entirely eliminate subjective judgment, but to keep it to a minimum. I'd suggest that waterway is a good example of where the subjective spectrum is small enough, and smoothness a good example of something which doesn't reduce the subjective spectrum at all. Chriscf 17:58, 13 February 2009 (UTC)

Where clear definitions exists

In some cases, clear definitions exists, no matter how obscure they may seem to novices. There where raised a question if two mappers would agree on coastline on different levels of tide. The coastline are actually defined as the line between the waterfront and the sea at Mean High Water at Spring Equinox (MHWS). If a dispute between two mappers of where the coastline goes, than check up this definition. On the other hand, Mean Low Water at Spring Equinox (MLWS) is used as a reference for depths. IMO both these lines should be in the spatial database, as this will give the rendering software the opportunity to base the map on one or the other, or to mark the tidal area with a different shade of blue, or what is desired of the map. --Skippern 20:27, 16 February 2009 (UTC)


I notice sac_scale=* is listed as an example of "bad" tag. Is it the consensus that sac_scale is not verifiable? Well if so than I must say the whole concept of verifiability seems fairly useless. Certainly much less useful than sac_scale is. RicoZ (talk) 17:22, 11 April 2016 (UTC)

I'd say the concept of verifiability is a good base for new tags. But calling bad a tag like sac_scale used 300k in the db is not what this page should do. Better have generic statement saying : try to define your proposed tags as measurable as possible, try avoiding fuzzy concept in definitions such as "quality of road is good".
In short +1 sletuffe (talk) 19:44, 11 April 2016 (UTC)