OpenStreetMap

Die heutige Hausnummerauswertung auf regio-osm.de stößt an ihre Grenzen und dies aus mehreren Gründen:

  • die verfügbaren Hausnummerlisten sind enorm angestiegen. In Europa gibt es für mehrere Länder komplette Listen, so z.B. für Polen, Tschechien, Niederlande, Belgien (Flandern-Teil), Dänemark …
  • die Art der Auswertung stößt an ihre Grenzen: es wird eine osm2pgsql-DB eingesetzt. Der Rechenaufwand zur aktuell Haltung der DB ist hoch und die DB-Struktur ist nicht optimal zur Auswertung geeignet.
  • Ein OSM-ler hat Interesse bekundet, Rechenleistung bereitzustellen. Die derzeitige Softwarearchitektur ist nicht gut geeignet dafür. Die Software ist aktuell auch eher aufwändig auf einen anderen Server zu portieren, z.B. damit die Community eines anderen Landes mit einer Hausnummerliste eigenständig Auswertungen durchführen kann.
  • Die Auswertungssoftware ist derzeitig in einem privaten Github Repository gelagert. Einige OSM-ler sind interessiert an der Programmierung, der Code ist aber nicht objektorientiert genug und besteht aus vielen, undokumentierten Teilprogrammen.
  • Die aktuelle, zentrale Lösung auf regio-osm.de verhindert die Auswertung neuer Listen oder die vorhandenen Auswertungen müssen seltener ausgeführt werden, was die OSM-Mapper eher demotivieren wird.

Daraus folgen aus meiner Sicht diese Anforderungen an eine neue Version der Auswertung:

  • die Auswertung sollte mit möglichst geringem Softwareaufwand machbar sein, also möglichst ohne lokale OSM-DB. Zu prüfen wäre u.a. die Eignung der live Overpass-Api Abfrage.
  • Auswertungen sollten parallel auf verschiedenen Servern laufen können, also interessierte OSM-ler sollten einfach Rechenleistung bereitstellen können.
  • die Ergebnisse der Auswertungen sollten optional zentral (aber ggfs. auf mehreren Servern) gesammelt werden. So könnten je Land Auswertungen gerechnet werden, diese aber in der Anzeige und ggfs. länderübergreifenden Ergebnisauswertung auf einigen oder allen Server bereitgestellt werden.
  • Die Ergänzung von Auswertungsservern sollte einfach möglich sein, allerdings ist sicherzustellen, wer den jeweiligen Server betreibt und das die Hausnummerlisten ggfs. im OSM-Umfeld bleiben (z.B. über PGP-Schlüssel und OSM-Accountidentifizierung).
  • Die Kommunikation der Server untereinander soll über eine API-Schnittstelle erfolgen.
  • Die Auswertungssoftware soll in einem öffentlichen Github Repository gehalten werden.
  • Die Softwareentwicklung sollte möglichst in einem Team erstellt werden.

Potential der neuen Auswertung

Die neue Version soll es lokalen Communities ermöglichen, in ihren Ländern oder Regionen eigenständige Auswertungen durchzuführen. Wenn die Ergebnisse aber Serverübergreifend verfügbar sind, ist eine OSM Gesamtauswertung und -darstellung möglich.

Wer als Einzelperson oder kleine Gruppe mit der Auswertung seiner Gebiete nicht zufrieden ist und das technische Potential hat, kann seine Gebiete so oft auswerten wie gewünscht. Diese Auswertungen wären wieder allgemein verfügbar.

Durch die mögliche Zusammenarbeit der bisherigen Entwickler sowie weitere neue Mitstreiter wäre ein größeres Potential vorhanden und die Abhängigkeit von Einzelnen geringer bzw. deren Wegfall nicht das Ende der Auswertungen.

Weg zur neuen Version

Ich habe mir noch keine Gedanken gemacht, wie die neue Version angegangen werden kann, aber ich hoffe, das schon in der Planungsphase mehrere Personen beteiligt sind.

Die aktuelle Version der Hausnummerauswertung bleibt selbstverständlich erhalten, bis die neue Version fertig gestellt ist.

Bitte diskutiert schonmal hier im Kommentarbereich zu diesem Blog,

viele Grüße

Dietmar aka okilimu

Discussion

Comment from Sanderd17 on 21 December 2014 at 22:00

Sorry to answer in English, but my German is really bad.

I think I tried to do more or less the same for the Flemish house numbers. See the tool we developed: http://crab-import.osm.be/import.html

Just enter a post code (I’m currently working in the post code 8800) and check to compare with osm data, and press update.

It compares the governmental data with osm data, and sees which addresses are not matching. At the bottom of the page, there’s a map with colour codes.

Though my approach is different in that I don’t use a central server (just a webpage hosted via github and some json files). The osm data comes live from overpass, and the actual comparison happens at the client (in js scripts).

The disadvantage is that it’s impossible to get a big picture (querying big areas is impossible with overpass, and comparison would time out too), and I also can’t keep statistics over the time (because we never get the results from the comparisons in the first place, and most municipalities won’t be queried for a long time). So the tool is pretty much worthless for statistics.

The big advantage is for the mapper though. As overpass normally only has a few minutes delay, just pressing update makes it possible to see all the new changes pretty much immediately.

When I started my project, I didn’t have an idea about this project, but I guess we can learn from each other. The tools have very different use cases for sure.

Comment from wiedergaenger on 22 December 2014 at 11:05

Hallo Dietmar,

Vielleicht ist es erst einmal sinnvoll zu diskutieren, welchen Ansatz der Software-Architektur man wählt, bevor man sich in Detailfragen verliert.

Ich finde die Idee der Verwendung der Overpass-API gar nicht schlecht. Angenommen man hat einen Server (oder auch Serverlandschaft) die die Hausnummenrlisten verwalten, dann könnte man das Ergebnis einer Overpass-Anfrage auf dem Server cachen und dann an Clients ausliefern. Alternativ kann man auch überlegen, ob der Client nicht auch die Berechnungen durchführt, wie Sanderd17 auch anführt. Also Client stellt Overpass-Api Anfrage und bekommt vom Server nur die Hausnummernliste geliefert (die einzelne Berechnung ist ja kein großartiges Aufwand). Frage ist nur, ob man damit eventuell die Overpass-API überlasten würde. Deswegen vielleicht auch mal ein paar Zahlen: Wie oft wird durchschnittlich so eine Hausnummernliste aufgerufen pro Stunde? Wieviele Listen gibt es momentan grob?

Würde gerne aktiv beisteuern, aber ich habe erst ab Mitte Februar Kapazitäten.

Viele Grüße

Comment from okilimu on 22 December 2014 at 22:19

Hello Sanderd17,

thanks a lot for giving me the info about your tool!

It would be very good to exchange information about our tools and to find out, what each tools does best.

I want to translate my blog entry in english in a few days or up to two weeks, but i found it very well to get the first comment in english ;)

Thanks a lot!

Greetings Dietmar

Comment from okilimu on 22 December 2014 at 22:33

Hallo wiedergaenger,

die Softwarearchitektur ist noch offen und ich habe mir ähnliches vorgestellt, was Du skiziert hast.

Die Berechnung soll möglichst verteilt auf verschiedenen Rechnern laufen, aber ich gehe davon aus, das explizite Programme laufen (Java wäre da aus meiner Sicht favorisiert). Wir haben Großstädte wie Berlin, wo über 375.000 Hausnummern vorhanden sind, da läuft nichts mal eben nebenbei in Realzeit.

Zu Deinen Fragen: * wie oft Hausnummerlisten abgefragt werden: keine Ahnung, habe ich noch nicht ausgewertet * wieviele Listen gibt es: - Belgien, Teil Flandern: 308 Gemeinden = ca. 2,8 Mio Hausnummern - Dänemark: komplett ca. 2 Mio Hausnummern - Deutschland: 69 von 11.237 Gemeinden, aber 10% aller Hausnummern (gesamt 21,24 Mio) - Österreich: 280 Gemeinden (1 von 7 Bundesländern) - Island: komplett 110 Hausnummern - Niederlande: komplett ca. 8,6 Mio Hausnummern - Norwegen: komplett ca. 1,8 Mio Hausnummern - Polen: komplett ca. 6,8 Mio Hausnummern - Tschechien: komplett ca. 2,9 Mio Hausnummern

Diese Listen sind verfügbar und nutzbar.

In den folgenden Ländern ist die Verfügbarkeit oder Nutzbarkeit noch etwas unklar: - Frankreich: etwas unklar ob komplett. Insgesamt ca. 17 Mio Hausnummern - Italien: vermutlich komplett, sollen ca. 15-18 Mio Hausnummern sein

Ich habe noch etliche Ländern in Europa nicht geprüft.

Zum Zeitablauf: ich will in Kürze mal einige Tests mit Overpass Abfragen probieren, um ein Gefühl zu bekommen, wie gut einsatzfähig es ist.

viele Grüße

Dietmar

Comment from okilimu on 22 December 2014 at 22:33

Hallo wiedergaenger,

die Softwarearchitektur ist noch offen und ich habe mir ähnliches vorgestellt, was Du skiziert hast.

Die Berechnung soll möglichst verteilt auf verschiedenen Rechnern laufen, aber ich gehe davon aus, das explizite Programme laufen (Java wäre da aus meiner Sicht favorisiert). Wir haben Großstädte wie Berlin, wo über 375.000 Hausnummern vorhanden sind, da läuft nichts mal eben nebenbei in Realzeit.

Zu Deinen Fragen: * wie oft Hausnummerlisten abgefragt werden: keine Ahnung, habe ich noch nicht ausgewertet * wieviele Listen gibt es: - Belgien, Teil Flandern: 308 Gemeinden = ca. 2,8 Mio Hausnummern - Dänemark: komplett ca. 2 Mio Hausnummern - Deutschland: 69 von 11.237 Gemeinden, aber 10% aller Hausnummern (gesamt 21,24 Mio) - Österreich: 280 Gemeinden (1 von 7 Bundesländern) - Island: komplett 110 Hausnummern - Niederlande: komplett ca. 8,6 Mio Hausnummern - Norwegen: komplett ca. 1,8 Mio Hausnummern - Polen: komplett ca. 6,8 Mio Hausnummern - Tschechien: komplett ca. 2,9 Mio Hausnummern

Diese Listen sind verfügbar und nutzbar.

In den folgenden Ländern ist die Verfügbarkeit oder Nutzbarkeit noch etwas unklar: - Frankreich: etwas unklar ob komplett. Insgesamt ca. 17 Mio Hausnummern - Italien: vermutlich komplett, sollen ca. 15-18 Mio Hausnummern sein

Ich habe noch etliche Ländern in Europa nicht geprüft.

Zum Zeitablauf: ich will in Kürze mal einige Tests mit Overpass Abfragen probieren, um ein Gefühl zu bekommen, wie gut einsatzfähig es ist.

viele Grüße

Dietmar

Comment from Sanderd17 on 22 December 2014 at 22:35

It’s no problem, since my native language is Dutch, I can understand German (though it takes some time to get used to the spelling every time I start reading German). Writing is a lot more difficult, not only the spelling, but also the conjugations.

I must warn you, our tool is made specifically for the CRAB database, so it includes fields like the precision, and depends on an administrative boundary structure that would make it hard to port to other regions and databases. Though the idea of using overpass queries with client side comparison can of course be tested and evaluated.

You can always pm me.

Comment from flohoff on 27 December 2014 at 18:09

I’d propose to look at the OSM Inspector Adresslayer processing. Its a libosmium based c++ tool which AMAZINGLY fast crunches through an osm.pbf file and generates an sqlite/spatialite output file with a lot of information - geometries, streets, housenumbers, point on next street (if there is no streetname etc). Probably not enough for the address lists but that should be easily doable.

Everybody could use an OSM Extract of the region of interest to process and compare to the addresslist.

Comment from okilimu on 28 December 2014 at 06:54

@flohoff thanks for this valuable hint, i didn’t think about osmi to check against, if it could be useable.

I’ll do a look into the code and i’ll probably meet the code author at the next karlsruhe hack weekend.

Greetings Dietmar

Comment from Rondom on 30 December 2014 at 00:37

Hello Dietmar,

I have just tried my hands on writing a quick an dirty Python script today. It fetches the data via the Overpass-API and compares it with preprocessed data from Tirol, Austria.

Running the comparison (including fetching the data via Overpass) takes around 5 to 20 seconds per municipality. I cannot provide nice numbers with variance and average since I am on a very slow and flaky internet connection at the moment. Actual CPU-time needed for the comparison is around 0.1s. So it is actually rather a question of how much concurrent requests the overpass-api can stand than a question of the load caused by the pre-processing and comparison of the data.

The script is not feature-complete, of course. It already takes into account associatedStreet-relations if there is not addr:street on the way/node and processes simple ranges. The code relies on serialized (pickeled) python dicts for the public data and is missing quite some features. This was okay for the quick prototype for testing the performance. In order to provide the same featureset as the current version in a robust and maintainable manner, using a database is obviously the way to go.

Considering these results I consider the disk space and maintenance-overhead of processing the whole planet and/or regular diffs overkill. Same goes for implementing a distributed system as you suggested.

I also looked at the OSM Inspector source and considering the above I found some of the algorithms worth taking into consideration.

If you are interested and if time allows, I can try to put together an early prototype and publish it.

Andreas

Log in to leave a comment