Hallo heine.
Danke für deine Mithilfe!
Meine Einschätzung ist, dass du mit einem eigenständigen Polygon auf dem richtigen Weg bist. Bei den Tags würde ich im Zweifelsfall lieber mehr als zu wenig hinzufügen. Konsolidieren kann man das im Nachhinein immer noch. Ich hoffe, dass sich noch jemand zu Wort meldet, da ich selbst wenig OSM-Erfahrung habe.
Ich habe gerade die Umweltzone Mönchengladbach eingetragen. Die Daten stammen von der Stadt
Wäre super, wenn nochmal jemand schauen könnte, ob ich das technisch richtig gemacht habe. Bitte hier Rückmeldung.
Da es mir zu mühsam ist die Frankfurter Umweltzone zu reparieren (wer meinte denn bitteschön eine komplette Boundary aus Autobahn-Ways machen zu müssen?) hier einige Hinweise für Mutige:
Allgemein orientiert sich die Umweltzone an dem Bereich zwischen A3, A5 und A661.
Aber die Frankfurter Stadtgrenze geht vor - Offenbach-Kaiserlei liegt nicht in der Umweltzone, auch wenn es von diesem Autobahnring umfasst wird.
Die Straßen Am Erlenbruch und Ratsweg entlang der A661 einschließlich dem Ratswegkreisel liegen nicht in der Umweltzone, obwohl innerhalb des Autobahnrings befindlich. Hier beginnt die Umweltzone ab der Kreuzung Am Erlenbruch/Ratsweg in westlicher Richtung, bzw. ab der Ausfahrt vom Ratswegkreisel auf die Hanauer Landstraße in westliche Richtung.
Auf der B3 von Süden kommend beginnt die Umweltzone ab der Kesselbruchschneise, d. h. die Mülldeponie und der zugehörige Parkplatz liegen außerhalb.
Die Commerzbank-Arena liegt ebenfalls außerhalb der Umweltzone.
Vielleicht kann ja jemand mit diesen Informationen etwas anfangen und da eine richtige Boundary zeichnen.
area=yes wird nicht benötig. Und meine Meinung zu type=LEZ kennst du ja hoffentlich
Jedenfalls sind die Zonenflächen für jeden, der eine mit osm2pgsql “gefütterte” Datenbank betreibt (u.a. OSM!) nicht vorhanden.
Mal eben eine Karte mit Umweltzonen zu rendern, kann man mMn vergessen.
Klar, mit der Overpass kommt man irgendwie ran, aber das ist so als wenn man einen RR in der Garage hat und nur Kia fährt.
osm2pgsql erstellt aus allen OSM-Daten, die wir mit den Editoren erstellen, eine Arbeitskopie für verschiedene Anwendungen und u.A. für Mapnik, dem Renderer.
Dabei werden nur Relationen übernommen mit type=multipolygon, type=boundary und type=route. Alle anderen Relationen werden verworfen.
/* Only a limited subset of type= is supported, ignore other */
if ( (strcmp(type, "route") != 0) && (strcmp(type, "multipolygon") != 0) && (strcmp(type, "boundary") != 0))
return 0;
aus den File output-pgsql.c von osm2pgsql.
Somit stehen in der Datenbanktabelle, die u.a. von Mapnik für openstreetmap.org und natürlich auch openstreetmap.de verwendet werden, diese Flächen einfach nicht drin.
Und was da nicht drin ist, kann nur mit extremen Klimmzügen aus anderen Daten zusammengeflickt werden.
Ich freue mich auf die erste Mapnik-Karte einer Stadt, die auch die Umweltzone enthält. Aber nicht als Overlay sondern gerendert in den Tiles. Wer das hinkriegt, hat wirklich was drauf.
So sieht grob der Datenfluß bei OSM aus:
User → Editor → API → Rohdaten-DB ->osmosis → DIFF-File → osm2pgsql → Render-DB → Mapnik → Tiles → Karte
osm2pgsql ist somit ein wichtiges, unverzichtbares Glied der Kette. (*)
Die Overpass greift direkt auf die noch “unverfälschte” Rohdaten-DB zu und findet die UZ noch, aber dann?
Mein Vorschlag: macht type=boundary und tobt euch bei dem Boundary-Tag aus.
*) Natürlich kann man osm2pgsql ändern, aber dazu muß man die Autoren , die mWn froh sind, dass das Teil überhaupt läuft, erst einmal bringen. Und kaum ist das geschafft, kriegen wir type=nature_reservate, type=hazard_zone, und vieles mehr.
Gruss
walter
NACHTRAG: Das ganze hier bezieht sich natürlich nur auf die Umweltzonen, die als Relation erfasst werden, weil sie z.B “Löcher” haben oder aus mehreren Teilflächen bestehen. “Einfache” Polygone sind hiervon nicht betroffen.
Wenn jemand Muße hat, kann er vielleicht noch mehr zusammenfassen? Ich hab auch Probleme Polygone/Relationen/Multipolygone mit verwendeten und am besten geeigneten Tags zu verbinden.
Die LEZ MG war ja total vermurkst: neben dem Way waren auch noch alle nodes drin.
Eigentlich bräuchte man da gar keine Relation, aber da alle internationalen Namen da schon dranhängen, kann man es auch so lassen.
Bei aller Diskussion ob Relation, boundray, type etc. wurde das Wichtigste vergessen:
wer darf (oder darf nicht ) in die low_emission_zone fahren?
In Stuttgart gibt es ein Zone, die nur mit Plakette grün befahren werden darf, und eine überlappende, abe nicht identische LKW Fahrverbotszone.
Beide sind als low_emission_zone getagged, nur aus dem Namen kann man (als gut deutsch Sprechende(r) ) erkennen, dass es Unterschiede gibt.
Vielleicht kann man das Ganze mit einem zusätzlichen access Tag erschlagen:
access=green_sticker_germany für die “normale” Zone
access:max_weight=12t für die LKW Verbotsszone ( wobei noch der Lieferverkehr erlaubt ist)
@warmbacher: Danke für deine Erklärung. Kannst du noch anfügen, wie wir als Relation erfasste Zonen technisch umwandeln … und in was für eine Objekt? Gerne als Beschreibung mit JOSM, QGIS o.ä. @fx99: Es müsste auf jeden Fall ein Namensschema beschlossen werden, dass auch im internationalen Raum funktioniert. Insofern finde ich den Suffix “_germany” schon wichtig. Werden diese “access” Attribute dann auch exportiert, wenn jemand osm2pgsql verwendet?
@warmbacher: Danke für die Übersichtsliste. Wäre super, wenn du noch die Query hinzufügen könntest, die du verwendet hast.
Ohne langjährige OSM-Erfahrung finde ich überzeugend, dass der Export-Filter in osm2pgsql nicht ständig angepasst werden kann, wenn ein neuer type in OSM dazu kommt.
Da ich warmbacher so verstehe, dass immer nur ein type vergeben werden kann, stimme ich hiermit für die Umstellung nach type=boundary, boundary=low_emission_zone.
Ich bin auf jeden Fall für eine einheitliche Lösung.
Wie gehen wir mit den Städten (Magdeburg, Neu-Ulm) um, die anstelle der Boundary die Straßen getagged haben?
gerne, aber bring euch absolut garnix, da ich das mit Postgresql und nicht mit der Overpass mache:
select id,
wno_gettag('type',tags) "type",
wno_gettag('name',tags) "name",
wno_gettag('boundary',tags) "boundary"
from planet_osm_rels
where wno_gettag('type',tags)='LEZ'
order by name;
Da hast du absolut Recht. MWn wurde das bisher 1 einziges mal gemacht als der type=boundary aufkam und den Programmieren wirklich die Argumente fehlten, das nicht zu integrieren.
Ignorieren oder einfach nachtragen ohne die Straßen zu löschen? Bin mir auch nicht schlüssig.
Für die Umweltzone gibt es zu viele Ausnahmen. Ich würde hier kein Access verwenden, die Zone steht für sich.
Bezüglich Rot/gelb/grün: Bis auf zwei Städte ist mittlerweile alles grün (Münster noch nicht aktuell, mache ich gleich). Die gelben Ausnahmen Augsburg, Neu-Ulm würde ich mit den Verkehrsschildern traffic_sign=DE:270.1,1031-50 taggen.
So, Mannheim ist fertig.
Ich habe ein Polygon erstellt mit boundary=low_emission_zone und type=LEZ.
Eins davon muss bestimmt weg.
Es existiert eine Relation “Umweltzone Mannheim” https://www.openstreetmap.org/relation/22825 die aber leer ist.
Was soll ich damit tun? Ich könnte mein Polygon der Relation zuordnen. Das wäre aber in meinen Augen dann doppelt.
Hi, ich habe mir die LEZ-“Zone” von Magdeburg mal näher angesehen:
Dort ist folgendes zu erkennen:
Alle in der Rel befindlichen 540 Straßenstücke sind im Layer NO rot dargestellt.
Es gibt Straßen innerhalb der von mir mal schnell berechneten Zone, die nicht in der LEZ-Relation enthalten sind. Hier hab ich mal nach residential, secondary, tertiary und service gesucht, die nicht in der Rel drin stehen und für die formal laut OSM kein Verbot besteht.
Das ist für mich auch absolut logisch, da es sich eigentlich nur wieder um eine der ach so beliebten Sammelrelationen handelt, die nie und nimmer zu 100% korrekt sein werden.
Daher rate ich dazu, eine vernünftige Zone zu erfassen (hier als einfaches Polygon) und die Rel zu löschen. Ähnliche Ergebnisse erwarte ich auch für Neu-Ulm.
Gruss
walter
ps: Am Rand des berechneten Zone gibt es gewisse Unschärfen, da Postgis mit ST_ConcaveHull es nicht besser hinbekommt.
Hab mal mit Augsburg angefangen und alle Aktualisierungen im Wiki vermerkt.
Es gab auch einige nicht geschlossene Relationen, also beim Editieren auch da drauf schauen!
So wie ich es verstehe, gibt es im Ruhrgebiet nur noch eine große Zone.
Was macht man mit den Unterzonen?
Die Relation 280734 für Bonn ist gelöscht, kann die jemand wieder finden?