OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#1 2018-07-26 18:12:58

Luzandro
Member
Registered: 2015-12-16
Posts: 174

BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Ich habe den BEV-Konverter noch ein wenig angepasst um das Ergebnis direkt als osm-Dateien zu bekommen. Ich weiß insbesondere unter Windows nicht genau, was zum Ausführen vorher installiert werden müsste, also habe ich die Dateien auch hier hochgeladen: https://my.sofortcloud.com/index.php/s/omEAU6sYShyaKlP

Wenn man die Dateien in JOSM öffnet, können diese Ebenen ganz bewusst NICHT direkt hochgeladen werden. Ihr müsst die Adressen, die euch interessieren, kopieren (bspw. per Lasso-Auswahl) und in eure Arbeitsebene einfügen (Ctrl+Alt+V fügt an der ursprünglichen Position wieder ein).

update:
die Ordner- bzw. Dateistruktur sieht nun so aus:
PLZ-Bereich / Gemeinde / Ort / Strasse_PLZ_Ort_(Gemeinde).osm
Wenn man sauber vorgeht, ist das völlig ironiefrei sogar ein großer Fortschritt. Sehr hilfreich ist auch der Shortcut "2" um auf den Bereich der Ebene zu zoomen.
Zum Öffnen mehrerer Dateien empfiehlt es sich diese per Drag&Drop in JOSM hinein zu ziehen

Es gab hier schon einige Diskussionen bzgl. Zugangskoordinate und Hauskoordinate. Grundsätzlich wird die Adresse wenn vorhanden auf die Hauskoordinate gelegt, wobei es noch ein paar Punkte zu beachten gibt. Es kann mehrere Gebäudepositionen zu einer Adresse geben - wenn diese eine Unteradresse besitzen, wird die als addr:unit angegeben (verwendet diesen Style um das auf der Karte zu sehen). Einige Gebäude besitzen eine "Gebäudebezeichnung", was ein beliebiger Beschreibungstext wie "Altbau", "Betrieb", "Lagerhalle", "Kindergarten", etc. sein kann. Ich habe diese als note übernommen, was auch durch das hochgestellte "N" am Node erkennbar ist - wenn möglich, hilfreich oder sinnvoll, übersetzt diese Notes in entsprechende OSM-Tags und löscht sie dann, aber bitte NICHT einfach so wie sie sind hochladen. Wenn es zu einer Adresse mehrere Nodes ohne Unteradressen gibt, die weniger wichtigen Nodes bspw. von der Lagerhalle löschen und die Adresse nur einmal auf dem "Hauptgebäude" belassen (update: Bei Adressen mit mehreren Gebäuden, die nur Gebäude ohne Subadresse haben wird jetzt nur noch die Zugangskoordinate ausgegeben.) -- wenn ihr JOSM > 13996 verwendet und die Warnung nicht deaktiviert habt, solltet ihr ansonsten sowieso eine Duplikatswarnung bekommen.
update: notes werden standardmäßig nicht mehr ausgegeben
rQ4DAMY.jpg

Es gäbe zu den Unteradressen auch noch einen Prefix zur Nummer wie "Obj.", "Stg.", "Haus", "/", etc. den ich nicht übernehme. Wie auch schon in diesem Thread thematisiert existieren allerdings auch ein paar Adressen, die sich nur dadurch unterscheiden. Auch hier sollte die Duplikatswarnung davor bewahren, dass man das übersieht. Um den Prefix in diesen Fällen dann doch wieder heraus zu bekommen, kann man bspw. geoland.at verwenden.
2BRIFId.jpg
Darüber wie Unteradressen angegeben werden sollen, existiert aktuell kein eindeutiger Konsens. Ich verwende (offensichtlich) addr:unit. Wenn es ein ganzes Gebäude betrifft mit der vollen Adresse, für mehrere Eingänge zu einem Gebäude vergebe ich dagegen mittlerweile nur mehr die Basisadresse auf das gesamte Gebäude und bei den einzelnen direkt am Gebäuderand liegenden Eingangs-Nodes nur mehr die Unit (die Auflösung der zugehörigen Gesamtadresse ist dabei trivial und auf der gerenderten Karte ist es deutlich übersichtlicher. Umgekehrt wäre es umständlicher, die redundante Information vor dem Rendern an den geeigneten Stellen wieder heraus zu filtern).

Zu einem Gebäude können auch mehrere Adressen existieren, allerdings kann nur eine davon als Hauptadresse für dieses Gebäude festgelegt werden. Die Hauptadresse wird daher bei mir auf die Hauskoordinate gelegt, die übrigen auf die entsprechenden Zugangskoordinaten. Auch dazu, wie mit Identadressen umgegangen werden soll, gab es schon Diskussionen ohne wirklichen Konsens, aber es sollte zumindest einmal erkennbar sein, was laut BEV die primäre Adresse sein sollte, wobei das auch manchmal fraglich ist, ob das überhaupt mit der Praxis übereinstimmt: die Hauptadressen auf dem folgenden Bsp.-Bild dürften auf die (größere) Vösendorferstraße 78 bzw. 80 lauten, obwohl die Garagenzufahrten und der Eingang dem Luftbild nach wohl in der Rigolettogasse liegen dürften.
mdFwWbi.png

update zur addr:city/place Logik
wenn Straßenname = Ortsnamen => addr:place=Ortsname
Das ist auch der einzige Fall, wo statt addr:street automatisch addr:place gesetzt wird!

addr:city wird jetzt durchgehend die Gemeinde zugewiesen. Wenn eine Straße in einer Gemeinde mehrfach vorkommt, wird bei den Adressen dieser Straßen zusätzlich ein addr:suburb mit dem Ort gesetzt. Ich finde das zwar auch noch nicht ganz optimal, aber überall möchte ich auch kein suburb setzen und es entspricht grob der Möglichkeit 2 aus dem Leitfaden der Post und ist konsistent

Wenn innerhalb eines Postleitzahl-Gebiets und einer Gemeinde eine Adresse zweimal vorkommt, ist neben die Postleitzahl nicht der Gemeindename, sondern der Bestimmungsort zu schreiben, der die Adresse eindeutig macht. Es gibt hier zwei korrekte Möglichkeiten der Adressierung:

Möglichkeit 1:
Die Ortschaft wird anstelle der Gemeinde
verwendet.

Möglichkeit 2:
Die Ortschaft wird als vorletzte Zeile geschrieben.

Skript welches in OSM schon vorhandene Einträge aus den Dateien filtert

Warum man nicht einfach stupid blind importieren sollte

Stichtagsdaten vom 1.10.2018 sind online

Vollständig: https://my.sofortcloud.com/index.php/s/1mVREyBx0dCZZ4q
Verschiedene reduzierte Datensätze, wie ohne identischen Einträgen vom letzten Stichtag, nur Adressen mit neuen IDs, oder nur neue Straßen: https://my.sofortcloud.com/index.php/s/vR5Yq9ojJGfvLW5
Liste mit geänderten Straßennamen: https://my.sofortcloud.com/index.php/s/EDLQNOCw7Fe9ef3

Bei den neuen Adressen/Straßen muss das nicht in jedem einzelnen Fall zwingend stimmen. Ich schaue da nur, ob die ID im letzten Datensatz noch nicht vorgekommen ist und tlw. tauchen da aus irgendeinem Grund auch alte Einträge mit neuer ID auf.

Scripts zur Auswertung gibts tlw. hier: https://github.com/Luzandro/osm-toolbox

edit 2018-10-13:
neue Stichtagsdaten
veraltete Information aktualisiert

Last edited by Luzandro (2018-10-24 11:50:55)

Offline

#2 2018-08-18 11:36:22

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 396

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Tolle Sache!!!

Offline

#3 2018-08-23 07:04:22

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 396

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

In den Daten sind oft auch Hausnamen enthalten z.B. "XXX-Hof" oder "YYY-Gut".

Ich raetsle was ich damit machen soll, nachdem ich den Sachverhalt oft nicht kenne, tendiere ich dazu den Hausnamen-Eintrag zu loeschen...

Hat jemand eine Meinung dazu?

Lg, Gppes

Offline

#4 2018-08-23 07:38:14

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Hast du ein Bsp. dafür?
Aber grundsätzlich: ohne Ortskenntnis nicht eintragen

Offline

#5 2018-08-25 13:05:51

addresshistory*org
Member
Registered: 2015-02-01
Posts: 1,114

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Gppes wrote:

In den Daten sind oft auch Hausnamen enthalten z.B. "XXX-Hof" oder "YYY-Gut".

Ich raetsle was ich damit machen soll, nachdem ich den Sachverhalt oft nicht kenne, tendiere ich dazu den Hausnamen-Eintrag zu loeschen...

Hat jemand eine Meinung dazu?

Lg, Gppes

Das JOSM Plugin austriaaddresshelper funktioniert offensichtlich wieder. Ich verwende hierbei weiterhin die auf Github zu findende https://github.com/JOSM/austriaaddresshelper/releases ältere Version des Plugins v0.5.1. Diese Version verzichtet noch auf eine integrierte Prüf Abfrage auf Duplikate, und ist daher wesentlich schneller.
Das finden von Duplikaten verlagere ich in einen weiteren Arbeitsgang. Eine gezielte Overpass-Turbo Abfrage nach Duplikat Adressen, bietet wesentlich bessere Flexibilität und Genauigkeit.

Vom User Luzandro bereitgestellten BEV Open Data Adressen (2018!) sind zu empfehlen, leider schlägt hierbei die in JOSM ebenfalls integrierte Fehlerwarnung, auf doppelte Adressen an, obwohl es sich per "note" angemerkt, hierbei um zum Beispiel wertvolle Information über Nebengebäude handelt. Ich klammere daher Adressen mit der Anmerkung "note" vom Prüf Vorgang aus. http://overpass-turbo.eu/s/Bma . (damit der overpass Server nicht übermäßig belastet wird, nur jeweils ein Overpass- Abfragefenster beschränkter Größe aufziehen)

Diese Prüf Abfrage kann man gegebenenfalls direkt in JOSM ausführen, das vereinfacht das Suchen und Finden von Duplikaten wesentlich.


BEV Adressen:https://tinyurl.com/ybculf7r AT-Geografen-OSM-Talk: http://talk.hxg.at Aktuelle Neuigkeiten zu OpenStreetMap auf Twitter: https://twitter.com/hashtag/OpenStreetMap

Offline

#6 2018-08-25 23:25:36

addresshistory*org
Member
Registered: 2015-02-01
Posts: 1,114

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Ich möchte anmerken dass im BEV- Adress-Satz von Luzandro, im Datenfeld addr:city die jeweilige Ortschaft steht.
Im vom austriaaddresshelper gelieferten Datensatz hingegen im Datenfeld addr:city der Name der Katastralgemeinde.

Google macht es so wie Luzandro, und leitet den Namen der Katastralgemeinde wohl nur aus der Gemeindegrenze ab.

Nach einigem experimentieren, bin ich in der Tiroler Katastralgemeinde Wildschönau auf folgendes, mittels OSM Nominatim funktionierende Baukastensystem gekommen:

addr:city=Wildschönau
addr:country=AT
addr:housenumber=20
addr:postcode=6311
addr:street=Dorf, Oberau
addr:suburb=Oberau
building=yes

addr:city=Wildschönau
addr:country=AT
addr:housenumber=83
addr:postcode=6313
addr:street=Dorf, Auffach
addr:suburb=Auffach

Eine OpenStreeetMap Adress- Abfrage, liefert so das selbe Ergebnis wie per Tiroler Tiris System.


BEV Adressen:https://tinyurl.com/ybculf7r AT-Geografen-OSM-Talk: http://talk.hxg.at Aktuelle Neuigkeiten zu OpenStreetMap auf Twitter: https://twitter.com/hashtag/OpenStreetMap

Offline

#7 2018-08-26 06:47:55

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

addresshistory*org wrote:

leider schlägt hierbei die in JOSM ebenfalls integrierte Fehlerwarnung, auf doppelte Adressen an, obwohl es sich per "note" angemerkt, hierbei um zum Beispiel wertvolle Information über Nebengebäude handelt.

Wie gesagt sollen die Notes auch nicht einfach direkt übernommen werden. Informationen wie "linkes/rechtes Gebäude" oder "Altbau/Neubau" sind für OSM uninteressant und verdienen keine "eigene" duplizierte Adresse. Ähnlich sieht es bei bestimmten Gebäudetypen wie "Lagerhalle" aus, die man nur, wenn man möchte, als spezifischere building Information übernehmen könnte. Interessant sind v.a. Informationen zu POIs, die noch nicht in den OSM-Daten sind, wie "Kindergarten" oder "Gasthaus", wobei man da auch noch kontrollieren sollte, ob das noch aktuell ist.

Die Wildschönauer Adressen schauen etwas eigenwillig aus, aber offenbar wird das so verwendet. Da könnte man zwar theoretisch auch automatisch erkennen, ob der Ortsname schon beim Straßennamen angehängt ist und entsprechend city/suburb setzen, aber ich glaube es ist besser wenn solche Sonderfälle im Einzelfall von Personen mit Ortskenntnis entschieden werden.

Offline

#8 2018-08-26 08:00:32

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 396

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Luzandro wrote:

Hast du ein Bsp. dafür?
Aber grundsätzlich: ohne Ortskenntnis nicht eintragen

Ich habe jetzt mal ein XML (PLZ 8770) mit dem Browser aufgemacht und nach "addr:housename" gesucht. Da hat man fast schon den Eindruck, dass es eher die Regel ist, dass da was drinnen steht... ;-) :

<node id="-2260288" lat="47.337258" lon="15.020231"><tag k="addr:country" v="AT"/>
<tag k="at_bev:addr_date" v="2018-04-02"/><tag k="addr:postcode" v="8770"/>
<tag k="addr:street" v="Sattlergasse"/><tag k="addr:city" v="Sankt Michael in Obersteiermark"/>
<tag k="addr:housenumber" v="2"/>
<tag k="addr:housename" v="Zimmermannkeusche"/></node>

<node id="-2260289" lat="47.337126" lon="15.021776"><tag k="addr:country" v="AT"/>
<tag k="at_bev:addr_date" v="2018-04-02"/><tag k="addr:postcode" v="8770"/>
<tag k="addr:street" v="Schulgasse"/><tag k="addr:city" v="Sankt Michael in Obersteiermark"/>
<tag k="addr:housenumber" v="1a"/>
<tag k="addr:housename" v="S C H U L H A U S"/></node>

<node id="-2260290" lat="47.337024" lon="15.021988"><tag k="addr:country" v="AT"/>
<tag k="at_bev:addr_date" v="2018-04-02"/><tag k="addr:postcode" v="8770"/>
<tag k="addr:street" v="Schulgasse"/><tag k="addr:city" v="Sankt Michael in Obersteiermark"/>
<tag k="addr:housenumber" v="1"/>
<tag k="note" v="Volksschule"/></node>

Offline

#9 2018-08-26 08:17:39

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Das ist das, was in den BEV-Daten als "Hofname" angegeben ist. Siehe Schnittstellenbeschreibung:

Der Hofname ist eine ortsübliche Bezeichnung für einzelne Gebäude oder Gebäudekomplexe wie zB. Bauerngehöfte. Wird landläufig auch als Vulgoname bezeichnet.

addr:housename ist da mMn. falsch, wenn es eine richtige Adresse gibt (ich hab noch nicht geschaut, ob es überhaupt Fälle gibt, die NUR einen Hofnamen haben). Tlw. könnte man es als "name" übernehmen, aber nicht wenn so etwas wie "S C H U L H A U S" angegeben ist.

edit: es gibt 348 ohne Adresse, aber auch da ist es oft nur _irgendein_ Beschreibungstext wie "Wasserbehälter", "Trafosation" oder "Beachvolleballplatz" (sic)
Wäre wohl auch besser kombiniert mit der Gebäudebezeichnung als "note" aufgehoben

Last edited by Luzandro (2018-08-26 08:53:35)

Offline

#10 2018-08-26 18:54:36

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Ich hab jetzt erst einmal den Hofnamen auch zu note hinzugefügt

Offline

#11 2018-08-27 18:44:12

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Um einen besseren Überblick zu bekommen, was in diesen Feldern gespeichert ist, habe ich jetzt noch alle existierenden Werte für Hofnamen und Gebäudebezeichnungen sortiert nach Häufigkeit ausgegeben und ebenfalls online gestellt. Die Hofnamen beziehen sich dabei auf die gesamte Adresse, die Gebäudezeichnungen auf einzelne Gebäude. Mit den gestern aktualisierten Daten wird jetzt beides zusammen als note ausgegeben und nichts mehr unter addr:housename. Bitte die neuen Daten herunterladen und die mit addr:housename nicht mehr verwenden - in praktisch allen Fällen ist das mal mehr oder mal etwas weniger falsch als housename.

Offline

#12 2018-08-27 20:03:13

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 396

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Luzandro wrote:

Um einen besseren Überblick zu bekommen, was in diesen Feldern gespeichert ist, habe ich jetzt noch alle existierenden Werte für [...]  sortiert nach Häufigkeit ausgegeben und ebenfalls online gestellt. [... ]Bitte die neuen Daten herunterladen und die mit addr:housename nicht mehr verwenden[...]

Danke, ist Dein Skript auf github jetzt auch auf dem gleichen Stand? Ich bin darauf umgestiegen...

Offline

#13 2018-08-27 20:35:33

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Ja natürlich

Offline

#14 2018-08-30 18:15:36

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Ich habe mich entschieden den Output noch feiner aufzugliedern und nicht nur für jede PLZ ein eigenes File anzulegen, sondern für jede Ortschaft+PLZ.

Nachdem mir diese Changeset-Diskussion mit einer falschen Zuweisung für addr:city aufgefallen ist, habe ich Leoben zu den Ausnahmen aufgenommen. Die neuen Dateinamen richten sich nach dem Input, also dem Ortsnamen in den BEV-Daten, in diesem Fall "8700 Göß.osm" - Göß wird dort allerdings nur noch als suburb gesetzt und addr:city ist die Gemeinde Leoben (wie auch für die anderen "Ortschaften" der Gemeinde).

Es gilt weiterhin:

Luzandro wrote:

Bitte etwas darauf achten, ob diese Zuweisungen im konkreten Fall auch passen (insbesondere bei Städten).

Offline

#15 2018-08-30 20:24:36

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 396

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Wuerde es Dich stoeren, als Trenner Zwischen PLZ und Ortschaft einen Unterstrich und kein Space zu verwenden? ;-)

Offline

#16 2018-08-31 05:44:29

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Script ist geändert, Dateien werde ich später hochladen. In den Ortsnamen war sowieso schon vorher (u.a.) kein Space erlaubt und jetzt sind auch noch alle nur klein geschrieben, denn zumindest in einem Fall gab es eine unterschiedliche Groß-/Kleinschreibung für den Ortsnamen, was für Filenamen auch nicht so ideal ist

Offline

#17 2018-08-31 11:54:47

addresshistory*org
Member
Registered: 2015-02-01
Posts: 1,114

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Wie man auf https://regio-osm.de/hausnummerauswertu … misch.html sieht, werden Regionen ab einem Adress-Abdeckungsgrad von ca 80% als vollständig gemappt angesehen.
Das bisherige Jahr war zumindest für mich ein Jahr des Lernens. Die uns zur Verfügung stehenden Werkzeuge sind zuletzt immer besser geworden. Besonders hervorzuheben sei hier das JOSM Plugin austriaaddresshelper, und besonders die von Luzandro aufbereiteten BEV Adressen.
Immer wieder werden Importe kritisch hinterfragt. Wir sollten uns aber nun aufgrund neuer mächtiger Werkzeuge -Luzandro sei erwähnt- eine Zielvorgabe setzten, bis zu welchem Zeitpunkt wir der Öffentlichkeit Österreich als flächendeckend mit wenigstens 80% gemappt präsentieren können.
Erst ab diesem Zeitpunkt dürfen wir über weitere Qualitätsvorgaben diskutieren.
Vielfach wird davon gesprochen dass die wertvolle Arbeit der vorort Mapper zu achten ist. Vorort Mapper arbeiten niemals mit Adress-Nodes sondern zu 99% mit Gebäude Polygonen. Selbst wenn wir also die Adresse vom Gebäude auf einen Adress- Node übertragen, bleibt hierbei immer die wertvolle Arbeit der Vorort Mapper in der Gebäude Historie erhalten, und so auch diese Information weiterhin erhalten.

User gemeinsames Ziel:
Österreich bis zum 31. 12 2018 in Adresse als vollständig gemappt zu präsentieren.


BEV Adressen:https://tinyurl.com/ybculf7r AT-Geografen-OSM-Talk: http://talk.hxg.at Aktuelle Neuigkeiten zu OpenStreetMap auf Twitter: https://twitter.com/hashtag/OpenStreetMap

Offline

#18 2018-08-31 12:31:36

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Von schnell schnell möglichst viel halte ich überhaupt nichts. Mein Ansatzpunkt ist verschiedene Werkzeuge zur Verfügung zu stellen, die häufige Fehlerquellen reduzieren. Mittlerweile bin ich der Ansicht, dass auch das Aufbereiten der Daten in dieser Form mehr Nutzen als Schaden darstellt. Man kann die Büchse der Pandora sowieso nicht mehr schließen, auch per regio-osm waren sie schon weniger aktuell/detailiert als .osm-File verfügbar und basemap abzeichen oder AddressHelper haben auch schon zu großflächigen Fehlern geführt also kann man sowieso nur versuchen die User in richtige Bahnen zu lenken.

Ich möchte den Thread jetzt allerdings nicht in eine Grundsatzdiskussion zum Adressmapping abgleiten lassen, also bitte bei Themen bleiben, die sich auf diesen Datensatz beziehen.

Offline

#19 2018-08-31 13:01:46

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 396

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

addresshistory*org wrote:

[...]
User gemeinsames Ziel:
Österreich bis zum 31. 12 2018 in Adresse als vollständig gemappt zu präsentieren.

Wie ich schon auf der Mailingliste geschrieben habe: Wir (speziell Du) sollten uns am Projekt OSM nicht verheizen und auch die Geduld der Kollegen nicht ueberstrapazieren.

Zwischendurch mal ein ausgedehnter Survey (Spaziergang) der die eine oder andere Parkbank mit schoener Aussicht oder andere Kleinode in die Datenbank bringt haben auch viel Wert.

Du solltest Dich dort zu den Vorwuerfen auf der Mailingliste aeussern und Deine Plaene offenbaren, sonst riskierst Du - zu Recht - eine Sperre. Derzeit hast Du dort ohnehin die Mehrheit hinter Dir.

Aus meiner Sicht basiert OSM auf drei Saeulen:
o Der computerbasierten Arbeit Daten zu erfassen
o Dem Survey (Naturgenuss)
o Der Kontakt mit der Community

Nimm Dir das zu Herzen!

Lg, Gppes

Offline

#20 2018-08-31 23:14:40

addresshistory*org
Member
Registered: 2015-02-01
Posts: 1,114

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Thema OpenStreetMap Adresserfassung Österreich, Ziel 80% bis 31. Dezember 2018

Fortsetzung unter: https://forum.openstreetmap.org/viewtop … 53#p713453

Last edited by addresshistory*org (2018-08-31 23:20:19)


BEV Adressen:https://tinyurl.com/ybculf7r AT-Geografen-OSM-Talk: http://talk.hxg.at Aktuelle Neuigkeiten zu OpenStreetMap auf Twitter: https://twitter.com/hashtag/OpenStreetMap

Offline

#21 2018-09-02 08:38:35

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Das Script akzeptiert jetzt tlw. unvollständige Input-Files, bspw. kann man STRASSE.csv durch eine Version ersetzen, die nur die Zeilen enthält, die sich im Vergleich zum letzten Stichtag unterscheiden und alle anderen Straßen werden ignoriert.

Die Änderungen sind nicht immer ganz offensichtlich und enthalten nicht nur neue Straßen, oder Straßen mit geändertem Namen. Zum einen kann sich einfach nur die zugewiesene Gemeinde geändert haben, oder auch nur ein Straßennamenzusatz, der vom Script ignoriert wird. Laut BEV kann dieser Zusatz zwar auch Bestandteil des Straßennamens sein, aber bspw. soll es hier die Wiener Straße (und noch andere, die über mehrere Ortsgrenzen gehen) mit dem Zusatz als Namensbestandteil "Traiskirchen" oder "Möllersdorf" geben, was mir neu wäre, dass das hier irgendwo so verwendet wird:
https://www.openstreetmap.org/way/34832 … 5/16.29476

Zu finden im Ordner diffs.

Offline

#22 2018-09-02 12:21:32

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

addresshistory*org wrote:

Das finden von Duplikaten verlagere ich in einen weiteren Arbeitsgang. Eine gezielte Overpass-Turbo Abfrage nach Duplikat Adressen, bietet wesentlich bessere Flexibilität und Genauigkeit.

Vom User Luzandro bereitgestellten BEV Open Data Adressen (2018!) sind zu empfehlen, leider schlägt hierbei die in JOSM ebenfalls integrierte Fehlerwarnung, auf doppelte Adressen an, obwohl es sich per "note" angemerkt, hierbei um zum Beispiel wertvolle Information über Nebengebäude handelt. Ich klammere daher Adressen mit der Anmerkung "note" vom Prüf Vorgang aus.

Ich wäre dir wirklich sehr dankbar, wenn du die Duplikatsprüfung nicht deaktivierst und auch nicht weiterhin trotz wiederholtem Hinweis "wertvolle Informationen" wie "Wohnhaus" einfach so wie sie sind hineindumpst

edit:
In dem Fall gibt es überhaupt nur den einen Node, der relativ offensichtlich zu einem "Wohnhaus" gehört, aber du darfst auch gerne building auf house ändern:
https://www.openstreetmap.org/node/5873542096

In dem Fall lässt du absichtlich 3 Nodes, was ich für völligen Schwachsinn halte:
https://www.openstreetmap.org/node/5873542085
Kein Router wird dir Note als Unterscheidungsmerkmal anzeigen - wenn du einen Betrieb zu dem "Betriebsgeb." kennst, kannst du ja einen entsprechenden POI mit der Adresse anlegen. Ansonsten kannst du building=commercial/warehouse setzen, wenn du diese Information nutzen möchtest, wobei du ja nicht einmal die beiden Gebäude getrennt, aber 2 Nodes für 2 Gebäude gesetzt hast. Die Adresse kann man einmal auf dem Wohngebäude oder der Einfahrt lassen, aber nicht so mit 3 Nodes, das ist einfach nur ein schneller Pfusch damit deine Malen nach Zahlen Karte eine andere Farbe bekommt und danach schaust du die Gegend nie wieder an und irgendjemand anders kann das dann aufräumen

Last edited by Luzandro (2018-09-02 13:09:59)

Offline

#23 2018-09-03 21:25:01

addresshistory*org
Member
Registered: 2015-02-01
Posts: 1,114

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Luzandro wrote:

In dem Fall lässt du absichtlich 3 Nodes, was ich für völligen Schwachsinn halte:
https://www.openstreetmap.org/node/5873542085
Kein Router wird dir Note als Unterscheidungsmerkmal anzeigen - wenn du einen Betrieb zu dem "Betriebsgeb." kennst, kannst du ja einen entsprechenden POI mit der Adresse anlegen. Ansonsten kannst du building=commercial/warehouse setzen, wenn du diese Information nutzen möchtest, wobei du ja nicht einmal die beiden Gebäude getrennt, aber 2 Nodes für 2 Gebäude gesetzt hast. Die Adresse kann man einmal auf dem Wohngebäude oder der Einfahrt lassen, aber nicht so mit 3 Nodes, das ist einfach nur ein schneller Pfusch damit deine Malen nach Zahlen Karte eine andere Farbe bekommt und danach schaust du die Gegend nie wieder an und irgendjemand anders kann das dann aufräumen

Hallo Luzandro,
es gibt noch andere Anwendungsarten als Routing. Bei Gehöften ist die Zusatzinformation Lagerhaus, Wohnhaus oder Austragshaus sehr wohl eine relevante Information.
Zum Argment Routing fällt mir noch auf, dass in den BEV Sätzen -ausgenommen Vorarlberg- eine Systematik festzustellen ist, dass die Adresse fast immer auf ein Nebengebäude verortet ist.

Ich lagere die Duplikatsprüfung auch deshalb in einen weiteren Arbeitsgang aus, da hierbei viel differenzierter geprüft werden kann. OverPassTurbo sei Dank. Überhaupt ist OpenStreetMap nach einer Adressergänzung noch keineswegs fertig gemappt. Da sind noch viele weitere Arbeitsschritte notwendig. Ich finde jeder Arbeitsschritt sollte aber möglichst vollständig in sich abgeschlossen sein. Wenn schon Adresse, dann unbedingt jeweils für das gesamte Gemeindegebiet vollständig. Darauf habe ich auch  http://hdyc.neis-one.org/?Negreheb in meinem Blog hingewiesen. https://www.openstreetmap.org/user/addr … mment42715

Übrigens, egal was Du aktuell sonst im Forum postest. Du bist definitiv jene Person in Österreich, der wir in letzter Zeit für viele konstruktive Werkzeuge zu Danken haben. Dem Meister der Werkzeuge Luzandro und dem BEV für deren hochwertigen Adressdaten ein klares Danke.

Edit. +Dank

Last edited by addresshistory*org (2018-09-03 22:36:39)


BEV Adressen:https://tinyurl.com/ybculf7r AT-Geografen-OSM-Talk: http://talk.hxg.at Aktuelle Neuigkeiten zu OpenStreetMap auf Twitter: https://twitter.com/hashtag/OpenStreetMap

Offline

#24 2018-09-08 07:44:05

Luzandro
Member
Registered: 2015-12-16
Posts: 174

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Noch zur Info was nicht verwendet wird: prinzipiell gäbe es zu Gebäuden auch noch ein Feld für die "Überwiegende Eigenschaft dieses Objektes" mit 9 Kategorien, die sich zwar relativ problemlos direkt in building tags übersetzen ließen, aber soweit ich das sehe sind da viel zu viele falsche Informationen drinnen, die auch niemand kontrollieren würde (abgesehen davon, dass es aktuell wohl sowieso kaum eine Auswirkung hat).
Ähnlich sieht es mit der Tabelle GEBAEUDE_FUNKTION aus, die einigen Objekten eine Funktion wie "Apotheke" zuweist. Ich habe mir mal eine Liste mit den Adressen ausgeben lassen, wo sich laut BEV eine Apotheke befinden soll, aber im Umkreis von 150 Metern keine in den OSM-Daten gefunden wird - das waren 157/647, aber 3/4 davon werden bei einem Recheck auf https://www.apotheker.or.at auch nicht gefunden, bzw. tlw. sind auch andere Apotheken so nah, dass dort schon dadurch gar keine sein dürfte.


Ich habe kurz überlegt, ob ich die Ausgabe für mehrfache Gebäude zu einer Adresse ohne Unteradressen irgendwie ändern soll, aber fürs erste sehe ich das als unnötigen Aufwand ohne Nutzen an. Unabsichtlich kann meiner Ansicht nach nicht viel passieren und gegen Absicht kann ich sowieso nichts machen. Was evtl. unabsichtlich durchrutschen könnte, sind unnötige Notes, wie das gelegentliche "Wohngebäude" auf dem einzigen Gebäude einer Adresse, das um nichts anders aussieht, als die ganzen anderen Wohngebäude drumherum in der Siedlung ohne Note. Das ist zwar auch ein wenig nervig, aber wenigstens richten sich notes nur an andere Mapper und zumindest Enduser sollten davon normalerweise nicht irritiert werden.

Das Wiki sagt zu mehreren Gebäuden zu einer Hausnummer:

Multiple buildings for one housenumber
This often happens in farms, factories or schools. In that case, it's possible to add a perimeter to the site which contains the addr tags and other general tags such as the name. This makes sure you have less redundancy in your data. If the buildings cannot be contained in a single perimeter (for example, school with two buildings a block apart), use a multipolygon relation or site relation.

Mir ist allerdings keine Relation bekannt, mit der man eine (oder mehrere) Zugangskoordinate(n) mit der dazugehörigen Fläche verknüpfen und somit Routing-/Render-Position beeinflussen könnte. Insbesondere bei sehr großen Flächen mit mehreren Adressen wäre es ja sinnvoll die einzelnen Adressen als Punkte anzulegen und mit der Fläche zu verknüpfen, wo die gemeinsamen Eigenschaften gespeichert sind, aber auch ohne Verknüpfung würde ich in dem Fall eben Nodes zur Einfahrt setzen.

Offline

#25 2018-09-08 11:48:35

addresshistory*org
Member
Registered: 2015-02-01
Posts: 1,114

Re: BEV-Adressen (incl. Subadressen) als .osm-Files (neue Daten 10/18)

Luzandro wrote:

Ich habe kurz überlegt, ob ich die Ausgabe für mehrfache Gebäude zu einer Adresse ohne Unteradressen irgendwie ändern soll, aber fürs erste sehe ich das als unnötigen Aufwand ohne Nutzen an. Unabsichtlich kann meiner Ansicht nach nicht viel passieren und gegen Absicht kann ich sowieso nichts machen. Was evtl. unabsichtlich durchrutschen könnte, sind unnötige Notes, wie das gelegentliche "Wohngebäude" auf dem einzigen Gebäude einer Adresse, das um nichts anders aussieht, als die ganzen anderen Wohngebäude drumherum in der Siedlung ohne Note. Das ist zwar auch ein wenig nervig, aber wenigstens richten sich notes nur an andere Mapper und zumindest Enduser sollten davon normalerweise nicht irritiert werden.

Hallo Luzandro, ich gehe inzwischen in meiner Arbeitsweise dazu über, den BEV Satz unverändert als gesamtes einzuspielen. Erst anschließend beginne ich -ohne Overpass- Filter- unter Einbeziehung aller OSM Daten mit der Bereinigung von Duplikaten.
Über den BEV Datums- TAG kann man aktuelle BEV Daten problemlos filtern. Beim zusammenfügen von Adressen aus früheren BEV Adresssätzen, löse ich hierbei jeweils den ältere BEV Datums- Merker auf. So wie ich das sehe sollten nach einem erfolgreichem Abgleich sämtliche älteren BEV Datums Merker in neueren Daten aufgelöst sein, bleiben ältere BEV Adressen übrig, so ist das ein Hinweis dass es diese Adressen nicht mehr gibt.

Vielleicht beschreibst auch Du eine Vorgangsweise im Abgleich nach Deinen Vorstellungen.
Grüße Johann

Edit: typo

Last edited by addresshistory*org (2018-09-08 11:52:05)


BEV Adressen:https://tinyurl.com/ybculf7r AT-Geografen-OSM-Talk: http://talk.hxg.at Aktuelle Neuigkeiten zu OpenStreetMap auf Twitter: https://twitter.com/hashtag/OpenStreetMap

Offline

Board footer

Powered by FluxBB