gibt es eine Möglichkeit das geographische Zentrum von PLZs, die ja letztlich ein Gebiet umschreiben, in Koordinaten umzuwandeln? Hat das schon jemand mal gemacht? Technisch möglich müsste es ja sein, wenn auch nicht exakt.
=> Dann könnte man z. B. im Umkreis dieses Zentrums nach Straßenamen suchen und diese als Schreibhilfenkorrektur z.B. in Adressverwaltungen anbieten, das wäre zwar nicht so exakt wie der Datafactory Streetcode (=> https://www.deutschepost.de/de/d/deutsche-post-direkt/datafactory.html)) - aber besser als nichts.
==> Gibt es da schon was und ist das zulässig?
Wenn du das alles in einer Postgis hast kann die dir ja über ST_Centroid den berechnen. Aber je nach Form könnte es sogar sein das das geometrische Mittel ausshalb deiner Fläche liegt.
Einfach ist vermutlich einfach ALLE Adressen zu extrahieren und als strukturierte daten in ein Elasticsearch zu packen - Damit kann dann search as you type realisieren und eben auch mit “typos” dir trotzdem die “beste” lösung anbieten.
Ich habe mir da für Adressvergleich mal was gebaut:
geomcity, geomcounty, geompostcode, geomsuburb kommen entsprechend aus admin boundarys oder postcode areas.
id/source entsprechen dem OSM objekt - d.h. way oder node. Die lat/lon ist schon ein “centroid” des ways oder eben die lat/lon des nodes.
Das dingen kann noch mehr - ich nutze das zur Fehleranalyse und vergleiche dann den output u.a. auch mit anderen Adressdatenbeständen etc. Ausserdem nutze ich die Adressen um routen bzw distanz zum Routingfähigen Netzwerk zu berechnen (Mit OSRM)
Dann hätte man nur noch die Schwierigkeit, die Straßen, die im Umkreis liegen, zu selektieren: geht das dann auch via Postgis (https://de.wikipedia.org/wiki/PostGIS)?
Habe jetzt einen analogen Löungsansatz gefunden (hier geht es zwar um Flurstücke anstatt um Straßen, die im 200m Umkreis eines geplanten Windrades gesucht werden), es sollte bei PostGIS beispielsweise so gehen:
SELECT wkb_geometry, flurstueckskennzeichen
FROM ax_flurstueck
WHERE ST_Distance( ST_GeomFromText( 'POINT(353937.74 5531106.746)', 25832 ), wkb_geometry) <= 200 ;
Das funktioniert so nicht, schonmal mindestens nicht in Deutschland.
PLZ können mehrere Gemeinden umspannen und dadurch Straßennamen mehrmals enthalten.
Es gibt z.B. Schulstraße 37127 Dransfeld (OT Varmissen) und Schulstraße 37127 Scheden.
Besser ist:
“select” alle Straßen innerhalb der umschließenden admin_level=8, z.B. way[highway](area.YourTown); in overpass,
dann Levenshtein oder sonstige Korrelationsfaktoren berechnen (ist sogar unabhängig von der Query und könnte man aus ner pregenerierten Tabelle ziehen)
Mir ging es nicht um eine exakte Ermittlung aller Straßen in einem PLZ Gebiet, sondern nur um Vorschläge zur Rechtschreibkorrektur bei offensichtlichen Tippfehlern.
Deshalb würde ich um das geometrische Zentrum (nach @Nakaner - danke für den Hinweis) mit ST_DWithIn im Kreis mit einer großzügigen Distanz nach relevanten Straßen als Vorschläge suchen, die der Benutzer in der Adressverwaltung dann übernehmen kann oder auch nicht. Um es vollautomatisch (ohne Benutzereingriff exakt) zu lösen, dürfte man ja programmiertechnisch nur innerhalb der PLZ Grenzen nach Straßen suchen, was den Algorithmus kompliziert und langsam machen würde.
Da ich ein Anfänger im Projekt OSM bin, sagt mir der Satz: “select” alle Straßen innerhalb der umschließenden admin_level=8, z.B. way[highway](area.YourTown); in overpass,
(noch?) leider gar nichts. Kannst du das näher ausführen?
Die Levenshtein Distanz ist mir wieder klar, damit ist das gemeint: https://de.wikipedia.org/wiki/Levenshtein-Distanz
Es geht schlicht um die (mathematische) Menge aller Straßennamen in der gewählten Gemeinde. Die ergibt sich widerrum einfach aus der Menge aller Straßensegmente, die in der Gemeinde liegen. Die Gemeinde selber liegt als Area vor. Und mit dem Wissen baust du dir dann dein SQL-Statement zusammen, mit SELECT und ST_DWithin und was-auch-immer.
Die meisten Anwender halten aber keinen PostGIS-DB-Klon lokal vor. Daher wird oft die Overpass-DB (remote) abgefragt, und das mit Overpass-QL. Die Select-Statements sehen dort gänzlich anders aus, auch weil es, anders als SQL, eine Art imperative Sprache ist.
Was wahrscheinlich die beste Lösung wäre: wenn man doch versuchen würde im PLZ Gebiet möglichst exakt die Strassen zu ermitteln und die Ergebnisse dann in eine Tabelle zu speichern. Die Adressverwaltung könnte dann performant über Indexe auf diese Tabelle zugreifen (und bräuchte kein PostGIS / Overpass-QL, da sie über die PLZ einfach die relevanten Strassen filtern und vorschlagen könnte). Dann wäre die Laufzeit egal, da man die Strassenaktualisierung von OSM => PLZ/Strassentabelle nur einmal im Vierteljahr laufen lassen müsste (die Strassen ändern sich ja nicht täglich ;-)).
Das wäre dann die zweite, schwierigere Aufgabenstellung zur ersten Umkreissuche Lösung:
==> Suche alle Strassen innerhalb eines PLZ Gebietes.
Wie könnte man dies bewerkstelligen? Gibt es da auch schon fertige Befehle dazu, wie bei der Umkreissuche mit ST_DWithIn, oder muss man da selbst erst einen Algorithmus entwickeln?
In https://forum.openstreetmap.org/viewtopic.php?id=20839 ist schon erklärt, wie man so eine Liste mit overpass generiert. Da jeder Straßenschnipsel einzeln aufgeführt wird, muß man die Roh-Liste beispielsweise mit den üblichen Kommandozeilentools sortieren und die Duplikate rausfischen.
addr:postcode hängt in der Regel an einem Gebäude, event. auch an einem Grundstück. https://www.openstreetmap.org/way/39973424
Straßen haben dagegen kein tag addr:postcode.
In DE fehlen noch Millionen von Adressen und damit auch das addr:postcode daran.
@fx99: Vielen Dank für den Hinweis, dann nehme ich postal_code.
Auszug aus DE:Overpass API Wiki:
Download großer Mengen von Daten
Da die Größe des Ergebnis einer Overpass API Abfrage erst dann bekannt ist, wenn der Download abgeschlossen ist, ist es nicht möglich, während des Downloads eine Dauer für diesen Download abzuschätzen. Auch benötigt die Overpass API länger dafür, die Daten zu generieren und zu downloaden, als man bräuchte, um einfach alle Daten der selben Region statisch zu downloaden. Daher ist es besser, ein Planet file zu downloaden, wenn man Regionen in Ländergröße mit (fast) allen Daten haben will. Die Overpass API ist dagegen dann sehr nützlich, wenn man nur eine Auswahl von Daten einer bestimmten Region haben möchte.
=> https://wiki.openstreetmap.org/wiki/DE:Overpass_API#Einschr.C3.A4nkungen
==> Bekomme ich da ein Problem, wenn ich alle Straßen ganz Deutschlands herunterladen will? PostGIS ist halt schwierig zu installieren - mit der Overpass API wäre es deutlich einfacher.
Wenn Du die geschätzt 10.000 Abfragen am Stück laufen lässt, bekommst Du wahrscheinlich Probleme mit der Quota.
Aber zeitlich verteilte Abfragen auf den diversen Overpass Servern könnte gehen.
Spätestens, wenn es Richtung Europa ginge (FR / CH / AU wären z. B. auch interessant), wäre dieses wohl unumgänglich: Overpass API/Installation als Clon => https://wiki.openstreetmap.org/wiki/Overpass_API/Installation
Oder sieht jemand noch einen anderen Weg?
ACK, deshalb habe ich mir nun anhand der obigen Anleitung die overpass API installiert - die beeindruckt mich doch sehr ob ihrer Funktionalität. Das funktioniert nun gut, ich kann nun z. B. via SSH und Python (https://python-overpy.readthedocs.io/en/latest/introduction.html) auf die API zugreifen, denn Python scheint mir ohne viel Overhead elegant auf die API zuzugreifen und dann kann ich auch soviele Abfagen pro Sekunde machen, wie das System hergibt - und ich habe gleich die ganze Welt installiert.
Danke für alle Hinweise, nun sollte sich mein Problem vollends lösen lassen.
