Die Ebenen können jetzt nicht nur nicht direkt hochgeladen werden, sondern sie sind auch noch gelocked. Zum einen bedeutet das, dass man sie nicht bearbeiten kann, die spannendere Auswirkung ist allerdings, dass man dadurch auch nichts in diese Ebene hinein laden kann. Wenn daher eine gelockte Ebene aktiv ist und man lädt diesen Bereich herunter, landen diese Daten stattdessen in der Arbeitsebene, solange man nur eine offen hat, und ansonsten eben automatisch in einer neuen Datenebene.
addr:city wird jetzt durchgehend die Gemeinde zugewiesen. Wenn eine Straße in einer Gemeinde mehrfach vorkommt, wird bei den Adressen dieser Straßen zusätzlich ein addr:suburb mit dem Ort gesetzt. Ich finde das zwar auch noch nicht ganz optimal, aber überall möchte ich auch kein suburb setzen und es entspricht grob der Möglichkeit 2 aus dem Leitfaden der Post und ist konsistent
Und dann hat der Output jetzt eine neue Struktur und ist u.a. nach Gemeinden gruppiert, die Ordner- bzw. Dateistruktur sieht nun nämlich so aus:
PLZ-Bereich / Gemeinde / Ort / Strasse_PLZ_Ort_(Gemeinde).osm
Wenn man sauber vorgeht, ist das völlig ironiefrei sogar ein großer Fortschritt. Sehr hilfreich ist auch der Shortcut “2” um auf den Bereich der Ebene zu zoomen.
Pro Halbjahr sind etwa 10.000 Adressen mit neuen IDs dabei, also umgerechnet um die 400 pro Woche, wobei gerade bei neuen Einträgen die Qualität oft noch sehr mangelhaft ist und diese einfach mal irgendwie grob in die Gegend geworfen werden bzw. dort oft auch noch mehr zu tun ist, wie neue Straßen anzulegen - das ungeschaut zu übernehmen ist kontraproduktiv. Und ja, ich erwarte von dir, dass du bevor du etwas hochlädst, dir das zumindest einmal anschaust, denn danach wirst du das nicht mehr machen und “irgendwer” darf sich dann darum kümmern, dass das korrigiert und aktualisiert wird. Es sind weder der Konverter, noch die Duplikatsprüfung (die nicht einmal auf das Mergen von Imports ausgelegt ist), noch die Basisdaten perfekt - wenn dem so wäre, bräuchte es auch keinen manuellen Schritt und von blind kopierten Adressen ohne Straße irgendwo im Nichts, wie von Negreheb gezeigt, hat auch niemand etwas. Es hält höchstens noch jemand anderen davon ab, die Gegend mit Straße etc. zu erfassen, denn laut regio-osm ist dort ja alles perfekt (und bevor du das jetzt wieder als Diskreditierung von regio-osm deutest: das ist natürlich nicht die Schuld von regio-osm, ich halte das für ein tolles Tool, aber es ist eben auch nur ein Werkzeug und wie bei so vielen QA-Tools sollte es nicht darin ausarten, nur noch blind dieses zufrieden stellen zu wollen). Wenn dein Filter soviel weg filtert, dass du nicht einmal siehst, ob dort überhaupt eine Straße ist, oder ob diese mit den Adressen zusammen passt, dann ist das nicht sinnvoll.
Na zum Glück war der plan.at-Import “vollständig”, damit wir auch heute noch was davon haben
Nein, ich schlage vor, so wie bisher bspw. auch mit dem AddressHelper selektiv vorzugehen. Der “Quelltext” sind mehrere Tabellen mit Dutzenden Feldern, aber nur zur völligen Transparenz: im Gegensatz zum AddressHelper unterschlage ich auch den HAUSNRBEREICH und generiere nicht so Hausnummern wie “1-3, alle Zahlen des Intervalls”. Was jetzt gar so furchtbar daran ist, dass einige mit “str.” abgekürzte Straßennamen daran angeglichen werden, wie die Straßen sowieso schon in OSM heißen, hast du uns auch noch nicht richtig begründen können, außer dass dann vielleicht einzelne Gemeinden auf regio-osm evtl. orange statt gelb angezeigt werden könnten. Ich lasse mich ja überzeugen, dass das keine gute Idee ist, aber bis jetzt warst du als einziger dieser Meinung, ohne das gut begründen zu können.
Ich nehme an, mit dem Filter meinst du das hier, aber zum einen ist das ein unabhängiger Schritt vom Konvertieren (und wäre auf diese Art für so große Mengen und nicht on demand gar nicht machbar. Es ist auch jetzt mit der Abfrage je Datei nach der Umstellung auf Straßennamen etwas suboptimal) und weder importiere ich einfach alles, was über bleibt, noch ignoriere ich alles andere, wenn mir Unstimmigkeiten auffallen. Es ist halt nur ein weiteres Hilfsmittel, wenn auch ein sehr sinnvolles, wenn man soviel mit diesen Daten macht wie du.
Um das ganze unter Windows zu verwenden: Python 3.x installieren und dabei die Checkbox “Add Python 3.7 to PATH” wählen.
Dann eine Commandline öffnen (Startmenü “cmd”) und
pip install overpy
eingeben.
Das zip-File mit der osm-toolbox herunterladen und entpacken.
Diesen Ordner kann man jetzt noch zu den Umgebungsvariablen hinzufügen: Startmenü “Umgebungsvariablen” => “Umgebungsvariablen” => Path Bearbeiten und dort den Pfad zur osm-toolbox angeben.
Wenn du jetzt eine neue Commandline aufmachst (evtl. musst du dich vorher nochmal ab- und neu anmelden) solltest du unabhängig vom aktuellen Verzeichnis “filter_address_files.py” eingeben können, ohne Fehlermeldung.
Jetzt den Ordner einer Ortschaft öffnen, im Windows-Explorer auf Datei->Windows Powershell öffnen und
filter_address_files.py .
eingeben.
edit 2019-04-15: statt mehreren einzelnen Files akzeptiert das Script nur mehr ein einzelnes Verzeichnis, daher habe ich "" auf “.” geändert*
Beim ersten Mal musst du es anscheinend tatsächlich ausschreiben und kannst keine autocompletion verwenden, aber beim nächsten Mal brauchst du nur CTRL+R filter eingeben.
Damit wird neben den vollständigen Dateien auch noch eine entsprechende mit postfix _filtered.osm angelegt, wo die vorhandenen Einträge entfernt sind. Du kannst dann also im Explorer nach _filtered suchen und die Dateien per drag&drop in JOSM öffnen.
Was aktuell zB nicht heraus gefiltert wird: Adressen mit einem anderem addr:city, oder Subadressen, die mit “/” angegeben sind.