OSM Standard verabschieden und Renderer müssen ihn knall hart umsetzen

Hallo,
ich finde OSM an sich eine geniale Sache, doch eines trübt meine Aufbruchstimmung:
Dieses Tagging-Chaos.
1.) Es gibt viele Möglichkeiten eine Sache zu taggen und oder mit Relationen zu versehen - selbst hier im Forum wird sich oft gestritten, wie man das nun richtig taggt.
2.) Viele Sachen lassen sich gar nicht eindeutig taggen z.B. Freibäder, Parkgaraden oder andere Sportgebiete.
3.) Viele Beschreibungen sind einfach nicht ausreichend: z.B. Wie macht man eindeutig klar, dass ab den abschnitt eine Spur hinzukommt, wo dann nach hundert Metern die Abfahrt kommt und erst ab da eine seperate Straße beginnt?
4.) Viele Tags, die sehr häufig verwendet werden sind eigntlich gar nicht im "Standard" und werden noch in mehreren leicht modifizierten Versionen genutzt.
5.) Hat jeder Tagger seinen eigenen Fingerabdruck, taggt bischen anders und überschreibt somit auch die Tags anderer, weil er denkt, so wäre es besser.
6.) Eigentlich sind nur 2 Sachen unvergänglich: GPS-Tracks und der Verlauf von Straßen sowie eingezeichnete Gebäude und Flächen.

-> das sind so meine Erfahrungen bis jetzt
Wäre ich jetzt Renderer-Entwickler würde ich ständig Alpträume haben 😉

Dieses Tagging-Chaos hat folgende Nachteile:
1.) Man würd nie fertig, weil sich ständig was umgetagt werden muss oder von anderer wird.
2.) Jeder Renderer interpretiert Tags unterschiedlich und kann mit einigen Tags gar nichts anfagen.
3.) Rendern ist sehr aufwändig, alle Tags zu unterstützen und diese zu "verstehen" bzw. richtig zu interpretieren. -> viele Darstellungsfehler
4.) So können Routing-Services, basierend auf OSM, nie richtig gut funktionieren.

Mein Vorschlag:
1.) Ein neuen Standard entwickeln, der ein Modernes Konzept verinnterlicht:
a) Es gibt keine Tag-Alternativen mehr - nur noch eine Möglichkeit.
b) Alle Objekte abdeckt, auch Sportanlagen, Freibäder
c) Jede Straße muss zuvor als Relation angelegt werden
d) Häuser müssen der Relation der jeweiligen zugehörigen Straße (nach Anschrift) zugeordnet werden.
e) Jedes Haus ist ebenfalls eine Relation und hat ein oder mehrere Eingänge (entrance).
f) Jeder Eingang muss die Relation des Gebäudes zugeordnet werden.
g) Der Eingang kann sich nicht irgendwo befinden, sondern muss am Gebäuderand kleben (-> muss vom OSM Editor garantiert werden)
h) Nur noch kein Gebäude eingezeichnet wurde oder falls es nur ein Postfach ist und es kein Gebäude dazu geben sollte, sind Adressen (adresspoint) als Punkte erlaubt. Diese müssen dann aber die Relation der zugehörigen Straße enthalten.
i) Doppelte Tags sind verboten: So darf das Gebäude keine Adresse enthalten, da es schon eindeutig durch die Relation der Straße und der Eingänge beschrieben ist. Auch dürfen Straßen kein Namen-Tag enthalten, da sie schon durch die Relation beschrieben sind.
j) Interpolationen sind nur vorrübergehend erlaubt (so lange es noch kein Gebäude gezeichnet wurde).
k) Anwohnerstraßen, die den selben Namen tragen wie die eigentliche große Straße, müssen einen Tag "Nebenstraße" enthalten, so dass der Renderer eindeutig den Verlauf der Straße erkennt und auch Routen einfach und korrekt berechnet werden können.
l) Gebäude sollten ggf. Flächen zugeordnet werden (z.B. Garten-Fläche, Eigenttumsgebiet, ...)

-> Das alles würde dazu führen, dass wenn eine Straße umbenannt wird, ich nur die Relation anpassen muss. Das gleiche gild für Postleitzahl, Vorwahlen, Stadtteil-Namen (gehören alles in Form von Relationen zu Eingänge der Gebäude, nicht zu Gebäuden selbst und nicht zu Straßen).

2.) Muss der Standard durchgesetzt werden:
a) Der Editor muss gleich bei Fehlern drauf hinweisen.
b) Der Render muss knall hart sein und nur den Standard unterstützen und fehlerhafte Tags ignorieren und auf der Karte eine Warnung einblenden
c) Es muss eine Feher-Renderer-Karte geben, die alle Fehler, unvollständige Einträge, fehlende Relationen, TODO-Hinweise anzeigt, so dass sich leute aufmachen können und das korrigieren können.

3.) Zudem schlage ich vor, Höhentags einzuführen:
Höheninformationen (+- X Meter über den Meeresspiegel) müssen als einzelne Punkte auf der Karte eingetragen werden, so dass die Erdoberfläche auch dreidimensional angezeigt werden kann und Straßenverläufe realistischer werden (wenn eine Straße nach links oder rechts geneigt ist, wirkt sie von oben schmaler).
Aber: Höheninformationen nur als unabhängige Punkte, gehören nciht in Gebäude oder Straßen (da wenn diese Verschoben werden ...).

4. Noch ein Vorschlag für die OSM-Organisation/ Koordination:
In den OSM-Editoren sollte es verschiedenen Modi geben, wo die wesentlichen Objekte hervorgehoben werden und unwesentliche in den Hintergrund geraden oder ganz ausgeblendet werden.
a) Modus für Straßenbearbeitung.
b) Modus für Gebäude und Flächen
c) Modus für Landschaft
d) Modus für Zusatzinformationen (Fotos, 360° Panoramabilder, Zusatzinformationen (über Entstehung von Gebäuden, Geschichte etc.)

-> so wäre es Möglich in mehreren Ebenen zu Arbeiten:
1.) GPS-Tracks auswerten und Straßen zeichnen oder von Yahoo abzeichnen
2.) Wenn das fertig ist, geht man zur nächsten Ebene über, wo alle neu hinzugefügten/ editierten Objekte hervorgehoben werden und man sie dann taggen kan (vorwiegend mit Relationen).
3.) Anschließen dann Fleißarbeiten, wie Einzeichnen von Gebäuden
4.) Dann die Adressen bzw. Eingänge
5.) Landschaft

Ganz wichtig ist auch die Dokumentation im Wiki. Dort sollte es für alles eine EINDEUTIGE Lösung/ Antwort geben mit Bildern und mehreren Anwendungsbeispielen bei OSM in verschiedenen Städten.
Ein FAQ sollte auch aufgebaut werden, damit nicht immer die gleichen Fragen erneut auftauchen. Die Antworten auf die Fragen sollten aber in die Wiki indirekt eingebaut werden, also der Sachverhalt, falls nicht vorhanden, dort beschrieben werden.
Im FAQ sollte dann ein Verweis im Wiki auftauchen und eine kurze Fragespezifische Antwort + Zusammenfassung.

-> Das alles waren nur Ideen und Anregungen und nicht im Sinne "Macht das mal endlich" 🙂 Ich möchte mich daran gerne beteiligen.
Ich freue mich auf eine Sachliche Argumentation, Anregungen, Ideen, Kritiken und bin auf eure Meinungen gespannt.

Nachtrag
Für das bilden des Standards sollte man 1 Jahr informationen sammeln, gucken was bisher wie verwendet wurde, User fragen, was gebrauch wird.
Das sollte Systematisch aufgebaut werden.

Weitere Idee:
Bau von Kategorien. Weil building=yes -> ist irgenwie doof. Gibt es dann auch building=no
oder gibt es building=yes+landuse=commercial ?
Solche widersprüche kann man mit ein Kategorien (in verschiedenen Ebenen) lösen:
z.B. Kategorien:
-Gebäude
--Haus

---

Wohnblock
Eigentumswohnug
Ruine

...
-Fläche
--Boden

---

Sand

--Wasser

---

Salzgewässer
Süßgewässer

...

Nur alles was nicht eindeutig einer Kategorie zuzuordnen ist, sollte als Tag beschrieben werden.