Entwicklung OSM Tagging Schema

Communities Deutschland (Germany)
1

Wie entwickelt sich im Laufe der Zeit das OSM Tagging Schema?

Gibt es Leute/Gruppen, welche größeren Einfluß dadrauf haben, was von den Tags sichtbar gemacht wird?

Ich gebe seit über ein Jahr regelmäßig Daten in OSM ein. Manche Daten werden gerendert und sichtbar, andere bleiben erstmal bei den beiden Renderer unsichtbar.

Als Mapper hat man dann natürlich die Hoffnung, daß eines Tages ein bisher nicht gerenderter Tag sichtbar wird.

Durch regelmäßges Lesen des Forums und der Mailigliste bekomme ich mit, daß es immer wieder Ideen gibt, was wichtig ist und was nicht (jedenfals was die Leute dafür halten)

Muss das Tagging intenational gleich sein oder kann es ein lokales (z.B. deutsches) Tagging geben? Lokales Taggingschema könnte sich schneller entwickeln.

Hat wirklich nur der Entwickler von Mapnik/Osmarender Einfluß auf das sichtbare rendern?
z.B. habe ich Fahrrouten in Relationen gesteckt, leider wird dies von der Cyclemap nicht umgesetzt, obwohl ja Relationen besser sein sollen,

Bisher hat mich folgendes beim tagging beeinflußt:
Karlsruher Adressschema, TCM, ISIL, Diskussion DE:urban kontra maxspeed=50, HInweis eine Mappers statt leisure=commen doch landuse=village_green zu benutzen, das Tagging anderer Mapper, de:Map Features, Lulu-Ann tagging für Blinde

SChön finde ich es, wenn hier im Forum ein Unterordner nur für Tagging da ist. Man könnte auch andere Themen in verschiedene Ordner packen.

Offene Baustellen bein Tagging sind z.B.
bessere Fahrbahndarstellung (lFahrbahnen, Grünstreifen, durchgezogene Mittellinie, breite der Straße)
bessere Erfassung der Fahrradwege (links nur ein Fahradweg, auf einer Seite Fahrradweg in beide Richtungen)
bessere Adresserfassung, da immer wieder die Frage kommt, was man mit mehreren Geschaften mit gleicher Adresse macht.

Norman

2

Vielleicht hilft dir dieses Thema weiter, weil mehr kann ich auch nicht sagen…

OSM Standard verabschieden und Renderer müssen ihn knall hart umsetzen
http://forum.openstreetmap.org/viewtopic.php?id=5728

3

Also grundsätzlich gibt es 2 Verfahrensweisen:

  1. Der Proposal Prozess (“der offizielle weg”)

welcher hier ganz gut beschrieben ist:
http://wiki.openstreetmap.org/wiki/Proposed_features#Proposal_Status_Process

  1. Just do it
    Man benutzt einfach “sein” tagginschema… wenns genügend Leute machen
    (z.b. die earthquake:* tages im haiti projekt) dann kommt der rest von alleine.

Ob/ Was dann gerendert wird liegt an den Leuten die sich um die Renderregeln kümmern. Nicht alle Daten werden / sollen in der Karte angezeigt werden.

4

Die Programmierer der Renderer. Die wiederum werden wahrscheinlich durch ihre lokalen Gruppen und die von ihnen gelesenen Mailinglisten, etc. beeinflusst, sind aber an sich frei in ihrer Entscheidung. Außerdem haben die Programmierer der Editoren einen gewissen Einfluß, wie getaggt wird, was sich dann natürlich auch auf die Renderer auswirken wird.

Natürlich freut man sich, wenn Daten, die man erfasst, dargestellt werden. Trotzdem sollte man sich davon nicht abhängig machen. Es können nicht alle Daten in den Karten auf der OSM-Seite angezeigt werden. Es gibt aber viele Seiten, die ihre eigenen Karten mit eigenen Schwerpunkten anbieten. Und wenn sich auch da nichts für die eine oder andere Anwendung findet, kann man immernoch selbst ein Schema zum Rendern entwickeln und sich seine eigene Karte basteln. Jedenfalls ist nicht jede Information sinnvoll darstellbar, sollte aber trotzdem erfasst werden. Beispielsweise für Routing-Applikationen oder ähnliche oder auch für Anwendungen, an die bis jetzt noch niemand gedacht hat.

Nachdem jeder mappen kann wie er will, ist nie alles gleich. Es ist natürlich wünschenswert, dass gleiches möglichst gleich gemappt wird, damit eine sinnvolle Auswertung möglich ist. Aber wenn kein allgemeiner Konsens existiert, ist es auch schonmal sinnvoll, sich wenigstens mit dem lokalen Umfeld zu einigen.

Ja, das entscheiden letztendlich nur die Entwickler der Renderer. Aber man kann ja bei denen anfragen, wenn man ein besonderes Anliegen hat.

Naja, ich bin eher Gegner von landuse=village_green, da das doch, soweit ich die Map Features verstehe, eigentlich ein Spezialfall ist, den es bei uns so kaum gibt.

Dem kann ich nur zustimmen. Ich denke, es macht langfristig nur Sinn, eine Straße in mehrere Ways aufzuteilen, am besten einen pro Spur. Macht natürlich viel Arbeit und wirft noch zu klärende Fragen auf, z.B. was das Routing angeht, ist aber auch die genaueste Wiedergabe der Realität. Vielleicht sollte man Straßen sogar irgendwann als Flächen darstellen, aber das ist noch deutlich komplexer. Auch die Sache mit den Adressen wird neue Lösungen erfordern, ich denke, mit geeigneten Relationen wird sich das am Besten lösen lassen.

5

Was ein Programm auswertet, entscheiden die Entwickler des jeweiligen Programms. Das wars dann eigentlich auch schon.

Interessant wird es natürlich deshalb, weil so ein Entwickler seine Ideen ja auch irgendwo her hat. Aus anderen Auswerte- oder Editierprogrammen, aus Wiki-Proposals, Diskussionsbeiträgen oder einfach Tag-Verwendungsstatistiken - und diese Faktoren beeinflussen sich natürlich auch gegenseitig wieder. Man könnte diesen Prozess auch einfach als “Chaos” beschreiben und läge nicht gar so falsch. :wink:

Insbesondere die Wiki-Abstimmungen sehen zwar “offiziell” aus, aber haben keine verbindlichen Resultate. Sie können natürlich zu einer höheren Zahl von Verwendungen führen, und vielleicht halten sich manche Entwickler auch freiwillig daran - aber das sind indirekte Wirkungen. Die Qualität der Tags fördern sie allerdings m.E. sehr wohl.

Ich glaube nicht, dass die Entwicklungsgeschwindigkeit momentan das Hauptproblem ist. Ich fände eher ein wenig Stabilität in den “alten” Bereichen und eine bessere Definition mancher Themenkomplexe wünschenswert.

Da du aber jederzeit beliebige Tags verwenden kannst, hält dich natürlich auch keiner davon ab, dich mit anderen Leuten aus der Gegend zusammenzuschließen und ein lokales Tagging-Schema zu erfinden. Ob das sinnvoll ist, musst du eben selber beurteilen.

Das sind auch meine “Lieblingsbaustellen”. Ideen gibts ja genug, und funktionieren würden die meisten davon auch. Ich glaube allerdings, dass es hier weniger an Entscheidungsfähigkeit mangelt, sondern an Arbeitszeit, um

  • so ein Schema mal bis zum Schluss durchzudefinieren (bis jetzt beschreiben zwar alle detailliert, was entlang eines Ways vorhanden ist, aber wie die Verbindungen an Kreuzungen aussehen, bleibt außen vor)
  • Programme zu schreiben, die das verwenden
  • Editor-Hilfen zu schreiben
    Wenn du zumindest zwei der genannten Dinge anzubieten hättest, dann würde ich fast garantieren, dass sich das Schema durchsetzt.
6

hi,

ich kann hier nur für josm strechen:

es gibt IMO noch mindestenz zwei “instanzen”, die einfluss auf die popularität von tags haben: die voreinstellungen/preferences für objekte in den editoren und bei josm noch der validator.
mir wäre schon geholfen, wenn der validator die gleiche datenbasis wie die preferences von josm verwenden würde. hier weiss die eine “hand” nicht was die andere tut.

hier sind wieder die entwickler gefordert - also falsches forum.

wambacher

7

JOSM nimmt alles, was im aktuellen Bereich liegt, als Vorlagen + seine eigenen Voreinstellungen.
Das heißt, JOSM legt einen nicht wirklich fest, fördert dadurch aber ein lokal einheitliches Tagging.

Der Validator krankt etwas daran, dass er einige Keys und Values, die längst approved sind
und in den Map_Features aufgeführt werden, nicht kennen will.

Wenn man - wie ich - die Map_Features als Referenz für akzeptiertes Tagging ansieht,
ist das schon sehr ärgerlich. Trotzdem zeigt er viele Probleme auf und ist daher für mich
immer noch ein wertvolles Tool. Einige Meldungen werden von mir ignoriert (z.B. alles
was mit administrativen Grenzen zu tun hat), anderes sehe ich mir dann im Detail an.
Schwerwiegendere Probleme, die ich nicht selbst lösen will/kann trage ich dann in OpenStreetBugs ein.

Edbert (EvanE)

8

Ah, ein wenig Begriffsverwirrung. :wink: Du meinst die Autovervollständigung, wenn man Tags per Hand eintippt. Die wird in der Tat an die geladenen Daten angepasst.

Die Vorlagen (englisch “Presets” - die Dialoge, die man über den “Vorlagen”-Eintrag in der Menüleiste von JOSM erreicht) werden von Menschen gebaut und spiegeln daher wie jede andere Software, einschließlich der bisweilen durchaus problematischen grafischen Darstellung in JOSM, einfach die Meinung ihres jeweiligen Entwicklers wider.

9

mir ging es hier um seine “eigenen Vorstellungen”. die kommen halt vom entwickler.
oder von den zugeschalteten objektvorlagen.

ja, das ist genau das, was mich stört und am anfang sogar leicht verwirrt hat:

ein teil von josm schlägt tags vor und ein anderer teil motzt die dann an.

muss da gerade an gespaltene wenn nicht sogar multiple persönlichkeiten denken .
vielleicht muss man auch “ein bischen bluna” sein um damit gut leben zu können. :wink:

10

Der Validator ist ein Plugin für JOSM und per se erst einmal unabhängig.
Gerade darum wünscht man sich eine bessere Abstimmung zwischen den beiden.

Ein Teil der Fehlermeldungen vom Typ Schlüssel oder Wert nicht in Vorlagen kommt
von größeren Datenimporten, die eigene Tags verwenden, um die Original-Information
zu dokumentieren. Ein weiterer Teil kommt von Erweiterungen, die lokal/regional üblich
sind, aber über die Approved Features hinaus gehen. Beide lernt man zu ignorieren.

Aber ein kleiner Teil davon sind echte Typos und das macht den Validator wieder nützlich.

Edbert (EvanE)

11

Es gibt noch eine dritte Instanz: Plugins.
Das Terracer-Plugin (teilt Häuserblocks in Einzelhäuser) erzeugt für einen damit
geteilten Block eine Relation mit type=relatedStreet.
Das kollidiert mit der der Adress-Relation nach dem Karlsruher Adress-Schema
(type=associatedStreet).

Da dieses Tool gerne eingesetzt wird, ergibt sich eine ziemlich große Verbreitung
von Relationen mit type=relatedStreet, was nirgendwo im OSM-Wiki beschrieben ist.

Dieses Vorgehen ist zwar nachvollziehbar, da der Block weiterhin als eine Einheit
erkennbar sein soll, führt aber letztlich dazu, eine Idee mit zwei ähnlichen Tags
auszudrücken.

Edbert (EvanE)