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.

ich denke feature/proposal-Seiten im Wiki sind schon mal ein guter Anfang, sowie der konsequente Hinweise auf dort ablaufende Diskussionen und Abstimmungen. Und zwar der Hinweis einzelner Mitglieder wie aber auch ganzer community-Bereiche (z.b. an Stammtischen etc.), damit der Wissensstand und somit Quasi-Standards erweitert und etabliert werden. Zu vielen deiner Vorschläge gibt es auch bereits entsprechende proposals und Diskussionen. Also einfach dort einbringen, vieles wurde in der Tat bereits diskutiert. Nachteil: braucht viel Lese- und Recherchearbeit.

Aber man kann und soll sich grundsätzlich Fragen, wie man diesen Prozess verbessern und vor allem auch beschleunigen kann (beschleunigen im Sinne von “es soll schnell gehen bis als Standard definiert” und im Sinne von “so schnell wie möglich an die Masse bringen (sei es im Sinne von Editoren-Verbesserung oder von Dokumentations-Verbesserung”). Und hier sehe ich noch eingies an Verbesserungspotential… doch wer nimmts in die Hände…?

Es braucht aber meiner Meinung nach einen richtigen Standard. Leider gibts auch auch viel zu viele Anlaufstellen, wo ich mich informieren muss.
Bei meinen meisten Fragen konnte mir das Wiki nicht eine eindeutige antwort geben.
Sondern nur: man kann es so machen oder so oder so.

Was denn nun am besten ist, kann sich wohl jeder selber raussuhen. Und die Wiki weist auch nur viel zu selten auf Relationen hin. Das sollte an höhchter stelle Stehen. Wen bringt eine gut getaggte Karte was, wenn > 60% weit weg vom Standard taggen?

Meiner Meinung nach: Qualität geht über Quantität.

Das Problem ist auch: wenn ich jetzt irgendwas versuche zu Korrigieren, kommt irgendwann ein anderer, der das nicht versteht und taggt das alles wieder um, weil er mit Relationen nichts anfangen kann.
Deswegen muss an der Stelle gleich der Editor aufschreien: Den User erst gar nciht die Möglichkeit geben, nicht standardisierte Tags und Attribute hinzuzufügen oder den User zumindset vorher informieren und auf der Karte dann ein Warn-Schild einblenden.

EDIT:
Im Sinne der Geschwindigkeit ist ein Standard das beste. Ich habe meine eigenen Tags schon mehrmals geändert, weil ich erst später mitbekommen habe, wie es besser geht. Aber so wirklich zufrieden mit irgendeiner Tag-Lösung bin ich gar nicht.
Das Beste ist meiner Meinung nach ein Relations-Konzept sowie ein Kategorie-Schema und Tags nur für Zusatzinformationen verwenden.
Wer sich nicht im Standard halt, sollte spätestens 1 Tag später vom Renderer eine Feedback bekommen: “Damit kann ich nichts anfangen”

Hallo mpeter,

ich möchte nur zwei kleine Punkte herauspicken:
Zu 3. Höhendaten: Sind meiner Meinung nach genau genug durch SRTM-Daten abgedeckt. Ich sehe keinen Grund, damit die OSM-Datenbank vollzumüllen.

Zu 2. Festschreibung von Regeln: Woher soll irgendjemand wissen, wie ein bestimmtes Objekt getaggt werden soll und was optimal ist? Das kristallisiert sich immer mehr heraus und irgendwann gibt es einen Quasi-Standard. Etwas von vornherein festlegen birgt ein großes Risiko.

Für deinen Vorschlag 4 stimme ich Dir vollkommen zu. Das wäre wirklich sinnvoll und die Gefahr von unabsichtlichem Daten-Vandalismus wäre geringer.

Bis dann
Johannes

Das mit dem Editor ist schon klar, doch davon sind wir noch weit entfernt, weil es eben die Standards noch gar nicht gibt, wie du ja selber schreist. Sich darüber Gedanken zu machen bringt also jetzt im Moment noch nicht viel (im Sinne von konkreter Beseitigung des Problems). Also bleibt doch wieder nur der Weg das Wiki aufzuräumen und Klarheit zu schaffen, wie du selber schreibst. Ein Anfang in meinen Augen wäre sich einen Überblick zu verschaffen, wo explizit Mehrdeutigkeiten existieren resp. explizit mehrere Varianten zur Lösung eines Tagging-Problems im Wiki existieren, diese aufzulisten und dann Stück für Stück abzuarbeiten mit proposals und votes. In einem zweiten Schritt dann die Verbesserung von bestehenden Ansätzen. Beides ist aber wie beschrieben bereits im Gange, doch - zumindest empfinde ich es so und da sehe ich wie gesagt das grösste Problem - noch zu unkoordiniert: zu Proposals und Diskussionen komme ich nur, wenn ich mich durch jede Edit-Seite klicke und jedem Link folge, und so muss ich mir jeden Krempel zusammen reimen. Dass Leuten so der Geduldsfaden reisst und sie nicht schnell und effizient an die Informationen kommen - und dadurch auch Zweigleisigkeiten entstehen - verwundert mich dann nicht mehr.

Wie Johannes sagt bringt ein Festlegen von Standards gleich von Beginn an auch ein gewisses Risiko mit sich. Aber ich selber habe das Problem mit Quasi-Standards, weil genau die sind eben - da sie nur Quasi sind - oft nicht explizit und verbindlich, zumindest in den Köpfen der Leute. Und hier hackt der Prozess noch etwas: es diskutieren - leider - bei vielen bspw. proposals nur wenig Leute mit. Das ist der Bekanntheit von Problemstellen und vor allem von Lösungsansätzen nicht gerade förderlich. Weil dadurch braucht solch ein Prozess der Optimierung zwingend ettliche Monate, weil erst so überhaupt genügend Leute in Kontakt mit den Problemstellen gekommen sind und sich - durch die Lösungsvielfalt - Lösungsansätze herauskristallisieren, die alle denkbaren use cases abdecken. Das ist etwas misslich.

Ich für mich fände eine Optimierung des Wikis und der darin ablaufenden Prozesse ein guter, erster Schritt in die richtige Richtung.

@srtm: da kann man sicherlcih diskutieren, was auch vom Rechenaufwand und der Verarbeitung (Berechnungen von Steigungen diverser Strecken etc.) besser ist. Ich kanns nicht sagen, da mir der Hintergrund dazu fehlt. Allerdings - und das ist ev. eher ein Punkt - habe ich bei vielen GPS-Geräten die ich bisher gehabt habe, eine grössere Ungenauigkeit in Bezug auf die Höhe als auf die anderen beiden Achsen festgestellt. Ev. nur Zufall… Aber gerade gute Daten hätte ich damit auch nicht gekriegt. Einzelne Punkte als Höheninfos finde ich aber auch etwas unsinnig.

Hallo JohannesF,

Die meisten Objekte sind doch Eindeutig: z.B. Gebäude:
-wenn vorhanden Relation zur Fläche (Eigenheimviertel …)
-Tag name=MyBuilding

Zum Gebäude gehört immer mindestens ein Eingang:
-Relation: MyBuilding
-Relation: StraßeAusDerAnschrift
-Tag Hausnummer=1
-Straße=Müllerstraße
-Postleitzahl=03355
-Hausnummer=21A
-Land=DE

Wenn die Kategorien gut aufgebaut sind, dann lernt man beim lesen der Kategorien und versteht.

Falls Fragen sind, kann man im Wiki suchen, dass zu jeder Anwendung eine Erklärung sowie mehre Beispiele parat hat.

Sehe ich nicht so. OSM gibts mittlerweile schon seit mehrenen Jahren. Daraus kann man eigentlich ziemlich gut alle bedürfigen Beschreibungen für Objekte etc. erkennen.
Wie oft kommt es denn vor, dass was neues in OSM eingetragen wird, dass noch nie da war?

Wenn ein Standard gut durchdacht ist, dann kann man damit alles einer Stadt, eines Dorfes und Landschaft sowie Straßensystem eindeutig abdecken.
Falls dann noch was fehlt, kann man es zumindest grob mit den Kategorien beschreiben und einen tag setzen “Genauere Beschreibung lässt standard noch nicht zu” und im Kommentar schreiben, wie man sich das gedacht hat.

Der Standard kann ja auch erweitert werden.

Der aktuelle Quasistandart besteht eigentlich fast nur aus Tags. Viele Tags sind einfach doppelt. Was passiert wenn sich eine Straße umbenennt, müssen dann alle tausend Objekte umgetaggt werden?

Wiki ist natürlich eine guter Schritt. Aber wie soll ich da was schreiben, was ich selbst nicht genau weiß, wie es richtig ist.

Nur weil die Mehrheit es so macht, muss es deswegen nicht richtig und schon garnicht optimal sein.

Ich könnte zwar dort teilweise mein Konzept mit einbringen (Relationen hervorheben, Alternative Tags entfernen), doch das würde sicherlich wieder schnell rückgängig gemacht werden.

Neben den Wiki ist noch der Renderer wichtig:
Ich wäre dafür, dass Mapnik und Osmarenderer einfach unübliche oder schlechte Tags nicht darstellt.

Dann würden die User sich erst wundern und dann im Wiki schauen oder zumindest denn im Forum auf das Wiki verwiesen werden.

Und welcher Meeresspiegel soll es dann sein?

Leider ist das Normalnull in vielen Landern anders definiert B)

http://de.wikipedia.org/wiki/H%C3%B6he_%C3%BCber_dem_Meeresspiegel#Amtliche_H.C3.B6hensysteme_ausgew.C3.A4hlter_L.C3.A4nder

Aber bei den vielen verschiedenen Regeln und dem Chaos im Wiki stimme ich Dir zu.

Auch das man erst in zig quellen suchen muß (Wiki, Mailliste,…) macht keinen Spaß.

Hallo mpeter,

Für die ersten beiden Sätze hast du meine volle Zustimmung. Ich halte es z.B. für grausam, jede Hausnummer mit PLZ, Ort und Land zu versehen. Ich mache es trotzdem (nur das Land lasse ich weg…).
Der 3. Satz ließe sich eventuell durch einen Editor lösen, mit dem mehrere Straßen auf einmal editiert werden können.

Das grundsätzliche Problem ist meiner Meinung nach, dass jeder Mapper die Tags in Form von key/value-Paaren direkt versteht und umsetzen kann. Relationen sind schwieriger zu durchschauen und auch schwieriger umzusetzen (das liegt aber hauptsächlich am Editor).

Ich denke, die Lösung muss hier im Editor liegen (insbesondere Potlatch hat Verbesserungspotential), so dass man Relationen einfach und übersichtlich darstellen kann und sich durch die Abhängigkeiten klicken kann, per drag & drop oder klicken Wege bzw. Punkte hinzufügen kann und so weiter.

Bis dann
Johannes

genau das ist das die Schwierigkeit: Konzeptverbesserungen sollte man immer unabhängig von - im Falle von OSM - dem Editor und dem Renderer sehen. Letztere haben sich dann letztlich anzupassen, was meist - im Falle von Renderer - eine rein technische Sache ist resp. - im Falle des Editors - eine usability-Angelegenheit. Und idealerweise vermischt man diese Diskussionen auch nicht, weil sonst zu schnell Missstände in Editoren etc. sich auf die Konzeptentwicklung von tags, relations und deren Gebrauch auswirken. Und das wäre fatal.

ich mag die Entwicklung, die es bei JOSM gegeben hat: klick auf Icons und schon habe ich eine Eingabemaske und kann alles wichtige für ein feature eingeben. Mich interessieren dann die zu Grunde liegenden Tags nicht mehr. Wenn das nun so weit geht, dass im Hintergrund tags und/oder relations vergeben werden, dann ist das perfekt: der Editor entscheidet, wann welche Variante erlaubt ist (wenn bspw. explizit gem. Spezifikationen auch mehrere Tagging-Varianten erlaubt wären… situationsgebunden halt) und der Benutzer bleibt davon komplett verschont.

Ich frag mich eben auch, ob in jedem Fall genau EINE Tagging-Veriante reicht: PLZ und Strassen als Beziehung zu Gebäuden hinzufügen ist toll. Gibt aber genug Kartenausschnitte, wo Gebäude da sind (weil sie jemand hingeklatscht hat, warum auch immer), die Strassen dazu aber noch fehlen und erst in Monanten kommen, wenn ein anderer Mapper sie erfasst hat. Natürlich, ist per se eine schlechte Art Daten zu erfassen, aber leider halt nach wie vor möglich. Hier ist dann ein tag für plz, Strassenname etc. zwingend. Weil eine relation geht hier nicht (egal ob artifizielles Beispiel oder nicht: gibt genügend davon…). Man muss halt unterscheiden zwischen Ideallösung, die aus konzeptueller Sicht perfekt ist, und einer machbaren Lösung für ein Netzwerk an Daten, dass sich ständig im Aufbau und Umbruch befindet. Insofern verstehe ich es ein Stück weit, wenn es mehrere Lösungen für das selbe Problem gibt.

Anders schauts bei eindeutigen Dingen aus. Der öffentliche VErkehr hat ja auch je nach Land und community eine leicht andere Art umgesetzt und verstanden zu werden. Aber solange es sauber dokumentiert ist, kann man es automatisch umwandeln lassen. Aber: jemand muss es initiieren und tun. Und da sind wir dann wieder bei der Schwäche des ganzen Systems: zu wenig globale Organisation und Struktur, die einen Grundrahmen und Standards etabliert. Gleiches gilt - wie bereits gesagt - auch fürs Wiki: ich finde es sehr positiv, weils viele Infos drin hat die sehr helfen, aber letztlich ists ein Chaos.

Die Relation kann man ja trotzdem anlegen und hinzufügen, selbst wenn es die Straße als Weg noch gar nicht gibt.

Für Hausnummer-Punkte gehören die auch dazu. Schon alleine, weil man nur so schnell nach Adressen suchen kann.
Trotz diesen Tags finde ich, dass zusätzlich noch die Relation Straße zum Adresspoint/ Hausnummer dazugehört, weil man nur so den Zusammenhang eindeutig darstellen kann.
Es gibt auch Hausnummern, zu denen keine Straße dazugehört, sondern ein anderer Zusammenhang.

Warum nicht? Zusätzlich zur Adresse gehört die Relation, egal ob die Straße schon eingezeichnet ist oder nicht, die Relation kann man ja trotzdem anlegen.

Es geht ja nur darum, die Grundstruktur des Straßensystems eindeutig und mit Beziehungen zu einander gestalten: Gebäude, Straßen, Hausnummern, Stadtteil
Wenn ich die Relation Stadtteil übergebe, dann brauch ich nicht mehr Taggen, das das Objekt zur Stadt … gehört, denn der Stadtteil zeigt ja auf die Stadt, die hat dann wieder als Relation das Land usw.

Bei Geländen kann man sich nciht alles eindeutig machen. Dafür sind dann Tags angebracht. Aber man kann zumindest grob eine Kategorie zuordnen und entscheiden, ob es privat ist oder öffentlich zugänglich.
Bei Wäldern kann man so die Kategorie Wald auswählen und die Unterkategorie Nadelwald/ Mischwald … Dann gibt es noch einen standardisierten tag, wo man die Baumdichte grob angeben kann.

Grob gibts eigentlich nur: Straßenbahn, S-Bahn, Zug, U-Bahn, Bus, Zug, Taxi.
Welche Züge auf den Strecken genau langfahren, lässt sich wieder mit Relationen klären (für jede Linie eine Relation, die enthält Name, Art (Regional-Zug, ICE, Tram, …) zusätzlich vllt. noch Fahrtzeiten.

Und hier zeigt sich wieder die Genialität des Konzeptes: z.B. bei den Fahrzeiten. Man brauch somit für jede Linie nur die Informationen eintragen.
Mithilfe einer Fahrzeittabelle und den eingetragenen Haltestellen ist es für Software ein kinderspiel Routen für ÖPNV zu berechnen - mit Zeitangaben, umsteigen.

Mit Tags ist das gar nicht zu machen oder der Aufwand wäre katastrophal hoch.

Ich denke mit mehreren Konzepte: Relationen (für Infrastruktur bis Gebäude und Hausnummern sowie Gelände), Kategorien (Gelände, Sportplätze, Landschaften, sonstige Objekte, Gewässer) und Tags (für zusätzliche und überkategorische Informationen z.B. kann man wheelchair=yes/no bei Haltestellen, Gebäuden, Aufgängen, Wege (wegen Treppen = no) unterschiedlicher Orts einsetzten).

Nachtrag

Das finde ich gar nicht mal so schlecht. Selbst wenn die Hausnummer die Referenz der Straße hat, gehört meiner Meinung nach nochmal die vollständige Adresse zum Eingang/ Adress-POI. Damit erleichterst du Suchmaschinen und Route-Software erheblich die Arbeit.
Das addr:full ist dann meiner Meinung nach überflüssig.

Mit den Web Editor geht das sehr einfach einfach auf “Relation hinzufügen” und es wird eine Liste eingeblendet oder eine Relation erstellen anklicken.
Wenn man aber Relationen verwendet, muss zuvor ein Konzept klar sein.
z.B. gehört in Objekt “Hausnummer” bzw. “Eingang” die Relation “Straße” und die Relation “Haus”. Somit ist alles eindeutig beschrieben.
Das Haus/ Gebäude sollte NICHT mehr die Relation Straße enthalten, da es schon mit Hausnummer und somit auch mit der Straße verknüpft ist.

Das was aber im Webeditor noch fehlt ist, dass ich die Relationenliste in echtzeit filtern kann, so dass ich deutlich einfach Relationen auswählen kann und nichti immer neu in der Liste zu suchen.

EDIT: sorry, ausversehen zu viel geklickt

ich spreche von ganzen ÖPNV-Schemas (bspw. Oxomoa) und deren Abwandlungen davon. Hier herrscht zu viel Diversität und die Prozesse zur Vereinheitlichung oder gar Durchsetzung sind zu langsam. Solange aber die Dokumentation klar ist, haben wir keine Probleme, weil es sich jederzeit transformieren lässt (mit mehr oder weniger Aufwand). Das wollte ich ausdrücken. Um konkrete Umsetzungen oder das Verfluchen von Relationen ging es mir gar nicht

Hallo mpeter89,

als ich den Titel Deines Posts gelesen habe, kam mir ehrlich gesagt die Galle hoch.

“OSM-Standard verabschieden … und knallhart umsetzen”

Wenn ich solche Sätze lese, zeigt das mir, dass Du den Sinn von und die Absicht von OSM nicht verstanden hast.

OSM ist von je her ein anarchisches Projekt. Das heißt viele Wege führen nach Rom, wie Du das ja auch unter 1.) treffend bemerkt hast

Na und das ist ja gerade das Gute. In der Community wird nach einer Lösung gesucht und meistens wird auch eine gefunden. Manchmal ist sie nicht optimal aber die Karte kann sich trotzdem sehen lassen und braucht mittlerweile keinen Vergleich mit "G****e zu scheuen.

Dann mach ein Proposal und sorg’ dafür, dass es sich durchsetzt !

Indem man es im Editor entsprechend einzeichnet, auch wenn ich im Moment nicht nachvollziehen kann, was Du meinst.

Kannst Du da Beispiele nennen?

Solange es die Renderer rendern, beweist dies nur die Vielfältigkeit von OSM und irgendwann setzt sich der beste Tag durch.

OSM wir auch nie fertig, weil immer wieder neue Möglichkeiten gefunden werden etwas zu erfassen und zu taggen. Wenn es fertig wären, müssten wir uns ja ein neues Hobby suchen.

Jeder Renderer interpretiert die Tags, wie es sein Programmierer vorsieht. Das ist ja das Schöne an OSM, wir erstellen eine Datenbank, aus der sich die Renderer das extrahieren was sie für ihre spezielle Karte brauchen.

Wir taggen nicht für die Renderer und auch nicht für die Router.

Mit dieser Überstandardisierung erreichst Du nur, dass die Vielfalt von OSM verloren geht und damit auch Menge Mapper

Da gibt es schon mehrere davon z.B. Keepright

Auf die Idee sind schon andere vor Dir gekommen. Das bedingt aber auch einen ungleich größeren Hardwareaufwand. Dann mach Dich schon mal auf Sponsorensuche

Da kann ich Dich nur zitieren “Macht das mal endlich” Wir sind eine ehrenamtliche und vielfältige Community und nur vom Reden darüber tut sich nichts. Und nicht jeder hat die Zeit sich ausschließlich mit diesem wenn auch fast süchtig machenden Hobby zu beschäftigen.

Auch wenn ich mich wiederhole, mach ein Proposal und sorge dafür, dass es sich durchsetzt ?

Gruß

Volker

Ich bin auch ein sehr grosser Freund von Standards.

Allerdings hat Steve’s Artikel ueber “Architecture Astronauts” mich etwas nachdenklich gemacht. Leider ist der Link auf diesen Artikel am Ende der Seite http://wiki.openstreetmap.org/wiki/Developer_community kaputt…

Ich denke, man sollte diesen Artikel gelesen haben, bevor man ueber ein wie auch immer geartetes Erzwingen von Standards nachdenkt. Hat jemand einen Link darauf? Dieser Artikel ist uebrigends nicht nur fuer Entwickler interessant.

Wenn ich für OSM arbeite mache ich das aus 2 Gründe: Spaß und Freude daran Fortschritt eines großartigen Projektes zu sehen.
Doch wenn ich arbeite, möchte ich auch, dass meine Arbeit nicht so schnell vergänglich ist. Wenn jede Straße anders getaggt, kann man mit den Daten nicht viel anfangen.
Was nützt dir ein Haufen von Daten ohne Struktur? Das ist wertlos.
Nur wenn sich alle an einen Standard halten und nach vorgegebenen Konzept Daten einplegen, sind die Daten gut verwertbar: Routing-Services, Map-Service, Adresssuche oder je nach Anwendung selbst nach eigenen Kriterien generierte Karte.
Außerdem ist es anstrengend bei jeder kleinigkeit zu überlegen und an 5 verschiedenen stellen zu suchen, nur um zu Wissen, wie man was korrekt taggt. Letztens wollte ich ein Freibad taggen. Dafür gibt es keinen Tag kann man es nur ganz grob und verwaschen mit anderen eher selten verwendetet Tags beschreiben.
Woher soll der Renderer jetzt aber wissen, wie er das richtig Darstellen soll? Für einen Renderer ist es verdammt schwierig alle verschiedenen Tags, die eigentliche das selbe meinen, richtig auszuwerten.

Was spricht gegen standards? Wenn Windows heute keine Quasimonomol hätte, dann würde auch unter Windows Softwareinstallation extrem aufwändig ablaufen wie unter Linux - ganz zu schweigen von den armen Programmieren, die jede einzelne Plattform unterstützen müssen. Aber das ist ein anderes Thema.

In einer anderen Community/ Forum wird dann für das gleiche Problem eine andere Lösung gefunden.
Ganz schlimm ist es dann, wenn man so taggt, dass der Renderer es richtig darstellen kann. Das finde ich ganz absourd. Ich tagge immer so, wie es in der Realität ist und nicht anders, nur damit es im renderer richtig dargestellt wird.
Das was du anspricht funktioniert aber nur zu einer gewissen stufe. Sicher sieh es ganz gut aus. Aber das schwierige steht eigentlich noch bevor: die Optimierungen, die Kleinigkeiten. Und wenn es jeder anders macht, dann kommt der Renderer nicht mehr hinter her alles richtig darzustellen.
Außerdem will man auch mehr machen als nur Karten anzeigen. Mann will wie Google Maps auch Routing-Services anbieten. Das funktioniert aber nur gut, wenn alles eindeutig ist und sich jeder an einen Standard hält.

Vielleicht will man OSM irgendwann auch für Wissenschaftliche Aspekte benutzen - z.B. Auswertung von Parkflächen der Städte etc. Die Daten sind aber nur dafür nutzbar, wenn sie einfach anzusprechen sind. Das geht wiederum nur mit Relationen.

Vielleicht nicht das beste aber: addr:…, addr:full, is_in Wobei dann manche auf die Ideen kommen und bei Straßen und Feldern Adressen angeben.
Hausnummern gehören z.B. nur 1 einziger mal als Punkt auf die Karte.
Stellt dir ein Routing-Service vor, wo man eine Adresse sucht und der plötzlich 3x die selbe Adresse bei verschiedenen Objekten findet…

Das ist eben falsch. Man soll sich nicht an renderer richten. Es ist der falsche Weg, dass ein Renderer sich an den User richten muss. Ein anderer Renderer interpretiert deine Daten vllt. ganz anders.
Stell dir vor der Duden würde sich nach den richten, was die leute so schreiben, z.B. im Chat

Außerdem will man damit mehr machen als nur einfache Karten anzeigen.

Darum geht es nicht. Es geht darum, dass man einfach einen Haufen schon vorhandener Objekte, Wege immer wieder überarbeiten muss, weil sich der Volks-Standard ständig ändert. So kommen neue Tags hinzu, die ein Sachverhalt deutlich besser ausdrücken und der vom Dienst x viel besser unterstützt wird.
Anders gesagt: Man kommt nicht weiter, weil man nur dabei ist das Chaos anderer zu korrigieren.
Wenn es alle gleich richtig machen würden, wäre OSM schon viel weiter. Leider wächst der Aufwand auch exponential an.
Das wiederum müssen dann wieder verzweifelt die Editoren ausgleichen.

Wenn ein Renderer z.B. nur alle Freizeitangebote anzeigen möchten, aber diese nur so ganz komisch getaggt sind, dann wird er leider die Hälfte übersehen. Ein Schwimmbecken musste ich z.B. mit natural=water taggen.
EIn Renderer könnte das als See interpretieren. Ein anderer denkt, vllt. das wäre ein Becken, interpretiert dann aber Gewässer falsch.

Dann frage ich mich: für was tagst du dann.
Gute strukturierte und kategorisierte Daten kann man ganz schnell und einfach aufbereiten. Andernfalls wird es sehr schwierig die Daten automatisiert zu bearbeiten.
Ein Computer kann nicht wie ein Mensch die Daten erfassen, sondern kann nur Relationen, Kategorien auswerten und Tags.
Mit Relationen, Kategorien ist das aber besonders eindeutig beschrieben.

Sehe ich anders. Die meisten pfleizigen Mapper werden irgendwann eher frustiert aufgeben, weil sie einfach immer nur dran sind, die Karten zu verbessern, aber keinen Fortschritt sehen.

Du übersiehst, dass eine gutes Konzept sehr viel Arbeit spart.

1. muss deutlich weniger getaggt werden
2. muss man sich nicht ständig den kopf zerbrechen wie man was macht
3. ist es doch viel bequemer die Straße als Relation hinzuzufügen und die entsprechende kategorie auszuwählen, als mit 4 tags zu versuchen ein speziellen Sportplatz zu beschreiben

Wer redet denn davon, dass alles als statische bilder gerendert werden muss.
Ich frage mich sowieso, warum man statt bilder nicht einfach die Vektordaten lädt und die dann bei jeden im Browser oder Programm in Echtzeit gerendert werden.
Genau so wird es doch auch bei jeden OSM Editor gemacht - auch JOSM rendert in echtzeit die Daten.
Hat den Vorteil dass man keine Rechenserver mehr brauch und der User deutlich schneller die Karte bekommt und auch dynamisch sachen aus- und einblenden kann und stufenlos zoomen etc.

windows = google maps
linux = openstreetmap

wunderbar so soll es sein

routing funktioniert doch heute schon? Die schwächen sind bekannt (abbiegerelationen etc) aber da wird dran gearbeitet (http://wiki.openstreetmap.org/wiki/DE:Relation:restriction).

Ähm eindeutig nein: http://wiki.openstreetmap.org/wiki/Xapi
Mit der relation entwirfst du nur einen weiteren Key für eine definierte Menge. Einfacher wird es nur für den Durschnittsuser. Für alle die soetwas semiprofessionel machen die werden sich eh auf die Nodes Ways stürzen und sich nicht auf irgendwelche realtionen verlassen.

mir bisher nicht begegnet … wird verbessert oder der mapper angeschrieben was er sich dabei gedacht hat…

tut er wenn auch um ein vielfaches langsamer
http://www.duden-suche.de/suche/abstract.php?shortname=fx&artikel_id=1002402&verweis=1

Außerdem will man damit mehr machen als nur einfache Karten anzeigen.

bis aufs öpnv habe ich das in de letzten 2 jahren nicht mitbekommen. bzw es ist mir nicht bewusst. und schlieslich gibts für solch simple änderugen bots die das automatisch durchführen können.

bitte gib mir mal ne bounding box wo das vorkommt ich möchte mir die eidts mal ansehen auf die du hier ansprichst…

definiere was ist richtig?
du kannst vlt noch einen Standard für Deutschland durchdrücken aber nicht international da gabs doch schon grosse probleme mit den boundaries und admin leveln weil die halt nur vernünftig für GB passten.
Und eine Wohnstrasse in Indien oder China sieht nun mal anders aus als hier und hat ihre lokalen besonderheiten die durch landesbegebenheiten die du nicht erschlagen kannst. Bzw ich hab keine Lust für “mein” mappingebiet zu erfassen ob Elephanten oder Pferde vorfahrt vor Fahrrädern oder Zirkustraktoren hat.

Ein renderer würdeerstmal interpretieren das da Wasser ist. Gemeinsam mit dem Key sport=swimming weis er zumindest das dort eine Fläche ist die zum schwimmen genutzt wird.
Für die Unterscheidung künstliches schwimmbecken / naturbecken fehlt derzeit etwas ja.
Da könntest du ja mal nen proposal machen. wenn man es denn braucht

wieso ist das damit besonders eindeutig beschrieben ?
Ich habe einen eine fläche mit 4 punkten. Jeden Punkt ist eine eindeutige Koordinate zugeordnet.
Die verbindung zwischen den punkten (der way) hat ein tag (als beispiel landuse=recreation_ground)
Dami ist das ding meines errachtens ersteinmal eindeutig beschrieben.
Was macht es besser wenn du jetzt noch die abstraktionschicht einer realtion drüberlegst und es in die relationen “Parks in Hamburg” schiebst ?

Sinn machen realtionen meiner meinung nach nur bei Logischen lokalen zusammenhängen (Haltestellen, Öpnv netz, turn restrictions).

Es wird einen punkt geben da kann man nur noch verbessen. Aber ich sehe täglich neues was man taggen kann. Woher beziehst du dein Wissen das die Leute frustriert aufgeben weil es nur ums verbessern geht? Google hat doch grade eindeutig das gegenteil bewiesen?

Ja das sehen wir ein. Unser konzept heisst Nodes/Way/Keys/Tags und inzwischen realtionen. Und damit fahren wir bislang sehr gut.

begründe das bitte. das kann ich nicht nachvollziehen.

das macht doch grade spass dran. Das man durchaus auch mal mitdenken darf.

Verdamm nochmal ich will aber die Detailgenauigkeit. Ich möchte unterscheiden können zwischen einen reinen Fussbalplatz und einen Fussballplatz and em Basketballkörbe Hängen. Oder einen Sportplatz wo drumherum eine Laufbahn ist. Ich möchte auch wissen welchen Belag die hat. Oder ob da eine Sprunggrube für den Weitsprung oder ein Wassergraben für den Hindernislauf.

Wenn ich dann nur noch sagen könne hier ist ein Sportplatz na DIN Iso 9003 dann wäre ich sehr traurig.

Versuch mal auf 200 Mhz (Handy) nen vernünftiges echtzeitrendering hinzulegen…
Ausserdem GLAUBE ich das vorgerenderte Datein immernoch schneller übertragen werden als die Rohdaten (die auch erst übertragen werden müssen) gerendert werden.
Welchen Standard würdest du denn vorschlagen um die Daten in Echtzeit im Browser zu redern?

Standardisierung ist sinnvoll, würde ich nicht bezweifeln. Allerdings ist Standardisierung auch mit Nachteilen verbunden. Insbesondere behindert sie die Entwicklung in Phasen, in denen man eigentlich eher “Brainstorming” haben will - in denen also noch überhaupt nicht bekannt ist, was für Informationen man letztlich alles erfassen möchte. Wir haben momentan z.B. noch ein sehr rudimentäres Straßenmodell. Wir können Spuren, Radwege und dergleichen fast nicht darstellen. Wir können manche Verkehrsschilder-Kombinationen noch überhaupt nicht darstellen (vor allem, wenn man Proposals außen vor lässt). Und wenn man sich so umschaut, werden eigentlich ständig Dinge erfasst, für die man noch keine Tags hat. Das fängt bei Ärzten bestimmter Fachrichtungen an, geht bei selteneren Verkehrsregelungen und Hinweisschildern weiter und hört bei Ampelanlagen noch lange nicht auf.

Insgesamt sind wir da noch weit unterhalb des Niveaus dessen, was man etwa auf einem kommerziellen Navi bekommt, und weitere Entwicklung des Modells ist dringend vonnöten. In dieser Situation würde ich mir nicht zutrauen, eine adäquate Lösung aus dem Hut zu zaubern, die alle Anforderungen abdeckt - da bedarf es noch einiger weiterer Erfahrungen, und als Experimentierstation ist die aktuelle ungeordnete Entwicklung ganz brauchbar. Und wenn man bedenkt, dass auch unsere Software noch lange nicht ausgereift ist (die API hat nicht umsonst Version 0.7), können sich auch die Randbedingungen noch deutlich ändern.

Andersrseits: Ich muß zugeben, dass ich nicht vollends überzeugt bin, dass OSM in der Lage ist, aus dieser zu Experimentierzwecken sinnvollen Chaosphase dann auch irgendwann einmal herauszukommen. Denn ich sehe es keineswegs als unverzichtbaren Vorzug des Projekts an, die Definitionen bestehender Tags alle paar Wochen umzuwerfen, sondern eher als “gläserne Decke” für die erreichbare Qualität. Die vorhandenen Probleme abstreiten bringt es da auch nicht:

Routing funktioniert irgendwie natürlich immer, und mehr Features bietet die heutige OSM-Software einfach nicht. Damit es wirklich funktioniert, braucht es noch einiges an Klärung, und ich rede nicht mal von Spurassistenten, detaillierten Wegbeschreibungen oder dergleichen “Luxus”. Ein paar Beispiele aus den letzten Tagen:

• Die Definitionen von trunk_link/primary_link/secondary_link wurden kürzlich mal wieder eigenmächtig geändert. Neuerdings soll oneway=yes jetzt wieder nicht mehr impliziert sein. Manche Mapper werden sich aber darauf verlassen haben.
• Es gibt immer noch regelmäßig Streit darum, was footway/cycleway/… und path eigentlich genau bedeuten. Kürzlich hat auf der Mailingliste mal wieder jeder seine Privatdefinition vorgetragen.
• Es gibt keine verlässliche Methode, um zu entscheiden, ob eine Straße inner- oder außerorts ist. Man ist sich nicht einmal einig, wie das eigentlich eingetragen werden soll. (Polygon? Tags? Ortseingangsschilder-Nodes? Relation?)
• Manche Tags sind überhaupt nicht vernünftig definiert, z.B. die ganzen day/date_on/off.
• Die Interaktion von verschiedenen Tags, und gerade auch Implikationen, ist noch gar nicht geklärt. Einfaches Beispiel: Ändert ein access=private am highway=cycleway irgendetwas an den Nutzungsrechten? Nach dem hier nein (es müsste bicycle=private heißen, um einen Effekt zu haben). Würde man eine Auswirkung erwarten? Aber sicher doch, m.E… Nur definiert das mal formal und widerspruchsfrei in einer Weise, dass die unausgesprochenen Annahmen jedes Mappers zu jedem Tag erfüllt werden. Ich nehme an, das ist letztlich unmöglich.

Und so weiter. Der Teufel liegt in den gar nicht so randständigen Details.

PS: Höhendaten sind meines Erachtens ein völlig anderes Thema, also kein Kommentar hier dazu. Auch wenn SRTM vorne und hinten nicht reicht.

Schwerlich machbar, denn alle Beteiligten arbeiten auf freiwilliger Basis bei OSM mit. So können die Programmierer der Renderer zu nichts verpflichtet werden. Folglich machen sie es so, wie es Ihnen gefällt. Sie übernehmen von den Vorschlägen nichts oder nur das, was sie für sinnvoll erachten. Will man sie dennoch bevormunden, könnte es sein, dass sie es ignorieren oder schlicht nicht mehr weiterarbeiten. Und dann gibt es eben überhaupt keine Renderer mehr. Das Prinzip ist im Übrigen im jedem freien Projekt ähnlich.

Alternative: Selbermachen oder Leute finden, die dies in Deinem Sinne tun.

Tut mir leid, aber eine andere Lösung sehe ich nicht.

@Tordanik
Sehr guter Beitrag!

Konntest mich zum Teil überzeugen.

Ich kenne noch weitere sehr Problematische Beispiele:

• Den Umgang mit Fuß-, Rad und Gehwegen.
  Soll dafür eine extra Spur angezeigt werden - auch wenn der Gehweg parallel zur Straße gleich hinter dem Bordstein beginnt.
  Was ist mit Straßen, bei denen ein schmaler Radfahrerstreifen auf der eigentlichen Straße ist?
  Ist eine Fußwegspur zuende, wenn sie an eine Straße komm, bei der der Gehweg wieder neben den Bordstein verläuft.
  Wie geht man mit Rad- und Fußwegen bei Kreuzungen (Straße mit mehreren Spuren) um?
• Wie zeichnet man Verkehrschilder ein, wenn diese nur auf einer Straßenseite stehen? z.B. ein Stop-Schild.

Aber wäre folgende Herangehensweise ein Lösung?
1.) Verschiedene Ebenen: d.h. dass es eine Ebene mit Straßen etc. gibt, eine mit POIs, eine die verschiedenen Nutzungs-Flächen (Wohnfläche, Feld, Industriegebiet, Verkaufsplatz, …) markiert sind. Zudem kann es eine Ebene geben, wo Städte als Flächen eingezeichnet werden sowie für Bundestländer, Stadtteile, Postleitzahlen etc. Aber auch Stromleitungen oder irgendwelche unterirdischen Leitungen (Interteil, Wasserrohre, Erdstromkabel …) sollten in eine seperaten Ebene liegen, denn solche Eintragungen lenken beim normalen Kartografieren nur ab.
2.) Ein Gruppierungsmodell:
Das Modell erlaubt es, einen Weg, Objekt, oder Fläche weitere Teile hinzuzufügen.
So kann ich bei einer Straße jede einzelne Spur zeichnen (auf einer gemeinsamen Straße). Zudem zeichne ich naneben noch den Gehweg.
Alles wird aber bei der weiteren Bearbeitung auf 1 Weg minimiert, enhält aber alle Informationen. Wenn ich den Weg verschiebe oder den verlauf entwas ändere, passen sich automatisch die anderen Spuren an…

Wie werden eigentlich die Daten von “professionellen” Kartenmaterial gespeichert/ verwaltet? Wie löst Navigon & Co. die angesprochenen Probleme?