ich habe zwei Anläufe (der zweite, erfolgreiche war am 27.10.) gebraucht, um die lokale OSM-DB neu aufzubauen.
Ich habe das mögliche Auswertungsgebiet innerhalb Europa ausgedehnt und dadurch brauchte der initiale DB Aufbau länger (5 Tage inkl. Indizes) und dieser OSM-Datenstand Verzug wird auch kaum/mühselig aufgeholt seitdem, es sind immer noch 4,5 Tage. Das aufholen ist relativ unabhängig von der Last der Auswertungen für die Straßenlisten und Hausnummern.
Die gesamten Auswertungen laufen seit einer Woche wieder im normalen Rhythmus, nur halt mit dem Rückstand in den OSM Daten.
Die monatliche Sonderauswertung für die theoretische Hausnummerauswertung [1] läuft trotzdem seit gestern los und wird in 3-4 Tagen fertig sein.
Ein Freund schaut sich die DB in den nächsten Tagen an, wo da optimiert werden kann, obwohl einige Parameter schon für den osm2pgsql Import hochgesetzt wurden.
Möglicherweise führt das “>;” dazu, dass auch die Hausecken in die Ergebnismenge aufgenommen und dann mitgezählt werden? Dito das “>>;” bei den Relationen?
Der modifizierte Code liefert deutlich geringere Werte, u.a. für Nufringen den erwarteten Wert 1.
Technisch tauschst Du in einfach Zeile 3 das ““081150.*”” gegen das gewünschte Pattern aus. Soweit ich die Logik nachvollziehen kann, braucht die Abfrage linear mit der Anzahl abgefragter Regionen. Wenn Du also die zehnfache Anzahl an Regionen anfragst, wirst Du π * Daumen die zehnfache Zeit brauchen.
Danke, das ist korrekt! Ist mir die Tage schon aufgefallen, hab’s aber wieder vergessen zu posten.
“>” und “>>” müssen beide raus, sonst sind da noch die Punkte bzw. Wege+Punkte mit im Ergebnis.
Genau. Dieses Pattern müsste noch mit einem “^” beginnen, sonst matcht der Regex evtl. Unsinn.
Oops, ich ging fälschlicherweise davon aus, dass der Ausdruck implizit mit “^” und “$” geankert ist. Denn ohne Ankerung ist das “." am Ende im "081150.” überflüssig.
Groß/kleinschreibung ignoriert (ignoriert = sortiertechnisch identisch, ergo zufällige Sortierung oder bei stabilem Sortierverfahren die Reihenfolge, in der die Schnipsel reingekommen sind.
klein
klein
groß
groß
groß
klein
groß
groß
klein
klein
klein
Wenn ich da aufeinanderfolgende gleiche zusammensortiere, kommt genau das Ergebnis auf der Seite raus.
Ich hab vor kurzen zur Vorberitung einer Suchfunktion die OSM-Wegeschnipsel je Straßenname und Gemeinde zusammenfassen wollen (man will ja nicht die einzelnen OSM-Ways im Suchergebnis haben), und hab depperterweise zuerst zusammengefasst (die nach Quad sortierten Schnipsel) und erst danach nach Straßenname und Gemeinde sortiert. Gibt auch ein überraschendes Ergebnis: unglaublich, wieviele Hauptstraßen es in einer einzelnen Gemeinde geben kann.
die nachfolgenden Poster haben recht, das ist eine falsche Sortierung und ich beachte die Groß-/Kleinschreibweise.
Die verlinkte Version ist von OSM. Wie wird denn die Straße korrekt geschrieben?
Wenn es die offizielle Schreibweise ist, dann in OSM an den Hausnummerobjekten addr:street korrigieren.
Ansonsten hier angeben oder mir eine Mail schreiben, dann muß ich die offizielle Variante in der DB direkt korrigieren.
Monatsupdate Dezember und Jahresendabrechnung zu meiner Adressstatistik:
Kurzfassung: Es gab am 31.12.2014 7.668.547 Adressen (Definition siehe Wiki). Das sind +228.989 im Vergleich zum Vormonat (ca. 7.387 pro Tag). Seit meiner ersten Messung am 26.06.2014 sind beachtliche 1.570.323 Adressen hinzugekommen (ca. 8350 pro Tag).
1.992 Gemeinden und gem.fr. Gebiete verbleiben ohne eine einzige Adresse (-66 zum Vormonat).
Auch noch das Update für Adressen ohne Straßenangabe als CSV-Datei (Latin1).
Die Overpass Abfrage, die ich am 26.12 (Tagesansicht) habe loslaufen lassen, erzeugt aber noch andere Zahlen, die Zählung sollte ich vielleicht einfach rauswerfen.
Nicht richtig ist, alternativ besteht die Gefahr, das ich “Datenverluste” zu beklagen habe (fehlenden Transaktionen in MongoDB). Aber ich habe versucht, in typischen Fehlersituationen die Daten korrekt wieder herzustellen, was mir bei meinen Checks auch gelungen ist.
Christoph
Edit: Vielleicht ist auch mein Regionalschlüsselansatz falsch, und ich muss auf den Gemeindeschlüssel wechseln.
Die Auswertung ist einfach anders, Details stehen auch auf der Wiki-Seite. Weiterhin fehlt ein Bezugszeitpunkt: wenn da mehrere Tausend Queries über ein paar Stunden hinweg laufen, hat jede Query ihren eigenen Zeitstempel. Da müsste man wohl noch am Anfang ein [date:“2015-01-01T00:00:00Z”] oder sowas einbauen, damit alle Queries mit gleichen Zeitstempel arbeiten.
Danke, der Hinweis mit dem Zeitstempel ist ganz praktisch. Ich habe auch noch vor, die gezählten Objekte eventuell, die Zeitstempel der Abfragen in jedem Fall anzeigbar zu machen.
Ich glaube aber der grössere Unterschied ist im wiki erklärt.
Ich sollte die Daten einfach nicht mischen, und das Projekt an der möglichen neuen Wochenaufgabe “reifen” lassen.