Wochenaufgabe Umweltzonen

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)

Für Tübingen habe ich die Quelle der Stadt im Wiki aktualisiert, vielleicht mag einer die Gebiete malen.
http://www.tuebingen.de/Dateien/umweltzone_in_tuebingen_uebersichtsplan.pdf

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

Kann man machen, da ist aber gerade eine größere Änderung in Diskussion.

ist doch ganz einfach: type=LEZ → type=boundary, boundary=low_emission_zone umwandeln.

technisch: mit irgendwas (ihr nehmt wohl die Overpass) alle Relationen mit type=LEZ suchen und in Josm umwandeln. Hier mal eine Liste der Kandidaten.


   id    | type |              name               |     boundary      
---------+------+---------------------------------+-------------------
 2461289 | LEZ  | Fascia Verde                    | 
 1014684 | LEZ  | Korrektur Umweltzone Stuttgart  | 
 3937563 | LEZ  | London Low Emission Zone        | 
  374352 | LEZ  | Umweltzone Augsburg             | 
   14980 | LEZ  | Umweltzone Berlin               | low_emission_zone
  113379 | LEZ  | Umweltzone Bochum               | 
  308968 | LEZ  | Umweltzone Bottrop              | 
 2353399 | LEZ  | Umweltzone Bremen               | 
   14521 | LEZ  | Umweltzone Dortmund             | 
 2724570 | LEZ  | Umweltzone Düsseldorf           | 
   55856 | LEZ  | Umweltzone Düsseldorf           | 
   90990 | LEZ  | Umweltzone Frankfurt            | 
  370059 | LEZ  | Umweltzone Freiburg im Breisgau | 
 2050865 | LEZ  | Umweltzone Hagen                | 
 2676846 | LEZ  | Umweltzone Heidelberg           | 
 3996094 | LEZ  | Umweltzone Heilbronn            | 
 1631028 | LEZ  | Umweltzone Krefeld              | 
 1462106 | LEZ  | Umweltzone Leipzig              | 
 1919505 | LEZ  | Umweltzone Magdeburg            | 
   22825 | LEZ  | Umweltzone Mannheim             | 
 4016166 | LEZ  | Umweltzone München              | 
 2915341 | LEZ  | Umweltzone Münster              | 
  409356 | LEZ  | Umweltzone Neuss                | 
   51852 | LEZ  | Umweltzone Neu-Ulm              | 
 4012591 | LEZ  | Umweltzone Osnabrück            | low_emission_zone
  332021 | LEZ  | Umweltzone Pfinztal             | 
   83302 | LEZ  | Umweltzone Pforzheim            | 
  176409 | LEZ  | Umweltzone Regensburg           | 
 2045639 | LEZ  | Umweltzone Ruhrgebiet           | 
 3059614 | LEZ  | Umweltzone Schramberg           | 
 2005579 | LEZ  | Umweltzone Ulm                  | 
 2459896 | LEZ  | ZTL Anello Ferroviario          | 
 2459882 | LEZ  | ZTL Diurna Centro Storico       | 
 2572441 | LEZ  | ZTL Diurna Trastevere           | 
 2573034 | LEZ  | ZTL Notturna Centro Storico     | 
 2573006 | LEZ  | ZTL Notturna San Lorenzo        | 
 2573007 | LEZ  | ZTL Notturna Testaccio          | 
 2691714 | LEZ  | ZTL Notturna Trastevere         | 
 2459883 | LEZ  | ZTL Tridentino                  | 
(39 rows)

JOSM: r2573034,r2459883,r2005579,r2573006,r176409,r22825,r1014684,r2353399,r2676846,r332021,r2459882,r2461289,r2459896,r14980,r1919505,r374352,r51852,r3996094,r2045639,r113379,r2050865,r3059614,r2724570,r2915341,r4012591,r90990,r14521,r370059,r409356,r1462106,r3937563,r83302,r308968,r1631028,r2572441,r2691714,r55856,r4016166,r2573007

wenn jetzt Konsens herrschen würde, wäre das relativ flott gemacht. uk und italien müsste man noch kurz ansprechen.

Gruss
walter

ps: nicht damit es jetzt heisst “es geht ja doch!” Ich kann eine Liste der Rels erstellen allerdings ohne Flächeninformationen.

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

Gruss
walter

Ich hatte ja Bedenken von wegen Multipolygon. Aber die Relation vom Typ Boundary erlaubt ja auch inner/outer. Also verstehe ich das richtig so:

  • Wenn Relation: type=boundary, boundary=low_emission_zone - und zwar auf der Relation

  • Wenn Polygon: boundary=low_emission_zone

Also für das LkW-Fahrverbot passen normale Access-Tags wie auf einem highway. Es gilt für alle LKW über 3,5t und im Endeffekt ist nur die Durchfahrt verboten. Also hgv=destination

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.

Hier die overpass Query: http://overpass-turbo.eu/s/4XS

Die Wiki-Seite hab ich nicht korrekt aktualisiert, da man dort eine Relation angeben muss, und die hab ich nicht, naja :slight_smile:

Jo, wenn es wie hier eine einfache geschlossen Linie ist, reicht boundary=low_emission_zone. type=xxx ist hier sogar total daneben.

Gruss
walter

absolut korrekt.

damit klappt es dann sowohl für die Osmapi-Anwender als auch für die Datenbankbenutzer.

Gruss
walter

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?

Hallo Wambacher,

Servicewege habe ich nicht in der LEZ in Magdeburg erfasst. Sie sind an der Grenze auch nicht beschildert.
Alles andere sollte eigentlich passen.

Ich werte gerade eine Fahrradkarte mit Maperativ aus. Kann ich die Wege dann noch der LEZ zuordnen wenn sie innerhalb eines Polygons liegen?

Gibt es im Wiki mittlerweile eine Taggingvorgabeseite? Hab spontan nichts gefunden.

Merkwürdig aber net so wichtig. Also könne man theoretisch doch dort reinfahren?

Soll das bedeuten, du hast nachgebessert? So ist und war das eigentlich von mir nicht gedacht.
Ich wollte - mal wieder - die prinzipielle Unsicherheiten bei Erfassungen mit “Sammelrelationen” darstellen. Mehr ist diese LEZ-Liste nämlich nicht.

Kenne Maperative nicht so gut. Weiss ja auch nicht, wo du deine Rohdaten herbekommst. Mit der Overpass geht das auf jeden Fall und Mapnik sollte auch kein Problem machen.

Jo: http://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dlow_emission_zone allerdings noch sehr rudimentär.

Gruss
walter

Nachtrag: Ich habe mich hier eigentlich eingeklinkt, weil es mir um das prinzipielle Problem der Erfassung von “Zonen” geht. Egal ob es sich um LEZ-Zonen, Wasserschutzgebiete, Naturschutzgebiete, Wahlkreise oder andere flächenhafte Objekte handelt.

Bei allen solchen Objekten macht es absolut keinen Sinn, eine Liste der Inhalte aufzustellen. Das ist der Job von spatialen Abfragen und die brauchen ein Polygon/Relation zur Flächendefinition.

Wiki-Seite überarbeitet, type=LEZ durchgestrichen.

Hab mal kurz reingeschaut. Maperitive wird ja normalerweise mit OSM-Daten im XML-Format “gefüttert”

Ich nehme an, du hast einfach alle Highways geladen, die in der LEZ-Liste drin sind und die dann in Maperitive verarbeitet. Das kann du relatiov einfach mit der OsmApi machen, wenn du alle dich interessierenden Highways lädts, die sich innerhalb des LEZ-Polygons befinden. danach geht es wie gehabt weiter.

That’s all.

EDIT: und so sieht es für Wiesbaden aus:

query:

(
  area(3603996816)->.input;
  way (area.input) ["highway"];
  >;
);
out;

bin kein Overpass-Spezi und musste das Area noch aus dem Ergebnis manuell entfernen. Aber dann ging es.

Ich habe die beiden Mapper fx99 und Thilo87 mal angeschrieben.
In Stuttgart ist die B10/B27 im Norden nicht mehr ausgenommen, (neuer Text alter Text) das müsste noch korrigiert werden. Ich habe dazu leider keine Zeit.

Für Deutschland erledigt.
Neu-Ulm und Magdeburg sind jetzt type=collection, collection=low_emission_zone

@wambacher:Kannst Du zur Sicherheit nochmal Deinen Check laufen lassen.

Das Bild zeigt schön die zukünftigen Probleme beim Rendern und vermutlich noch viel mehr beim Routen…

Vermutlich darf ich auf der A643 von Süden in das Gebiet einfahren und am Schiersteiner Kreuz nach Osten abbiegen. In Walters Bild sind die Autobahnen aber zum Teil drin, weil kaum ein Programm auf die Idee kommt, dass die Grenze der LEZ nicht zur LEZ gehört.

Da müsste man entweder mit Abstand zur Straße mappen, oder sich Abfragen basteln, die die LEZ erst um 2 Meter schrumpft und dann die Abfrage macht, oder bei Abfragen den Rand ausnehmen.

Grüße, Max

Edit: Text geändert, das Problem ist ja nicht, dass die Autobahnen auf dem Bild fehlen, sondern, dass sie zum Teil drin sind…