Finde ich garnicht spannend - ist völlig OK. Es darf Haltestellen mit beiden Angaben und welche ohne Platform und welche ohne Halteposition geben. PTv2 verlangt nur, dass die Dinger in den Relationen vorkommen, wenn sie vorhanden sind. Auch sind die alten Tags durch PTv2 nicht aufgehoben worden; es ist also nach wie vor völlig OK, wenn da ein Node mit nur highway=bus_stop auf oder neben der Straße ist. (Nicht OK ist es, wenn beide gemappt sind und alle beide highway=bus_stop haben. Zwei highway=bus_stop sind zwei Haltestellen. Das hat aber nichts mit PTv2 zu tun.)
Es gibt riesige Probleme im OSM-ÖPNV (allein in NRW komme ich auf rund 30000 Fehler). Da würde ich solche Sachen vielleicht für 2020 einplanen.
Offtopic: Das wäre doch mal was für eine Wochenaufgabe: Tagging von ÖPNV-haltestellen und stop_area-Relationen. (Linien-Routen und ähnliches würde ich wegen der Menge an Arbeit ausgrenzen)
Den Gedanken ist verlockend… Die Reparatur ist aber schwieriger als die Fehlersuche und die Reparatur fremder Sachen ist schwieriger als die Reparatur eigener Sachen. Bei eigenen Sachen muss man nur eine richtige Möglichkeit kennen … bei fremden Sachen alle.
Eine Beispiel für die Schwierigkeit der Reparatur: Ein Node kommt in einer Route mit der leeren Rolle vor und die Route hat public_transport:version=2. Das ist ganz einfach falsch. Soweit der leicht zu findende Fehler. Jetzt die Reparatur: Ist es wirklich eine PTv2-Relation? Vielleicht ist es falsch, dass public_transport:version=2 in der Relation steht. In PTv1-Routen wäre die leere Rolle völlig OK.
Zunächst denke in den Dimensionen einer beschaulichen Mittelstadt in Norddeutschland mit etwa 350 Bushaltestellen, einem Dutzend innerstädtischer Linien und vielleicht zwei Dutzend Überlandlinien, die in den umliegenden Landkreis führen. Da können die beiden der lokalen Mapper, die sich für ÖPNV interessieren, die Latte schon mal höher legen
Mmh. Ich will Dir das gern glauben. Das beschlossene Proposal sagt, dass stop_position mandatory ist. Fand ich immer logisch, weil eine Bushaltestelle ohne stop_position mir nicht in den Sinn kommen will. Was übersehe ich?
Dass das “mandatory” sich auf das Tag bezieht., “public_transport=stop_position” darf bei einer stop_position niemals entfallen.
Z.B. darf man ja die route_master-Relation weglassen (einer der PTv2-Fehler, wenn man mich fragt), aber am “type=route_master” steht “mandatory”.
Bei zwei einander gegenüberliegenden Wartehäuschen jeweils mit Bank und Blindenleitbelag ist ein Node auf der Straße mit
-highway=bus_stop
-tactile_paving=yes
-bench=yes
-shelter=yes
eigentlich komplett.
public_transport=stop_position wäre noch wünschenswert.
Weitere Hinzufügungen kann man als Detailmapping natürlich machen, aber es “komplettiert” nichts.
Weide
PS: wheelchair=… hab ich jetzt nicht erwähnt. Es gehört eigentlich mit rein, das Tagging ist aber mit meines Wissen noch nicht angegangenen Problemen verbunden.
Ja, eigentlich. Ich lese PTv2 mit dem Selbstverständnis, dass es einen erstrebenswerten Zustand beschreibt, also einen Fortschritt möchte, der einen vorherigen Zustand ablöst. Dann darf ich PTv2 nicht zurücknehmend lesen. Ansonsten müsste ich mich nicht wundern, wenn niemand PTv2 ernst nimmt.
Hallo zusammen,
ich versuche mit Overpass-Turbo eine Karte der Bundesländer zu erzeugen.
Konkret geht es um http://overpass-turbo.eu/s/7Fu.
Meine Schwierigkeit ist, dass ich die beiden POI pro Bundesland (label und admin_centre) nicht angezeigt haben will.
Mit MapCSS kann ich zwar alle Nodes ausblenden:
Hallo MKnight,
vielen Dank für die schnelle Antwort. Ja das hilft schon mal sehr. Ich wusste nicht, dass man die Bedinungen auch hierarchisch verknüpfen kann.
Zu
Ich will die POI (also in dem Fall die Haupstädte der Bundesländer) nicht anzeigen, aber ggf. noch weitere Nodes, wenn ich die Abfrage noch erweitere.
Weitere Frage:
Ich habe Deinen Hinweis eingebaut in: http://overpass-turbo.eu/s/7FW. Jetzt sieht es schon ganz gut aus. Aber scheinbar funktioniert meine Formattierung zum Namen des Bundeslandes nicht:
Sollte eigentlich den Text in Grün im Zentrum des Gebiets erscheinen lassen, aber die Schrift ist bei mir Schwarz und bei BaWü auch nicht im Zentrum. Scheinbar habe ich da die Anleitung von http://wiki.openstreetmap.org/wiki/MapCSS/0.2 nicht ganz richtig verstanden.
Hast Du eine Idee, wie man das hinbekommt?
Weitere Frage: Ich wollte das ja auf ganz Deutschland ergänzen, aber http://overpass-turbo.eu/s/7FR steigt mir immer wieder aus. Sind da dann zu viele Daten im Spiel oder ist mein Skript falsch?
Hallo Gridy,
du musst auch bedenken, dass mapcss von eigentlich allen Tools nur teilweise unterstützt wird. Siehe dazu die Tabellen im Wiki unter Vocabulary. Die Implementierung in OverpassTurbo erscheint da zwar nicht, aber hier gibt es ein paar Informationen, was alles unterstützt wird: http://wiki.openstreetmap.org/wiki/Overpass_turbo/MapCSS
Ja, das dürften zu viele Daten sein. Wenn ich das mal extrapoliere von einzelnen Bundesländern, dürften es knapp 100 MB Daten sein, die da kommen müssten. Du brauchst allerdings nicht alle Wege und deren Nodes für deinen Zweck. Es reicht die Geometrie der 16 Relationen. (Zumindest sollten es 16 sein… irgendwo ragt das niederländische Groningen aber nach Deutschland rein…)
So bleibt es bei 20 MB in einer verträglichen Zeit. http://overpass-turbo.eu/s/7FX
Habe ich einen taktisch unklugen Zeitraum (Wochenende) für diese Frage gewählt? Ich hoffe: ja und erlaube mir deshalb, die Frage noch einmal in Erinnerung zu bringen.
Da wäre ich auch schon wieder mal:
ich möchte die wege mit der Rolle “from” bzw. “to” der “relation=restriction” mit verschiedenen Farben anzeigen lassen. Soweit bin ich schon mal: [out:json];
(rel[“type”=“restriction”];>;);
out skel;
Problematisch wird es jedoch spätestens dort, wo wir auch Fahrradspuren haben, weil lanes=* blöderweise etwas unglücklich nur die Spuren für den motorisierten Verkehr zählt. An Stellen wie diesen: https://www.openstreetmap.org/way/326338169
kommt man da ganz schnell ins Schleudern, wenn man auswerten will, ob alle :lanes-Varianten vollständig erfasst wurden. cycleway=lane hilft da auch nicht.
Die einzige näherungsweise Lösung wäre, die verschiedenen :lanes: je Richtung zu checken, ob bei allen die gleiche Anzahl an “|” (Langstrichen) vorhanden ist.
Wenn man zuerst prüft, ob überhaupt Fahrradspuren erfasst sind, indem man bicycle:lanes: sucht, könnte man bei ways ohne diese mit der Anzahl aus lanes bei oneway=yes oder sonst aus lanes:* arbeiten. Damit könnten wir doch zumindest eine größere Teilmenge “erschlagen”
Farbliche Hervorhebung von ways mit bicycle:lanes:* könnte dann markieren, wo Handarbeit durch Analyse der tags am way erforderlich wird.
Ich bitte um Lösungsvorschläge für overpass-turbo.
Am einfachsten wäre natürlich, wenn wir mit lanes die Anzahl aller Spuren erfassen würden. Aber dafür ist der Zug wohl abgefahren
Ermittle alle Relationen im aktuellen Kartenfenster, die vom Typ route=bus sind, speichere das Ergebnis nach .all
Ermittle alle Parent-Relationen von .all, die vom Typ route_master=bus sind
Ermittle aus dieser Liste von route_master-Relationen wieder alle Child-Relationen vom Typ route=bus. Dies sind nun alles Routen, die Teil eines Masters sind.
Bilde die Differenz aus .all und dem Ergebnis aus 3. (ermittelt also alle Routen, die nicht Teil der Menge aller Routen, die einen Master-Parent haben, sind)