Keypad-Mapper 3: wie kann man real fehlende Hausnummern mappen?

Hallo,

die nächste Version des Keypad-Mapper wird ein Feature haben, mit dem man sich fehlende Hausnummern in der Umgebung anzeigen lassen kann um diese dediziert vor Ort suchen und ergänzen zu können.
Dieses Feature ist vor allem gedacht für Gegenden, in denen es schon recht viele Hausnummern gibt, aber eben noch nicht alle.

Dabei wollen wir so vorgehen, daß wir die höchste in einer Straße bekannte Hausnummer ermitteln aus der Liste aller vorhandenen Hausnummern in der Straße. Das funktioniert unter Laborbedingungen auch schon ganz gut.
Da Hausnummern oft fortlaufend sind, kann man dann im Umkehrschluß ganz gut ermitteln, welche Hausnummern noch fehlen.
Es ist uns klar, daß wir mit dieser Vorgehensweise nicht alle fehlenden Hausnummern erwischen, aber die Datenbasis wird dadurch schon mal erheblich besser als sie heute ist.

Nun meine Frage:
es gibt in der Realität immer wieder echte Lücken in den Hausnummer-Sequenzen, sei es ein leeres Grundstück, weil zwei Hausnummern zu einer zusammengefasst wurden u.s.w.
Damit nun nicht jeder Mapper wieder nachschauen geht, was es mit der fehlenden Hausnummer auf sich hat, suchen wir nach einer geeigneten Lösung, die Info, dass die Hausnummer auch in der Wirklichkeit fehlt, zu hinterlegen.

Hat jemand eine praktikable Idee?

Cheers Markus

Vielleicht einfach als note in einer standardisierten Form bei der vorhergehenden Hausnummer hinterlegen. Das könnte dann der Keypad-Mapper auswerten und Mapper könnten mit der Information auch etwas anfangen.

Wie bei maxheight=none → addr:housenumber=none (keine Angabe vorhanden)

Die beiden Vorschläge könnte man ein vorhandenes Haus pappen (z.B. für Nebengebäude, Stall, usw.), aber was macht man mit einem leeren Grundstück, wie eingangs auch die Frage war? :slight_smile:

Eine andere Frage ist, inwieweit die Tags sinnvoll und gewünscht sind.

Ich würde nur einen Punkt setzen - ins Grundstück (Hauslücke in Städten?) oder ins Haus und ist damit auswertbar.

Es gibt leider nicht nur Lücken, sondern prinzipbediengt viele kleine Lücken. Ein schönes beispiel ist vielleicht die Walter-Richter-Straße in 01773 Altenberg.
Hier gab es nicht nur den Rückbau nicht benötigter Gebäude, sondern die Nummern sind nach Straßenseite vergeben. Eine Seite die geraden auf der anderen Seite die ungeraden Nummern. Dadurch fehlen jetzt beispielsweise vor allem ungerade Hausnummern. Bei der Auswertung mit einem Punkt hätte das zur Folge jetzt von 8 - 14 vier Hausnummern zu ergänzen. stünden die Häuser mit den Nummern 30-42 noch wären die Lücken sehr viel Größer und beträfen dann auch die andere Straßenseite.
Ähnliches ist sicher in vielen Regionen mit städtebaulichem Rückbau zu beobachten.

Wenn man mal über den “Tellerrand” blickt, gibt es Länder, die riesige Lücken zwischen den Hausnummern haben:

Wir haben bei OSM ja den Ansatz, nichts zu erfassen, was es nicht gibt. Tags wie “name=unknown” oder Nodes mit “note=hier fehlt ein Haus” sind taboo.

Man könnte die Info “jetzt kommt Lücke” an das Haus vor/nach der Lücke taggen (etwa addr:next_housenumber=4711 und 100 Meter weiter addr:previous_housenumber=4711)), aber so richtig glücklich bin ich nicht darüber.

Gruss
walter

[1] http://de.wikipedia.org/wiki/Hausnummer#Nummerierungssysteme

Man muss gar nicht über den Teich blicken, das gibt es auch schon in Frankreich :wink:

Auf jeden Fall wäre es (glaube ich) wichtig, einstellen zu können, nach welchem System die Straße numeriert ist (eine Seite gerade, andere Ungerade; oder fortlaufend). Der mir bekannteste extremste Fall in meiner Umgebung ist, dass die Hausnummer 1 vis-a-vis der Hausnummer 94 ist. :wink:

Moin,

och, ich biete 2 gegenüber 102. ;)*

Aber auch sonst bin ich nicht so der Freund von “wir packen einfach QS-Informationen in die OSM-Datenbank”.
Lieber ist mir da das Prinzip “keepright” oder “OSB” - die QS-Informationen inkl. “false positive” in einer eigenen Datenbank.

Gruß
Georg

  • Karlstraße in Braunschweig

Hallo Georg

In Berlin ist es üblich Hausnummern fortlaufend zu vergeben also auf einer Seite die Nummern 1-xxx (ohne Lücken) und auf der Gegenseite zurück von (xxx+1) bis (xxx+(~xxx)).

Bei Stichstraßen hat man oft nur (un)gerade Hausnummern auf beiden Seiten, so wie es der Seite des Hauptweges entspricht.

Insgesamt stimme ich dir zu, dass QS-Informationen nicht in OSM gehören. Die Ausnahmen sind note=* und fixme=*, da die meist nicht systematisch gefunden werden könnten.

In einer Anwendung wie Keypad-Mapper will man solche Lücken trotzdem gerne haben. Es ist nur die Frage, wie und ob man das systematisch ermitteln kann. Schon bei eingetragenen Gebäuden ist das nicht einfach. Das Haus direkt an der Straße hat wahrscheinlich eine Hausnummer, die Gebäude dahinter können entweder Nebengebäude sein (dann keine Hausnummer) oder Hinterlieger (dann eine eigene Hausnummer).

Edbert (EvanE)

Hausnummernschema “links hoch, rechts runter” zählt nicht :wink:
Ich hätte eine 6 gegenüber einer 135 im System links ungerade, rechts gerade im Angebot, freilich mogelt die linke Seite mit etlichen Stichwegen und die rechte Seite ist ziemlich grün; ohne Stichwege und in dichter Bebauung 210 gegen 305. Ansonsten noch zwei unmittelbar aneinandergebaute Hausnummern 85 und 113.

Das ursprüngliche Anliegen in allen Ehren, aber bei dessen Nutzen bin ich skeptisch. Wenn ich die Idee richtig verstanden habe, soll etwa anhand der Folge 1, 3, 5, 9 erraten werden, daß Nummer 7 möglicherweise noch fehlt. Eine fehlende 3a wird auf diesem Wege nicht detektiert, das hatte Markus59 schon im Ausgangsposting angedeutet. Ich möchte einmal darauf hinweisen, daß solche Hausnummern mit Buchstabenzusatz keineswegs selten sind und daher auch ihr Anteil an den fehlenden/vergessenen Hausnummern keineswegs vernachläsigbar ist. Tatsächlich dürften Hausnummern mit Zusatz sogar überproportional häufig fehlen: wenn man beim Hausnummernmapping unterwegs nur die Nummern 17 und 21 sieht, schaut man noch einmal genauer hin und entdeckt vielleicht doch noch die unauffällige 19 am Seiteneingang, dem Anbau, der Zufahrt zum Hinterhaus oder dergleichen. 17a wird dagegen viel leichter übersehen - man merkt einfach nicht, daß hier noch etwas fehlt.

An den eingetragenen Hausnummern haben solche mit Buchstabenzusatz nach meiner Rechnung einen Anteil im oberen einstelligen Prozentbereich. Folgende Zahlen sind schon drei Monate alt, aber an der qualitativen Aussage dürfte sich wenig geändert haben: in (Geofabrik-) DE gibt es 3,6 Millionen Hausnummern (addr:housenumber, heute 4 Millionen). Bei 200k davon folgt auf eine Ziffernfolge der Buchstabe a; die Buchstaben b bis i begleiten weitere 125k Hausnummern; insgesamt sind es etwa 330k mit Buchstabenzusatz. Dies sind 9 % der vorhandenen Hausnummern; ihren Anteil an den fehlenden Hausnummern schätze ich eher noch höher (s.o.).

Abgesehen davon scheint es mir sinnvoller, eine eventuelle “Lückensuche” nicht in einem Erfassungsprogramm zu verstecken, sondern im Web anzubieten (wo sich dann auch der Keypad-Mapper seine Daten holen kann); vorzugsweise integriert in eines der bestehenden QS-Systeme.

Es gibt bereits einiges an QS-Tools, die sich um Adressen kümmern. Dies sind der Adress-Layer im OSM-Inspector und das QA Tool von Simon Poole (als Beispiel hier Nassau (Lahn)). Es gibt wohl noch andere wie der Hausnummern-Validator (Schwerpunkt doppelte Hausnummern).

Das Problem beim OSM-Inspector und Simons QA-Tool ist, dass sie a) im wesentlichen bestehende Gebäude/Adressen prüfen und b) nicht unterscheiden können zwischen Nebengebäuden (keine eigene Hausnummer, außer bei building=farm_auxilary sehr schwierig) und Hinterliegern (meist eigene Hausnummer).

Weiter kümmern sich diese Tools nicht um mögliche Lücken. An der Stelle könnte man noch etwas ergänzen, falls man überhaupt einen Algorithmus dafür findet. Weltweit mit den unterschiedlichen Adress-Formaten dürfte das recht schwierig sein. Aber selbst in DE / Mitteleuropa gibt es schon viele Varianten wie Hausnummern relativ zu Straßen vergeben werden. Genannt seien hier für DE kleine Orte, in denen die Hausnummern nach Ort und nicht nach Straßen vergeben werden.

Edbert (EvanE)

In die erste Version des housenumbervalidators hatte ich so eine „Lückensuche“ eingebaut. Da diese aber in „meiner Gegend“ eigentlich nur Fehlalarme produziert hat, habe ich die wieder entfernt und das Thema nicht weiter verfolgt.

Und genau aus dem Grund halte ich eine noch weitere Fragmentierung der Landschaft für nicht wünschenswert.

OSMI hat den meisten anderen Werkzeugen immerhin schon voraus, daß er nicht nur Einzelobjekte betrachtet, sondern z.B. Adressen in Beziehung zu Straßen setzt und daraus die Meldung “street not found” bzw. Verbindungslinien zur Straße generiert, siehe am Beispiel von Lübeck, zweites Beispiel. Das finde ich deutlich interessanter als die Kennzeichnung von Gebäuden ohne Adressdaten, die u.a. OSMI auch bietet. Dies könnte man sicher noch dahingehend weiterentwickeln, zu einer Straße gehörende Adressen zu gruppieren und neben Lücken auch verdächtige Reihenfolgen (100, 102, 436, 104, …) zu finden.

Auch der housenumbervalidator kann schon Adressen vergleichen (-> Duplikatprüfung). Zusammen mit dem öffentlich verfügbaren Code bietet dieser neben OSMI wahrscheinlich noch die besten Voraussetzungen, eine Lückensuche aufzunehmen - wenn sich eine solche überhaupt sinnvoll realisieren läßt.

So sehe ich das auch.
Allerdings ist der Adress-View zur Zeit leider nicht voll funktionsfähig (leere Layer-Anzeige). Das tritt auch bei anderen Views (z.B. Water-View auf). Und von den drei Public Transport Views funktionieren zwei überhaupt nicht (Server Error).

PS: Im zweiten Beispiel scheinen einige falsche Straßen-Zuordnungen zu existieren.
(oben links, vermutlich falsch kopiertes addr:street)

Edbert (EvanE)

Wie wäre der Ansatz, wenn die App durch einen Online-Dienst unterstützt wird. Dieser würde dann alle Adressdaten für eine Strasse ermitteln, die Hausnummern daraus extrahieren und die Daten oder das Hausnummern-Delta an die App übergeben. Insgesamt ist der Ansatz aber um einiges aufwändiger …

Gruß Klaus

Ansich finde ich persönlich die Idee gar nicht mal schlecht. Aber ich würde es nicht begrüßen, wenn überall in der DB Nodes mit “vermuteten” Adressen wären.
Bei einer “externen” Datenbank könnte ich mir auch gut ein Web-Interface vorstellen, wo man direkt angeben kann z.B. “Hausnr. 8 gibt es in der xy-Straße nicht” bzw. “Hausnr. 56 c fehlt noch im YZweg”

Aber moment gab es nicht mal ein “Spiel” (ich glaube es war von skobbler) wo man fehlende Adressen aufsuchen musste? Ich meine es hieß “Addresshunter” oder so. Weiß jemand was daraus geworden ist? Wäre sowas nicht auch ne Möglichkeit?

Wir haben jetzt folgenden Ansatz gewählt, der, wenn Erfahrungen vorliegen, gerne verfeinert werden kann:
Mit der OVERPASS API (einen Dank an die Entwickler und Betreiber dieses coolen Tools!) lesen wir online die vorhandenen Hausnummern aus der aktuellen OSM Datenbank aus.
Daraus berechnen wir dann alle fehlenden Hausnummern pro Strasse in der Umgebung des Android Telefons indem wir nachschauen, welche Ganzzahlen zwischen der 1 und der größten gefundenen Nummer fehlen.
Zusätzlich suchen wir nach einigen Besonderheiten: gibt es z.B. die 13ii, dann wird 13i als fehlend gemeldet wenn nicht vorhanden.

Erkennt man vor Ort, dass eine Hausnummer tatsächlich fehlt, kann sie mit dem Keypad-Mapper 3 entsprechend gekennzeichnet werden. In der für September 2013 geplanten Version werden die tatsächlich nicht vorhandenen Hausnummern erstmal in einer Datenbank auf dem Handy gespeichert.
Die für Weihnachten 2013 geplante Version wird dann die Möglichkeit bieten, die tatsächlich nicht vorhandenen Hausnummern an einen Server zu schicken, so dass andere Mapper diese Information ebenfalls zur Verfügung haben. Das gilt auch für die ab September erfassten Infos.
Aktuell beobachten wir zusätzlich, wie sich die Bereitstellung von Hausnummernlisten durch Gemeinden weiterentwickelt. Vielleicht lohnt es sich ja demnächst, den Keypad-Mapper 3 dahingehend zu erweitern, dass er solche Listen einlesen und in OSM vorhandene Daten damit abgleichen kann.

Wenn jemand Lust hat, für den Keypad-Mapper 3 diese oder andere nützliche Routinen als Android Library zu entwickeln dann binden wir diese gerne in das Programm mit ein.

Wollt ihr nicht etwas bauen, was den OpenData Gedanken weiterführt und extrem nützlich sein könnte?

Am Beispiel Köln könntet ihr eine Datenbank betreiben, die vorhandene Straßen mit Hausnummern als OpenData sammelt und damit direkt in Keypad-Mapper verglichen werden kann.

Das könnte ein Anreiz bieten, andere Städte / Gemeinden zu überreden, ebenso ihre Daten als OpenData freizugeben.

Dann noch eine schöne Heatmap, die Bereiche mit vielen fehlenden Hausnummern…

Die Heatmap-Idee ist gut. Mal sehen, was die Entwickler dazu sagen…

Köln - OpenData:
genau das ist der Plan, jedenfalls dann, wenn weitere Datenspenden dazukommen. Für Köln alleine ist das zu aufwändig.
Wo gibt es denn aktuell die meisten Adresslisten, die man als für das Auffinden fehlender Hausnummern verwenden könnte?