Talk:Verifiability

Discuss Verifiability here:

---

Verifiable and non-verifiable Geometries

I've added a section about mapping features with ways or areas when these geometries are not verifiable. This has been discussed on the tagging list several times in the past few months, in regards to tags like natural=bay, natural=strait, place=*, and proposals like natural=mesa. Please suggest any improvements to the wording or corrections. --Jeisenbe (talk) 04:45, 28 April 2019 (UTC)

Just a short note for a start - I lack warning about problems with node verifiability (especially for areas) and some examples where the nodes would make a problem (I mean indefinite borders here or joining the lake with a river). I think this section should be more a hint about problems with different approaches, so the reader gets full picture and might make conscious decision. Currently proposed version hides all the controversy as if there was one proper solution. Kocio (talk) 11:17, 30 April 2019 (UTC)

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)

2019 update: do we still need this list of problematic tags? They are all quite old now. I can't tell if this list is meant to clarify the meaning or verifiability or to show that there are many tags that are not verifiable? At any rate it doesn't necessarily help new users to understand the concept. --Jeisenbe (talk) 07:52, 1 May 2019 (UTC)

Wikipedia definition

Would it be worth adding the Wikipedia definition? http://en.wikipedia.org/wiki/Wikipedia:Verifiability And perhaps http://en.wikipedia.org/wiki/Wikipedia:Neutral_point_of_view 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)

tracktype

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)

sac_scale

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)

Dam/weir example is not a good one

Most dams are designed for water to flow over them. Some dams have spillways that pass through the structure or pass around the dam (over a saddle for example, but the majority go over the top.

Adavidson (talk) 03:17, 28 November 2018 (UTC)

No, the vast majority of dams, in particular larger ones, are not designed to be overtopped and huge efforts are made to reduce the risk of this happening. Anyway - this is not really the point here because designed for here means designed to have this as a routine function, not designed to withstand the possibility of this happening under exceptional circumstances. --Imagico (talk) 11:13, 28 November 2018 (UTC)

That's not what the article says. If that's what you mean then you need to change the text to say a dam is "designed not to be over topped". This definition still doesn't work because some dams are designed to be over-topped eg: Burdekin Dam and a lot of weirs are designed not to be over-topped eg: Hay Weir. Mildura Weir is designed to be pulled out of the river on rails during floods so the water is not designed to go over. My point is that this is supposed to be an article on verifiability and the dam/weir example is not a good one to illustrate it with unless you want to use it in the negative sense. Adavidson (talk) 19:54, 28 November 2018 (UTC)

I don't see the problem. waterway=dam and waterway=weir indicate a clear verifiable difference to me. Note this is based on the meaning of the tags, not on if something is called a weir or a dam in English language. The meaning of tags in OSM is not necessarily equivalent to the meaning of the values in English (which also might differ between BE and AE). --Imagico (talk) 20:19, 28 November 2018 (UTC)

Let's assume for the moment that the meaning of weir and dam don't have to line up with their common use in BE. Looking at the definition: "a weir is designed for water to flow over it" there are at least three problems with the verifiability. Firstly: "designed for" means that there was an intent by the designer(s) that water should flow over the structure. How is this "practically verifiable in everyday mapping"? Secondly: how deep does the flow have to be and for how long to to qualify as having the "water to flow over it"? 50 mm for two minutes? 10% of the height of the structure indefinitely? Thirdly: how much of the structure has to be submerged? All of it? Part of it? Do access walkways count? Adavidson (talk) 09:38, 7 December 2018 (UTC)

I have to say i can't really follow you theoretical examples - Verifiable tags do not mean there cannot be - at least theoretically - borderline cases. There are between natural=water + water=lake and waterway=riverbank or between natural=wood and natural=scrub or between natural=grassland and natural=heath. That does not make these tags non-verifiable. If you have a practical example for something that might be waterway=dam or waterway=weir and you can't decide this can be discussed and if necessary the documentation of the tags be adjusted. As far as intermittent waterflow is concerned - intermittency of things is inherently of limited verifiability but in case of water flow you can often find indicators how recent water flow has occurred at a certain place. So reliably mapping an intermittent river in the dry state is more difficult but not universally impossible. --Imagico (talk) 11:39, 7 December 2018 (UTC)

Mapping points with nothing on the ground there

Mention even if the United Nations Committee of Geographical Wizards unanimously declared an exact X,Y to be the ... but there is nothing on the ground actually there, one should still not add a point to the map... or not? [1]

But some people will object: "That county border is on the map with nothing on the ground, so why can't I map such an important point?" Jidanni (talk) 02:02, 6 January 2020 (UTC)

Openstreetmap is maintained by local volunteers, so if we add informantion that is only available from an "official" source like the national government or the UN, then there will not be a way for local mappers to find out if the government or UN information is wrong. For the example of the "geographical center" of an area, this should not be mapped because it is metadata which can be calculated from the actual area feature in the openstreetmap database - the boundary or multipolygon relation or closed way which defines the area can be used to determine it's centroid or weighted center, based on whatever map projection the database user prefers. The center of a complex area like a lake or forest or country does not have one true answer: it depends on how you do the calculation, so such derived data should not be included in the Openstreetmap database. I believe this is mentioned under "Statistical properties" but we could add something specific about derived data, which would also exclude mapping things like the topographical prominence of peaks (calculated from the elevation of the key saddle and the elevation of the peak) or adding calculated area size values to Openstreetmap objects. --Jeisenbe (talk) 02:41, 6 January 2020 (UTC)

Official boundary sources

For official boundary turnpoint locations, even passing through lakes, users should not be afraid of downloading from official sources like International Boundary Commission. Jidanni (talk) 13:39, 29 March 2023 (UTC)