Zuerst definiere bitte, was du mit „die Karte“ meinst 
1.: OSM ist keine Karte (trotz des Namens), OSM ist eine Datenbank mit Geodaten.
2.: Aus den Geodaten in dieser Datenbank lassen sich Karten erzeugen.
3.: Weil die Karten, die aus der Datenbank erzeugt werden sollen, unterschiedlichen Zwecken und Zielgruppen dienen, legen sie unterschiedliche Schwerpunkte. Einem Autoatlas ist egal, wo Wiese und wo Acker ist, einer Wanderkarte weniger.
4.: Weil wir allen Karten, die sich in unserer Datenbank bedienen, gerecht werden möchten, erfassen wir in Schritt 1 so viele Details wie möglich. Welche dieser Details für die jeweilige Anwendung nicht relevant sind und vereinfacht oder weggelassen werden können, entscheidet die jeweilige Anwendung in Schritt 2, was sie aus der Datenbank übernimmt und was nicht.
Um deiner Idee eines übersichtlichen Stadtplans gerecht zu werden, kann eine Stadtorientierungskarte alle Wohngebäude weglassen – warum nicht? Aber eine topographische Karte möchte alle Gebäude abbilden, deshalb wäre der TK schlecht gedient, wenn wir, deine Idee vorausnehmend, die Wohngebäude gar nicht erst einzeichnen würden. Es gibt immer auch andere Anwender mit anderen Präferenzen und anderen Bedürfnissen. Beispielsweise sind amenity=hunting_stand auf Wanderkarten wertvolle Festpunkte.
Daher nochmals meine Bitte: Trag möglichst viel in die Datenbank ein. Alles, was sich nicht kurzfristig verändert. Hochsitze, Wegweiser, Sitzbänke, Mülleimer, Schuppen, Funkmasten, Freileitungen. Dann sind die von dir erfassten Daten nicht nur für die eine Karte gut, die dir gerade vorschwebt, sondern für viele andere auch noch.
Gute Idee.
Schlechte Idee. Die Information „Der Trampelpfad zweigt gleich hinter dem Schuppen da ab und geht dann rechts an der nächsten Scheune vorbei“ ist in einer Wanderkarte sehr hilfreich. Geht aber nur, wenn nicht nur der Pfad selbst, sondern auch diese Gebäude in der DB sind.
D’accord – Innenstädte sind in OSM schon äußerst komplex. Ich glaube aber nicht, dass wir das ändern, indem wir Gebäude weglassen. Das braucht ein neues Strukturkonzept, das z.B. Admin-Grenzen, Schienen, Straßen und Landcover auf unterschiedlichen Ebenen abbildet, die sich unabhängig voneinander bearbeiten lassen, statt wie jetzt alles in eine Ebene zu packen.
Mit Verlaub – Bestrebungen, durch Vorselektion von Daten einzelne Bytes einzusparen, sind heute komplett sinnlos. Speicherplatz ist kein Thema mehr, auf Handgeräten schon gar nicht – eine (gute!) 64-GB-Karte fürs Schlaufon bekommst du unter 30 Euro und kannst da ein Planetfile von OSM draufpacken. (Vielleicht kein Planetfile, aber die kompletten OSM-Daten von Europa sind aktuell heute als pbf gerade mal 18.1 GB groß.) Wenn wir mal neue Speicher- oder Serverhardware brauchen, weil der Plattensatz aus den Nähten platzt, dann legen wir zusammen und fertig – aber wir fangen bestimmt nicht an, nur noch ganz grob zu mappen, um Daten zu sparen. Wir möchten eine detaillierte Geodatenbank aufbauen, keine Sparkarte.
Wohlgemerkt: Eine Sparkarte (für speicherschwache Handys oder dünne Internetanbindungen) kann daraus natürlich jederzeit erzeugt werden! Aber das ist Schritt 2. Es gibt halt immer auch Anwender, die mehr Details haben möchten und brauchen, daher sollten die nicht in Schritt 1 schon weggelassen werden.
Nur ein Beispiel: Wenn ich mit meinem Hund in einer fremden Kleinstadt spazierengehe, er dort einen Haufen macht und ich dann mit der gefüllten Tüte dastehe, bin ich sehr dankbar, per Osmand gezielt den nächsten öffentlichen Mülleimer ansteuern zu können. (Anhand dieses Beispiels mache ich sogar Werbung für OSM bei meinen Freunden.) Wenn aber ein Automat7 einfach mal beschlossen hat, dass wir keine Mülleimer in der Datenbank brauchen, um Speicherplatz zu sparen, dann geht mir dieser Nutzen von OSM verloren.
Wirf mal einen ganz vorsichtigen Blick auf http://demo.f4map.com/#lat=50.1094369&lon=8.6745726&zoom=17. Ja, das sind OSM-Daten.
–ks
