AustriaAdressHelper in der Praxis

Hallo JM82, ich gehe davon aus, dass das BEV ihre Geokoordinaten, uns nicht ganz selbstlos zur Verfügung stellt.
Man kann aus OSM Koordinaten und BEV Daten, nämlich sehr professionelle Korrekturlisten erzeugen.
Ist dir schon mal aufgefallen, dass beim Helper Popup jeweils die Abweichung in Meter angezeigt wird.

Ich gehe davon aus, dass professionisten in einigen Jahren solche Korrekturlisten abarbeiten, und unsere in OSM heute eingepflegten Koordinaten daher künftig teils als Grundlage für geprüfte amtliche Daten herangezogen werden.

Die von uns anzustrebende Arbeitsweise ist immer noch der Lokalaugenschein, ich gehe davon aus dass sobald OSM in Adresse relevant ist, auch die Rückmeldung seitens der Bürger und Firmen signifikant zunehmen wird.

Und das ist genau das woran ich in den letzten Monaten so hart arbeite. Wir müssen diesen disruptiven Punkt meistern.

OSM darf nicht wie derzeit nur als Karten Tile, am Server von Mapxxx enden, OSM muss zum überleben auch in Adresse relevant werden.
Aber leider ist hierzu der aktuelle Gegenwind gewaltig, alte Platzhirsche wissen ihren Adress- Pfrund zu verteidigen. Von den Tile Verwertern ist auch keine Unterstützung zu erwarten. Diese leben lieber mit den alten Adress- Hirschen in Harmonie.

Grüße Johann

Ja, nur dann muss auch mal die Adresssuche in OSM einwandfrei funktionieren. Stichwort: addr:place Tag in ländlichen Gebieten.:rolleyes:

Wie aber auch dein Hintergrund (basemap) zeigt, sind die Hausnummern nicht auf den jeweiligen Häuser zu finden. Das sind allesamt amtliche Daten, auf welchen diese Karten basieren. Ergo ziehe ich den Schluss - und frage mich zugleich: wie willst du präziser sein, als die amtlichen Daten, wenn du selbst keinen Lokalaugenschein vorgenommen hast? Das wäre gewissermaßen päpstlicher als der Papst selbst. :wink:

Das ist der Hauptaspekt meines Posts gewesen. Weil, dass die Gemeinden in der Zuordnung selbst einen Haufen Fehler machen, ist uns allen mittlerweile bekannt. Ergo stellt sich für mich die plausible Frage, wie du mit “Korrekturlisten” arbeiten willst, wenn selbst die Gemeinden falsche Daten liefern bzw. gespeichert haben in deren eigener, amtlicher Karte?
Vor allem, sind diese Fehler keinesfalls homogen: sie stehen nicht immer 10/50/100m vom eigentlichen Gebäude entfernt, sondern irgendwie. Und wenn mehrere Gebäude rund um eine Hausnummer stehen, kann jedes dieses die Hausnummer tragen.

Ich möchte nicht deinen Tatendrang bei der Hausnummernzuordnung “bremsen”, vielmehr nur auf die Problematik hinweisen, die dadurch entsteht, wenn offensichtlich falsche Hausnummern zu Gebäuden in der guten Hoffnung dazugespielt werden, dass es richtig ist. Es entsteht schlichtweg eine “Pseudogenauigkeit”, die zwar die Statistik befriedigt, aber nicht mehr. Fehlerhaft zugeordnete Adresen wird man wohl nie mehr wieder korrigieren (können), da bei tausenden und millionen Adressen der Aufwand exorbitant ist, das zu bewerkstelligen.
Daher: aus meiner Sicht - so man keinen Lokalaugenschein durchführen kann - besteht in diesen Fällen nur die Möglichkeit, all diese fragwürdigen Adressen zu markieren/sammeln und dann in weiterer Folge der jeweiligen Gemeinde vorzulegen. Das habe ich ja in meiner Region gemacht mit dem doch beachtenswerten Ergebnis, dass von Hunderten Adressen dieser Art gerade mal ein paar duzend übrig geblieben sind. Bei rund 60.000-70.000 Adressen sind ein paar Duzend gewiss vertretbar - beträgt doch dann die Vollständigkeit mehr als 99,9%.
Ich kann leider hier keine Attachments anhängen, sonst würde ich gerne posten, wie so eine Liste aussieht. (zur besseren Verständlichkeit)

Ich muss hier mal die Gemeinden in Schutz nehmen, diese verorten die Adresse zu einem Zeitpunkt, an dem das Gebäude noch gar nicht existiert.

Dass das wiki Prinzip funktioniert, beweist uns Google.
Google ist ein für Unternehmer relevantes System. Daher ist wohl der erste Klick eines Unternehmers, sicherzustellen, dass der Google Eintrag korrekt ist.
OSM ist über aktuell riesige Adresslücken, z.b. im Bundesland Salzburg, derzeit schlechtweg irrelevant. Mainstream ist daher für viele allein Google, fragmentierte Länder Portal- Gis Systeme, wie Sagis, der Stadtplan Wien, oder Tiris und andere spielen da nur eine Nebenrolle.

Die alten LokalGis Adresshirsche, arbeiten seltsamerweise verbissen gegen ein erstarken von OpenStreetMap, dabei erkennen sie nicht, dass Sie längst gegen Google und Co. verloren haben, und nur in Zusammenarbeit aller Länder Gis Systeme in einer zentralen amtlichen Instanz genug Schlagkraft als amtliches Register solches noch ändern könnte.

Ich habe aus gut informierter Quelle erfahren, unser BEV arbeitet aktuell an einer zentralen Adress- Webseite also einer basemap für Adressen.
Und genau das unterstütze ich sehr gerne. bzw. basemap- Adresse und OSM werden sich sehr gut miteinander vertragen.

Ich sehe daher die Zukunft in einer:

  • Österreich Ebene, geprüfter umfassender amtlicher Geo Informationen. Speziell der gesamte Blaulichtsektor ist auf solches angewiesen.

  • In einem amtlichen Server für betriebliche Informationen, der sich Live aus dem Gewerberegister speist.

  • In einem barrierefreien OpenSource Geo System, mit besonderer Aktualität.

Genannt: BaseMap.at & OpenStreetMap

Grüsse Johann

edit: Text

Ich habe heute in einer Salzburger Gemeinde begonnen Fehler zu beseitigen, wobei mir ein Unterschied der Positionen aufgefallen ist, die regio-osm und der Address Helper liefern:

Der Grund dürfte darin liegen:

http://www.bev.gv.at/pls/portal/docs/PAGE/BEV_PORTAL_CONTENT_ALLGEMEIN/0200_PRODUKTE/SCHNITTSTELLENBESCHREIBUNGEN/BEV_S_AD_ADRESSE_RELATIONALE_TABELLEN-STICHTAGSDATEN-CSV_V1.3.PDF

Der Address Helper verwendet die aktuellsten Daten und setzt die Adresse Zirmkogelstraße 44 zur Einfahrt, wodurch die Einfahrt vom noch nicht gebauten/sichtbaren Haus Hochkogelstraße 24 näher beim gesuchten Punkt liegt.
regio-osm verwendet anscheinend Stand 12.10.2016, wo die Zirmkogelstraße 44 noch mittig am Gebäude gelegen ist.

Ich habe mir jetzt nochmal die BEV-Daten angesehen. Die Adresse liegt, oder soll jetzt wie gesagt auf der Zugangskoordinate liegen. Zusätzlich gibt es noch alle Gebäude zu einer Adresse mit ihren Positionen. Idealerweise sollte der Address Helper wohl bei beiden suchen:

Wenn dem so ist, so ist das Address Helper Plugin für OSM Zwecke bald annähernd unbrauchbar.

Ich stelle also bereits drei Baustellen fest:

  • Eine zweite Tastenkombination die einen Adress Node setzt fehlt
  • Der Plugin Bezug auf die Gebäude Koordinaten oder Zugang Koordinaten, müsste visualisiert und möglichst vor einstellbar sein
  • Ein eigener Adress Node TAG für die Zugangs- Adresse fehlt.

Johann, willst Du hier provozieren? Das Plugin leistet tolle Dienste, in gewissen Gegenden sind eher die BEV-Daten unbrauchbar…

Optimierung des AustriaAdressHelper Arbeitsplatzes unter JOSM.

Dazu in JOSM folgenden TMS Layer eintragen

tms:https://maps{switch:1,2,3,4}.wien.gv.at/basemap/bmapoverlay/normal/google3857/{zoom}/{y}/{x}.png

(Hinweis stammt vom User Luzandro https://forum.openstreetmap.org/viewtopic.php?id=61922) diesen Layer hierbei als bmapoverlay benennen.

JOSM neu starten, den zu bearbeitenden Kartenbereich laden,
nun als

  1. Hintergrund bmapoverlay wählen
    als
  2. Hintergrund basemap.at Ortophoto, beim Ortophoto eventeuell die Deckkraft etwas reduzieren.

Ich arbeite grad all die Adressen ab in Gemeinden, welche auch in der aktuellen, 2017er BEV-Liste mitunter zweifelhafte Adressen haben (Pos. falsch usw.).
Wieder was dazu gelernt. Es gibt offenbar Hausnummern/Adressen, wo nie ein Haus gestanden ist und offenbar auch keines stehen wird. Das hat mir ein Gemeindebediensteter einer Gemeinde in der SO geschrieben. Wenn nämlich das Bauvorhaben bewilligt wurde, dennoch nicht gebaut worden ist.
Solche Arten von Adressen, derer es gewiss österreichweit hunderte wenn nicht gar tausende gibt, sind gleichsam Datenleichen und die Gefahr beim Adresshelper ist durchaus, dass der einem umliegenden Gebäude zu einer solchen Adresse diese zuweist.
Aber, nur wenn man mit der Gemeinde in Kontakt ist, kommt man dahinter, was wirklich los ist.
Und: viele Adressen sind vergeben, das Haus steht schon, aber unsere Luftbilder sind alt. Ergo kein Haus erkennbar (noch).

Adressen erfassen mittels Address- Nodes

Das Plugin Addr Helper benötigt als Adressträger oder Adresscontainer ein bereits bestehendes Objekt. (Node oder Polygon)

Es hat sich vielfach bewährt, Nodes als Adressträger zu nutzen. Solche kann man zum einfangen der BEV Adresse, vorläufig an den Zutrittspunkt zum Grundstück platzieren (BEV Verortungspunkt), und anschließend mit Adresse befüllt in jene Gebäudeecke ziehen, in deren Nähe, auch der Zufahrtsweg am Gebäude endet.

Ist später mittels Lokalaugenschein die Position des Gebäudeeinganges zweifelsfrei geklärt, kann man den Adress Node an dieser Stelle in das Gebäude Polygon einfügen, und mit entrance=yes komplettieren.

Das oftmals praktizierte Binden der Adress- Information, an das Gebäude Polygon ergibt eigentlich wenig Sinn, da hierdurch der Gebäude Zutrittspunkt völlig unklar wird. Das BEV setzt übrigens seine Adressen sogar an den Straßenrand Grundstück Zutrittspunkt.

Wir haben das in OSM nicht notwendig, da unsere Straßen und Wege in das Grundstück hineinführen, und dort erst in unmittelbarer Nähe zum Gebäude enden.

Zur vereinfachten Arbeitsweise welche das erstellen eines Adress Containers und das Befüllen mit der Adresse automatisiert erfolgt.
Verweise ich auf meinen Blog Beitrag: https://www.openstreetmap.org/user/wiki%20the%20map/diary/43339 Der Tipp müsste auch mit jeder anderen Skript fähigen Gaming Hardware funktionieren. Es gibt auch PC Software mittels derer man Funktionstasten mit Befehlssequenzen belegen kann.

Grüße Johann

Du gehst aber in deinen Ausführungen von sehr (hohen) “Idealannahmen” aus.

Nun, genau das mache ich, solange der Umstand der Adresse zweifelsfrei geklärt ist, genau nicht. Grade vor wenigen Minuten bekam ich von einer Gemeinde wieder mal eine Info, dass die Hausnummern im Bestand haben, wo weder Haus noch sonst was drauf steht. Diese Hausnummern werden bei “künftigen Bauvorhaben” neu vergeben, wodurch sich Position der Hausnummer gänzlich ändern wird. Dies bei Hausnummern, die mittels addr:place getaggt werden. Daher, wo besteht der Sinn, dass ich in OSM an der Pos. des BEV-Nodes einen OSM-Node mit der Adresse setze? Nur, dass der STatistik genüge getan ist und scheinbar eine “Pseudovollständigkeit” erreicht ist? Sonst kann ich keinen Sinn darin erkennen.

Genau letzteres ist praktisch nie der Fall - ausser Mapper zeichnen die ganzen Hauseinfahrten, was in den wenigsten Regionen in AT der Fall ist.
Auch wenn der Zutrittspunkt des Gebäudes dahingehend unklar verbleibt, wenn die Hausnummer am Gebäudepolygon geataggt ist, sehe ich deinen Ansatz zwar als interessant an, nur vervielfacht dieser den Mappingaufwand immens. Machbar vielleicht mit der 10-fach, aktiven Mapperzahl in AT, aber nicht in der dzt. Situation.
Denke ich nun, alleine im pol. Bezirk, wo ich mappe, etwa 60.000 Gebäude einen Lokalaugenschein abzustatten, nur im den Hauseingang zu eruieren - da brauche ich wohl gut 10-15 Jahre dafür…:stuck_out_tongue:
Bleiben wir da mal realistisch: eine Karte ist nun mal eine Abstraktion der Wirklichkeit und ich bin der Überzeugung, für 99,99% der Anwendungsfälle von OSM ist es derzeit ausreichend, wenn das Gebäude Polygon die Hausnummer trägt. Alleine dieser Umstand ist in weiten Gebieten in AT schon ein Wunschdenken, ist doch die Adressabdeckung in AT nach wie vor vielerorts dürftig.

Ich setze dort keine Adresse, sondern ich hole an der BEV Position lediglich die Adresse ab, anschließend verschiebe ich den mit der Adresse befüllten Node in das Gebäude.

Da bin ich genau Deiner Meinung, aber bedenke, das OSM Projekt ist noch sehr jung, Gebäude und Straßen laufen uns ja nicht davon, und wir benötigen in 10 Jahren auch noch etwas zu tun.

Genauso ist es, daher ist es aktuell wichtig um OSM relevant zu machen, möglichst viele Adressen zu erfassen.
Man nennt solches den Disruptiven Punkt erreichen. Haben wir diese Schwelle erreicht, dann mappt sich der Rest der Adressen von selbst.
Ab diesem Zeitpunkt benötigen wir dann eher wirksame Qualitätssicherung Werkzeuge.

Grüße Johann

Die genaue AddressHelper Vorgangsweise im Detail:

Fassen wir noch einmal zusammen.

Der uns vom BEV zur Verfügung gestellte Verortungspunkt von Adressen liegt nicht auf dem Gebäude, sondern am Grundstück- Zutrittpunkt.
Ich nenne daher diesen mal AddressHelper Punkt.

Wenn wir also mittels AddressHelper die Adresse holen, wird dies sofern sich das Gebäude in der Nähe des AddressHelper Punktes befindet funktionieren, nicht jedoch dann wenn sich das Gebäude weit im Grundstück befindet.

Wie holen wir nun die Adresse trotzdem ab.
Dazu benötigen wir am AddressHelper Punkt, zunächst ein provisorisches Objekt, nun mittels Addresshelper Tastenkombination strg shift + A die Adresse holen. Wurde diese erfolgreich geliefert, dann verschieben wir den Adresspunkt mit der Maus in den Gebäudeumriss.

Entweder wir lassen den AddressNode nun im Gebäude stehen, oder wir lösen den AddressNode mittels JOSM Funktion Geometrie ersetzen im Gebäudepolygon auf.

Hat alles geklappt, so ist nun das Gebäude Polygon Träger der Gebäudeadresse.

Grüße Johann

Unsere Werkzeugkiste füllt sich:

Die Kombination folgender Werkzeuge sollte die Problematik doppelt erfasster Adressen wesentlich verbessern.

[out:xml][timeout:25][bbox:{{bbox}}];
{{geocodeArea:Austria}}->.searchArea;
(
 node
  ["addr:housenumber"](area.searchArea)({{bbox}});
  way
  ["addr:housenumber"](area.searchArea)({{bbox}});
  relation
  ["addr:housenumber"](area.searchArea)({{bbox}});
);
(._;>;);
out meta;

Neue verbesserte OverPassTurbo Abfrage, zum prüfen ob möglicherweise doppelte Adressen vorliegen:

Mehrfacheinträge Hausnummern:
Berücksichtig addr:street
Berücksichtig addr:place
Polygone und Nodes
Prüft mehrfach eingetragenes Gewerbe

http://overpass-turbo.eu/s/yqI

// Abfrage doppelter Hausnummern. Nodes und Gebäudepolygone ohne Adressen mit Namen oder Gewerbe. (addr:Place und addr: street wird berücksichtigt). Bitte zur Vermeidung unnötiger Serverbelastung, jeweils einen Kartenausschnitt manuell festlegen, oder das Fenster nicht zu groß wählen.

[bbox:{{bbox}}];
nwr["addr:city"]["addr:housenumber"];
for(t["addr:city"] + " " + t["addr:street"] + " " + t["addr:place"]+ " " + t["shop"] + " " + t["addr:housenumber"] + " " + t["name"]+ " " + t["amenity"]+ " " + t["shop"])
{
  if (count(nodes) + count(ways) + count(relations) > 1)
  {
   (._;>;); out meta;/*fixed by auto repair*/
  }
};

Interessehalber, hab letzte Woche das erste mal ein paar allererste einfache Overpass anfragen ausprobiert:
Wenn ich das von dir bei Overpass einfüge und ausführe, kommen eigentlich nur Scriptfehler. Da ich davon ausgehe, dass ich da was falsch mache - wie geht denn das?
Code reinkopieren, ich lösch den letzten Part mit JOSM (weil ichs noch nicht benutze) und drücke dann auf ausführen. Dann kommen lauter Parse und Static Error.

Grüße

Im Moment ist folgende Zeile noch absolut notwendig:

```
{{data:overpass,server=http://dev.overpass-api.de/api_mmd/}}
```

Die Query läuft noch gegen einen Entwicklungsserver und erst wenn die nächste Version rauskommt, wird das auch auf dem produktiven Server laufen.

Update: 1.5. Ist nicht mehr notwendig, bitte den produktiven Server unter overpass-api.de verwenden.

Oh, danke, ich hatte das Kommentar davor auf die Zeile danach bezogen, dass die Zeile für den Export nach JOSM benötigt wird. Gesammtes Kommentar lesen hilft halt auch :smiley:
Funktioniert, soweit ich das sehen konnte, danke.

nop

Ja, ist leider nicht in der JOSM-Hilfe beschrieben. Auf der Seite untem im Screenshot gibt es einen weiteren Tabreiter für Overpass, dort kann man den Server eintragen als http://dev.overpass-api.de/api_mmd/ - zumindest vorübergehend.
Ist nicht mehr notwendig, bitte den Produktiv-Server unter overpass-api.de verwenden!

Wichtig: den Teil {{data:overpass … }} am Ende unbedingt weglassen, diese overpass turbo Erweiterung versteht JOSM nicht und versucht es an den Server zu schicken, was aber nicht wirklich sinnvoll ist.