Definitely, I'm not the oldest and the most experienced member of the OSM community. But for the last five years I had quite a few discussions and arguments regarding of basic principles of contributing to OSM. Usually, it's about the nature of those basic rules, listed on Good practice Wiki page. (By the way, having the majority of "don'ts" there, shouldn't it be called "Bad practice"?) Discussions I'm talking about took place on Russian OSM community forum, in comments on several online articles (written by me) about OSM and in a real life.
People, especially those, who have no familiarity with geospatial science, database architecture, IT in general, just can't get the idea, why these rules are so important and where they come from. Common misconception also includes association of OSM project with certain derivative product: interactive web map on openstreetmap.org or converted maps for digital navigation systems (OsmAnd, Garmin, Navitel and so on).
These people, including several experienced contributors, wonder: "Why shouldn't we tag it in a manner to make it visible on a map? There is no use in this object if it's not displayed (searchable)." Their understanding is based on particular way to use data: visually observe a map, run search on indexable objects on their navigation device/software and so on.
Is there any way to explain, why they must not do what they do without mentioning that OSM is a database? Honesty, I don't know any reliable one. And why should anyone look for one, if the concept of structured geospatial database as both core component and product of OSM project explains more or less every well-known basic rule?
Someone could probably say, that it's a question of philosophy or even demagogic thing to insist on "OSM is a database" instead of "OSM is a map". But here are several reasons to do so:
- Copyright page of openstreetmap.org clearly says, and it's a legal copyright notice: "OpenStreetMap® is open data, licensed under the Open Data Commons Open Database License (ODbL) by the OpenStreetMap Foundation (OSMF)."
- Same Copyright page uses the term "map" only regarding of map tiles, generated from OSM data.
- Answer for the question from title is: "Database comes first." No single map derived from OSM open data can ever exist without this database.
- Every single way of direct contribution into OSM project involves adding, modification or deletion of features of OSM database via OSM API. (By "direct contribution" I don't mean editing Wiki, for example.)
Important thing to know about it is that map is a symbolic depiction (visual representation) of real-world objects, while geodatabase is a structured storage of feature descriptions, including geometry and semantic properties within formally defined scheme.
From my experience, which includes teaching physics, math and other scientific disciplines, I learned, that using deductive reasoning based on single core concept to explain many different secondary effects is much more effective than trying to explain these effects separately. I mean, yes, it's possible to force people to memorize separate things, but this kind of "knowledge" very unlikely transforms itself into any sort of systematic understanding. And only systematic understanding allows people to solve problems by themselves, in opposite to following predefined templates. Also, systematic understanding is usually more reliable in terms of not violating the rules deliberately.
Telling people that OSM is a map, like on About OpenSteeetMap page leads to misconception, explained above.
I completely understand, that wording like this is used there to avoid scaring newbies away. But there are several questions:
- Is it really necessary to completely remove any reference to OSM as a geodatabase?
- Isn't it possible to introduce newbies to both concepts of core geodatabase and its visualization?
- Shouldn't any wording, which potentially leads to misconception, be used very carefully to prevent future harm?
- Is there any study, which tells, if those newbies, totally "allergic" to words like "geodatabase", are actually capable to learn relatively complex concepts of OSM, required to become an effective contributor in the future? (By "effective" I mean "a contributor, who doesn't create more problems for other contributors than data.")
By telling all these things, I just want to remind people about this fundamental conception, because certain experienced people in this project got used to it to the point, where they starting to think that it's not important at all (because for them it's already completely natural).