Die "Prinzipien" erschließen sich, wenn man versteht, was OSM eigentlich will. Es geht darum, eine freie Geodatenbank zu haben, sprich eine für faktisch jede Anwendung offene und frei verfügbare Datenquelle, aus der man dann beliebige (Spezial-)Karten, Suchalgorithmen oder andere Dinge generieren kann. Ausschlaggebend für den Erfolg ist eine möglichst umfangreiche und einheitliche Datenbasis.
Wenn Fahrradverbote auf einer aus OSM-Daten erstellten Karte nicht auftauchen (in den OSM-Daten aber erfasst sind), dann ist der richtige Adressat der Kritik derjenige, der aus den OSM-Daten die Karte generiert; eine Manipulation der Datenbasis kann nicht der richtige Ansatz sein. Denn dann bilden die Daten nicht nur nicht mehr die Realität ab, sondern das hat auch Auswirkungen auf alle anderen Nutzer, die aus den OSM-Daten Geomaterialien (wie Karten) erstellen. An dem Prinzip gibt es nix zu überdenken, alles andere ist ganz offensichtlich Käse!
Dem nächste passionierten Nichtmotoristen werden die Autobahnen auf der Standardkarte zu fett und dominant dargestellt und er entscheidet, die alle als Stromleitung umzudeklarieren, weil stört dann weniger auf der Karte ... das kann es echt nicht sein!

Was die Nutzerfreundlichkeit betrifft - mag sein, dass man da Optimierungsmöglichkeiten hat. Die Hürde für den Otto-Normal-Anwender in einer Datenbank Änderungen vorzunehmen ist ziemlich hoch, da muss man geeignete niedrigschwellige Zugänge anbieten.
Manches ist da aber auch prinzipbedingt. OSM-Karten werden halt aus den Geodaten generiert - das braucht Zeit und ist resourcenaufwändig. Daher kommen Updates hier halt nicht "live" beim Nutzer an, sondern erst, wenn die aus den OSM-Daten erstellte Karte ebenfalls neu generiert wurde und auch auf dem Gerät des Nutzers geupdated worden ist. Je nach Karte und Anwendung, kann das Tage, Wochen, oder auch mal Monate dauern. Andererseits kann das System aber auch sehr schnell sein. Bei Naturkatastrophen kann man ganz schnell (mit vielen Freiwilligen) bei OSM eintragen, welche Straßen unpassierbar sind, wie die neue Küstenlinie ist, welche Gebäude zerstört sind, wo Infrastruktur beschädigt ist, ... Und wenn man dann umgehend eine Karte mit diesen relevanten Daten generiert, hat man ein Live-Lagebild mit genau den Informationen, die die Helfer brauchen.

GoogleMaps funktioniert ganz anders. Dort hat Google die Geodatenhoheit und entscheidet eigenständig welche Informationen sie aufnehmen und vor allem auch welche nicht. Und es gibt im Kern nur eine aus den Daten generierte Karte, die man dabei berücksichtigen muss. Es gibt also eine viel stärkere Bindung zwischen Geodaten und der Karte, die die Daten darstellt. Und die Karte wird über eine online-Datenverbindung übertragen. Sie ist somit stets aktuell(er), aber das Prinzip halt auch wesentlich resourcenintensiver (hoher Datenverkehr, hohe Rechenlast, weil die Karte stets neu berechnet wird) Und das System ist halt nicht offen für Spezialanwendungen wie bspw. Darstellung fokusiert auf Naturschutzgebiete und Landflächennutzung, spezifischen Karten für Wanderer und Radfahrer, Stromnetzkarten, Karten mit Eisenbahn- und Schmalspurlinien, Karten mit Trinkwasserversorgungsstellen für Fernwanderer und Radfahrer, ...

Ich will hier mal die App Streetcomplete einwerfen, war glaube noch nicht hier im Forum. Damit ist es sehr einfach bestimmte Daten in Openstreetmap zu aktualisieren/hinzuzufügen. Also vor allem Öffnungszeiten, Straßenbeschaffung (oder der Durchmesser von Hydranten ) etc. Allerdings eben nur Sachen, die in OSM als fehlend/falsch markiert wurden (Qests) . Man kann aber auch beliebige Anmerkungen machen, die dann später überprüft werden. Durch "Gamification" soll das sozusagen als Spiel betrachtet werden und für Leute attraktiv sein, die sich nicht mit den Details befassen wollen.

Wenn man über eine Datenbankabfrage für ein kleineres Gebiet z.B. "Routen" eingibt bekommt man eine Tabelle, anhand der man sieht, dass da manche den Zugang haben, neue Spalten (neben den schon existierenden ca. 50) erstellen, und in diese Werte eintragen, die eigentlich woanders hingehören. Nach dem Motto: Viele Köche verderben den Brei.
Wer dann daraus eine Karte erstellt, berücksichtigt das möglicherweise trotz bestem Willen nicht. Ich weiß nicht, ob es daran liegt, vermute aber dass dadurch die Ungereimtheiten bei den verschiedenen Routenplanern entstehen.

Bei OSM gibt es grundsätzlich keine Hierarchie oder besondere Berechtigungen und die Eigenschaften der Objekte in der Datenbank können von jedem User frei gewählt werden. Die Eigenschaften eines Objekt in der Datenbank werden als Liste von (Schlüssel, Wert)-Paaren erfasst, wobei Schlüssel und Wert Freitext sind. Natürlich gibt es dafür Konventionen und Regeln, aber rein technisch und administrativ gibt es keine Beschränkung. Wenn man will, dass der Fahrradladen, den man einträgt, auch auf Karten erscheint und von Anwendungen ausgewertet wird, dann kennzeichnet man ihn sinnvollerweise mit dem Schlüssel shop und dem Wert bicycle. Möchte man dazu noch erfassen, dass der Laden auch Laufräder baut und es dafür noch keine eingeführte Schlüssel/Wert-Kombination gibt, steht es einem frei, dafür z.B. wheelbuilding=yes zu verwenden. Mit etwas Glück wird das auch von anderen Mitwirkenden so gemacht und irgendwann auch von OsmAnd ausgewertet.

Du beziehst dich gerade konkret auf OSM?
Es ist in der Tat so, dass das Datenbankformat relativ offen ist (das ist ja eine der Stärken, dass man es nahezu beliebig erweitern kann) und soweit mir bekannt, gibt es schon Dinge, die nicht immer einheitlich gehandhabt werden. Sowas diskutiert die Community dann gern in den Mailinglisten und zumindest für die häufigen Fälle etabliert sich irgendwann ein Standardvorgehen. Verbote für bestimmte Verkehrsarten sind ein gaaaaanz alter Hut, da ist das richtige Vorgehen seit sicher mehr als 10 Jahren klar und unstrittig.

StreetComplete ist gut, wenn man zu einem oder mehreren Themen beitragen möchte. Um gezielt einzelne Änderungen oder Ergänzungen zu machen, z.B. die Öffnungszeiten eines Restaurants ergänzen oder eine Sitzbank hinzufügen, eignen sich andere Apps besser. "Every Door" finde ich gut gemacht. Gibt es für Android, iOS weiss ich nicht. Ähnliche Funktionen bietet "OSM Go!", das auch im Browser läuft. Bei beiden braucht man natürlich einen OSM-Account.

Habe mich ne Weile nicht mehr damit beschäftigt. OSMGo! gefällt mir gut.

Ja, ich habe mit QGIS Abfragen in mir gut bekannten Gebieten gemacht, sowohl zu Tracks, als auch zu Routen und da einige Ungereimtheiten entdeckt.
Aber auch bei Rastplätzen, Sitzbänken und Unterständen gab es da etliches, was entweder falsch eingetragen war, oder im Lauf der Zeit verändert wurde (Nachtäglich ein Dach über die Sitzbänke) und von niemandem aktualisiert wurde.

Was Straßenkategorisierungen anbetrifft: In Ungarn kann man nicht davon ausgehen, dass eine Straße mit 5-stelliger Nummer, die dann unter "terciary" eingetragen ist, in Wirklichkeit auch eine relativ verkehrsarme Straße ist. Im Gegenteil auf vielen Straßen mit einstelliger Nummer ist der Verkehr geringer, und Radfahren geht besser, weil diese Straßen wesentlich breiter sind.

Insofern finde ich dieses Kategorisierung als unzureichend, aber das ist meine subjektive Meinung. Es bräuchte eine Kategorie Für Radfahrer etwa so: empfehlenswert-erträglich-möglichst zu vermeiden (auch wenn kein Radfahrverbot existiert).

VG z.Zt. aus Leipzig
Martin