OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#76 2018-10-03 06:10:15

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

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

Aktueller Status:

Luzandro hat sein Projekt "BEV-Adressen (incl. Subadressen) als .osm-Files"

beendet, und zu einem Projekt

"BEV-Adressen" als Transport Container zum einbringen einer von Ihm kreierten Langform von OSM Adressen umgebaut.

Lang und Kurzform haben in OSM Ihre Berechtigung, wobei ich es persönlich schade finde, dass das in den letzten Wochen gut  vorangekommene Projekt, Amtliche Adressen von Ihn nun beendet ist. Damit das bisher erarbeitet nicht verloren geht, haben ich seine letzt verfügbaren amtlichen Adressen auf meiner Webseite, (sowie per Direktlink in meiner Signatur erreichbar) gesichert.

Wie gesagt, Luzandros neues Projekt Langadresse, hat seine Berechtigung, ich finde aber wir sollten zuvor noch eine 100% Abdeckung mit amtlichen Adressen anstreben. Unser Ziel, das bis Ende 2018 in Österreich abzuschließen.


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

#77 2018-10-03 06:20:16

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

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

addresshistory*org wrote:

Das herumbasteln an den dortigen Straßenbezeichnungen ist derzeit daher wohl auch unser allerletztes Problem.

Es soll eben gerade nicht daran herumgebastelt werden. Nehmen wir an, wir hätten einen User, der nicht sehr sorgfältig mit diesen Daten umgeht und einfach riesige Bereich importiert - die Duplikatsprüfung würde dabei nicht anspringen, da die nicht schaut, in welchem Land sich eine Adresse befindet und welche Abkürzungen dort gebräuchlich sind. Oder nehmen wir an, wir hätten einen pedanten User, der meint das wäre die einzig korrekte Schreibweise und anfängt großflächig vorhandene Adressen und Straßennamen auf diese Version zusammen zu stutzen. Brauchen wir beides nicht, also wird es gleich von vornherein auf die in OSM übliche Schreibweise angeglichen.

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

Ja mach das und dokumentiere den Anruf bitte auf deinem YouTube-Channel

Offline

#78 2018-10-03 06:37:04

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

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

Link Thema Namensraum: https://forum.openstreetmap.org/viewtop … 53#p718553

emga erkennt keinen weiteren Diskussionsbedarf, und hat das Thema daher bereits wieder geschlossen.
Danke emga.

Aktuell betrachte ich daher meinen Vorschlag Amtliche Schreibweise im Standard Namensraum als akzeptiert, es sei denn es stellt jemand noch eine Gegenthese auf, welche dann mehrheitlich von den top 50 Mappern (neis liste) http://osmstats.neis-one.org/?item=coun … ry=Austria unterstützt werden sollte.

edit: Text aus aktuellem Anlass komplett überarbeitet.

Last edited by addresshistory*org (2018-10-03 17:32:45)


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

#79 2018-10-03 16:38:19

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

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

Öh, wie bitte? Niemand stimmt dir zu, alle sagen, bei OSM werden keine Abkürzungen verwendet, es steht sogar so im Wiki und du sagst trotzdem "Ich sehe es als akzeptiert!"? Da schrammst du aber schon eher weit an der Realität vorbei und machst es so, wie du willst.

Kannst du andere Vorteile von der Kurzschreibweise nennen, außer "Steht so in den BEV-Daten drinnen!"?

Offline

#80 2018-10-03 17:30:16

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

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

Negreheb wrote:

Kannst du andere Vorteile von der Kurzschreibweise nennen, außer "Steht so in den BEV-Daten drinnen!"?

Die ausgeschriebene Schreibweise eignet sich perfekt für den namen:de Raum. Eine salomonische Lösung, regio-osm.de kompatibel, Wiki Konform -wie in Natura auf den Straßenschildern geschrieben-, Google.maps kompatibel, und zudem auch noch in internationaler OSM Anwendung -mit weiteren Sprachen- eine echte Bereicherung.

Edit: Text + regio-osm.de Komptabilität

Last edited by addresshistory*org (2018-10-03 21:35:48)


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

#81 2018-10-03 21:55:13

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

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

Aha, und das bestimmst du ohne die Mailingliste zu kontaktieren oder auf Antworten anderer Leute zu warten? Spannend.

regio-osm.de ist ein Werkzeug, wir mappen nicht für Werkzeuge. Im Wiki steht "Keine Abkürzungen", sogar als überschrift. Nochmal kopier ich den Absatz nicht rein. google.maps ist uns bei OSM egal.
namen:de=* ist das einzige, was hier Sinn macht.

Also, bitte auch auf der Mailingliste klären, da die Mailingliste immernoch auch ein offizielles Kommunkationsmedium ist. Und warte hier, bis noch ein paar Leute etwas geschrieben haben.

Offline

#82 2018-10-04 08:34:23

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

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

Negreheb wrote:

Aha, und das bestimmst du ohne die Mailingliste zu kontaktieren oder auf Antworten anderer Leute zu warten? Spannend.

regio-osm.de ist ein Werkzeug, wir mappen nicht für Werkzeuge. Im Wiki steht "Keine Abkürzungen", sogar als überschrift. Nochmal kopier ich den Absatz nicht rein. google.maps ist uns bei OSM egal.
namen:de=* ist das einzige, was hier Sinn macht.

Also, bitte auch auf der Mailingliste klären, da die Mailingliste immernoch auch ein offizielles Kommunkationsmedium ist. Und warte hier, bis noch ein paar Leute etwas geschrieben haben.

Tendenziell spreche ich mich hier jetzt einmal gegen das Verwenden von Abkuerzungen aus.

Interessant wird es aber bei Strassen, wo Eigennamen selbst abgekuerzt sind, sollte das da auch noch gelten?

Ich halte das Abkuerzungsproblem fuer kein oesterreichisches Problem sondern (zumindest) fuer ein DACH-Problem. Fuer eine ernsthafte Diskussion koennte man das deutsche Forum oder gleich die Mailingliste Tagging bemuehen.

Fuer mich gibt es in AT kein offizielles Diskussionsmedium. Jeder, der sich vor einem der beiden Medien verschliesst ist selbst Schuld. Schade, dass es diese Form der Verweigerung gibt.

add*org: In mir reift die Meinung, dass fuer Dich eine "Abkuehlung" notwendig wird. Auch das finde ich sehr Schade, weil Du viele interessante Aspekte in die Karte bringst: Deine Arbeit selbst, das Vorstellen Deiner Methoden, die Diskussion ueber die Gemeindenamen und auch die Diskussion ueber die Abkuerzungen.

Leider ziehst Du einen Rattenschwanz an ideologischem - sorry - Mist mit; Plus: Du hast voellig ueberhitzte Ambitionen, was die Umsetzung betrifft. Wenn Du Kollegen vergraemst und diese in langwierige Diskussionen verstrickst, richtest Du auch grossen Schaden an!

Offline

#83 2018-10-04 09:25:05

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

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

Gppes wrote:

Interessant wird es aber bei Strassen, wo Eigennamen selbst abgekuerzt sind, sollte das da auch noch gelten?

Ich habe dazu keine endgültige Meinung. Fest steht für mich, dass es nicht zielführend ist, vorhandene Information komplett weg zu schmeißen. Welches jetzt die Alternative (oder der official_name) sein sollte und was als eigentlicher Name präferiert werden sollte, finde ich nicht immer völlig eindeutig. Tendenziell eher der offiziell abgekürzte Eigenname, solange das in dem Bereich (Ort/Gemeinde) konsistent ist und bei weniger bzw. nur lokal bekannten Persönlichkeiten weiß man ja auch gar nicht unbedingt immer, wofür die Abkürzungen überhaupt stehen sollen. Umgekehrt halte ich es aber auch nicht für wahnsinnig sinnvoll, alle Straßennamen zu ändern, wenn die dort schon jemand alle konsistent ausgeschrieben erfasst hat.

edit: ich hab mir jetzt mal eine Gegend angesehen, wo bei den offiziellen Daten die Vornamen alle abgekürzt sind - here und Google schreiben die dort alle aus.

Last edited by Luzandro (2018-10-04 12:05:32)

Offline

#84 2018-10-04 09:37:54

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

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

Was ich für gangbar halten würde wäre: name=* voll ausgeschrieben, official_name=* wenn die Abkürzung wirklich irgendwo stehen muss. short_name=* ist nach Studium von https://wiki.openstreetmap.org/wiki/Key:name dafür eher nicht geeignet.
Wobei hier immer noch fraglich wird, ob die Abkürzung wirklich offiziell so ist oder nur aus Platz/Kostengründen so auf den Schildern steht.
Ich werde mal bei mir in der Umgebung schauen, ob ich abgekürzte Straßenschilder finde und mir das mal ansehen.

Meiner Erinnerung nach sind die Abkürzungen eher vereinzelt zu finden, eben speziell bei langen Doppelnamen usw.

nur lokal bekannten Persönlichkeiten weiß man ja auch gar nicht unbedingt immer, wofür die Abkürzungen überhaupt stehen sollen.

Das ist eh auch so im Wiki (englisch und deutsch https://wiki.openstreetmap.org/wiki/Nam … _do_it.29)  angemerkt, wenn man nicht weis, was es bedeutet, einfach die Abkürzung hinschreiben, bis es jemand ändert, der sich auskennt.

Unabhängig davon:
Ändern von kurz auf lang oder umgedreht halte ich für Falsch. Das wäre eine Änderung ohne Mehrwert imho, sondern nur, weil es jemandem besser gefällt. Also, das sollte imho nicht gemacht werden!

Offline

#85 2018-10-04 15:37:15

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

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

Luzandro wrote:

ich hab mir jetzt mal eine Gegend angesehen, wo bei den offiziellen Daten die Vornamen alle abgekürzt sind - here und Google schreiben die dort alle aus.

Das ist mir auch aufgefallen, Danke für den Hinweis auf diesen Umstand. Zumindest Google findet die Örtlichkeit unter Eingabe einer fast beliebigen Schreibweise. Ich gehe davon aus dass Google hierfür ein eigenes internes Regelwerk entwickelt hat.
Eine Entsprechung für solche Regeln habe ich in OSM nirgendwo klar dokumentiert gefunden, ich kann mich da aber auch irren.
Jedenfalls kann solches unser Nominatim bislang nicht.

Daher: für Ausschreibungen benötigen wir zuerst ein Standardwerk also eine genormte Beschreibung dafür, und basierend darauf ein Nominatim welches auf dieser Norm aufbaut, und eine dann funktionierende Suche umsetzt.

Beides kann ich aktuell nicht erkennen, eigenmächtige Interpretationen sollten nicht in einem Importsatz ansetzten, sondern anschließend nachvollziehbar, als OSM Prozess.
Sinnvoll fände ich, eine Empfehlung .osm Sätzte vollständig mittels getrennten Importuser- Account durchzuführen.
Z.B Luzandro_Import und erst anschließend mit Veränderungen und Bereinigungen zu beginnen.


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

#86 2018-10-04 16:00: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:

...
Eine Entsprechung für solche Regeln habe ich in OSM nirgendwo klar dokumentiert gefunden, ich kann mich da aber auch irren.

Was ist am Wiki so schlimm? https://wiki.openstreetmap.org/wiki/Nam … t_do_it.29

Ich zitiere die Überschrift und den ersten Satz, mit passendem Bildbeispiel daneben:

Abbreviation (don't do it)
If the name can be spelled without an abbreviation, then don't abbreviate it.

Oder kann das so anders interpretiert werden? Ernsthafte Frage, steht ja auch auf der Deutschen Seite so drinnen.

Sinnvoll fände ich, eine Empfehlung .osm Sätzte vollständig mittels getrennten Importuser- Account durchzuführen.
Z.B Luzandro_Import und erst anschließend mit Veränderungen und Bereinigungen zu beginnen.

Irgendwo frag ich mich schon, ob du uns alle so richtig hart trollen willst...
Als du noch behauptet hast, du machst keine Imports, habe ich dir die Import-Guidelines verlinkt, nicht nur einmal. Hier gern noch einmal: https://wiki.openstreetmap.org/wiki/Import/Guidelines
Was du suchst ist unter Schritt 6 Punkt 5 zu finden, bzw. hat sogar einen eigenen Punkt https://wiki.openstreetmap.org/wiki/Imp … er_account
Wenn du Importe durchführen willst (was du eh schon machst die ganze Zeit), dann MUSST du dafür eigentlich einen eigenen Account anlegen. Eben, adresshistory*org_import oder so.
Die Erklärung, warum das so ist, ist dort auch schön beschrieben smile

Und, das soll aber keine Ausrede sein, falsche Daten auf OSM hochzuladen. Man kann, auch, wenn man einen eigenen Importbenutzer verwendet, die Daten direkt kontrollieren und dann korrekt hochladen. Das wäre nämlich falsch und ist imho so auch eig. nicht gewollt.

Offline

#87 2018-10-04 18:20:08

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

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

Negreheb wrote:

https://wiki.openstreetmap.org/wiki/Imp … er_account
Wenn du Importe durchführen willst (was du eh schon machst die ganze Zeit), dann MUSST du dafür eigentlich einen eigenen Account anlegen. Eben, adresshistory*org_import oder so.
Die Erklärung, warum das so ist, ist dort auch schön beschrieben smile

Und, das soll aber keine Ausrede sein, falsche Daten auf OSM hochzuladen. Man kann, auch, wenn man einen eigenen Importbenutzer verwendet, die Daten direkt kontrollieren und dann korrekt hochladen. Das wäre nämlich falsch und ist imho so auch eig. nicht gewollt.

Hallo Norbert,
korrekt, ich thematisere hier eine Variante als Import. Importe sind nur dann ein Import, wenn diese vollständig und nachvollziehbar sind.
Was Luzandro nun vorschlägt, ist hingegen ein Import per von Ihm konfigurierten Importfilter der neuerdings auch noch den BEV Quelltext verändert. Also ein unvollständiger Import.
Was mir hier missfällt, ist dass sein Filter undokumentiert ist. Also eine Black Box.

Erzwungene Automatisation

Luzandro wrote:

aber da überlege ich ernsthaft eher, diese in Zukunft auch noch nach Straßen zu trennen um ein genaueres Vorgehen damit zu erzwingen und grobe Massenimporte zu vermeiden.

Luzandro ist aktuell dazu übergegangen seine Importsätze in immer kleiner Fragmente zu zerlegen. Seine letzte Aufbereitung beinhaltet daher bereits je Gemeinde bis zu 20 Suburb Einzelteilbereiche, und er überlegt gerade diese Fragmentierung auch noch auf Straßen auszuweiten.

In Anbetracht von jährlichen BEV Veröffentlichungen, müssten wir dann laut Luzandro, jedes Jahr hundert tausende Einzelsätze jeweils von Hand einspielen und laut Luzandro jeweils einzeln von Hand kontrollieren. Das ist unmenschlich, dabei sitzt Luzandro selbst vor seinem Computer und drückt einen Knopf.

Importe von tausenden Einzeldateien erzwingt also Automatisation,
oder große Adressbereiche mit einem anschließend erstellten Schwarzplan der Fehler und Lücken visualisiert. Thomas Konrad hat so etwas für Gebäudeumrisse umgesetzt. Wir haben so etwas in Ansätzen, als Overpass Turbo Abfrage nach Duplikat Adressen verfügbar.

Warum also nicht gleich regio-osm.de, einige meinen regio-osm sei nur ein Spiegel bereits vorhandener falscher Daten, diese renommierte Plattform öffentlich zu diskreditieren finde ich aber als vermessen. Vielleicht sollten wir über die uns vom BEV zur Verfügung gestellten Daten diskutieren. Jedenfalls werden diese auch in der basemap.at angewandt.

Edit: Artikelteilung auf Wunsch von emga wieder rückgängig gemacht.

Last edited by addresshistory*org (2018-10-05 21:51:07)


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

#88 2018-10-05 08:21:47

emga
Moderator
Registered: 2014-05-21
Posts: 295

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

addresshistory*org wrote:

Warum also nicht gleich regio-osm.de?, Weiter dazu unter: https://forum.openstreetmap.org/viewtop … 13#p718913

Diskussionen NICHT zerteilen, und schon gar nicht wenn sie dann Off-Topic werden.
Vielen Dank,
emga

Offline

#89 2018-10-06 08:35:09

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

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

Die Ebenen können jetzt nicht nur nicht direkt hochgeladen werden, sondern sie sind auch noch gelocked. Zum einen bedeutet das, dass man sie nicht bearbeiten kann, die spannendere Auswirkung ist allerdings, dass man dadurch auch nichts in diese Ebene hinein laden kann. Wenn daher eine gelockte Ebene aktiv ist und man lädt diesen Bereich herunter, landen diese Daten stattdessen in der Arbeitsebene, solange man nur eine offen hat, und ansonsten eben automatisch in einer neuen Datenebene.

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.

Und dann hat der Output jetzt eine neue Struktur und ist u.a. nach Gemeinden gruppiert, die Ordner- bzw. Dateistruktur sieht nun nämlich 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.

In Anbetracht von jährlichen BEV Veröffentlichungen, müssten wir dann laut Luzandro, jedes Jahr hundert tausende Einzelsätze jeweils von Hand einspielen und laut Luzandro jeweils einzeln von Hand kontrollieren.

Pro Halbjahr sind etwa 10.000 Adressen mit neuen IDs dabei, also umgerechnet um die 400 pro Woche, wobei gerade bei neuen Einträgen die Qualität oft noch sehr mangelhaft ist und diese einfach mal irgendwie grob in die Gegend geworfen werden bzw. dort oft auch noch mehr zu tun ist, wie neue Straßen anzulegen - das ungeschaut zu übernehmen ist kontraproduktiv. Und ja, ich erwarte von dir, dass du bevor du etwas hochlädst, dir das zumindest einmal anschaust, denn danach wirst du das nicht mehr machen und "irgendwer" darf sich dann darum kümmern, dass das korrigiert und aktualisiert wird. Es sind weder der Konverter, noch die Duplikatsprüfung (die nicht einmal auf das Mergen von Imports ausgelegt ist), noch die Basisdaten perfekt - wenn dem so wäre, bräuchte es auch keinen manuellen Schritt und von blind kopierten Adressen ohne Straße irgendwo im Nichts, wie von Negreheb gezeigt, hat auch niemand etwas. Es hält höchstens noch jemand anderen davon ab, die Gegend mit Straße etc. zu erfassen, denn laut regio-osm ist dort ja alles perfekt (und bevor du das jetzt wieder als Diskreditierung von regio-osm deutest: das ist natürlich nicht die Schuld von regio-osm, ich halte das für ein tolles Tool, aber es ist eben auch nur ein Werkzeug und wie bei so vielen QA-Tools sollte es nicht darin ausarten, nur noch blind dieses zufrieden stellen zu wollen). Wenn dein Filter soviel weg filtert, dass du nicht einmal siehst, ob dort überhaupt eine Straße ist, oder ob diese mit den Adressen zusammen passt, dann ist das nicht sinnvoll.

korrekt, ich thematisere hier eine Variante als Import. Importe sind nur dann ein Import, wenn diese vollständig und nachvollziehbar sind.

Na zum Glück war der plan.at-Import "vollständig", damit wir auch heute noch was davon haben roll

Was Luzandro nun vorschlägt, ist hingegen ein Import per von Ihm konfigurierten Importfilter der neuerdings auch noch den BEV Quelltext verändert. Also ein unvollständiger Import.
Was mir hier missfällt, ist dass sein Filter undokumentiert ist. Also eine Black Box.

Nein, ich schlage vor, so wie bisher bspw. auch mit dem AddressHelper selektiv vorzugehen. Der "Quelltext" sind mehrere Tabellen mit Dutzenden Feldern, aber nur zur völligen Transparenz: im Gegensatz zum AddressHelper unterschlage ich auch den HAUSNRBEREICH und generiere nicht so Hausnummern wie "1-3, alle Zahlen des Intervalls". Was jetzt gar so furchtbar daran ist, dass einige mit "str." abgekürzte Straßennamen daran angeglichen werden, wie die Straßen sowieso schon in OSM heißen, hast du uns auch noch nicht richtig begründen können, außer dass dann vielleicht einzelne Gemeinden auf regio-osm evtl. orange statt gelb angezeigt werden könnten. Ich lasse mich ja überzeugen, dass das keine gute Idee ist, aber bis jetzt warst du als einziger dieser Meinung, ohne das gut begründen zu können.

Ich nehme an, mit dem Filter meinst du das hier, aber zum einen ist das ein unabhängiger Schritt vom Konvertieren (und wäre auf diese Art für so große Mengen und nicht on demand gar nicht machbar. Es ist auch jetzt mit der Abfrage je Datei nach der Umstellung auf Straßennamen etwas suboptimal) und weder importiere ich einfach alles, was über bleibt, noch ignoriere ich alles andere, wenn mir Unstimmigkeiten auffallen. Es ist halt nur ein weiteres Hilfsmittel, wenn auch ein sehr sinnvolles, wenn man soviel mit diesen Daten macht wie du.

Um das ganze unter Windows zu verwenden: Python 3.x installieren und dabei die Checkbox "Add Python 3.7 to PATH" wählen.
Dann eine Commandline öffnen (Startmenü "cmd") und

pip install overpy

eingeben.
Das zip-File mit der osm-toolbox herunterladen und entpacken.
Diesen Ordner kann man jetzt noch zu den Umgebungsvariablen hinzufügen: Startmenü "Umgebungsvariablen" => "Umgebungsvariablen" => Path Bearbeiten und dort den Pfad zur osm-toolbox angeben.
Wenn du jetzt eine neue Commandline aufmachst (evtl. musst du dich vorher nochmal ab- und neu anmelden) solltest du unabhängig vom aktuellen Verzeichnis "filter_address_files.py" eingeben können, ohne Fehlermeldung.

Jetzt den Ordner einer Ortschaft öffnen, im Windows-Explorer auf Datei->Windows Powershell öffnen und

filter_address_files.py *

eingeben. Beim ersten Mal musst du es anscheinend tatsächlich ausschreiben und kannst keine autocompletion verwenden, aber beim nächsten Mal brauchst du nur CTRL+R filter eingeben.

Damit wird neben den vollständigen Dateien auch noch eine entsprechende mit postfix _filtered.osm angelegt, wo die vorhandenen Einträge entfernt sind. Du kannst dann also im Explorer nach _filtered suchen und die Dateien per drag&drop in JOSM öffnen.
Was aktuell zB nicht heraus gefiltert wird: Adressen mit einem anderem addr:city, oder Subadressen, die mit "/" angegeben sind.

Offline

#90 2018-10-06 18:50:55

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

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

Hallo Luzandro,
Du kennst den von mir verwendeten JSOM Filter
vielleicht solltest Du parallel zu Deinen jeweiligen Aufbereitungen, auch den dazu passenden JOSM Filter definieren.
Wenn es Sinn ergibt, warum nicht auch die Straße mitnehmen.
Was mir aktuell dazu aber fehlt ist eine dazu notwendige allgemeine Beteiligung.

Es ist leicht zu sagen, du hast die Kartoffel ins Feuer geworfen, nun bist du für diese verantwortlich.
Nein so ist das nicht, niemand verlangt schließlich von anderen OSM Usern -deren Steckenpferd zum Bespiel darin besteht Landnutzungspolygone zu zeichnen-, dass diese zugleich auch noch etwas anderes machen müssten. Warum verlangst Du von mir aber wenn ich Adressen Mappe, dass ich zugleich auch Straßen benennen soll. Ein weiterer -sich selbst zur Community hochstilisierter- User -Id Anwender-, phantasiert sogar, dass ich hierbei auch noch mögliche doppelte Gebäudepolygone bereinigen soll, das ergibt keinen Sinn.

Es ist ganz klar ersichtlich, Adressen sind von Dir, und per addresshelper als Zuckerl gedacht, Lockmittel um andere  Interaktionen wie das Zeichnen von Gebäudepolygonen, und neuerdings das Benennen von Straßen zu erzwingen.

Es gibt keinen legitimen Anspruch auf Erfüllung einer derart gesteuerte Interaktion. Wenn OSM Mapper dann aus deinen sorgsam gelegten Schienen ausbrechen, machst Du den Beleidigten, und baust allerlei Erschwernisse ein.

Was mich freut, ist dass es bei Deinen Adressen eine stete Optimierung gibt. Ich gehe diese Schritte gerne mit, wenn diese Änderungen Verbesserungen bringen. Sofern diese hingegen das Ergänzen von Adressen verunmöglichen, dann verweise ich auf ältere Versionen, zu finden als Link in meiner Signatur. Was erlaubt ist und was nicht, bestimmst keinesfalls Du, du bist schließlich ein OSM User wie jeder andere auch. Auch Deine älteren Aufbereitungen sind daher legitim.

Deinen Aktuellen Schritt, die Ausschreibung von Namen eigenmächtig zu ändern gehe ich nicht mit. Aber Du könntest ja die amtliche Schreibweise ebenfalls im Changeset belassen. Sofern OSM Nominatim hierbei in Namensauflösung mitzieht bin ich für solche Vorschläge aufgeschlossen.

Ein größeres Problem ergibt sich aus Deiner aktuellen Initiative in Langausschreibung mit bereits in Österreich gemappten Adressen. Mein Vorschlag dazu, solche Langnamen im bislang vielfach ungenutzte Datenfeld name:de unterzubringen. Beispiel Semperitstraße in Ternitz. https://wiki.openstreetmap.org/w/index. … _Addresses wurde aber leider bereits wieder vom Moderator emga unterbunden. Dass hier in Luzandros Thread dieses Thema nun untergeht, entlarvt emgas Eingriff in Form der Themensperrung meines dafür gestarteten Artikel https://forum.openstreetmap.org/viewtopic.php?id=63954 als manipulativen Eingriff in die Diskussion.

Edit: Text ergänzt, es hat noch niemand geantwortet.

Last edited by addresshistory*org (2018-10-07 16:52:32)


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

#91 2018-10-09 19:46:57

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

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

Luzandro wrote:
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

Zurück zum Thema:

Luzandro wrote:

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.

Gibt es in dieser Annahme, regionale Unterschiede oder trifft diese Aussage auf gesamt Österreich zu ?


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

#92 2018-10-10 19:59:58

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

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

wie gesagt ist das mittlerweile auch nicht mehr ganz aktuell, nicht zuletzt weil auch du dich beschwert hast, dass du immer noch nicht verstehst, warum nicht immer die Gemeinde als addr:city geliefert wird und es tatsächlich nicht immer ganz konsistent war:

Luzandro wrote:

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.

Aber gibt es da regionale Unterschiede? Ob in einer Gemeinde Straßennamen mehrfach vorkommen, ist tatsächlich regional sehr unterschiedlich. In den PLZ-Bereichen 4-6 ("Westen") kommt das fast gar nicht vor, 7-9 ("Süden") etwas mehr und am häufigsten im Osten.

Das wiki sagt zu addr:city

Name der Stadt beziehungsweise des Ortes allgemein (Dorf uw.), wie er in postalischen Adressen angegeben wird

Wie im oben verlinkten "Richtig Addressieren" der Post, ist der "Bestimmungsort" bspw. in der Gemeinde Götzendorf an der Leitha aber nicht die Gemeinde, sondern die Ortschaft, da bspw. die Hauptstraße 65 sowohl in der Ortschaft Götzendorf an der Leitha, als auch ein paar Hundert Meter weiter in der Ortschaft Pischelsdorf vorkommt und die Adressen nach der ersten Variante der Post dann folgendermaßen lauten müssen:

Hauptstraße 65
2434 Pischelsdorf

und

Hauptstraße 65
2434 Götzendorf an der Leitha

addr:city=Pischelsdorf ist dafür also völlig korrekt, v.a. aber ist es zwingend erforderlich, dass Pischelsdorf in der Adresse überhaupt aufscheint. Warum habe ich es für die Ausgabe des Konverters dann trotzdem nochmal geändert? Man könnte nur bei den Straßen oder Adressen, die ansonsten nicht eindeutig sind, ein anderes addr:city setzen, aber das ist völlig inkonsistent und für User und Mapper ohne zusätzlichen Hinweis schwer nachvollziehbar, warum das so ist und dass das v.a. Absicht ist und es einen Grund dafür gibt. Wenn man es für den gesamten Ort  / die gesamte Gemeinde ändert, ist es zwar lokal konsistenter, das Problem mit der Nachvollziehbarkeit ist aber immer noch ein wenig gegeben und wenn jemand daher kommt und meint, diese Angabe wäre falsch, weil doch immer die Gemeinde in addr:city stehen muss, und das entsprechend ändert, gibt es plötzlich wieder Adressen, die nicht mehr eindeutig sind. Daher ist die Variante 2 der Post mit addr:suburb vermutlich etwas sicherer und konsistenter, wobei ich es aktuell nur bei den Straßen setze, die ansonsten nicht eindeutig sind. Warum nur bei den Straßen? "Ortschaft" kann wie gesagt alles mögliche und auch sehr klein sein, für alle Ortschaften ist es also mMn. nicht sinnvoll, auch nicht wenn man die abzieht, die unter die addr:place Regel fallen. Man könnte es auch nur in den Orten setzen, wo mehrdeutige Straßennamen vorkommen. Das kann aber auch etwas irritierende Ergebnisse liefern, wo bei "gleichwertigen" Katastralgemeinden einmal überall suburb vorkommt und bei der anderen dagegen nur die Gemeinde aufscheint. Umgekehrt für die gesamte Gemeinde würden dann auch kleine Ortschaften dieser Gemeinde (und wieder nur dieser Gemeinde) ein Suburb bekommen, daher scheint es zumindest für diese automatisch generierten Dateien jetzt einmal nur dort auf, wo es am ehesten auch tatsächlich notwendig ist, auch wenn es an mehr Stellen passend sein könnte.

Zum Key selbst: ich weiß nicht, wie verbreitet der für Ortschaften/Katastralgemeinden ist, aber auch nach den Reaktionen einiger anderer User auf diversen Kanälen zu schließen, ist es nicht falsch, aber bisher auch nicht unbedingt üblich - so zumindest mein Eindruck. Beim Durchforsten des Forums (und auch bei den Overpass-Abfragen in Grenznähe) hatte ich den Eindruck, dass das in Deutschland eher verbreitet ist und so wie man "city" nicht zu wörtlich nehmen darf, ist das bei "suburb" wohl genauso.
Man findet bei den Werten für addr:city auch die Angaben "Gemeindename", "Gemeinde Gemeindename", "Ortsname", oder "Gemeindename-Ortsname" bunt gemischt, was bei einem Community-Projekt wie OSM auch nicht weiter überraschend ist, aber mittlerweile bin ich auch der Ansicht, dass der Ortsname (wenn es nicht nur ein Place ist) unter suburb wohl am besten aufgehoben ist, wenn man ihn angeben will oder muss.

Es ist auch jetzt mit der Abfrage je Datei nach der Umstellung auf Straßennamen etwas suboptimal

Das Filter-Script ist mittlerweile übrigens wieder freundlicher zum Overpass-Server und damit auch wieder deutlich schneller, also falls das jemand verwendet, sollte man es aktualisieren

Offline

#93 2018-10-11 06:35:46

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

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

@ Luzandro:

Luzandro wrote:

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.

Es gibt natürlich noch eine weitere Möglichkeit, nämlich: Ortschaft-Beistrich-Straße. Konkret beim Bsp. Pischelsdorf: Götzensdorf an der Leitha, Hauptstraße 65 2434 Pischelsdorf.
im Addr:city Feld steht IMMER die pol. Gemeinde, niemals die Katastralgemeinde, die speziell durch die Gemeindezusammenlegungen in der Stmk. vor einigen Jahren vermehrt entstanden sind.
Und das ganze kommt dann in das addr:street Feld, die Straße davor muss natürlich gleich heißen.

Luzandro wrote:

Aber gibt es da regionale Unterschiede? Ob in einer Gemeinde Straßennamen mehrfach vorkommen, ist tatsächlich regional sehr unterschiedlich. In den PLZ-Bereichen 4-6 ("Westen") kommt das fast gar nicht vor, 7-9 ("Süden") etwas mehr und am häufigsten im Osten.

Das wiki sagt zu addr:city

Name der Stadt beziehungsweise des Ortes allgemein (Dorf uw.), wie er in postalischen Adressen angegeben wird

Wie im oben verlinkten "Richtig Addressieren" der Post, ist der "Bestimmungsort" bspw. in der Gemeinde Götzendorf an der Leitha aber nicht die Gemeinde, sondern die Ortschaft, da bspw. die Hauptstraße 65 sowohl in der Ortschaft Götzendorf an der Leitha, als auch ein paar Hundert Meter weiter in der Ortschaft Pischelsdorf vorkommt und die Adressen nach der ersten Variante der Post dann folgendermaßen lauten müssen:

Hauptstraße 65
2434 Pischelsdorf

und

Hauptstraße 65
2434 Götzendorf an der Leitha

Offline

#94 2018-10-11 06:45:21

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

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

Unsere Post stellt beide Varianten zu.

Wenn ich die Wahl habe, wähle ich daher die nicht so elegante aber dafür konsistente Variante.

Eine Alternative wäre in OSM, Regionalverantwortliche zu ernennen. Regionalverantwortliche mit Ortskenntnis welche den jeweiligen regionalen Status per regelmäßiger Sichtung und Kontrolle aufrechterhalten.
Aufgrund mangelnder Ressourcen ist das aktuell aber nicht zu machen. Daher meine Meinung, eine einheitliche Umsetzung über ganz Österreich mit dem Gemeindenamen im Feld addr:city ist derzeit die besser Variante.


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

#95 2018-10-11 06:50:56

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

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

JM82 wrote:

Es gibt natürlich noch eine weitere Möglichkeit, nämlich: Ortschaft-Beistrich-Straße. Konkret beim Bsp. Pischelsdorf: Götzensdorf an der Leitha, Hauptstraße 65 2434 Pischelsdorf.
im Addr:city Feld steht IMMER die pol. Gemeinde, niemals die Katastralgemeinde, die speziell durch die Gemeindezusammenlegungen in der Stmk. vor einigen Jahren vermehrt entstanden sind.
Und das ganze kommt dann in das addr:street Feld, die Straße davor muss natürlich gleich heißen.

Wie gesagt machen das manche Gemeinden so (entsprechend taucht dort dieses Problem dann auch nicht auf), der Ortsname ist dann allerdings auch tatsächlich Teil des Straßennamens. In den Fällen, wo das nicht so ist, ist das nach Ansicht der Post keine korrekte Form der Adressierung und es ist auch für OSM nicht sinnvoll das dort dennoch einzuführen, eine Straße mit diesem Namen gibt es dort schlicht nicht.

Offline

#96 2018-10-11 13:33:26

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

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

Luzandro wrote:
JM82 wrote:

Es gibt natürlich noch eine weitere Möglichkeit, nämlich: Ortschaft-Beistrich-Straße. Konkret beim Bsp. Pischelsdorf: Götzensdorf an der Leitha, Hauptstraße 65 2434 Pischelsdorf.
im Addr:city Feld steht IMMER die pol. Gemeinde, niemals die Katastralgemeinde, die speziell durch die Gemeindezusammenlegungen in der Stmk. vor einigen Jahren vermehrt entstanden sind.
Und das ganze kommt dann in das addr:street Feld, die Straße davor muss natürlich gleich heißen.

Wie gesagt machen das manche Gemeinden so (entsprechend taucht dort dieses Problem dann auch nicht auf), der Ortsname ist dann allerdings auch tatsächlich Teil des Straßennamens. In den Fällen, wo das nicht so ist, ist das nach Ansicht der Post keine korrekte Form der Adressierung und es ist auch für OSM nicht sinnvoll das dort dennoch einzuführen, eine Straße mit diesem Namen gibt es dort schlicht nicht.

Ich habe das vor zwei Jahren in der Gemeinde Wildschönau -nach viel Probieren- ebenfalls so umgesetzt, und das Thema daher für mich damals abgeschlossen.
Manchmal fällt es schwer eine eigene Erfahrung in einem kooperativen Projekt zu transportieren. Aber siehe da, andere kommen auf die selbe Lösung.

Leider ist das Handstricken solcher Adressen (addr:street=Straße,Ort) sehr zeitaufwendig. Wildschönau du hast mich Wochen beschäftigt.


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

#97 2018-10-11 16:34:13

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

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

Luzandro wrote:
JM82 wrote:

Es gibt natürlich noch eine weitere Möglichkeit, nämlich: Ortschaft-Beistrich-Straße. Konkret beim Bsp. Pischelsdorf: Götzensdorf an der Leitha, Hauptstraße 65 2434 Pischelsdorf.
im Addr:city Feld steht IMMER die pol. Gemeinde, niemals die Katastralgemeinde, die speziell durch die Gemeindezusammenlegungen in der Stmk. vor einigen Jahren vermehrt entstanden sind.
Und das ganze kommt dann in das addr:street Feld, die Straße davor muss natürlich gleich heißen.

Wie gesagt machen das manche Gemeinden so (entsprechend taucht dort dieses Problem dann auch nicht auf), der Ortsname ist dann allerdings auch tatsächlich Teil des Straßennamens. In den Fällen, wo das nicht so ist, ist das nach Ansicht der Post keine korrekte Form der Adressierung und es ist auch für OSM nicht sinnvoll das dort dennoch einzuführen, eine Straße mit diesem Namen gibt es dort schlicht nicht.

Ich zweifle nicht mal näherungsweise, dass die Post mit der Kombination Ortschaft-Beistrich-Straße + PLZ & Ort, ein Problem haben wird. Denn, präziser kann man kaum einen Brief/ein Paket adressieren, als zu einer Ortschaft/Gemeinde, in der es in der Tat 2 oder mehr gleichnamige Straßen gibt, noch zusätzlich die Katastralgemeinde in den Straßennamen zu schreiben. wink
Ich habe eh schon hier im Forum vor 1-2 Jahren auf diese Thematik hingewiesen. Es wird jedoch - grade durch die Gemeindezusammenlegung in der Stmk auch bedingt - hier die einzige praktikable Lösung bleiben. Denn, wie auch in den BEV-Daten vorhanden, steht im addr:city Feld immer der Name der Gemeinde drinnen. Beim zuvor genannten Bsp. ist es "Götzendorf an der Leitha"lt. Wikipedia.

Last edited by JM82 (2018-10-11 16:34:33)

Offline

#98 2018-10-11 18:08:24

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

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

Ich gehe auch nicht davon aus, dass es nicht ankommen wird, aber der vorgesehene Platz dafür ist für die Post entweder statt der Gemeinde nach der PLZ - was wie oben ausgeführt für OSM unpraktisch ist und Nachteile hat - oder in der vorletzten Zeile, was der Angabe von addr:suburb entspricht:

Hauptstraße 65
Pischelsdorf
2434 Götzendorf an der Leitha

Wenn die Gemeinden solche Sonderfälle nicht von sich aus umgehen und Straßennamen verhunzen, indem sie den Ortsnamen mit oder ohne irgendwelchen Zeichen davor schreiben

Welten, Hauptstraße 25
8383 Sankt Martin an der Raab

Rax-Raxer Hauptstraße 4
8380 Jennersdorf

Walbersdorf Berggasse 3
7210 Mattersburg

Überfeld/Dorfstraße 25
9311 Frauenstein

oder danach schreiben

Feldgasse, Rattersdorf 7
7443 Mannersdorf an der Rabnitz

Gartengasse (Seyring) 12
2201 Gerasdorf bei Wien

gibts keinen Grund, warum wir das unnötigerweise verfälschen und verschandeln sollten

Offline

#99 2018-10-13 00:06:42

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

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

Luzandros aktuelle BEV Adressaufbereitung liegt nun in einem derart massiv fragmentierten Format auf, als dass seine Aufbereitung nur noch maschinell weiterverarbeitet werden könnte.
Somit kann man sein Projekt -für laienhafte Mapping Aktivitäten- nun als unbrauchbar erachten.

Schade,
was als ambitioniertes Projekt begonnen hat, endet also nun. Auch die dem JOSM Plugin zugrunde liegenden BEV Daten sind längst nicht mehr aktuell, werden also offensichtlich nicht mehr aktualisiert.

Aktuell verweise ich auf die in meiner Signatur erreichbaren älteren Aufbereitungen. Ich finde es macht Sinn Österreich mit diesen Daten in Adressabdeckung zu vervollständigen. Ein anschließend hoffentlich eintretender Wiki Effekt, sollte das importieren weiterer BEV Daten künftig überflüssig machen.


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

#100 2018-10-13 16:23:41

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

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

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

Offline

Board footer

Powered by FluxBB