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

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,

JohannesF wrote:

Zu 2. Festschreibung von Regeln: Woher soll irgendjemand wissen, wie ein bestimmtes Objekt getaggt werden soll und was optimal ist?

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.

JohannesF wrote:

Das kristallisiert sich immer mehr heraus und irgendwann gibt es einen Quasi-Standard. Etwas von vornherein festlegen birgt ein großes Risiko.

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?

marcschneider wrote:

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

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.

mpeter89 wrote:

3.) Zudem schlage ich vor, Höhentags einzuführen:
Höheninformationen (+- X Meter über den Meeresspiegel)

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.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,

mpeter89 wrote:

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?

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.

marcschneider wrote:

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.

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

marcschneider wrote:

Hier ist dann ein tag für plz, Strassenname etc. zwingend.

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.

marcschneider wrote:

Weil eine relation geht hier nicht (egal ob artifizielles Beispiel oder nicht: gibt genügend davon...).

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.

marcschneider wrote:

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.

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.

marcschneider wrote:

Insofern verstehe ich es ein Stück weit, wenn es mehrere Lösungen für das selbe Problem gibt.

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.

marcschneider wrote:

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.

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.

marcschneider wrote:

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.

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

JohannesF wrote:

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...).

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.

JohannesF wrote:

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).

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

mpeter89 wrote:

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.

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.

2.) Viele Sachen lassen sich gar nicht eindeutig taggen z.B. Freibäder, Parkgaraden oder andere Sportgebiete.

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

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?

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

4.) Viele Tags, die sehr häufig verwendet werden sind eigntlich gar nicht im "Standard" und werden noch in mehreren leicht modifizierten Versionen genutzt.

Kannst Du da Beispiele nennen?

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.

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

Dieses Tagging-Chaos hat folgende Nachteile:
1.) Man würd nie fertig, weil sich ständig was umgetagt werden muss oder von anderer wird.

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.

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

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.

4.) So können Routing-Services, basierend auf OSM, nie richtig gut funktionieren.

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

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

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

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.

Da gibt es schon mehrere davon z.B. Keepright

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

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 😄

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.

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.

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

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.

aeonesa wrote:

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

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.

aeonesa wrote:

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.

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.

aeonesa wrote:

4.) Viele Tags, die sehr häufig verwendet werden sind eigntlich gar nicht im "Standard" und werden noch in mehreren leicht modifizierten Versionen genutzt.

Kannst Du da Beispiele nennen?

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...

aeonesa wrote:

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.

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

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.

aeonesa wrote:

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.

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.

aeonesa wrote:

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

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.

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.

aeonesa wrote:

4.) So können Routing-Services, basierend auf OSM, nie richtig gut funktionieren.

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

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.

aeonesa wrote:

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

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

aeonesa wrote:

-> 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

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 😄

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.

mpeter89 wrote:

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.

windows = google maps
linux = openstreetmap

Ich tagge immer so, wie es in der Realität ist und nicht anders, nur damit es im renderer richtig dargestellt wird.

wunderbar so soll es sein

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.

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

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.

Ä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.

Stellt dir ein Routing-Service vor, wo man eine Adresse sucht und der plötzlich 3x die selbe Adresse bei verschiedenen Objekten findet...

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

Stell dir vor der Duden würde sich nach den richten, was die leute so schreiben, z.B. im Chat 😉

tut er wenn auch um ein vielfaches langsamer
http://www.duden-suche.de/suche/abstrac … &verweis=1

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.

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.

Anders gesagt: Man kommt nicht weiter, weil man nur dabei ist das Chaos anderer zu korrigieren.

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

Wenn es alle gleich richtig machen würden, wäre OSM schon viel weiter. Leider wächst der Aufwand auch exponential an.

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 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.

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 😉

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.

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).

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.

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?

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

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

1. muss deutlich weniger getaggt werden

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

2. muss man sich nicht ständig den kopf zerbrechen wie man was macht

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

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

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.

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.

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:

Islanit wrote:

routing funktioniert doch heute schon?

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.

mpeter89 wrote:

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

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?

mpeter89 wrote:

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.

Ich warte auch schon lange darauf, dass man mal endlich Layer einführt.
Dann könnten einige Cracks endlich ihre OpenFlightMap und OpenKanalisationsMap machen,
ohne dass alles unübersichtlich wird.

Auch meiner Meinung nach gehört in OSM ein Standard eingeführt, an den sich jeder zu halten hat.
Ich habe es satt, dass jeder seine eigene footway/path/cycleway-Definition hat.
Wenn es feste Regeln geben würde, wäre endlich klar, was was in Wirklichkeit darstellen soll.

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"

timme ich mit dir überein das es bis dahin ein weiter weg ist. Man muss aber auch mal sehen was OSM ursprünglich als absicht hatte nämlich eine normale Strassenkarte zu erstellen. Und da sind wir doch recht weit gekommen. Jetzt wäre die Frage wie macht man weiter um auch solche Anforderungen sinnvoll unterzubringen.

- 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.

war mir nicht bekannt das man das oneway weglassen konnte...

- 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.

Problem der Internationalisierung. Entweder man lebt damit das das Us/ Uk schema nicht 100% passt. Oder man verabschiedet einen Standard für Deutschland und lebt damit das er nicht / nur eingeschränkt gerendert wird. Optimal wäre natürlich eine Definition zu finden die für alle Länder passt.

- 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?)

Jo wurde diskutiert und bisher kein ergebnis... wie wärs mit nem proposal im wiki ?

- Manche Tags sind überhaupt nicht vernünftig definiert, z.B. die ganzen day/date_on/off.

->Proposal
Das Problem ist hier der Namensraum ich find das trennen von tags via ":" überhauot nicht schön.... leider hat sich das ja durchgesetzt....

Die Interaktion von verschiedenen Tags, und gerade auch Implikationen, ist noch gar nicht geklärt.

Gebe ich dir recht.
Bei deinem konkreten Beispiel passt es aber nicht in der Wiki steht "Default-Access-Restriction if not tagged on the individual street. " da dein beispiel an dem Fahrradweg gettagt wurde sollte der Router das berücksichtigen

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.

Strassenbegleitende Wege: Mein letzter Stand war das diese nicht eingezeichnet werden sollen
http://wiki.openstreetmap.org/wiki/Wiki … %C3%BCndel

Was ist mit Straßen, bei denen ein schmaler Radfahrerstreifen auf der eigentlichen Straße ist?

radstreifen auf der fahrbahn sind im wiki beschrieben....

Wie geht man mit Rad- und Fußwegen bei Kreuzungen (Straße mit mehreren Spuren) um?

was meinst du genau ?

- Wie zeichnet man Verkehrschilder ein, wenn diese nur auf einer Straßenseite stehen? z.B. ein Stop-Schild.

Bisher werden Verkehrsschilder kaum einzel erfasst 😉 bis auf das Stoppschild... wieder was gesehen was man morgen taggen kann. Wobei wir da derzeit kein passendes Schema haben wie es mit Stoppschildern an der Ampel aussieht 😉

Zum Rest: Layer währen in der Tat recht interessant. Sehe ich aber in den Kommenden 1,5 Jahren erstmal nicht.

Auch meiner Meinung nach gehört in OSM ein Standard eingeführt, an den sich jeder zu halten hat.
Ich habe es satt, dass jeder seine eigene footway/path/cycleway-Definition hat.
Wenn es feste Regeln geben würde, wäre endlich klar, was was in Wirklichkeit darstellen soll.

Gibt es doch heute?
http://wiki.openstreetmap.org/wiki/DE:Key:cycleway
http://wiki.openstreetmap.org/wiki/DE:Key:highway

Das Problem ist das es eine Überschneidung zwischen path und footway gibt. Wenn man die korrigiert sollte es passen. Deinem Problem das ein Mapper den Weg für einen Trampelpfad (da unbefestigt) und der andere für einen ausgebauten fussweg (da beschildert) hält wirst du damit nicht lösen können.

Auch wenn ich mich jetzt als Rookie oute, aber mal ehrlich:
Standards = JA
aber ab wann wird ein Standard zur Bremse. Gerade in einem Umfeld wie OSM. Einem Projekt das auf Freiwilligkeit beruht. Und wenn man von Standards spricht, welche Standards meint ihr? Deutsche Standards oder internationale? 😉 Ich selbst bin viel international unterwegs und verdammt froh über OSM, weil ich für mein Handheld GPS nicht jedes mal 200EUR teure Karten kaufen muss. Und bisher bin ich mit den downlaodbaren Karten super zurecht gekommen. "Abbiegbare Nebenstraßen"? Weniger das Problem, eher das noch nicht alle Straßen erfasst sind. Und in Ländern wie Thailand auch noch ein Sprachenproblem, denn ich kann kein Thai lesen. 🤣

Verschiedene Renderer? JA unbedingt, denn wenn ich Nightlife suche, hätte ich gern eine andere Darstellung als wenn ich Wandern gehe.

Mag sein, daß ich nicht immer richtig tagge, dann kann ein Experte dies gern korrigieren im Nachgang. Aber wenn mein Editor anfängt Fehlermeldungen zu produzieren und meine Daten nicht mehr akzeptiert, würde ich wohl aufhören. Aber das möchte ich ehrlich gesagt nicht, dafür macht es viel zu viel Spaß.

Ach ja und schaut euch mal die Smilies Definition für das Forum an. Da gibt es auch oft 2 Möglichkeiten 😄 oder 😄 ihr seht keinen Unterschied? Liegt wohl am Renderer...

Gewisse Standards wären schon schön. Und die gibt es ja teilweise auch. Aber eben nur teilweise und sie entwickeln sich weiter. Was voriges Jahr nach den damals geltenden Regeln getaggt wurde, muß heute nicht mehr stimmen. Auch im Ausland entstehen oft Fragen. Ist das nun in PL eine Kreisstraße oder eher eine Bezirksstraße. In solchen Fällen ist es wohl wichtig, daß die Straße überhaupt erst ein mal aufgenommen wurde.

Als ich neulich mal "mein" Gebiet betrachtete, entdeckte ich eine Höhle. Nun, ich bin der Autor der deutschen Veröffentlichungen zu dem entsprechenden Naturlehrpfad und wußte: Da ist ein frühmittelalterlicher Bergwerksstollen. Also den User angeschrieben. Antwort: Ja, wir haben den Stollen als Höhle getaggt. Was anderes wird ja nicht gerendert... Dinge, die sich auch auf normalen Topokarten finden, sollten imho schon gerendert werden. Alles darüber hinaus gehende wäre zukünftig ein Fall für Layer und bis es so weit ist, sollten spezielle Renderer zum Einsatz kommen.

Gruß

Dieter

gerade dein Stollen vs. Höhlen-Beispiel zeigt aber eben eines der typischen Probleme: die Leute haben den Prozess nicht richtig verstanden, weil dieser nirgends sauber definiert und bereits von Beginn an jedem User klar ist. In deinem Falle wäre es: change request an den Renderer und nicht rumpfuschen mit den tags, damit es doch irgendwie auf der Karte erscheint. Und so etwas läuft für mich eben auch unter Standards, und zwar im Sinne von klar und sauber definierten Prozessen, die letztlich die Diversität und Flexibilität von OSM positiv unterstützen, weil eben Bastel-tagging zum Zweck eines schnellen Erscheinens auf der Karte verhindert wird. ABer ansonsten stimme ich dir natürlich voll zu.

Tordanik wrote:

Standardisierung ist sinnvoll, [...].

Tordanik wrote:

Standardisierung [...] behindert [...] 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.

das finde ich sehr treffend formuliert, und ich glaube dass all diejenigen, die hier gegen eine zu starke "Einengung" durch "knallharte" Standardisierung wettern, berechtigterweise Angst haben, dass dieses kreative brainstorming durch die Vorschläge von mpeter89 zu kurz käme.

Dennoch geht es mir irgendwie ähnlich und ich vermisse oftmals so etwas wie die von mpeter89 angesprochene Kategorisierung.

Nur: eine Kategorisierung setzt immer eine bestimmte Perspektive voraus, die aber oftmals nicht eindeutig sein kann: z.B. kann sich die "tagging"-Perspektive an Nutzungsrechten von Wegen orientieren. Als Mountainbiker interessieren mich dagegen eher Wegbeschaffenheiten und nicht, ob z.B. in Baden-Württemberg das Radeln auf schmäleren Waldwegen untersagt ist. Den Wanderer interessiert die Wegbeschaffenheit wiederum aus einer anderer Perspektive. Wenn man das nun weiterdenkt, wird es zumindest in manchen Fällen irgendwann schwierig, eindeutige Kategorien zu definieren. Vielleicht gibt es deswegen solche immerwährenden Diskussionen, wie z.B. diejenige um die Verwendung von "path" und "footway".

Jede Kategorisierung geht doch von einer Perspektive bzw. einem Modell aus, mit dem ich die Welt betrachte.
Das Argument, einfach nur die "Realität" so genau abbilden zu wollen wie möglich, ist für mich nicht so ganz überzeugend, denn die Wirklichkeit gibt es eben nur in der Wirklichkeit, und jede Abbildung ins OSM ist eine Projektion nach einer bestimmten (wenn auch manchmal unbewussten) Kategorisierung. Nur möglichst viele und möglichst detailgetreue Informationen zu sammeln, wird dann tatsächlich irgendwann keinen Nutzen mehr bringen und auch keine sinnvolle "Abbildung" der Wirklichkeit mehr bringen.

Ein bisschen muss man eben doch "für den Renderer taggen", sonst kann man die so vielbeschworene kreative Anarchie irgendwann auch wieder sein lassen und sollte lieber einfach nur für sich selbst raus in die echte Wirklichkeit gehen diese einfach ohne OSM genießen.

Tordanik wrote:

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.

Hat jemand irgendeine Idee, wie sich dies bewerkstelligen ließe? Ich denke man braucht irgendwie beides: verbindliche (aber dennoch ausreichend "lebende") Standards und kreatives Chaos, wobei sich letzteres auf die Fälle beschränken sollte, wo man irgendwas im Rahmen der Standards eben wirklich nicht erfassen kann.

Wenn die Antwort darauf nur lauten kann: "mach halt ein proposal", dann zielt es für mich an der Sache vorbei, denn die hier gewälzten Themen sind ja noch lange nicht ausreichend konkrete Vorschläge, für die man eben nur mal eben werben muss, sondern es wäre ein langer Weg, hier gemeinsam mit vielen anderen gewillten OSM'lern neue Strukturen zu entwickeln (die ja wirklich niemanden einengen sollen, wenn er etwas erfassen mag, was sich partout nicht in diese Strukturen zwängen lässt).

Wie lässt sich hier was in der Richtung tun, dass sich die aktuelle Vorgehensweise in OSM letztendlich nicht als die

Tordanik wrote:

"gläserne Decke" für die erreichbare Qualität

erweisen wird?

longtoby wrote:

Tordanik wrote:

Standardisierung ist sinnvoll, [...].

Tordanik wrote:

Standardisierung [...] behindert [...] 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.

das finde ich sehr treffend formuliert, und ich glaube dass all diejenigen, die hier gegen eine zu starke "Einengung" durch "knallharte" Standardisierung wettern, berechtigterweise Angst haben, dass dieses kreative brainstorming durch die Vorschläge von mpeter89 zu kurz käme.
[...]
Jede Kategorisierung geht doch von einer Perspektive bzw. einem Modell aus, mit dem ich die Welt betrachte.
[...]

Meiner Meinung nach gibt es dieses Modell fuer OSM nicht -- und es wird nie eines geben. Es wird deshalb keines geben, weil das Projekt offen ist.

Jeder kann jeder Zeit neue Ideen einbringen, das Projekt kann sich staendig weiterentwickeln. Das macht fuer mich seinen besonderen Reiz aus.

Fuer so ein offenes Projekt kann man keinen Standard (abschliessend) definieren, weil die Diskussion nie enden wuerde. Steckt man einen festen Rahmen ab, wuerde man viele Leute mit (teilweise) anderen Interessen ausgrenzen, Leute, die heute mitmachen und die das Projekt weiterbringen. Ich glaube auch nicht, dass sich die aktuell Beteiligten auf einen bestimmten Rahmen einigen koennten.

Regeln, die man natuerlich braucht, werden sich im Laufe der Zeit herausbilden. Wenn deren Einhaltung "knallhart" erzwungen wird, droht man die Weiterentwicklung abzuwuergen, oder wenigstens zu behindern.

Wenn man so will, hat OSM ein "anderes" Vorgehensmodell. Damit mag man sich abfinden, oder nicht. Man mag es reizvoll finden -- oder eben nicht.

Ich glaube, mit aehnlichen Argumenten wollten einige Leute auch begruenden, dass eine offene, nicht zentral gesteuerte Softwareentwicklung nicht funktionieren kann. Der Erfolg von Open Source Projekten widerspricht dem bislang.

longtoby wrote:

denn die Wirklichkeit gibt es eben nur in der Wirklichkeit, und jede Abbildung ins OSM ist eine Projektion
[...]
Nur möglichst viele und möglichst detailgetreue Informationen zu sammeln, wird dann tatsächlich irgendwann keinen Nutzen mehr bringen und auch keine sinnvolle "Abbildung" der Wirklichkeit mehr bringen.

Die Datenbank ist gross und sie kann die Wirklichkeit mehr und mehr approximieren -- sie ist offen. Jeder Renderer definiert eine Projektion. Man kann beliebig viele weitere Renderer/Projektionen schaffen.

Um nochmal klarzustellen. Mir geht mir nicht um "knallharte" Standardisierung.
Ein guter Weg ist: Das was bis jetzt schon da und klar ist zu standardisieren. Das Konzept muss natürlich so sein, dass man es gut erweitern kann. Alles was nicht standardisiert ist, kann weiter getaggt werden, bis irgendwann man wieder 1 Level erreicht hat, wo man Sachverhalte eines Themas wieder zusammenfassen kann und in den Standard einfügt.

Gut wäre auch, wenn editoren den Nutzern etwas den Weg weisen würde. Ein Problem ist ja auch, dass man sich schon zu früh ins Detail stürzt, wenn rudimentäre Sachen noch fehlen.
So kommt es vor, dass an einigen Straßen schon Häuser eingezeichnet sind mit Hausnummern, eine Straße weiter sind die Tracks aber noch sehr grob und viele Nebenstraßen Fehlen.
Der Editor sollte helfen, einen den User drauf hinzuweisen, wo im vergleich zu Nachbarstraßen die Qualität noch deutlich geringer ist.

Ich glaube trotzdem, dass es ein Weg gibt, alle Daten (von Straßen über Hausnummer bis hin zu einzelnen Bäumen und Verkehrschildern) sauber und in Relation zueinander darzustellen.
Das schwierige ist die Abstraktion. Man muss also mit mehreren Konzepten arbeiten: Ableitungen, Schichten, Relationen/ Verknüpfungen Kategorien und Tags.

Cool wäre es, wenn ich ein Objekt einen Verweis auf ein Eintrag/ Tabelle/ Datum in einer Datenbank geben könnte.
Mir schwebt da so folgendes im Kopf: Für den ÖPNV gibt es für jede Haltestelle für jeden Zug einen Fahrplan. Dieser ist unmöglich in Tags darstellbar. Aber wenn der Fahrplan in deiner Datenbank liegt, bräuchte man diesen nur noch mit der Haltestelle verknüpfen.

Nur: eine Kategorisierung setzt immer eine bestimmte Perspektive voraus, die aber oftmals nicht eindeutig sein kann: z.B. kann sich die "tagging"-Perspektive an Nutzungsrechten von Wegen orientieren. Als Mountainbiker interessieren mich dagegen eher Wegbeschaffenheiten und nicht, ob z.B. in Baden-Württemberg das Radeln auf schmäleren Waldwegen untersagt ist. Den Wanderer interessiert die Wegbeschaffenheit wiederum aus einer anderer Perspektive. Wenn man das nun weiterdenkt, wird es zumindest in manchen Fällen irgendwann schwierig, eindeutige Kategorien zu definieren. Vielleicht gibt es deswegen solche immerwährenden Diskussionen, wie z.B. diejenige um die Verwendung von "path" und "footway".

Es spricht nichts dagenen, mehrere Kategorien parallel zu setzen.
Zum Beispiel: Kategorie für Wegbeschaffenheiten , für Nutzung (obwohl ich das eher nicht kategoriesieren würde sondern taggen.

Bei Straßén ist das eher ungünstig geeignet, da man dort eben schwer entscheiden kann, ob es radweg, fußweg oder kleine straße ist.
Nutzungsrechte kann man am besten taggen. kategorie: weg, 1 spur, breite=2m, boden=geplastert, auto=nein, fahrad=ja
Wobei man nur beschreiben sollte was explizit erlaubt oder verboten ist.

Kategorien miten sich eher für Flächen und Objekte an.

nachtrag

schlauchboot wrote:

Meiner Meinung nach gibt es dieses Modell fuer OSM nicht -- und es wird nie eines geben. Es wird deshalb keines geben, weil das Projekt offen ist.

Allein mit Tags kommt man nicht weit. Wenn man Städte mit mehreren Details ausstatten möchte, sollte man über weitere Konzepte nachdenken. Die Beischreibung mit Tags ist unelegant, sehr aufwändig und nur mit guten Tools und Makros großflächige Änderungen vorzunehmen.

schlauchboot wrote:

Jeder kann jeder Zeit neue Ideen einbringen, das Projekt kann sich staendig weiterentwickeln. Das macht fuer mich seinen besonderen Reiz aus.

Soll er ja auch. Aber es wäre unsinnig, wenn jeder sein eigenes Rad erfindet.
Es geht darum, grundstruktur zu standardisieren, und nochmal zu überprüfen, ob Tags wirklich überall das beste Konzept für alles ist, oder ob man mit anderen Modellen Zusammenhänge besser ausdrücken könnte.

schlauchboot wrote:

Fuer so ein offenes Projekt kann man keinen Standard (abschliessend) definieren, weil die Diskussion nie enden wuerde.

Das offene Office-Format ODT, dass haupsächlich vom offenen Office-Programm OpenOffice genutzt wird, ist ein gutes Beispiel für einen Standard.

schlauchboot wrote:

Steckt man einen festen Rahmen ab, wuerde man viele Leute mit (teilweise) anderen Interessen ausgrenzen, Leute, die heute mitmachen und die das Projekt weiterbringen.

Analogie: Kenne keinen, der sich einer Programmiersprache verweigert, weil die Syntax festgeschrieben ist und er nicht kreativ die Syntax ändern kann.
Es geht nur darum, die Basis-Beschreibung zu Standardisieren. Alles was man sonst nicht ausdrücken kann, schreibt man dann als Tags.

schlauchboot wrote:

Ich glaube auch nicht, dass sich die aktuell Beteiligten auf einen bestimmten Rahmen einigen koennten.

Eine Arbeitsgruppe muss einen oder mehrere Vorschläge liefern, die dann zur Diskussion ausgesetzte werden. Dann folgen Verbesserungen und dann kann man nochmal überprüfen, in wie weit man die OSM-Daten in dem Standard darstellen könnte. Dann gibts es ein Voting und am ende steht ein fester Termin für den Abschuss.
Wenn man will geht das schon.
Eigentlich ist es auch nicht soo wichtig, wie er aussieht. Wichtig ist nur, dass er nur eingehalten wird. Das erleichtert vielen Usern auch das arbeiten, erleichtert Renderern und Editor-Entwickler die Arbeit und bei OSM kann man sich dann auf die eigentliche Arbeit konzentrieren (jetzt ist es so, dass der eine Mapper vom anderen alle Tags überarbeitet, weil er meint, es wäre besser so, ein anderer ändert es dann nochmal ...).

Ich glaube, mit aehnlichen Argumenten wollten einige Leute auch begruenden, dass eine offene, nicht zentral gesteuerte Softwareentwicklung nicht funktionieren kann. Der Erfolg von Open Source Projekten widerspricht dem bislang.

Beispiel Linux:
Das "Betriebssystem" Linux hatte meiner Meinung nach die letzten Jahre sehr wenig Marktanteil gehabt und gewinnen können, weil es eben dort keine/ wenige Standards gibt und verschiedene Distributionen zueinander inkompatibel sind. Apple ist zumindest zu sich selbst kompatibel. Microsoft hat seine "Standards" durchgesetzt und Windows konnte sich so einen erheblichen Vorteil sichern: Software läuft auf verschiedenen Windowsversionen fast immer -> sehr praktisch und kostenschonend für Softwareprogrammierer. Für den Kunden ist das auch ein wichtiges Argument.

marcschneider wrote:

gerade dein Stollen vs. Höhlen-Beispiel zeigt aber eben eines der typischen Probleme: die Leute haben den Prozess nicht richtig verstanden, weil dieser nirgends sauber definiert und bereits von Beginn an jedem User klar ist. In deinem Falle wäre es: change request an den Renderer und nicht rumpfuschen mit den tags, damit es doch irgendwie auf der Karte erscheint. Und so etwas läuft für mich eben auch unter Standards, und zwar im Sinne von klar und sauber definierten Prozessen, die letztlich die Diversität und Flexibilität von OSM positiv unterstützen, weil eben Bastel-tagging zum Zweck eines schnellen Erscheinens auf der Karte verhindert wird. ABer ansonsten stimme ich dir natürlich voll zu.

Betreffs der Höhle/Stollen-Problematik: Ich gebe es ja zu, ich habe da persönliche Skrupel. Die haben sich Mühe gegeben, sind über die Berge MTB gefahren. Und das ist in der Gegend nicht wirklich spaßig. Jedenfalls nicht aus meiner Sicht. Haben was entdeckt und es eingetragen. Wollten es anderen mitteilen. Und haben es eben vordergründig völlig falsch eingetragen. Was soll ich nun machen? Klar könnte ich es ändern. Ich kann aber auch noch ein Jahr warten, bis sich bestimmte Sachen vielleicht geklärt haben. Auf meiner watch-Liste steht es eh. Sauber zu lösen ist es heute obendrein nicht, da m.W. proporsal. Sonst gäbe es gar keinen Tag.

Ansonsten bin ich ja selbst nicht besser, was die Regeln betrifft :-) Das befördert das Verständnis für solche User. Einfach mal nach Panzerwerk im Wiki suchen und sich den Rest denken...

Gruß
Dieter

DieterTD wrote:

marcschneider wrote:

gerade dein Stollen vs. Höhlen-Beispiel zeigt aber eben eines der typischen Probleme: die Leute haben den Prozess nicht richtig verstanden, weil dieser nirgends sauber definiert und bereits von Beginn an jedem User klar ist. In deinem Falle wäre es: change request an den Renderer und nicht rumpfuschen mit den tags, damit es doch irgendwie auf der Karte erscheint. Und so etwas läuft für mich eben auch unter Standards, und zwar im Sinne von klar und sauber definierten Prozessen, die letztlich die Diversität und Flexibilität von OSM positiv unterstützen, weil eben Bastel-tagging zum Zweck eines schnellen Erscheinens auf der Karte verhindert wird. ABer ansonsten stimme ich dir natürlich voll zu.

Betreffs der Höhle/Stollen-Problematik: Ich gebe es ja zu, ich habe da persönliche Skrupel. Die haben sich Mühe gegeben, sind über die Berge MTB gefahren. Und das ist in der Gegend nicht wirklich spaßig. Jedenfalls nicht aus meiner Sicht. Haben was entdeckt und es eingetragen. Wollten es anderen mitteilen. Und haben es eben vordergründig völlig falsch eingetragen. Was soll ich nun machen? Klar könnte ich es ändern. Ich kann aber auch noch ein Jahr warten, bis sich bestimmte Sachen vielleicht geklärt haben. Auf meiner watch-Liste steht es eh. Sauber zu lösen ist es heute obendrein nicht, da m.W. proporsal. Sonst gäbe es gar keinen Tag.

Ansonsten bin ich ja selbst nicht besser, was die Regeln betrifft :-) Das befördert das Verständnis für solche User. Einfach mal nach Panzerwerk im Wiki suchen und sich den Rest denken...

Gruß
Dieter

klar da hast du natürlich ein Stück weit absolut recht. Letztlich reicht die watchlist aber nicht aus. Viel mehr Leute (und da schliesse ich mich mit ein) sollten nicht nur beim mappen, sondern eben auch beim Konzipieren aktiv werden und etwas nicht nur auf die watchlist tun, sondern so viele Steine in Bewegung setzen wie möglich. Und weiter sollten comment, note und fixme tags viel öfters gebraucht und auch wahrgenommen werden. So können gerade beim editieren von bestehenden Punkten viele Missverständnisse ausgeräumt werden.

Und die Arbeit derjenigen, die etwas falsch eintragen, ist nach wie vor löblich. Doch gerade das sind oftmals die Leute, die man eben aktiv in die Diskussion mit einbeziehen sollte. Die wissen am besten, was sie eingetragen haben und auch warum sie es falsch eingetragen haben, und können so den Prozess der Verbesserung am besten füttern. Und das sind eben diese standardisierten oder besser gesagt "gemeinsam geteilten" Prozessabläufe, die ich etwas vermisse. Viele - so scheint es mir - taggen einfach mal drauf los und hoffen, dass sich a) ihr tagging irgendwann als doch noch richtig erweist oder b) sich jemand anders dann schon drum kümmert. Und DAS ist in einem community Projekt definitiv der falsche Ansatz. Letztlich ist es blöd, aber mappen alleine ist eben bei OSM nur die halbe Miete, da gehört noch wesentlich mehr Arbeit dazu. Und sobald jemand ein bisschen exotischere und komplexere Dinge zu mappen beginnt, gehört eben die Entwicklung und Konzeptdiskussion meinen Augen leider zur Aufgabe dazu, um in einem vernünftigen Zeitrahmen zu einem qualitativ hochwertigen Endprodukt zu kommen.

Viele - so scheint es mir wenn ich mit dem einen oder anderen mappe spreche, obwohl das zugegebenermassen noch nicht sehr viele gewesen sind - sind sich vielerlei Dinge in Bezug auf Diskussionsstränge, proposals, Änderungen etc. gar nicht bewusst. Und das ist einfach schade, weil so verschenken wir viele wertvolle Gehirne, die dem Projekt extrem dienen könnten.

mpeter89 wrote:

schlauchboot wrote:

Meiner Meinung nach gibt es dieses Modell fuer OSM nicht -- und es wird nie eines geben. Es wird deshalb keines geben, weil das Projekt offen ist.

Allein mit Tags kommt man nicht weit. Wenn man Städte mit mehreren Details ausstatten möchte, sollte man über weitere Konzepte nachdenken.

Worueber -- ueber welches Modell -- reden wir hier? Meiner Meinung nach muss man zwischen zwei Modellen unterscheiden:

(1) Dem "Meta"modell von OSM, welches sagt, dass alle Information durch Punkte, Wege, Relationen und Attribute (in Form von Tags) an diesen drei Objekten zu beschreiben ist.

(2) Dem Modell, welches sagt, wie ein konkretes Ding der Wirklichkeit (e.g. Klaeranlage) in der Sprache des Metamodells zu beschreiben ist.

Das sind zwei verschiedene Modellebenen. Beziehst Du Dich auf (1), wenn Du sagst, mit Tags allein kommt man nicht weit? Dein "eroeffnender" Beitrag schien mir eher auf (2) abzustellen.

mpeter89 wrote:

Die Beischreibung mit Tags ist unelegant, sehr aufwändig und nur mit guten Tools und Makros großflächige Änderungen vorzunehmen.

Reichen Tags also doch, ist nur die Bedienung nicht optimal? I.e. ist (1) voellig ausreichend und hast Du nur ein Problem mit (2)?

Kennst Du das Buch "The Cathedral and the Bazaar" von Eric S. Raymond? Ich habe es nicht gelesen, aber nach allem was ich davon gehoert habe, passt es auf diese Diskussion.

In diesem Sinne ist OSM ein Marktplatz auf dem jeder seinen Editor anbieten kann. Jeder Mapper entscheidet, welchen Editor er nutzen moechte. Die Community entscheidet, welcher Editor (welche Menge an Editoren) sich durchsetzt. So funktioniert Open Source. Schreibe Deinen Editor und biete ihn auf diesem Markt an.

Doch sei gewarnt: Viele Mapper koennen nicht programmieren und werden vermutlich mit "Makros" Probleme bekommen. Fuer viele scheinen Relationen schwer verstaendlich -- jedenfalls entsteht in dieser Liste gelegentlich dieser Eindruck. Auch diese Leute wollen mitarbeiten und suchen fuer sie geeignete Tools. Und auch diese Leute werden Deinen Editor bewerten.... ;-)

mpeter89 wrote:

Microsoft hat seine "Standards" durchgesetzt

Ein Standard ist offen, M$ nicht. Standards und M$ widersprechen einander. Vgl. z.B. http://de.wikipedia.org/wiki/Standard

Hallo miteinander,

ich möchte hier meine Stimme gegen Standartisierung abgeben.
Für mich besteht der Reiz des Projekts gerade in der offenen Struktur. Besser als Standarts wäre es, wenn man auf ganz kurzen Weg mit den anderen Kartografen (meine Muttersprache ist deutsch) Kontakt aufnehmen könnte:
schau mal hier, ich war auch dort, wäre es nich besser, die Wirklichkeit (was immer das sein mag) so.....zu beschreiben

Diese Wirklichkeit (mal so was profanes wie eine Hausnummer ausgenommen) nimmt jeder von uns anders wahr! Und jeder von uns hat seine eigene Vorstellung, was eine gute Karte darstellen sollte! Dazu kommt noch, dass es ja bei der Erarbeitung der Karten ganz unterschiedlich Zielgruppen gibt. Eine Wanderkarte ist eben keine Nahverkehrskarte und auch kein Stadtplan.

Ich bin seit etwa 25 Jahren Statiker. Ich habe noch keine "richtige" Statik gesehen, auch sind all meine eigenen Berechnungen niemals 100% richtig. Ihr könnt ganz ruhig bleiben, ich berechne überwiegend Eisenbahnbrücken!
Meine Statik ist niemals "richtig" oder "falsch", die Arbeit sollte aber zweckdienlich sein! Und darunter versteht eben jeder etwas anderes. Standartisierung würde darauf hinauslaufen, dass (nach einem irgendwie demokratischen Entscheidungsprozess) Regeln aufgestellt werden, die die Wirklichkeit eben auch nicht 100% so abbilden, wie ich das möchte. Dann würde ich mich an eine "Kommision" wenden, bitte, bitte... ich möchte...Detail.
Ich würde aussteigen!
Nun noch ein großes LOB an OSM. Ich kann mir hier einen wunderschönen Kindheitstraum erfüllen: eine Karte erstellen. Ich besitze eine Menge sehr detailierter Karten 1:10000 vom Landesvermessungsamt. Mein unmittelbares Umfeld (Kyffhäusergebirge) ist in OSM jetzt schon "zweckdienlicher" abgebildet als diese Karten es jemals schaffen konnten. Die Daten sind korrekt, detailiert und aktuell!

Aus der Tatsache, dass ein paar Beschreibungen fehlen (z.Bsp. ein Graben ohne Wasser! barrier=ditch?) würde ich auf gar keinen Fall ableiten, dass da nun ein Standart her muss. Sicherlich kann ich das ein bischen lockerer sehen. Mir persönlich geht es um eine detailierte Wanderkarte. Die Mitstreiter hier, welche an Routing oder auch verwaltungstechnische Anwendungen denken....geht es verständlicherweise etwas anders. Aber ich bin mir absolut sicher, dass sehr viele abspringen würden, wenn es zu einer zu starken Regulierung käme.
Ich möchte noch auf den eneormen Erfolg von WIKIPEDIA verweisen. Die haben nur minimale Regeln und einen langen Atem!
So, ich geh jetzt in den herrlichen Winterwald: oberes Tannenbergstal, kleine Wege, eine kleine Quelle und ehemalige Schwerspatstollen, eine alte Halde....

euch allen ein schöner Advent

Mich würde mal interessieren, wer denn eigentlich die hier geforderten Standard erarbeiten, festschreiben und überwachen soll? Soll das EIN Gremium werden, das die Standards weltweit erarbeitet erarbeitet, oder gibt es nationale Untergremien? Wie setzt sich das Gremium zusammen und wie wird es wiederum überwacht? Oder haben wir dann bald eine Administratoren-Elite wie bei Wikipedia, die behauptet, sich selber zu überwachen? Oder übernimmt die Standardisierung dann die OSM-Foundation?

Wird das Gremium dann alles Löschen, was nicht relevant - sorry - nicht dem Standard entspricht? Wie wird überprüft, ob wirklich vorort korrekt gemappt wurde?

Wieviel Zeit wird das Standardisierungsgremium vorrausichtlich benötigen, bis ein allgemeingülter Standard erarbeitet ist (in Jahren). Den aktuellen Stand zum Standard erheben wird nicht gehen. Dafür enthält er zu viele Widersprüche. Nach welchen Kriterien wird der Standard erarbeitet? Welche Lösung wird verwendet, wenn mehrere gleichwertige Vorschläge vorhanden sind. Wird es Arbeitsgruppen zu bestimmten Spezialthemen geben (Eisenbahn, Schifffahrt, Radtouristik, Routing usw.).

Und was machen wir solange, bis der Standard steht und verabschiedet wurde? Stellen wir das Mappen solange ein, bis das Gremium einen Standard erarbeitet hat?

Dazu würde ich mir ein paar Antworten von den Befürwortern einer strikten Standardisierung wünschen. ;-)

Detlef

@statikerkelbra

Einem guten Datenbestand ist die Zielgruppe egal. Jede Software kann sich genau das rauspicken, was für seine Zielgruppe wichtig ist. Das ist bei OSM zurzeit nicht gegeben. Damit das möglich wird, müssen Zusaemmenhänge mit Relationen beschrieben werden, eine grobe Gliederung durch sowas wie Kategorien gegeben sein, verschiedene Layer gibt (z.B. Flächen die Ein Wohngebiet beschreiben sind eigentlich unabhängig von POIs, Häuser und Hausnummern, dennoch für gewisse Zielgruppen interessanter als Gebäude selbst - als einen Haufen von Gebäuden erschließt sich nicht automatisch, dass es sich um ein Wohngebiert, Gewerbegebiet etc. handelt. Aber manchmal wird bei OSM eben diese Flächen gelöscht, wenn die einzelnen Häuser eingetragen werden, was verständlich ist, weil die Flächen im Editior stören -> angesprochene Problematik).
Zusätzliche Informationen, sollten weiterhin als Tags markiert werden.

Doch man sollte sich zum Beispiel einig sein, wie man Häuser + Hausnummern kartografiert. Einige setzten die Adresse direkt auf das Gebäude, andere (mich eingeschlossen) lassen das Haus Haus sein und setzten die Adresse als Punkt unmittelbar vor dem Haus (Symbolisiert gleichzeitig ein Eingang).
Dann bleibt auch die Frage, was passiert, wenn in einem Haus WOhnungen und eine oder mehrere Geschäfte drin sind. Zum Beispiel ist in einem Wohnhaus unten eine Apotheke drin.
Ich würde es als Wohnhaus taggen, die Adresse als Punkt davor setzten und den POI Apotheke mitten aufs Haus setzten. Andere machen es anders. Was nun perfekt, darüber kann man sich streiten.

Es ist aber doof, wenn mal die Adresse zum Haus gehört, mal als POI davor angegeben wird oder ein Haus den namen der Apotheke zu geben, obwohl da auch Wohnungen sind. Selbst durch das Wiki wird keine Empfehlung gegeben (ich werde das vielleicht mal anpassen müssen). Ein Gebäude gebe ich nur einen Namen, wenn es wirlich einer Firma allein gehört z.B. ein Lebensmittelanbieter oder ein großer Elektromarkt oder ein Museum, Halle etc.
Vielleicht gibt es aber auch andere Wege.

Wie auch immer. Ziel einer Standardisierung sollte sein, diese fragen öffentlich nochmal zu überprüfen und zu diskutieren, wie man es am besten macht. Zum Schluss sollte im Wiki dann nur doch das Ergebis/ die Einigung/ Kompromiss beschrieben werden. Wenn jemand was dann falsch taggt, kann ich mich aufs wiki berufen und diese Sachen korrigieren.

Was ist so schlimm an dieser Idee? Nur ich es als Standard beschreibe, muss es ja nciht gleich ein starres, undynamisches Ungehäuer sein.

dgdg wrote:

Mich würde mal interessieren, wer denn eigentlich die hier geforderten Standard erarbeiten, festschreiben und überwachen soll? Soll das EIN Gremium werden, das die Standards weltweit erarbeitet erarbeitet, oder gibt es nationale Untergremien? Wie setzt sich das Gremium zusammen und wie wird es wiederum überwacht? Oder haben wir dann bald eine Administratoren-Elite wie bei Wikipedia, die behauptet, sich selber zu überwachen? Oder übernimmt die Standardisierung dann die OSM-Foundation?

Er wird von einer Arbeitsgruppe entworfen, in der Öffentlichkeit diskutiert und die sicheren Punkte dann in der Wiki festgelegt, die Informationsquelle und Anlaufstelle bei Fragen und Zweifel zugleich ist.
Wenn es ein Bedarf geben sollte, eine Festlegung nochmal zu überarbeiten, kann man das erneut zur Diskussion stellen, wobei eine oder mehrere Arbeitsgruppen quasi Diskussionsleiter sind.

Aber das sollte nich allzu oft vorkommen. Z.B. kann ich mir nicht vorstellen, dass man bei Gebäude-Adressen-Festlegung irgendwann nochmal was grundlegendes ändern sollte.

schlauchboot wrote:

Reichen Tags also doch, ist nur die Bedienung nicht optimal? I.e. ist (1) voellig ausreichend und hast Du nur ein Problem mit (2)?

Tags sind für viele Sachen notwenig. Für grundlegende Beschreibungen wie z.B. ein Stadion, Fußballplatz, Basesee, Schwimmbecken würden sich Kategorien u.U. besser eignen.
Straßen lassen sich viel besser mit Relationen beschreiben.

Wobei was ist eine Relation eigentlich? Irgendein zusammenhang? Eine direkte Verbindung?
-> das ist ja nicht genau festgelegt. Vielleicht sollte man auch da nochmal unterscheiden.

dgdg wrote:

Mich würde mal interessieren, wer denn eigentlich die hier geforderten Standard erarbeiten, festschreiben und überwachen soll? [...<ganzer Beitrag>...]
Detlef

Ich stimme dem zu, moechte aber noch etwas ergaenzen.

OSM ist zwar ein Wiki, es hat jedoch in gewisser Hinsicht mehr mit "Open Source" gemein, als mit Wikipedia. Das sieht man schon daran, dass hier von Modellen, Projektionen u.ae. gesprochen wurde.

Ganz deutlich wird es aber, wenn man bedenkt, dass es schon einige Diplom- und/oder Doktorarbeiten gab, deren Thema im Rahmen von OSM angesiedelt war. Nach meinem (bescheidenen) Kenntnisstand gehoeren (wenigstens) OpenRouteService und das Routing fuer Rollstuhlfahrer dazu. Ein wie auch immer gearteter Standardisierungsprozess sollte Unis, insbesondere Projekte im Rahmen von Diplom- und Doktorarbeiten nicht behindern oder gar ausschliessen. Zu solchen Projekten sollte eher ermuntert werden, da sie i.d.R. eine Bereicherung darstellen. Solche Projekte beschaeftigen sich aber meistens mit etwas Neuem... und sie verfolgen wohl eher einen praktischen Ansatz und wollen sich nicht mit Standardisierung belasten.

so ihr Weihnachtsmänner,
der Wanderbursche ist aus dem Tannenbergstal zurück, Unterhemd komplett durchgeschwitzt, etwa 10km Weg und eine Latte voller .....Halden, eingefallener Stolleneingänge, ein Stützmauer mitten im Wald....habe ein bischen nachgedacht, wo den die Ursache für den Konflikt liegen könnte,
warum will mpeter89 standartisieren?
ich weisss es nicht, sollen alle Häuser auf der ganzen Welt mit dem oben beschriebeben Schema erfasst werden? Ich finde dieses Schema total einleuchtend, nur interessiert es mich gar nicht, denn ich interessiere mich ausschließlich für das Thema Wandern, Natur, Geschichte.... Häuser gehen mir (Eigenheimbesitzer) tangential am Arm vorbei.
mpeter89 hat sicherlich keinen einzigen zugefallen Schwerspatstollen in seiner Gegend, und wenn, dann geht es ihm mit diesem komischen Loch wie mir mit der Hausnummer von der Apotheke? wahrscheinlich
Standartisierung schreckt ab!
Ich möchte einen Vergleich mit WIKIPEDIA anstellen: dort gibt es einen Artikel über "Torsionsmoment". Was dort geschrieben steht, ist nicht wirklich gut und für mich als Statiker dann doch eher Grundkurs: aber es steht ein bischen was da und man findet einen Einstieg sowie Literaturangaben. Also ist doch der Artikel für meine zukünftigen Kollegen von Vorteil! Ich werde beim Lesen auch nicht dümmer. Nun kommt noch der gesunde Menschenverstand dazu. Ich erwarte doch gar nicht von einem WIKIPEDIA Artikel eine umfassende Abhandlung eines so komplizierten Themas. Dafür habe ich ein paar sehr teure Fachbücher im Regal stehen.
Was spricht denn dagegen, dass wir vom Nutzer unserer Daten erwarten, diese Daten entsprechend des OSM Prinzip (jeder darf fast alles, Haftung grundsätzlich ausgeschlossen) mit seinem hoffentlich gesunden Menschenverstand zu interpretieren. Wenn er das macht, so findet er unter der Hausnummer sowohl die Wohnungen als auch die Apotheke! Ein Mensch schafft das, bei Maschinen kann das schon mal schief gehen.

Wir haben, so denke ich, zwei wesentliche Kartografen: Hobbykartografen wie mich, den das ganze Projekt viel Spaß macht, für die aber nichts wirklich Wichtiges fehlt, wenn hier alles drunter und drüber geht und vielleicht irgendwie einschläft. Dann gibt es aber auch die SEMIPROFIS, für welche die Daten (und natürlich deren Qualität) Grundlage ihrer Erwerbsarbeit sind? Da muss man natürlich anders arbeiten.
Aber die Steigerung der Qualität sollte nicht auf einem abschreckenden Weg durchgeführt werden! Wenn jemand z.Bsp. Häuser einträgt, ohne eine Hausnummer hinzuschreiben, so ist das doch durchaus zweckdienlich? Auch wenn er die Apotheke nicht erwähnt? na und, machts eben der Apotheker!

mpeter89 wrote:

Er wird von einer Arbeitsgruppe entworfen, in der Öffentlichkeit diskutiert und die sicheren Punkte dann in der Wiki festgelegt, die Informationsquelle und Anlaufstelle bei Fragen und Zweifel zugleich ist. Wenn es ein Bedarf geben sollte, eine Festlegung nochmal zu überarbeiten, kann man das erneut zur Diskussion stellen, wobei eine oder mehrere Arbeitsgruppen quasi Diskussionsleiter sind.

Nicht sehr erschöpfend diese Antwort.

Wer richtet die Arbeitrsgruppen ein? Wer bestimmt, wer in den Arbeitsgruppen mitarbeiten darf oder soll? Wer bestimmt, was dann in der Wiki festgelegt wird? Dafür muss doch erstmal eine Organisationsstruktur geschaffen werden, die zur Zeit überhaupt nicht vorhanden ist.

Und ob das ganze gleich auf internationaler Ebene stattfinden soll oder erstmal z.B. nur in Deutschland oder im deutschsprachigen Raum, ist auch offen geblieben.

Denn über solche Dinge wäre doch erstmal zu diskutieren, bevor man sich weiter in technische Details verliert und darüber diskutiert ob das eine oder andere nicht besser als Relation getaggt werden sollte.

Detlef

@statikerkelbra
Du musst dich ja auch nicht für Häuser interessieren. Lass es doch aber andere machen. Das war auch nur ein Beispiel. Und es ist auch nicht schlimm, wenn du falsch taggs. Wenn es eine Anlaufstelle gibt, wo steht wie man es richtig macht, dann können andere deine Tags nachträglich noch verbessern.
Doch dazu muss es erstmal eine übersichtliche Anlaufstelle geben und die muss sich auf eine Möglichkeit für 1 Problem festlegen.

Das Problem ist doch jetzt, wenn ich sachen korrigieren will, weiß ich selber nicht so genau, ob das so richtig ist, weil das in der Wiki auch nur grob oder gar nicht drin steht.
Ein anderer denkt, dass es wieder falsch ist und versucht es nach seiner Auffassung zu berichtigen. Dieses Problem ist durch einheitliche Vorgaben größtenteils aus der Welt zu schaffen.

Ich stimme euch ja zu - ich habe meine Meinung nochmal durchdacht und rede jetzt nur noch von einem einheitliche Vorgaben/ Festlegungen für die grundlegendsten Dinge.
Schadet das? Ich denke nicht. Jeder kann trotzdem weiter machen wie bisher. Aber die "Kartenverbesserer" können dann nachträglich die Tags vereinheitlichen und OSM etwas professioneller zu machen und um die OSM-Daten besser handhabbarer zu machen: für Renderer, für Software bestimtmer Zielgruppen (z.B: Renderer für Scater, für Touristen) oder Routing-Services.

In der Wikipedia wurde nach und nach auch versucht, in Sachen Layout einiges zu vereinheitlichen. So hat jede Seite zu einen Film rechts diesen Streifen mit den Film-Infos.

@dgdg
Es war auch nicht meine Intention hier auf der schnelle genaue Lösungsvorschläge für ein Komitee zu machen, sondern ich wollte nur zeigen, wie es grob ablaufen könnte. Bei vielen anderen OpenSource-Projekten hat sich auch eine Organisation oder sowas wie ein Komitee herausgebildet, dass international die Richtung vorgibt und die Diskussionen lenkt.

mpeter89 wrote:

Es war auch nicht meine Intention hier auf der schnelle genaue Lösungsvorschläge für ein Komitee zu machen, ...

Hatte ich jetzt auch ehrlich gesagt gar nicht erwartet. Ich wollte einfach nochmal auf den Rattenschwanz an Organisation und Administration hinweisen. Und nebenbei auf Wikipedia hinweisen, die im Rahmen ihrer Qualitätsoffensive gerade vieles über Board schmeissen, was sie eigentlich ausgemacht hat.

Es ist meiner Meinung nach ein Irrglaube, dass man irgendwann ein bestimmtes Qualitätsniveau erreicht, wo plötzlich andere Regeln notwendig wären um dieses Niveau zu halten und weiter zu verbessern.

Stattdessen friert man ledlich eine bestimmen Stand ein. Die Aktiven werden sich auf einen Stamm an Spezialisten reduzieren, die wissen, wie man z.B. Relationen richtig mappt. Die Leute mit dem Vorort-Know-How, das eigentlich notwendig ist, werden ausgegrenzt, weil sie lieber durch die Natur radeln oder wandern, statt sich mit Relationen und komplizierten (weil von Experten-Arbeitsgruppen erstellten) Standards rumzuplagen.

Ich glaube nicht, dass sich auf OSM die Regeln und Erfahrungen mit irgendwelchen Opensource-Software-Projekten übertragen lassen. Und ich bin auch mal gespannt, ob Wikipedia noch die Kurve kriegt oder ob die von einem ehemals offenen nd hochdynamischen Projekt zu einer trägen Standard-Enzyklopädie verkommen.

Detlef

@dgdg
Ich glaube du bringst was durcheinander. Wikipedia musste wegen der Qualitätssicherung und vor Schutz vor Vandalismus Schutzmaßnahmen einführen. Das ist bei OSM jetzt aber nicht das Problem. Das Problem wird sicher OSM auch irgendwann haben...
Trotzdem finde ich es gut, dass der Seitenaufbau der Wikipedia überall einheitlich ist. Ich finde die Informationen genau da, woch ich sie erwarte z.B. Film-Informationen am rechten Rand.

dgdg wrote:

Es ist meiner Meinung nach ein Irrglaube, dass man irgendwann ein bestimmtes Qualitätsniveau erreicht, wo plötzlich andere Regeln notwendig wären um dieses Niveau zu halten und weiter zu verbessern.

Das würde ich nicht so verallgemeinern.
Wo wären wir ohne verbindliche Rechtschreibregeln? Dann könnte ich viele Leute im Internet kaum verstehen, besonders Leute aus anderen Dialekt-Gebieten.

Es gitbt durchaus viele andere Beispiele, bei denen Regeln einfach Sinn machen und notwendig sind.

Es würde ja bei OSM ausreichen, wenn man sich im Wiki bei vielen bekannten Problemen und Beschreibungen auf eine Variante einigen würde und auch nur diese propagieren würde.
So kann man eindeutig entscheiden, was wie getaggt werden muss (bei bisher erfassten und bekannten Problemen). So könnte könnten viele Leute aufbrechen und die OSM-Daten nach diesen Wissensstand anzupassen bzw. vereinheitlichen.

Wem es egal ist, ob jeder Mapper das anders macht ... denn ist es eben so. Vielen ist es aber nicht egal, besonders Softwareentwickler, dessen Programme auf den OSM-Daten aufbauen.
Aber was kann einen an - für einen selbst - unverbindliche Ordnung stören? Andere korrigieren schon die eigenenen Fehler, d.h. niemand muss sich unbedingt dran halten.

Wie gesagt: Ich bin mittlerweile davon abgekommen, alles umwerfen zu wollen (da gäbe es zu viele, die sich davor fürchten), aber ich denke, die Wiki von Grund auf zu erneuern, damit sie bei bekannten und gelösten Problemen einen EINE (nicht mehrere Möglichkeiten) Antwort gibt. Also ein Duden für OSM, nach dem man sich richten KANN.
Wenn man sich in der Wiki einig ist, dann ist es auch endlich möglich, das auf OSM zu übertragen - vorher ist das immer ein "Rumgeschaukel".

Es würde so niemand gezwungen gleich richtig zu taggen. Was aber erstmal berichtig wurde, hätte aber deutlich länger bestand, da man immer auf die Wiki verweisen kann.

mpeter89 wrote:

Wo wären wir ohne verbindliche Rechtschreibregeln? Dann könnte ich viele Leute im Internet kaum verstehen, besonders Leute aus anderen Dialekt-Gebieten.

Ein sehr interessanter Punkt. Er koennte sogar ein Gegenargument fuer Dein Ansinnen sein. Wie lange gibt es Sprache und Schrift, seit wann gibt es Rechtschreibregeln im Sinne eines Standards? Schau mal ein paar hundert oder gar tausend Jahre zurueck -- nicht nur bis zur letzten Rechtschreibreform.

Ich bin kein Experte auf diesem Gebiet, vielleicht liest einer hier mit und schreibt was dazu. In zwei Minuten Google-Suche habe ich nur das gefunden: http://www.schriftdeutsch.de/orth-his.htm

Der Text beginnt mit folgenden Worten: "Die Geschichte der Rechtschreibung ist nicht lang: Jahrhundertelang schrieb man individuell so, wie man es für richtig hielt, ..." erinnert mich irgendwie an OSM ;-)

@schlauchboot

Der Grund für die Rechtschreibreform war aber, dass es schwieriger war Texte zu lesen. Weil leute so geschrieben wie gesprochen haben, muss sich somit eine Kommunikation z.B. zwischen Sachse und Bayer als besonders schwierig erwiesen haben 😉
Bei OSM ist es ähnlich. Es werden immer mehr Details erfasst, aber für Software (egal ob Renderer, Routing-Software, Suchmaschinen) sind die Daten nur sehr schwer zu verstehen und richtig einzuordnen.
Aus diesem Sinne her, besteht mein Wusch, zumindest das Wiki eindeutig zu machen und man sich dort wenigsten einig ist und nicht monatlich an vorhandenen Beschreibungen grundlegende Veränderungen macht.

Also ich begrüsse jede Vereinheitlichung !

Und ich wünsche mir benutzerfreundliche Editoren.

Am liebsten so, dass ich einfach im Editor "Schwimmbad" eingeben kann,
und dann gefragt werden, ob ich das Gelände, das Becken oder ein Gebäude meine?
und ob es sich um ein Frei-, Hallen oder Strandbad handelt, und ob das Ding öffentlich oder privat ist.

Ich - und ich vermute die meisten OSMer - habe keine Lust,
mich bei jedem Objekt durch umfangreiche Wiki-Seiten oder gar endlose Listen und Foren durchzuwühlen.

Ich habe keine Ahnung von vielen Dingen (Bahn, ÖPNV, Flughäfen, Routing), und das mit den Wegen und Strassen habe ich selbst nach endlosen Threads bis heute nicht verstanden (auch da scheine ich nicht der Einzige zu sein, denn das kommt alle paar Monate wieder). Wenn ich etwas eintrage, dann möchte ich es auf simple Art "richtig" machen. Ich mag nicht denken, dass OSM sowieso viel zu kompliziert ist und ich da lieber nicht mehr mitmachen mag.

Ich mag auch nicht bei jedem Eintrag LEO bemühen müssen, um das englische Zeug zu verstehen.

Gruss, Markus

Hallo miteinander, vor allem mpeter89

ich war heute mit meiner Frau zum Weihnachtsschmaus im Nachbardorf. Hinzu die gemütliche Nummer, den Rückweg bitte etwas sportlicher. In diesen Wälder habe ich alle Wege, Gräben, Bäche, Grenzsteine... erfasst.
Aber sieh einer an, der sonst trockene Graben ist am zweiten Weihnachtsfeiertag ein Bach (ich musste tatsächlich springen!), und der ansonsten kleine Pfad aus dem Tal heraus (sonst ein kleiner Hohlweg) ist ebenfalss ein Minibach. Naja, und während meine Frau auf mir rumhackt... ihr kennt das sicherlich.... ging mir durch den Kopf, dass man die Wirklichkeit eben nur begrenzt realistisch abbilden kann, und mittels Standarts schon gleich gar nicht.
Ich schreib euch, wenn aus den kleinen Bächen wieder schummelische Waldwege geworden sind, und ich dann wieder ein dickes Lob von meiner Holden bekomme: so ein toller Weg!

Wie man das richtig erfasst: ich bin mir nicht sicher! Und sollte jemand da sein, der sich sicher ist, so werde ich ihm auf gar keinen Fall glauben!

Markus B wrote:

Ich mag auch nicht bei jedem Eintrag LEO bemühen müssen, um das englische Zeug zu verstehen.

Kannst ja versuchen sobald der/ein Fork da ist die Dokumentation auf Deutsch gemacht wird 😉

Hallo mpeter89

Der Weg ist das Ziel. Nicht das reden über den Weg.

1. Die heimlichen Standardisierer sind die Renderer... viele Mapper haben halt auch Interesse das hinten auch was rauskommt.
2. Neue tags oder Relationen werden nur gemacht wenn ein Mehrwert daraus entsteht. Beispiel, wer würde schon Postkasten mappen wenn es keine Karte gibt die diese anzeigt. Natürlich ist hier auch der Editor gefragt.
3. Qualitätssicherung http://wiki.openstreetmap.org/wiki/Qual … ssicherung
Hier werden eventuelle "Fehler" aufgedeckt und wenn es Wert ist auch korrigiert.

Wenn du an den drei Sachen was ändern kannst oder selbst auf die Beine stellen kannst wirst du was erreichen. Aber hier im Forum glaub ich weniger das du was erreichst, außer deine eigene Meinung abzugleichen. Da muss du schon auf die Leute direkt zugehen die diese drei Dinge in der Hand haben. Die müssen das dann nur auch als Sinnvoll erachten, vielleicht ist es innen noch nie aufgefallen. Wiki ist dann nur um es dann zu publizieren.

Gruß Miche 😉

miche101 wrote:

Der Weg ist das Ziel. Nicht das reden über den Weg.

Nicht schlecht. Ich kenne das als "es gibt nichts Gutes, außer man tut es".

Ich hab das mal über die Anfangszeiten von Linux gelesen, dass da die Leute gern gesehen waren, die sagten "ich habe da mal gemacht" und nicht so sehr die, die "man sollte mal machen".

"Ich hab da mal gemacht" birgt natürlich das Risiko, dass es nicht angenommen wird. Dann hätte man's umsonst gemacht. Aber wenn man es gut gemacht hat, dann wird es in der Regel auch akzeptiert.

Im Moment "tun" bei OSM sehr viele. Es wird gemappt, was da Zeug hält. Ich habe selten ein vergleichbares Projekt gesehen, wo soviel getan und so wenig theoretisiert wird. Mich erinnert das ein wenig an Schwarmintelligenz. Was im Detail chaotisch aussieht, macht erst im großen Zusammenhang Sinn. Und ich finde es beeindruckend, wie weit das Projekt damit in relativ kurzer Zeit gekommen ist. Vegleichbare Projekte wären nach traditionellen Methoden (Idee und Vorstudien, Lastenheft, Pflichtenheft, Realisierung, Pilotphase, ...)
vemutlich immer noch in der Planungsphase oder mit Vorstudien beschäftigt.

In diesem Sinne - plant nicht so viel. Ich habe gerade letzte Woche beim Mappen hier im Dorf wieder eine nette Strasse gefunden, in der ich noch nie gewesen bin, obwohl ich dachte, dass ich mich hier auskenne.

Detlef

PS. Für alle, die sich langeweilen: http://forum.openstreetmap.org/viewtopic.php?pid=51345. Ist viel besser als sich irgendwelche neuen Hemmschwellen für potentielle und das Projekt wichtige Mapper auszudenken.

Tordanik wrote:

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.

Tordanik wrote:

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.

KaChing_Cacher wrote:

Auch meiner Meinung nach gehört in OSM ein Standard eingeführt, an den sich jeder zu halten hat.
Ich habe es satt, dass jeder seine eigene footway/path/cycleway-Definition hat.
Wenn es feste Regeln geben würde, wäre endlich klar, was was in Wirklichkeit darstellen soll.

Man sollte Standards und Gesetze voneinander unterscheiden. Gesetze sind das, woran man sich halten muss. An einen Standard muss man sich nicht halten! Man darf nur nicht behaupten, man hätte sich daran gehalten, wenn man es garnicht getan hat. Man darf jede beliebige Art von Schrauben produzieren, man darf nur nicht "M10" dranschreiben, wenn es nicht M10 ist.

Genau das können wir auch tun:

- Es behindert die Freiheit nicht wesentlich, wenn wir ein einziges Tag (z.B. "OSMNORM") reservieren.

- Es behindert die Freiheit nicht, wenn wir eine zentrale Numerierung für solche Normen einrichten.

- Es behindert die Freiheit nicht, wenn solche Normen absolut unveränderlich sein müssen und keine Verweise auf Veränderliches enthalten dürfen (Es haben schon Leute nach dem alten Stand getaggt. Umdefinieren ist dann total sinnwidrig!). Verbesserungen kann man nur in eine neue Norm packen. An eine Norm sollte allenfalls noch die Anmerkung kommen "Bitte nicht mehr benutzen"

- Es behindert die Freiheit nicht, wenn jemand ein Objekt anhand einer Norm tagged. Der nächste Mapper ist nicht verpflichtet, die OSMNORM drin zu lassen oder unverändert zu lassen. Man muss sich nur darüber im Klaren sein, dass man damit evtl. die Interpretation anderer Tags ändert und dafür die Verantwortung übernehmen.

Was kommt dabei raus?

Wir hätten immer noch mehrere footway/path/cycleway-Definitionen! Aber man könnte endlich sehen, welche der Definitionen benutzt wurde. Der Hauptnachteil konkurrierender Definitionen ist doch, dass die Tags immer mehr Informationsgehalt verlieren, weil man alle Arten ihres Gebrauchs berücksichtigen muss. Dieser Nachteil würde komplett aufgehoben werden, ohne dass die Vielfalt entfallen würde.

Die Renderer könnten anhand der Normnummern den Informationsgehalt vor der eigentlichen Verarbeitung transformieren. Die Programme selbst würden weniger kompliziert und damit zuverlässiger.

Die Editoren könnten die für wichtig gehaltenen Normen nutzen, um Eingaben sehr viel besser als heute zu unterstützen. Denn eine solche Norm wird wohl Pflichttags, Defaults und mögliche Werte für Einträge festlegen und genau das kann ein Editor wunderbar in eine Eingabemaske umsetzen.

Klar definierte Defaults für Tags im Rahmen einer bestimmten Norm können die Datenbank verkleinern. Wenn durch die Norm z.B. festgelegt ist, dass ein fehlender "footway"-Eintrag als "footway=no" gilt, dann kann man für Einträge dieser Norm footway=no auch durch Robots rauswerfen.

Recht alte Einträge (aus der grauen Vorzeit, als noch niemand "dingsda" getagged hat) lassen sich automatisch in Daten neuerer Normen umsetzen ("dingsda=unknown"). Das ist besonders für Anfänger hilfreich, denn die sehen sinnvollerweise oft nach, wie "das denn von anderen gemacht wird".

Weide

dgdg wrote:

"Ich hab da mal gemacht" birgt natürlich das Risiko, dass es nicht angenommen wird. Dann hätte man's umsonst gemacht. Aber wenn man es gut gemacht hat, dann wird es in der Regel auch akzeptiert.

Ja des ist natürlich a Risiko, am besten man macht es für sich selbst und frägt dann nur obs wer noch anders auch brauchen kann 😉.

Ich hab mir letztes was geschrieben damit ich einen bestimmten Bereich auch den Cache von Marble löschen kann. Weil des dauert mir zu lange bis er den Cache von selbst aktualisiert. Grad wenn ich was eingezeichnet hab möchte ich es ja auch sehn wenn es gerendert wurde :-)

Möchte des wer haben? ;-)

Gruß Michael

Feste Standards sind Unfug, aber wo wie es im Moment läuft geht es auch nicht weiter. OSM ist eine offene Weltkarte. Offen bedeutet aber nicht totale Anarchie.

Wir haben hier Nutzer aus zwei Entgegengesetzten Richtungen. Gerade auf der Talk-Mailing-List scheint der Totale-Anarchie-Ansatz weit verbreitet zu sein. Vor einiger Zeit habe ich versucht ein neues Tag einzuführen (Schächte), und das Proposal entsprechend der Anleitung im Wiki an Talk gesendet. Zurück kamen fast schon "Anfeindungen" und Hinweise darauf dass das Wiki Mist ist und ich es ignorieren soll. Wenn man jetzt dieses Beispiel und z.B. den Vorschlag von mpeter89 anschaut, dann sieht man dass es wohl gegensätzlicher nicht mehr geht. Vergleichbar ist das Ganze mit den Inkludisten und Exkludisten in der Wikipedia. Dadurch das beide Gruppierungen auf ihrem Standpunkt verharren, gibt es Stillstand und nichts geht mehr weiter.

Bei OSM kommt erschwerend hinzu, dass es keine gemeinsame Diskussionsplattform gibt. Wir haben das Forum, das Wiki, die Mailing-List, die Blogs und den Chat. Oft bewegen sich Nutzer auf nur einer Plattform und schauen verächtlich auf das was die Anderen treiben. Gerade auf der Talk-Mailing-List ist mir das besonders stark aufgefallen. Mit was für einer Arroganz man sich dort zum Teil über Forum-Nutzer und ganz besonders über Wiki-Nutzer äußert ist nicht schön.

Man muss also erstmal eine gemeinsame Diskussionsgrundlage und überhaupt ein Problembewusstsein schaffen. Fakt ist aber, dass OSM mit seiner jetzigen Struktur nicht weit kommen wird.

Meine "Glaubensrichtung": Das Wort Standard ist nicht unbedingt das richtige Wort. Auch ein Standard kann Unsinn und Mehrdeutigkeiten enthalten. Ich würde es eher ein klar definiertes Regelwerk nennen. Solche religiös motivierten Tagging-Schemen wie bei footway/cycleway/path oder im Public-Transport-Bereich müssen ein Ende finden. Dies erreicht man aber nicht unbedingt durch Warten und Hoffen. Siehe HD-DVD und Blu-Ray, der Format-Streit wurde auch nicht dadurch gelöst, dass sich die Nutzer für das bessere Format entschieden haben. Die Existenz eines konkreten gutdefinierten Regelwerks schließt aber nicht aus das es weiter erlaubt ist frei nach eigenen Ansichten zu taggen. Schließlich "muss man Chaos in sich haben, um einen tanzenden Stern zu gebären".

Ich habe außerdem Zweifel ob das Wiki in seiner jetzigen Form als Dokumentationswerkzeug sinnvoll ist. Noch ungeeigneter finde ich es aber als Medium zur demokratischen Entscheidungsfindung. Das Proposal-Verfahren auf Wiki-Basis wie wir es im Moment haben ist Murks.

lesi wrote:

Ich habe außerdem Zweifel ob das Wiki in seiner jetzigen Form als Dokumentationswerkzeug sinnvoll ist. Noch ungeeigneter finde ich es aber als Medium zur demokratischen Entscheidungsfindung. Das Proposal-Verfahren auf Wiki-Basis wie wir es im Moment haben ist Murks.

dem muss ich nur zustimmen: ich habe wikis immer so aufgefasst, dass ich dort informationen über bestimmte sachen/angelegenheiten/personen und was sonst auch finde. und das gilt für mich auch bei "userem" wiki.

wenn ich etwas NICHT finde und mir absolut sicher bin, dass ich mich damit auskenne, trage ich auch schon mal was ein.

aber für diskussionen oder als plattform zum durchdrücken von meinungen halte ich wikis generell nicht geeignet.

mfg

wambacher

lesi wrote:

Vor einiger Zeit habe ich versucht ein neues Tag einzuführen (Schächte), ...

Das ist schonmal der falsche Ansatz. Bei OSM führt nicht ein einzelner Mapper irgendwelche Tags ein. ;-)
Ein Proposal habe ich anfangs auch mal geschrieben, als ich noch nicht verstanden hatte, wie OSM in der Praxis funktioniert. Inwischen hat irgendjemand den von mir vorgeschlagenen Tag aus dem Wiki gelöscht. Juckt mich eigentlich weniger, ich verwende ihn einfach weiter, weil er sinnvoll ist.

Letztendlich wird das gemappt, was man vor Ort für richtig und sinnvoll hält. Dabei setzen sich gewissen Tags durch, andere nicht. Das Wiki dient eigentlich nur dazu, eigene Tags oder Ideen für Mapping-Schemata zu propagieren. Die Entscheidung für oder gegen einen Tag trifft die Mapper-Gemeinschaft, in dem sie den Tag verwendet oder ignoriert.

Hinzu kommt die Macht der Renderer. Tags die es schaffen von einem der Standard-Renderer dargestellt zu werden, haben gewonnen (ja ja - wir mappen nicht für den Renderer - wofür denn sonst???).
Und die Editoren wie JOSM tun ihr Übriges dazu. Potlatch war anfangs neutral, weil es keine vordefinierten Tags gab. Das ist inzwischen (leider) auch vorbei. Wozu noch ins Wiki schauen, wenn es im Editor einen fertigen Button gibt?

Bei OSM kommt erschwerend hinzu, dass es keine gemeinsame Diskussionsplattform gibt.

Naja, die führende Diskussionsplattform ist die Mailingliste (zumindst in DE ist das so - wie es in anderen Ländern läuft, kann ich nicht beurteilen). Dort tummeln sich z.B. die JOSM-Programmierer, die großen Einfluss darauf haben, wie gemappt wird. Und wenn sich mal jemand aus der OSM-Foundation an die deutsche Mapper-Gemeinde wendet, dann tut er das in der Mailingliste. Das Forum hat eigentlich keine große Relevanz. Und ein Wiki ist nun wirklich keine Diskussionsplattform (vielleicht für Linux-User, aber nicht wenn man Windows-Komfort gewohnt ist. ;-))

Man muss also erstmal eine gemeinsame Diskussionsgrundlage und überhaupt ein Problembewusstsein schaffen. Fakt ist aber, dass OSM mit seiner jetzigen Struktur nicht weit kommen wird.

Naja, es ist auf jeden Fall viel weiter gekommen, als wenn man von Anfang an irgendwelchen starren Spezifikationen erarbeitet hätte.

Ich habe außerdem Zweifel ob das Wiki in seiner jetzigen Form als Dokumentationswerkzeug sinnvoll ist. Noch ungeeigneter finde ich es aber als Medium zur demokratischen Entscheidungsfindung. Das Proposal-Verfahren auf Wiki-Basis wie wir es im Moment haben ist Murks.

Du überschätzt die Bedeutung des OSM-Wiki. ;-)

Sehr schön, dass du in diesem Thread auch für die andere von mir dargestellte Seite so schön ein Beispiel gibst, in dem deutlich wird was ich mit totaler Anarchie und dem Beharren auf den eigenen festgefahrenen Argumentationslinien meine. 😉

die führende Diskussionsplattform ist die Mailingliste

Das die Mailingliste die führende Diskussionsplattform ist, ist vor allem die Sichtweise der Mailinglisten-Nutzer. Ich zumindest war ein paar Wochen auf der englischsprachigen Talk-Liste und möchte mir die dortigen Umgangsformen und die Arroganz nicht weiter antun. Die meisten Diskussionen im Forum oder im Chat habe ich auch zielführender in Erinnerung als das Geschwafel auf Talk. 😉 Wenn man Windows-Komfort gewohnt ist und mit einem Wiki nicht zurecht kommt, dann ist eine Mailing-Liste erst recht ein Problem.
Aber jetzt rede ich schlecht über Talk und eigentlich will ich ja eine Annäherung dieser Gruppen erreichen. Dieses Forum hier ist ja auch nicht optimal, z.B. ist die Forensoftware ziemlich schlecht.

Naja, es ist auf jeden Fall viel weiter gekommen, als wenn man von Anfang an irgendwelchen starren Spezifikationen erarbeitet hätte.

Die wenigsten Leute die etwas Ordnung ins System bringen wollen, fordern starre Spezifikationen. Wie ich schon schrieb, ist das Chaos etwas sehr Essentielles.

Um nochmals auf eine höhere Ebene zu kommen:
Da viele so denken wie dgdg ist so etwas wie die Anfangsforderung von mpeter89 vollkommen unrealistisch. Eigentlich sind alle Forderungen nach Standardisierung, Vereinheitlichung oder einem sonstwie etwas verbindlicherem Tagging-Schema Wunschdenken. Am Anfang gilt es User wie dgdg davon zu überzeugen, dass die totale Anarchie keine Lösung ist und das z.B. die Einigung auf eine eindeutige Vorgehensweise zum Taggen von Fußwegen Vorteile bringt und nicht unbedingt Einschränkungen der Freiheit mit sich bringen muss.

lesi wrote:

Da viele so denken wie dgdg ist so etwas wie die Anfangsforderung von mpeter89 vollkommen unrealistisch. Eigentlich sind alle Forderungen nach Standardisierung, Vereinheitlichung oder einem sonstwie etwas verbindlicherem Tagging-Schema Wunschdenken. Am Anfang gilt es User wie dgdg davon zu überzeugen, dass die totale Anarchie keine Lösung ist und das z.B. die Einigung auf eine eindeutige Vorgehensweise zum Taggen von Fußwegen Vorteile bringt und nicht unbedingt Einschränkungen der Freiheit mit sich bringen muss.

Mir ist völlig klar, dass die jetzige Anarchie langfrisitig keine Lösung ist. Damit wird auf Dauer kein Routing zuverlässig und flächendeckend funktionieren.

Aber solange es (ich beziehe mich jetzt mal auf Deutschland, weil ich die Situation in anderen Ländern nicht kenne) noch Flecken gibt, wo nicht mal die Landesstrassen vollständig gemappt sind (geschweige denn Ortschaften), halte ich jede Verkomplizierung (z.B. übermäßiges Taggen mit Relationen) für kontraproduktiv, weil es Leute mit Vorortkenntnis aber weniger EDV-Wissen abschreckt.

Als ich vor ungefähr einem Jahr hier angefangen habe, waren viele umliegende Ortschaften lediglich als einzelner Node vorhanden (aus irgendeiner Datenbank importiert). Und viele dieser Ortschaften wären es noch, wenn ich mich gleich zu Anfang erstmal mit Relationen oder mit Editoren wie JOSM hätte rumschlagen müssen. Denn bis auf einige Ausnahmen bin ich nach wie vor der einziger Mapper hier, der in diesen Ortschaften aktiv ist. Es geht mir dabei nicht um meine Arbeit (damit keine Missverständnisse entstehen - ich mappe, weil es mir Spaß macht). Ich möchte nur die Situation in vielen Regionen veranschaulichen.

Ich bin eigentlich gar nicht gegen eine Standardisierung. Ich bin lediglich gegen den Verwaltungsaufwand und Diskussionsaufwand, wer dann welche Regeln festlegen darf, welche Entscheidungsgremium und -wege notwendig sind usw. Nach deutscher Gründlichkeit werden wir dann in Kürze nur noch darüber diskutieren WIE Mapping-Regeln festgelegt werden und nicht mehr über die Regeln selbst.

Und das Eingangsposting war leider so polemisch und kompromislos formuliert (alleine schon der Thread-Titel und dann die Forderung, alles Möglich über Relationen zu taggen), dass man da einfach dagegen halten muss.

Detlef

Es wird niemals definitive Standards fuer OSM geben, schon alleine weil OSM nur dadurch so erfolgreich ist/war dass es keine fixen Standards gab, und etwas anderes eintragen unmoeglich war/ist. Dank tagwatch und map:features uebernehmen Renderer bzw Josm/Potlatch ihre Presets und damit werden Tags quasi standardisiert. Das highway=path/footway/cycleway Problem ist hierfuer ein gutes Beispiel. Bis vor 2 Jahren haben sich die Mapper halt keine Gedanken gemacht wer einen footway benutzen kann/darf/soll/muss und es ging schnell einzutragen. Es waren sowieso noch sehr wenig Daten eingetragen. Dann wurde die Vollstaendigkeit genauer und genauer und man wollte halt wissen, ist es ein Fußweg im staedtischen Bereich, außerstaedtsich, Wanderweg, darf man auch mit dem Fahrrad darauf fahren, .... und somit begannen User keys wie tracktype oder highway=path zu entwerden und zu benutzen. Dazu kamen keys wie cycleway=lane um Fahrbanen naeher zu spezifizieren - Zu OSM Anfangszeiten haette dies niemand eingetragen da erst einmal andere Sachen wichtiger waren (primaer einmal Bundes/Landesstraßen und Autobahnen fuer die Groborientierung, dann .....).

Problematisch ist eigentlich nur, wenn ein Key schlecht durchdacht eingefuehrt und haeufig benutzt wird - etwa die Verwirrung darueber ob die access tags nur vom Gesetz her ausgehen, oder ob sie (auch) auf die Benutzbarkeit abzielen. Andererseits braucht es einfach sehr viel Zeit ein komplett durchdachtes Tagging Schema zu entwickeln. Alleien die Frage "wie soll man Fahrbanen, Farhradfahrbahnen, Gehsteige am besten in OSM umsetzen" waere einer Diplomarbeit wuerdig. Nichts ist schlechter als ein nicht 100% durchdachter Standard. Und somit wird es auch zu keinen Standards kommen, selbst wenn 90% der OSM User dies fordern wuerden. Ganz einfach weil die Personen die die Renderregeln fuer Mapnik, Osmarender und Co, bzw Josm schreiben hier einfach schon genug Erfahrung haben dass Standards einfach keine Loesung sind in einem dynamischen Projekt wie OSM.

Wer fixe Standards will, soll sich halt selber einen Renderer schreiben und dafuer sorgen dass er so deutlich besser ist als andere Renderer, dass ers sich duchsetzt. Er wird schnell draufkommen dass viele Fragen einfach nicht beantwortbar sind oder festlegbar (etwa welche Darstellung soll welche Key Kombination haben) bzw dass es sehr viel Arbeit kostet gute Ergebnisse zu erzielen. Was Mapnik, Osmarender oder andere rendern, ist eben nicht dass was im Wiki, Mailingliste oder Forum gewollt wird, sondern dass was der Ersteller vom Renderer umsetzen will. Ist man damit nicht zufrieden dann muss man selber einen Renderer konfigurieren und verbreiten, bzw komplett selbst entwickeln.

Der Vorteil der Mailingliste ist einfach, dass es viel uebersichtlicher ist als dieses Forum oder der Wiki (Voraussetzung man ist in der Lage einen e-mail Client gscheit zu Konfigurieren). Ausserdem ist die Einstiegshoehe groeßer als fuer Wiki oder Forum. Dass ist ein großer Vorteil weil man somit weniger Zeit verbringt mit: Forderungen die von Personen geschrieben werden die mit OSM einfach noch wenig Erfahrung haben (wie Standard verabschieden und Renderer muesen ihn umsetzen) oder Fragen von Anfaengern. Was die fuehrende Kommunikationsplattform ist, kann man also schwer sagen, auch nicht ob die Diskussionen per ML gehaltvoller/intelligenter sind. Es ist jedoch eindeutig so, dass jene die schon laenger bei OSM mitmachen und viel Erfahrung haben, eher auf den Mailinglisten teilnehmen, und Anfaenger eher im Forum beheimatet sind. Und der Wiki ist keine Diskussionsplattform, sondern viel mehr eine Plattform auf der fertige Loesungen und Anleitungen niedergeschrieben werden.

halte ich jede Verkomplizierung (z.B. übermäßiges Taggen mit Relationen) für kontraproduktiv, weil es Leute mit Vorortkenntnis aber weniger EDV-Wissen abschreckt.

Verkomplizierung ist sicherlich der falsche Weg, aber die Einigung auf konkrete Tagging-Schemen wäre ja eine Vereinfachung. Man muss ja nicht gleich alles auf einmal standardisieren. Nehmen wir z.B. das Public-Transport-Tagging, wo es zwei völlig äquivalente Wege gibt einen Bahnsteig zu taggen und beide die gleiche Popularität haben. Hier sollte das Bewusstsein und die Bereitschaft dafür geschaffen werden, dass man sich auf eine Methode einigt. Wenn man jetzt ein Voting hierzu durchführt und sich eine (knappe) Mehrheit für ein System ausspricht, dann sollten die Verlierer dies akzeptieren und auch anfangen, dass Verfahren zu verwenden - eben weil es Voreile bringt nur ein Schema zu haben.

Wer fixe Standards will, soll sich halt selber einen Renderer schreiben

Die meisten Orientieren sich am Rendering auf der OSM-Hauptseite. Wieso gibt es aber auf der OSM-Hauptseite nicht gleich mehr Varianten der Karte zur Auswahl. Wieso werden gerade solche schlechten Versionen angezeigt, wie die Fahrradkarte? Und wieso wird nicht etwas genutzt, dass gleich eine größere Anzahl an Features unterstützt und somit der Popularität von weniger gemappten Objekten weiterhilft (so etwas wie OpenStreetBrowser).

Der Vorteil der Mailingliste ist einfach, dass es viel uebersichtlicher ist als dieses Forum oder der Wiki

Das eine Mailingliste übersichtlicher ist, muss ich ganz klar verneinen. Eine gute Forensoftware (die hier ist das im Moment nicht) ist einer Mailingliste bei weitem überlegen. Weiter ausführen will ich das hier nicht, weil es nicht in das Thema passt. Hinzu kommt, dass viele mit Mailinglisten nicht klar kommen und dies der Übersichtlichkeit ebenfalls schadet (z.B. Antworten an eine Person statt an die Liste, Antworten an eine andere Liste als die ursprüngliche Mail etc.). Desweiteren sind die OSM-Mailinglisten auch noch schlecht konfiguriert.
Das gerade die einflussreichen Personen (z.B. Programmierer) die Mailingliste nutzen liegt wohl vor allem an der traditionsbedingt starken Verbreitung von Mailinglisten innerhalb dieser Personengruppen. Und wegen dieser einflussreichen Personen sind dann halt auch viele andere auf der Mailingliste.
Ich habe auch schon Projekte erlebt, wo die Mailingliste zugunsten eines Forums aufgegeben wurde - geschadet hat es nicht.

extremecarver wrote:

Der Vorteil der Mailingliste ist einfach, dass es viel uebersichtlicher ist als dieses Forum oder der Wiki (Voraussetzung man ist in der Lage einen e-mail Client gscheit zu Konfigurieren).

Naja! Ich vermute mal, dass Du Linux verwendest, stimmt's? ;-)

Ausserdem ist die Einstiegshoehe groeßer als fuer Wiki oder Forum. Dass ist ein großer Vorteil weil man somit weniger Zeit verbringt mit: Forderungen die von Personen geschrieben werden die mit OSM einfach noch wenig Erfahrung haben (wie Standard verabschieden und Renderer muesen ihn umsetzen)

Auch nicht schlecht! Die meisten Leute sollen also draussen rumrennen und mappen, aber aus den Diskussionen sollen sie sich gefälligst raushalten - das ist nur was für Experten. Fragen von Anfängern: nicht erwünscht. ;-)

Wie wär's mit UUCP? Das reduziert den Kreis der nervigen DAU's nochmal drastisch. ;-)

Detlef

Der Thread ist schon sehr Textreich so viele Wörter... es ist glaub ich auch schon alles mal gesagt worden, kann man den ned abschließen mit einem Fazit von jedem. Eine Zusammenfassung im Wiki wär auch schön. Und dann kann man zu den einzelnen Punkten noch diskutieren. In einem neuen Thread natürlich!

Die Einstiegshürde in den Thread ist schon recht hoch... nicht mehr zumutbar für Linux- und Windowsnutzer oder was auch immer. Und das meiste bezieht sich nur noch auf den Titel und schweift ab.

dgdg wrote:

Naja! Ich vermute mal, dass Du Linux verwendest, stimmt's? ;-)

Ich könnt jetzt auch was schreiben, aber muss des sein. Betriebssystem ist doch egal, für jeden ist seins das beste.

gruß Michael

Hallo zusammen!

Bevor miche den Thread zu macht, muß ich auch noch einen Kommentar los werden.
Standart sinnvoll? - Ja? - Nein?
Ist halt die Frage, was man darunter versteht.

Als ich damit begann, meine tracks in OSM einzubauen, war ich oft ziemlich gefrustet, wenn ich auf meine vielen Fragen die Antworten im Wiki nicht auf Anhieb finden konnte. Was mir fehlt, ist eine Suchfunktion innerhalb einer Wiki-Seite. Nachdem ich dann zum x-ten Mal nach einem Tag suchte, das ich doch schon mal irgendwo - Ja, aber wo??? - gesehen hatte, kam mir schließlich die gloreiche Idee - (wieso war ich da eigentlich nicht sofort drauf gekommen?) - Jedes Suchergebnis in ein schnell sehr umfangreich werdendes Word-Dokument zu kopieren. Und seitdem finde ich die meisten Antworten auf meine Fragen mit wenigen Mausklicks. Das Tolle dabei: In den kopierten Texten führen unzählige Links zu den verschiedenen Wiki-Seiten und wenn ich dann sicherheitshalber noch mal was nachlesen will, mache ich nach erfolgreicher Suche einfach noch einen Mausklick mehr und lande so wenige Sekunden nach Aufkommen der Frage in einem Text, der sie meistens beantwortet. Diese hilfreiche Vorgehensweise dürfte wohl den Wenigsten geläufig sein. Und so verwundert es nicht, wenn dann - weil das Nachschlagen der üblichen Taggweise/Rechtschreibung in der im Wiki angebotenen Vorgehensweise sehr zeitraubend sein kann - viele Mapper die Tags aus der Erinnerung schreiben und dabei dann Varianten oder schlicht und ergreifend Schreibfehler taggen. Die fallen kaum auf. Denn wer kontrolliert schon regelmäßig die Wachlist? Ich gucke da höchstens mal nach, wenn ich nach einem Tag suche und wissen will, wie es andere machen.

Hätte ich nicht ein eigenes Kartenlayout entwickelt und würde ich nicht regelmäßig die Liste der unbekannten (also noch nicht in die Renderregeln eingebauten Tags) kontrollieren, wäre mir die Problematik der (unbeabsichtigten) Tagvarianten vermutlich weniger bewußt. Aber so stehe ich regelmäßig vor der Frage, ob ich diese und jene neu hinzu gekommene Tagvariante nun berücksichtigen soll oder nicht. Jede Tagvariante, die überflüssig ist, weil es ja bereits ein gleichbedeutendes Tag gibt, bläht die Renderregeln unnötig auf und verlängert den Rechenprozess und ärgert mich daher. Außerdem kostet es Zeit, sie in die Renderregeln einzubauen. Deshalb ignoriere ich Tagvarianten, die nur ein oder zweimal auftauchen.

Die Fähigkeit von Potlach, Begriffe automatisch zu ergänzen, hilft, ungewollte Tagvarianten zu vermeiden. Das ist eine feine Sache. Eine vereinheitlichte Tag-Rechtschreibung würde das Rendern sehr erleichtern. Mit "Freiheitsberaubung" hat das nichts zu tun.

Das Problem Höhle/Stollen kann ich nicht nachvollziehen. Ein Stollen ist keine Höhle aber offensichtlich etwas "historisches" oder eine "Attraktion" und dafür gibt es Tags, die sich adaptieren lassen. Ich hätte das nicht falsch stehen gelassen sondern mit den Erstellern des POI nach einer sinnvollen Lösung gesucht. Irgendeine Karte hätte sich dann sicher bald gefunden, die dieses neue POI anzeigt. (Und wenn es die eigene ist! ;-) )

Gruß
tippeltappel