OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#51 2018-09-28 13:49:31

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Was uns wirklich fehlt ist eine funktionierende Vorgangsweise, wie man die von Dir aufbereiteten BEV Adressdaten mit bestehenden OSM Adressen abgleicht. In bislang adresslosen Regionen, ist manuelles Sichten zwar zeitaufwendig, aber irgendwie zumindest für eine engagierte  lokale OSM Community noch machbar. Bei einem künftigen BEV Adress- Release, wird dies schon wesentlich schwieriger.
Es gäbe zwar die Strategie einfach den jeweiligen BEV Satz zu priorisieren, und sämtliche alte OSM Adressen zu löschen. Und es anschließend so wie JM82 zu machen, Behörden mit Fehlerlisten zu konfrontieren. Die Hoffnung dass beim nächsten BEV Relais solche Korrekturen berücksichtig worden sind mag trügerisch sein.

Eine Strategie wäre Adressen als BEV geprüft zu kennzeichnen. Aktuell mache ich das so, dass ich sofern ich eine BEV Adresse verändere, den Referenz Eintrag zum BEV entferne. Das müsste sich dann aber auch auf die Verortung beziehen. Sobald wir eine BEV Adresse auch nur minimal anderst positionieren, müsste der Verweis auf die BEV Herkunft raus.

Also, Stainz macht´s vor, sämtliche alte OSM Adressen raus, aktuelle BEV Adressen rein. Sofern anschließend "Negrehebs" Leidenschaft neu Positionierung notwendig ist, BEV Verweis jeweils rausnehmen.
Beim nächsten BEV Release, sämtliche verbliebene Alt- BEV Adressen löschen, aktuelle BEV Adressen wieder rein, und anschließend auf Duplikate prüfen. Sofern eine BEV Adresse nun erneut nicht passt, fliegt dann diese raus.

Leider lässt die aktuelle Genauigkeit der BEV Verortung derart zu Wünschen übrig, dass nur wenige BEV Adressen diese Aktion überleben würden. So schaut´s aktuell mit der BEV Verortungs- Qualität aus.
Also nur ein Leider.


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

#52 2018-09-28 14:06:03

Negreheb
Member
From: Austria
Registered: 2015-11-10
Posts: 133

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

addresshistory*org wrote:

Eine Strategie wäre Adressen als BEV geprüft zu kennzeichnen. Aktuell mache ich das so, dass ich sofern ich eine BEV Adresse verändere, den Referenz Eintrag zum BEV entferne. Das müsste sich dann aber auch auf die Verortung beziehen. Sobald wir eine BEV Adresse auch nur minimal anderst positionieren, müsste der Verweis auf die BEV Herkunft raus.

So ein quatsch. Warum entfernst du den Referenzeintrag? Dazu unten mehr.

addresshistory*org wrote:

Also, Stainz macht´s vor, sämtliche alte OSM Adressen raus, aktuelle BEV Adressen rein. Sofern anschließend "Negrehebs" Leidenschaft neu Positionierung notwendig ist, BEV Verweis jeweils rausnehmen.
Beim nächsten BEV Release, sämtliche verbliebene Alt- BEV Adressen löschen, aktuelle BEV Adressen wieder rein, und anschließend auf Duplikate prüfen. Sofern eine BEV Adresse nun erneut nicht passt, fliegt dann diese raus.

Leider lässt die aktuelle Genauigkeit der BEV Verortung derart zu Wünschen übrig, dass nur wenige BEV Adressen diese Aktion überleben würden. So schaut´s aktuell mit der BEV Verortungs- Qualität aus.
Also nur ein Leider.

Wie, wer ist jetzt Stainz? Es gehören nicht alte Adressen gelöscht und dann die, mehr oder weniger, gleichen, wieder reingepackt. Das ist NICHT, wie bei OSM gearbeitet werden sollte. Und du brauchst meinen Usernamen nicht in Anführungszeichen setzen und eine Adresse gehört bei OSM nun mal aufs Gebäude und nicht daneben oder auf die Straße. Völlig egal, wo das BEV die verortet.
Und die BEV Info sagt aus, wo die Daten herkommen und das bleibt die BEV. Die Position hat damit nichts zu tun, da hast du leider mal wieder ein Verständnisproblem. Wenn die Lizenz, unter der wir die Daten verwenden dürfen, besagt, dass wir das BEV nennen müssen, hast du damit durchaus ein Lizenzproblem geschaffen, welches geklärt werden muss.

Und wie du sagst, nur weils vom BEV ist, sagt das noch lange nichts über die Qualität davon aus. Da gibts massig Probleme. Genau deswegen wäre ein "BEV geprüft" schwachsinnig. Da wäre noch eher ein "Vor Ort geprüft" sinnvoll.

Offline

#53 2018-09-28 15:50:05

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

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

Zum x-ten Mal: dein Löschen und Import drüberbügeln ist völliger Irrsinn und destruktiv.

Bzgl. Abgleich: ich habe ein Python-Script, das die in OSM vorhandenen Adressen aus einem .osm-File herausfiltern kann. Ursprünglich hatte ich überlegt das evtl. auch noch irgendwie in ein JOSM-Plugin zu übersetzen, aber daraus ist bisher nichts geworden. Ironischerweise hatte ich mir da auch noch Sorgen gemacht, dass die restlichen dann einfach völlig unkontrolliert importiert werden könnten, ich hatte nicht wirklich damit gerechnet, dass du stattdessen einfach alles vorhandene löscht.

Auch die Unterschiede zw. den Stichtagsdaten können wir auswerten, seien es jetzt die kompletten Diffs, oder nur geänderte/neue Straßen etc., denn es bringt sowieso nichts automatisch irgendwelche neuen Adresspositionen zu importieren, wenn dort dann niemand die entsprechenden Straßen, Places, Landuses, Gebäude, POIs, Beschränkungen etc. anlegt.

edit:

Also, Stainz macht´s vor, sämtliche alte OSM Adressen raus, aktuelle BEV Adressen rein.

Und abgesehen vom grundsätzlich schwachsinnigen Vorgehen - du lest schon, was ich dir im Post direkt davor geschrieben habe?

Last edited by Luzandro (2018-09-28 15:59:15)

Offline

#54 2018-09-28 18:36:56

JM82
Member
Registered: 2016-01-07
Posts: 321

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

addresshistory*org wrote:

Es gäbe zwar die Strategie einfach den jeweiligen BEV Satz zu priorisieren, und sämtliche alte OSM Adressen zu löschen. Und es anschließend so wie JM82 zu machen, Behörden mit Fehlerlisten zu konfrontieren. Die Hoffnung dass beim nächsten BEV Relais solche Korrekturen berücksichtig worden sind mag trügerisch sein.

Natürlich ändern sich die Koordinaten dann im BEV-Datensatz, mit dem wir hier alle arbeiten. Denn diese BEV-Daten basieren ja auf den Daten, die von den Gemeinden gepflegt werden. Ich habe so auf diesem Weg mehrere Hundert bis vielleicht 2000 Adressen in SO korrigieren, richtigstellen lassen und dann eben 1 Jahr später in OSM eingearbeitet, als eine Update vom BEV zur Verfügung gestellt wurde.
Meine Vorgehensweise damals war eben sehr "manuell lastig" - im Grunde jede Adresse auf Plausibilität mal zu prüfen. Wenn der BEV-Node offensichtlich ein Holler ist und war, kam er auf die "schwarze Liste", welche der jeweiligen Gemeinde zur Prüfung übermittelt worden ist.
Natürlich ist diese Vorgehensweise nicht zu 100% präzise, und es können immer noch Fehler bei den Hausnummern samt derer korrekter Verortung passiert sein. Ein Bsp. wäre nämlich, wenn ein Haus die No. 100 hat (und diese pickt auch auf dem Gebäude drauf), in der Realität/Natura hat es aber die No. 10. Auf solche Fehler kommt man mit meiner Methode natürlich nicht drauf, ausser man hat lokales Wissen und weiß in der Tat, dass es die No. 10 ist. Davon gehe ich aber in den seltensten Fällen aus - bei vielleicht 10 Mappern in AUT, die sich mit Adressen beschäftigen oder beschäftigt haben, kann man kein lokales Wissen erwarten.
Ich betone nochmals die Wichtigkeit, Behörden Fehler in den Adressen anzuzeigen. Denn, nur so werden alle auf Behördendaten basierende Adresszuordnungen a la longue besser; so auch OSM.
Die Variante mit den lokalen Mappern kann man ja praktisch vergessen, da sich zu wenig bis keine lokalen Mapper finden in AUT, die strittige Adressen verifizieren - ich selbst habe das in meiner Heimatgemeinde auch nur punktuell gemacht, meist bei Gebäuden, die mehrere Hausnummern haben.
100% fehlerfrei werden die Daten niemals sein - ich denke an das wird man sich gewöhnen müssen. Jedoch bin ich der Überzeugung, dass man auf etwa 95-98% Korrektheit über ganz AUT gesehen, hinkommen wird - über die Jahre hinweg. Das ist eben ein langfristiges Projekt. Das gute ist ja, dass die Adressen sich - so sie korrekt sind - nicht mehr nachträglich ändern. Der Waldweg 10 bleibt wohl bis in die heiligen Zeiten der Waldweg 10. Ausnahmen dürften auch das bestätigen.

@adresshistory*org: warum ergänzt du addr:suburb vielfach in den Adressen, wo es diese gar nicht gibt? Wie ich feststellen musste, hast du in der Südsteiermark vielfach den Namen der Katastralgemeinde dort reingepackt, obwohl dieser in der Adresse eines Gebäudes gar nicht vorkommt.

EDIT: Tippfehler und Eränzungen

Last edited by JM82 (2018-09-28 19:00:29)

Offline

#55 2018-09-28 19:06:38

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

JM82 wrote:

@adresshistory*org: warum ergänzt du addr:suburb vielfach in den Adressen, wo es diese gar nicht gibt? Wie ich feststellen musste, hast du in der Südsteiermark vielfach den Namen der Katastralgemeinde dort reingepackt, obwohl dieser in der Adresse eines Gebäudes gar nicht vorkommt.

Basierend auf meiner Erfahrung mit Katastralgemeinden, im speziellen mit der Gemeinde Wildschönau, ist das aktuell die einzig funktionierende Vorgangsweise.

Natürlich spielt bei Katastralgemeinden die übergeordnete Zentralgemeinde eine Rolle, deren korrekter Platz ist im Datenfeld addr:city


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

#56 2018-09-28 19:08:44

JM82
Member
Registered: 2016-01-07
Posts: 321

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

addresshistory*org wrote:
JM82 wrote:

@adresshistory*org: warum ergänzt du addr:suburb vielfach in den Adressen, wo es diese gar nicht gibt? Wie ich feststellen musste, hast du in der Südsteiermark vielfach den Namen der Katastralgemeinde dort reingepackt, obwohl dieser in der Adresse eines Gebäudes gar nicht vorkommt.

Basierend auf meiner Erfahrung mit Katastralgemeinden, im speziellen mit der Gemeinde Wildschönau, ist das aktuell die einzig funktionierende Vorgangsweise.

Natürlich spielt bei Katastralgemeinden die übergeordnete Zentralgemeinde eine Rolle, deren korrekter Platz ist im Datenfeld addr:city

Funktionierend in welcher Hinsicht? Die Adresssuche funktioniert via Nominatim ja auch ohne diesen Tag - die hat ja andere Probleme wir hinlänglich bekannt ist.

Offline

#57 2018-09-28 19:17:59

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Luzandro wrote:

Zum x-ten Mal: dein Löschen und Import drüberbügeln ist völliger Irrsinn und destruktiv.

Das mache ich doch nicht absichtlich, ich weis aber nun über welche Möglichkeiten Du verfügst.

Leider liegt vieles in OSM im Dunkeln: wer bist Du du schreibst öfters im Plural, wer ist Negreheb, wer ist auf Talk-at aktiv, wie weit können wir auf eine Unterstützung seitens das BEV zählen, warum bremsen einige User auf Talk, warum zeichnen in OSM professionelle User systematisch unscharfe Gebäudeumrisse, und wie stehen Tile Verwerter wie Mapbox und geofabrik zu diesem Handeln. Warum gibt es eine so geringe Beteiligung bei der Adressergänzung, wer patzt regelmäßig meine Arbeit bei der OSM Data Workling Group an.

Liebe Leute Rätsel über Rätsel.

Du machst offensichtlich gute Arbeit, ich habe aber das Gefühl diese ist nicht zu Ende gedacht. Wir benötigen dringend ergänzend zu Deinen BEV Adresssätzen einen funktionierenden Workflow. Leider habe ich den Eindruck, dass vier von fünf Pferden in unserem Gespann genau das mit aller zur Verfügung stehender Kraft zu verhindern versuchen.

Edit: +Gespann

Last edited by addresshistory*org (2018-09-28 19:50:02)


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

#58 2018-09-28 19:25:54

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Negreheb wrote:

Und wie du sagst, nur weils vom BEV ist, sagt das noch lange nichts über die Qualität davon aus. Da gibts massig Probleme. Genau deswegen wäre ein "BEV geprüft" schwachsinnig. Da wäre noch eher ein "Vor Ort geprüft" sinnvoll.

Eine interessante Frage:
Dürfen wir vom BEV stammende Daten, verändern, und trotztem "Daten stammen vom BEV" weiterhin drauf-schreiben.
In einem Notruf vertauen vielleicht einige OSM speziell wegen der BEV Referenz, wer haftet anschließend für unsere offensichtliche Fälschung?


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

#59 2018-09-28 19:34:02

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

JM82 wrote:
addresshistory*org wrote:
JM82 wrote:

@adresshistory*org: warum ergänzt du addr:suburb vielfach in den Adressen, wo es diese gar nicht gibt? Wie ich feststellen musste, hast du in der Südsteiermark vielfach den Namen der Katastralgemeinde dort reingepackt, obwohl dieser in der Adresse eines Gebäudes gar nicht vorkommt.

Basierend auf meiner Erfahrung mit Katastralgemeinden, im speziellen mit der Gemeinde Wildschönau, ist das aktuell die einzig funktionierende Vorgangsweise.

Natürlich spielt bei Katastralgemeinden die übergeordnete Zentralgemeinde eine Rolle, deren korrekter Platz ist im Datenfeld addr:city

Funktionierend in welcher Hinsicht? Die Adresssuche funktioniert via Nominatim ja auch ohne diesen Tag - die hat ja andere Probleme wir hinlänglich bekannt ist.

Noch einmal: OSM ist Redundant. Der Ortsname im Grenzpolygon sowie im Datenfeld addr:city muss daher gleichlautend sein.

Nun meine Frage, wo packst du die Katastralgemeinde rein. Ich kann mich mit der Katastralgemeinde im Datenfeld addr:city nur dann anfreunden, sofern du sämtlichen Katastralgemeinden auch jeweils ihr eigenes Grenz Polygon spendierst. Viel Spaß in der Steiermark bei manchmal 16 Katastralgemeinden je Gemeinde mit jeweils nur 5 Häusern.


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

#60 2018-09-28 20:16:38

JM82
Member
Registered: 2016-01-07
Posts: 321

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

addresshistory*org wrote:
JM82 wrote:
addresshistory*org wrote:

Basierend auf meiner Erfahrung mit Katastralgemeinden, im speziellen mit der Gemeinde Wildschönau, ist das aktuell die einzig funktionierende Vorgangsweise.

Natürlich spielt bei Katastralgemeinden die übergeordnete Zentralgemeinde eine Rolle, deren korrekter Platz ist im Datenfeld addr:city

Funktionierend in welcher Hinsicht? Die Adresssuche funktioniert via Nominatim ja auch ohne diesen Tag - die hat ja andere Probleme wir hinlänglich bekannt ist.

Noch einmal: OSM ist Redundant. Der Ortsname im Grenzpolygon sowie im Datenfeld addr:city muss daher gleichlautend sein.

Nun meine Frage, wo packst du die Katastralgemeinde rein. Ich kann mich mit der Katastralgemeinde im Datenfeld addr:city nur dann anfreunden, sofern du sämtlichen Katastralgemeinden auch jeweils ihr eigenes Grenz Polygon spendierst. Viel Spaß in der Steiermark bei manchmal 16 Katastralgemeinden je Gemeinde mit jeweils nur 5 Häusern.

Ich habe bisher bei keiner Adresse die Katastralgemeinde als addr:suburb eingetragen, da diese auch so nicht vorkommt.
Entweder, die Katastralgemeinde kommt als addr:place vor (der Klassiker in der Steiermark und wohl sonst auch in ländlichen Gebieten in AUT) und wird dort eingetragen. z.B. Mühldorf 5, 8081 Wildon. Damit ist addr:place = Mühldorf und add:city = Wildon. Soweit klar.

2. Variante ist, dass diese mit im Straßennamen steht, der als addr:street getaggt wird - das machen unsere burgenländischen Nachbarn seit einigen Jahren so - dort wird systematisch von Ortsnamen in der Adresse weggegangen hin zu Katastralgemeinde + Straßenname. Also z.b. addr:street = Welten, Hauptstraße 5, 8380 Jennersdorf. Damit ist addr:street = Welten, Hauptstraße und addr:city = Jennersdorf.
Ist eine Adresse z.b. Mühldorf 5 und Mühldorf ist eine Katastralgemeinde von Sankt Veit in der Steiermark, dann addr:place. Gibt es Mühldorf, Hauptstraße 5 > addr:street und die Straße davor heißt so.
Es hängt aber ganz klar vom BEV-Datensatz ab: in der Regel steht in Ländlichen Gebieten die Katastralgemeinde im Straßennamen und die Hausnummer extra. Das wäre meine 1. Variante oben.

Ich habe grad in der Gemeinde Sankt Veit in der Südsteiermark geschaut: dort hast du flächendeckend als suburb St. Veit am Vogau angegeben und dann als addr:street die jeweilige Straße. Die Adresse lautet aber: Schulstraße 9, 8423 Sankt Veit in der Südsteiermark. Der Zusatz St. Veit am Vogau ist irrelevant und auch nicht offiziell, da es in der Gemeinde Sankt Veit in der Südsteiermark nur eine Schulstraße 9 gibt. Ergo ist es eindeutig. Der Suburb Tag wäre zwar eine zusätzliche Information (schließlich könnte die Schulstraße 9 ja auch in einer anderen Katastralgemeinde liegen), ist aber für die Adresse per se belanglos.

Offline

#61 2018-09-28 20:31:39

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

JM82 wrote:
addresshistory*org wrote:
JM82 wrote:

Funktionierend in welcher Hinsicht? Die Adresssuche funktioniert via Nominatim ja auch ohne diesen Tag - die hat ja andere Probleme wir hinlänglich bekannt ist.

Noch einmal: OSM ist Redundant. Der Ortsname im Grenzpolygon sowie im Datenfeld addr:city muss daher gleichlautend sein.

Nun meine Frage, wo packst du die Katastralgemeinde rein. Ich kann mich mit der Katastralgemeinde im Datenfeld addr:city nur dann anfreunden, sofern du sämtlichen Katastralgemeinden auch jeweils ihr eigenes Grenz Polygon spendierst. Viel Spaß in der Steiermark bei manchmal 16 Katastralgemeinden je Gemeinde mit jeweils nur 5 Häusern.

Ich habe bisher bei keiner Adresse die Katastralgemeinde als addr:suburb eingetragen, da diese auch so nicht vorkommt.
Entweder, die Katastralgemeinde kommt als addr:place vor (der Klassiker in der Steiermark und wohl sonst auch in ländlichen Gebieten in AUT) und wird dort eingetragen. z.B. Mühldorf 5, 8081 Wildon. Damit ist addr:place = Mühldorf und add:city = Wildon. Soweit klar.

2. Variante ist, dass diese mit im Straßennamen steht, der als addr:street getaggt wird - das machen unsere burgenländischen Nachbarn seit einigen Jahren so - dort wird systematisch von Ortsnamen in der Adresse weggegangen hin zu Katastralgemeinde + Straßenname. Also z.b. addr:street = Welten, Hauptstraße 5, 8380 Jennersdorf. Damit ist addr:street = Welten, Hauptstraße und addr:city = Jennersdorf.
Ist eine Adresse z.b. Mühldorf 5 und Mühldorf ist eine Katastralgemeinde von Sankt Veit in der Steiermark, dann addr:place. Gibt es Mühldorf, Hauptstraße 5 > addr:street und die Straße davor heißt so.
Es hängt aber ganz klar vom BEV-Datensatz ab: in der Regel steht in Ländlichen Gebieten die Katastralgemeinde im Straßennamen und die Hausnummer extra. Das wäre meine 1. Variante oben.

Ich habe grad in der Gemeinde Sankt Veit in der Südsteiermark geschaut: dort hast du flächendeckend als suburb St. Veit am Vogau angegeben und dann als addr:street die jeweilige Straße. Die Adresse lautet aber: Schulstraße 9, 8423 Sankt Veit in der Südsteiermark. Der Zusatz St. Veit am Vogau ist irrelevant und auch nicht offiziell, da es in der Gemeinde Sankt Veit in der Südsteiermark nur eine Schulstraße 9 gibt. Ergo ist es eindeutig. Der Suburb Tag wäre zwar eine zusätzliche Information (schließlich könnte die Schulstraße 9 ja auch in einer anderen Katastralgemeinde liegen), ist aber für die Adresse per se belanglos.

Hallo JM82, Danke für die ausführliche Erklärung. So ist  das plausibel. Leider bildest sich das so nicht in Luzandros BEV Sätzen ab. Wir sind  dort im Feld addr:city vielfach mit der Katastralgemeinde konfrontiert. Damit ich dieses Datenfeld für den tatsächlichen Gemeindenamen frei bekomme, wandle ich addr:city daher in addr.suburb um, und erstelle ein neues addr:city für den tatsächlichen Gemeindenemn. Das Feld addr:suburb müsste nun weiter nach den von dir genannten Kriterien aufgeräumt werden. Ich frage mich aber warum solches nicht bereits in der Aufbereitung der BEV Adressen durch Luzandro erfolgt. Meine Variante ist daher lediglich eine Verlegenheitslösung, löst die Problematik nicht vollständig, aber immerhin besser als nichts.

In der Gemeinde Wildschönau bin ich mit dem Problem konfrontiert dass es mehrere Dorfstraßen gibt. addr:suburb aber in Nominatim nicht greift. Daher verwende ich dort ergänzend das Format addr:street = Straße, Katastralgemeinde das wird von Nominatim korrekt aufgelöst.

vielleicht könnte man Katastralgemeinden in OSM auch einen spezifischen Tag z.B addr:cadastral-subdivision spendieren.

Edit:+ Beispiel in Wildschönau Ref: https://www.openstreetmap.org/way/133306346

Last edited by addresshistory*org (2018-09-28 21:44:40)


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

#62 2018-09-30 08:22:22

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

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

addresshistory*org wrote:

Das mache ich doch nicht absichtlich

Wie ist das wieder zu verstehen? Das passiert dir so zufällig, du empfiehlst es zwar jetzt regelmäßig so zu machen, aber es ist nicht Absicht?

Das "wir" ist das gleiche, das du dauernd verwendest. Ich habe zumindest einmal angenommen, dass du nicht den Pluralis Majestatis meinst, sondern "wir als OSM-Community". Gänzlich sicher bin ich mir dabei allerdings auch nicht mehr, denn was bei all deinen Fragen leider immer noch fehlt, ist die eigene Vorgangsweise zu hinterfragen und ob das "regelmäßige Anpatzen" tatsächlich immer völlig unbegründet ist und die Probleme nur von allen anderen ausgehen.

Das Thema addr:city war von Anfang an etwas unbefriedigend, darum habe ich auch mehrfach darauf hingewiesen, man soll darauf achten, ob diese Zuweisung im konkreten Fall passt. Warum sollte es bei diesem Mapping überhaupt irgendwelche Unklarheiten geben? Bei größeren Katastralgemeinden ist es üblich, dass diese in der Anschrift an Stelle der Gemeinde aufscheint, das ist mMn. auch das, was unter addr:city stehen sollte und in etlichen Gemeinden würden ansonsten auch Adressen existieren, die nur mit Gemeinde und Straße nicht mehr eindeutig sind, wobei da die von JM82 angesprochenen noch gar nicht dabei sind, denn die Straße heißt dort tatsächlich "Welten, Hauptstraße" und somit sind in der Gemeinde Sankt Martin an der Raab damit auch alle Adressen eindeutig. In der Gemeinde Großebersdorf dagegen gibt es zB in allen 4 Katastralgemeinden eine Feldgasse.
Ob etwas eine Katastralgemeinde ist, weiß ich rein aus diesem Datensatz im Übrigen gar nicht, denn hier gibt es nur die Unterscheidung zwischen Gemeinde und Ortschaft, was alles sein kann zw. einzelnen Häusern und gesamten Wiener Bezirken - eine simple 1:1 Übertragung der Ortschaft auf einen einzelnen OSM-addr-Tag, der in allen Fällen passt und sinnvoll ist gibt es somit nicht (3 Häuser sind kein addr:suburb - evtl. noch ein addr:hamlet wobei da auch fraglich ist, wie nützlich das ist, das steht dann meistens vermutlich sowieso unter addr:place), die bisherige Logik hat aber sicherlich oftmals einen Blödsinn geliefert, daher werden jetzt die Gemeinden mit mehrdeutigen Straßennamen bestimmt und dort die Ortschaft als addr:city gesetzt, alle anderen erhalten die Gemeinde. Man könnte bei den Mehrdeutigen stattdessen auch ein addr:suburb setzen, aber soweit mir bekannt ist das für solche Ortschaften bei uns bisher unüblich.

Eine andere kleine Änderung, die ich noch vorgenommen habe und die evtl. nicht jedem einzelnen passt: Straßennamen, die auf "str."/"g." enden, werden jetzt zu "Straße" und "Gasse" erweitert.

edit: "Gasse" wieder entfernt - kommt nicht oft vor und ist nicht eindeutig genug

Last edited by Luzandro (2018-10-02 21:07:28)

Offline

#63 2018-09-30 16:07:41

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Luzandro wrote:

Eine andere kleine Änderung, die ich noch vorgenommen habe und die evtl. nicht jedem einzelnen passt: Straßennamen, die auf "str."/"g." enden, werden jetzt zu "Straße" und "Gasse" erweitert.

Amtlich (ZMR und AGWR-II) entsprechende Straßenbezeichnungen:

Zur Dokumentation habe ich die letzte BEV-Aufbereitung

-Letzte Luzandro Version, noch mit den Amtlich (ZMR und AGWR-II) korrekten Straßenbezeichnungen-

unter http://www.addresshistory.org archiviert.
Direktlink auch in meiner Signatur.

edit: Link in meiner Signatur

Last edited by addresshistory*org (2018-09-30 16:57:00)


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

#64 2018-10-01 07:54:40

Negreheb
Member
From: Austria
Registered: 2015-11-10
Posts: 133

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

addresshistory*org wrote:

...Leider liegt vieles in OSM im Dunkeln: wer bist Du du schreibst öfters im Plural,

Ist doch egal?

addresshistory*org wrote:

wer ist Negreheb,

Geht dich nichts an.

addresshistory*org wrote:

wer ist auf Talk-at aktiv,

Wieso ist das eigentlich wichtig?

addresshistory*org wrote:

wie weit können wir auf eine Unterstützung seitens das BEV zählen,

Wir haben einen Adressdatensatz erhalten. Ich denke, das ist alles, was wir an Unterstützung erhalten. Wie wir das bearbeiten bzw. aufarbeiten liegt ganz an uns.

addresshistory*org wrote:

warum bremsen einige User auf Talk,

Deine Vorgehensweise zu hinterfragen ist nicht ein "bremsen".

addresshistory*org wrote:

warum zeichnen in OSM professionelle User systematisch unscharfe Gebäudeumrisse,

Gefährliche Unterstellung, das meiste kommt wohl eher noch von früher, bevor gute Luftbilder zur Verfügung standen.

addresshistory*org wrote:

und wie stehen Tile Verwerter wie Mapbox und geofabrik zu diesem Handeln.

Hä?

addresshistory*org wrote:

Warum gibt es eine so geringe Beteiligung bei der Adressergänzung,

Faulheit? Zu wenig Interesse? Wieso ist das wichtig? Es bestand bis dato kein Interesse daran, das ist (leider) alles.

addresshistory*org wrote:

wer patzt regelmäßig meine Arbeit bei der OSM Data Workling Group an.

Unten

addresshistory*org wrote:

Wir benötigen dringend ergänzend zu Deinen BEV Adresssätzen einen funktionierenden Workflow. Leider habe ich den Eindruck, dass vier von fünf Pferden in unserem Gespann genau das mit aller zur Verfügung stehender Kraft zu verhindern versuchen....

Wie wäre es, wenn du zur Abwechslung, wenn dich jemand kritisiert, nicht denjenigen angreifst oder mit Totschlagargumenten die jeweilige Kritik ungültig zu machen ("Man weis ja eh nicht wer das ist!" oder "Der verfolgt eine Agenda!") sondern mal bei dir selbst zu schauen, wo der Fehler liegt? Irgendwie muss es ja einen Grund geben, warum das so ist.

Und nachdem du so feurig mit dem BEV-Datensatz arbeitest, wie wäre es, wenn DU einen Workflow vorschlägst (BEVOR du damit zu arbeiten beginnst), im Forum und auf der Mailingliste, dann kann der Vorschlag diskutiert werden, verbessert werden und, wenn die meisten bzw. fast alle damit zufrieden sind, kann man damit Arbeiten beginnen.
Und, wenn man Glück hat, findet sich ja sogar noch etwas, was automatisiert werden kann.
Und dann wird nach dem Workflow gearbeitet und der wird nicht ständig gearbeitet - so bleibt das dann auch nachvollziehbar.

Aber du machst das lieber anders herum. Irgendwas machen, warten, bis sich jemand aufregt, dann nach viel Diskussion ein bisschen ändern, weitermachen und zwischendurch wieder alles ändern. ALLE hier und auf der Mailingliste wollen ein gutes und möglichst vollständiges OSM, völlig egal, was du dauernd unterstellst.

Offline

#65 2018-10-01 12:03:29

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Faden vom Proposal Katastralgemeinden hierher gelegt.

Luzandro wrote:

Ja und an den Pa[ss|ß]-Thurn-Straßen (bzw. den Adressen dazu) ändert sich genau gar nichts. Wir reden hier von etwa 90 von insgesamt über 130.000 Straßen, die bisher schon fast alle in ausgeschriebener Form in OSM vorhanden sind. Als alt_name ist es auch unnötig, da das sowieso als equivalent angesehen wird.

Was glaubst Du, wird unser Bundesamt für Eich und Vermessungswesen dazu sagen, wenn diese bemerken dass in OSM- Folgeprodukten Österreich Adressen mit BEV Signatur auftauchen, wo zwar BEV drauf steht, aber in Wahrheit gar kein BEV drinnen ist.
Das was Du da vorhast, ist bedenklich und möglicherweise sogar eine Fälschung.

Grüße Johann


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

#66 2018-10-02 09:09:15

Negreheb
Member
From: Austria
Registered: 2015-11-10
Posts: 133

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

Es ist schon etwas traurig, dass du ohne Ahnung von Lizenzen versucht dich über eben jene zu äußern.
http://www.bev.gv.at/portal/page?_pagei … ema=PORTAL

Die unentgeltlichen Produkte des BEV dürfen im Rahmen von Folgeprodukten Dritten zur Verfügung gestellt werden, wenn folgende Bedingungen erfüllt sind:

  - Be- und Verarbeitung der Daten (durch Verschneiden mit anderen ortsbezogenen oder thematischen Informationen bzw. durch Verwendung als Entwurfsgrundlage)
  - Hinweis auf die Schutzrechte des BEV in folgender Form: "© BEV, JJJJ".

Da steht, die Daten müssen Verarbeitet werden und die Info muss dort stehen. Da steht nicht, dass nichts geändert werden darf. Da steht aber sehr wohl, dass der Hinweis dort stehen muss. Insofern ist dein "Wenn ich was ändere, dann lösche ich den BEV-Hinweis" ein Lizenzproblem. Das andere nicht.

Und, Abkürzungen werden in OSM immer ausgeschrieben!
https://wiki.openstreetmap.org/wiki/DE: … nden.21.29

EDIT: Erklärung zu Abkürzungen eingefügt.

Last edited by Negreheb (2018-10-02 09:10:57)

Offline

#67 2018-10-02 11:32:12

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Negreheb wrote:

Und, Abkürzungen werden in OSM immer ausgeschrieben!
https://wiki.openstreetmap.org/wiki/DE: … nden.21.29

Also was steht da:

OSM-Wiki wrote:

Von den o.g. Regeln abgesehen, solltest du den Namen immer so eintragen, wie er auf den Straßenschildern steht.

daher, wir kürzen Straßennamen nicht eigenmächtig ab, sofern uns hochqualitative amtliche Informationen zur Verfügung stehen, in Fetten Wiki Lettern: "solltest du den Namen immer so eintragen".

Danke für diesen Hinweis.


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

#68 2018-10-02 11:37:44

Negreheb
Member
From: Austria
Registered: 2015-11-10
Posts: 133

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

Ernsthaft? "o.g." heisst "oben genannten". Und, was steht da?

Kürze keine Wörter ab. Computer können leicht Wörter abkürzen, aber nicht andersherum (St. könnte Street oder Saint heißen). Wenn die Straßenschilder Abkürzungen verwenden und du nicht weißt, wie das Wort ausgeschreiben heißt, dann kannst du die Abkürzung vorübergehend verwenden, bis jemand anderes den Namen vervollständigt. Kurze Formen zu verwenden ist eine Entscheidung der Software, d.h. in den Daten sollte der volle Straßenname stehen. Das ermöglicht einem Renderer, einen Router oder einer Ortssuchmaschine, Abkürzungen je nach Bedarf anzuwenden.

Sogar mit Erklärung. Genau so kann Str. verschiedenes bedeuten. Deswegen keine Abkürzungen verwenden, die restlichen Sachen aber genau so abschreiben.

Also, zusammengefasst: Benutze keine Abkürzungen, schreibe die Schileder abgesehen davon so genau wie möglich ab.

Offline

#69 2018-10-02 11:40:25

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Negreheb wrote:

Da steht, die Daten müssen Verarbeitet werden und die Info muss dort stehen. Da steht nicht, dass nichts geändert werden darf. Da steht aber sehr wohl, dass der Hinweis dort stehen muss. Insofern ist dein "Wenn ich was ändere, dann lösche ich den BEV-Hinweis" ein Lizenzproblem. Das andere nicht.

Es gibt auch noch eine andere Möglichkeit wie wir auf veränderte Adressdaten hinweisen. Indem wir der BEV Lizenz sofern wir den Datensatz verändert haben, eine Ergänzung hinzufügen z.b. mod. durch User


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

#70 2018-10-02 11:45:32

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Negreheb wrote:

Ernsthaft? "o.g." heisst "oben genannten". Und, was steht da?

Kürze keine Wörter ab. Computer können leicht Wörter abkürzen, aber nicht andersherum (St. könnte Street oder Saint heißen). Wenn die Straßenschilder Abkürzungen verwenden und du nicht weißt, wie das Wort ausgeschreiben heißt, dann kannst du die Abkürzung vorübergehend verwenden, bis jemand anderes den Namen vervollständigt. Kurze Formen zu verwenden ist eine Entscheidung der Software, d.h. in den Daten sollte der volle Straßenname stehen. Das ermöglicht einem Renderer, einen Router oder einer Ortssuchmaschine, Abkürzungen je nach Bedarf anzuwenden.

Sogar mit Erklärung. Genau so kann Str. verschiedenes bedeuten. Deswegen keine Abkürzungen verwenden, die restlichen Sachen aber genau so abschreiben.

Also, zusammengefasst: Benutze keine Abkürzungen, schreibe die Schileder abgesehen davon so genau wie möglich ab.

Hallo Negreheb,
bitte halte Dich daran, sofern uns eine amtliche Schreibweise bekannt ist. Ist diese anzuwenden. Warum sollen wir uns zur Verfügung gestellte hochwertige Daten eigenmächtig verschlechtern.

edit: Detail

Last edited by addresshistory*org (2018-10-02 11:54:09)


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

#71 2018-10-02 11:54:40

Negreheb
Member
From: Austria
Registered: 2015-11-10
Posts: 133

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

addresshistory*org wrote:

Es gibt auch noch eine andere Möglichkeit wie wir auf veränderte Adressdaten hinweisen. Indem wir der BEV Lizenz sofern wir den Datensatz verändert haben, eine Ergänzung hinzufügen z.b. mod. durch User

Wieso? Das ist schlicht und ergreifend nicht Notwendig. Warum etwas machen, was nicht notwendig ist?

addresshistory*org wrote:

Hallo Negreheb, das was Du da verbreitest erfüllt bereits den Tatbestand von Fake-News.
Bitte halte Dich daran, sofern uns eine amtliche Schreibweise bekannt ist. Ist diese anzuwenden. Warum sollen wir uns zur Verfügung gestellte hochwertige Daten eigenmächtig verschlechtern. Nur Feinde eines Projekte würden so etwas propagieren.

Die amtliche Schreibweise ist uns bei OSM EGAL! Bei OSM wird der Name ausgeschrieben, die Erklärung steht da. Und du weisst auch nicht was du sagst. Auf der einen Seite sind die Daten voller Fehler, auf der anderen immer wieder hochwertig.
"Ich mach die Welt, wiedewiedewie sie mir gefällt..."
Du liest die hälfte, dann weise ich dich darauf hin, plötzlich ist das Problem ein anderes. Das ist wirklich anstrengend.

Das BEV schreibt Abkürzungen um Platz zu sparen aus diversen Gründen. Schön für das BEV. Bei OSM werden Namen trotzdem ausgeschrieben. Steht auch so im Wiki. Halte dich bitte daran.

EDIT: Außerdem, Abkürzungen sind keine "Verschelchterung" oder "Verbesserung", es ist nur eine andere Schreibweise. Sinnvoller ist allerdings ausgeschrieben, da Programme dann selbstständig Abkürzen können, wenn das Notwendig ist.
Und bei mir lautet die Adresse am Brief immer noch "Hauptstraße 14" zum Beispiele und nicht "Hauptstr. 14", selbst wenn am Schild "Hauptstr." steht.

EDIT2: Und ja, der Brief wird wohl auch mit "Hauptstr." ankommen, um das gehts aber nicht. Nur um das vorweg zu nehmen.

EDIT3: Hier finde ich es auch schön zusammengefasst: https://forum.openstreetmap.org/viewtop … 99#p691199

EDIT4: Kannst es ja unter short_name=* packen, wenn du unbedingt willst. https://wiki.openstreetmap.org/wiki/Key:name

Last edited by Negreheb (2018-10-02 12:10:25)

Offline

#72 2018-10-02 18:49:24

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Negreheb wrote:

Die amtliche Schreibweise ist uns bei OSM EGAL! Bei OSM wird der Name ausgeschrieben

Du hast soeben der renommierten Webseite regio-osm.de jegliche Legitimität abgesprochen, bitte beruhige Dich und komm auf den Boden.


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

#73 2018-10-02 20:05:24

JM82
Member
Registered: 2016-01-07
Posts: 321

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

addresshistory*org wrote:
Negreheb wrote:

Die amtliche Schreibweise ist uns bei OSM EGAL! Bei OSM wird der Name ausgeschrieben

Du hast soeben der renommierten Webseite regio-osm.de jegliche Legitimität abgesprochen, bitte beruhige Dich und komm auf den Boden.

Wieso, ich sehe diesen Zusammenhang nicht.
Wenn das BEV Ortsnamen/Straßennamen abkürzt und regio-osm.de übernimmt ja diese Daten, dann ist das eigentlich nur ein Folgefehler.
Ich zweifle auch daran, dass die amtliche Schreibweise Abkürzungen dieser Art enthält, also Str. für Straße und G. für Gasse. Habe ich auch noch nie auf Straßennamenschildern gesehen.

Offline

#74 2018-10-02 21:35:20

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

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

JM82 wrote:

Wenn das BEV Ortsnamen/Straßennamen abkürzt und regio-osm.de übernimmt ja diese Daten, dann ist das eigentlich nur ein Folgefehler.
Ich zweifle auch daran, dass die amtliche Schreibweise Abkürzungen dieser Art enthält, also Str. für Straße und G. für Gasse. Habe ich auch noch nie auf Straßennamenschildern gesehen.

Das werden schon die "korrekten" Straßennamen der Gemeinden sein, v.a. bei den Ternitzern dürfte diese Unart verbreitet sein, von dort sind glaube ich ein Drittel der Einträge und dann sind sie sich auch nicht sicher, ob davor jetzt ein Abstand oder ein Bindestrich gehört. Aber ich sehe keinen Grund, warum wir deshalb jetzt zwingend "Str." auf die Karte schreiben müssen und bei so einer gängigen Abkürzung nicht konsistent "Straße" am Ende schreiben können. Wie gesagt ist das auch das, wie die Straßen jetzt schon meistens benannt sind, sowohl in OSM, als auch bei anderen Anbietern.

Offline

#75 2018-10-02 21:59:00

addresshistory*org
Banned
Registered: 2015-02-01
Posts: 1,115

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

Luzandro wrote:

Das werden schon die "korrekten" Straßennamen der Gemeinden sein, v.a. bei den Ternitzern dürfte diese Unart verbreitet sein,

Vielleicht befreit mal jemand den Ternitzer admin Boundary, vom Prefix "Gemeinde"

Jeder Wiederaufbau beginnt als erstes mit Entminen, und entfernen von Schützengräben und Panzersperren.

Ternitz liegt laut regio-osm.de aktuell bei einem mageren OSM- Erfassungsgrad von nur 16%. Das herumbasteln an den dortigen Straßenbezeichnungen ist derzeit daher wohl auch unser allerletztes Problem.

Ich schau mir nun mal Ternitz exemplarisch ganz genau an, und ruf dort auch in der Stadtgemeinde an, und frage wie diese ihre Straßen tatsächlich schreiben. Passt dies mit den BEV Angaben zusammen, so betrachte ich die von Euch neu eröffnete Baustelle, Straßenbezeichnungen- in OSM verschlimmbessern, als erledigt.

+Ternitz meine neue Agenda

Last edited by addresshistory*org (2018-10-02 22:47:51)


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