OpenStreetMap
OSM has some more or less clear criteria to decide if a certain information should be added to it or not. However, these criteria only take a nature of it into account. For example, there is no doubt that store operator is verifiable once it is known. Anyone could confirm that using the same source (store nameplate that refers to a company, open business registry, etc.) But will they do that?
I mean, time passes, store changes its owner. How possible it is that someone will update this kind of information? Definitely, less possible than, say, in a case of changed store name. Simply because it is harder to notice that change than to find out all details when you just going to create a POI.
It doesn’t mean that we should avoid adding this kind of information, but it does mean that an ability to keep a certain fraction of information up to date should be taken into consideration before adding it.
This diary entry is inspired by a question I came across today: “How to/ should we add time zone information to OSM?” My own short answer was “no”. A longer answer is: while OSM is not an authority on keeping reliable time zone information (IANA tzdb is), nobody who uses this information for something important will look for it here. At the same time, OSM can not be an authority exactly because of its nature: “anyone can edit it” (and nobody is truly responsible for data quality, unlike with tzdb, where Paul Eggert is an official responsible person).
So, theoretically, time zone information meets general criteria for data that could be added to OSM database, but it just doesn’t make any sense to add it since nobody can guarantee that it will be up to date and more or less accurate/complete. Here, I’d suggest using another OSM principle that usually refers to new tags: “don’t propose (here - don’t add) anything that you aren’t going to use (here - to keep up to date) by yourself”.
Discussion
Comment from Warin61 on 30 March 2017 at 23:24
All relative. There are large parts of the world where OSM mappers are not constantly active. In these regions roads may not well represented.
Story .. a remote road maker having made his remote road returned along it a year after its construction to find a building constructed right across it. The reason for this.. they wanted any visitor to report to the buildings occupiers before proceeding. So the road builder made a bit of a road leading around the building .. so he could get his bulldozer, grader and trucks around it. Point being - even remote locations have things happen fairly quickly and they won’t go on the map untill someone comes along who cares.
Should these things that don’t have frequent checking not be added to the map will result in large areas of the world being blank. So there is a balance. So I do add things that may get ‘out of date’ before they get checked .. but they do provide an indication of what was there .. and I expect to be there for some time. Things do change, highly unusual for building to appear across a new road though!
Time zones? I don’t care. If they were rendered on the map I’d not be using them anyway, I run on when things open/close. Where the mobile phone works then you have the time off that and an app for time zones. If someone wants it within the OSM data base .. fine go ahead, I don’t expect renders to use it, same as any other feature in the OSM data base, the rendering is selective. And that selection results in some things being frequently added, checked and regularly adjusted compared to other features. Things will sort themselves out over time.
Comment from joost schouppe on 10 April 2017 at 18:26
I agree that the level of detail we want to achieve should be limited by our ability to keep it up to date. That said, we’re constantly working to increase our ability. Say you map you neighborhood in crazy detail. All it takes is finding a few people half as crazy as you to keep that work up to date. I’ve noticed how new mappers have different interests then “old” mappers: some of them like to add ever more detailed stuff, but others love fixing mistakes or reviewing existing work.
The argument about authority is a bit strange to me. We are not an authority on anything, all our data is free to deteriorate, be it for lack of updates or wrong edits. So your argument seems to lead towards an empty database. Even the “nobody is going to use it” argument is a bit strange to me. It’s only after the fact that you can evaluate this.
In fact, I don’t believe the growth of scope and detail in OSM is limited by any guidelines. it is only limited by what mappers want to map. And that seems to be working pretty well in general.
Comment from BushmanK on 10 April 2017 at 19:07
@joost schouppe, it seems like somehow you didn’t get what I was trying to say about critical data. Some data users just can not afford using “freely deteriorating” data. Or at least, they need the best existing source of a specific type of data. In some cases (such as time zones, for example), OSM automatically can not be the best existing data source exactly because what you’ve said about freely deteriorating information. I have never said that OSM should be an authority, I’m saying that in cases described above, it doesn’t make sense to keep that kind of data that is, at the same time, critical to users and can not be kept up to date in OSM. And no, we don’t need to have an experimental result when data quality criterion sounds like “up to date or nothing”.