Ich mache mal dazu einen neuen Thread - wegen Offtopic:
Aber warum nicht addr:* - Was spricht dagegen?
Wenn eine Addresse benutzt wird sollte sie eingetragen werden.
Flo
Ich mache mal dazu einen neuen Thread - wegen Offtopic:
Aber warum nicht addr:* - Was spricht dagegen?
Wenn eine Addresse benutzt wird sollte sie eingetragen werden.
Flo
addr gibt die postalische Adresse eines Objekts an.
Hat das Objekt keine postalische Adresse werden folglich keine addr:* Tags gesetzt.
Wir tragen nur postalische Addressen ein? Ist mir neu. Aber gut - nehmen wir das mal an.
Sendemasten der Telekom haben Addressen - Eintragen oder nicht? Wird ja fĂŒr die Logistik genutzt.
Flo
Ach ja - und es geht hier nicht darum was addressen sind und aus welchen quellen etc - Das ist hinlÀnglich in diesem Thread diskutiert worden. Wer von Amtlichen oder Postalischen Addressen spricht muss erstmal erklÀren woher die denn kommen und wie man die erkennt und warum dann wenn das Amtliche sind wir die PLZ mit drin haben (Das ist Urheberrechtlich von der Post) oder wenn das Postalische sind warum wir die PLZ der Postfach Addressen nicht haben etc etc.
Und wenn wir alles nicht ĂŒbernehmen was nicht âAmtlichâ ist dann viel SpaĂ beim Löschen:
https://osm.zz.de/dbview/?db=addresses-nrw&layer=missingother#51.43892,7.79892,13z
Hast du dazu ein Beispiel?
Bzw sind das âeigene Adressenâ oder Adressen von GrundstĂŒcken/GebĂ€uden die dort in der NĂ€he sind.
Ich selbst finde das eigentlich ganz nett, dass es nicht mehrfach vergeben wird. Die Franzosen setzen das - wie ich gelesen habe - schon lÀnger um.
Das GebÀude bekommt eine addr:*=*
, ein Laden, der in dem GeschÀft ist bekommt contact:*=*
und dem Hydranten direkt vor dem GeschÀft verpasst man dann ein object:*=*
.
So hab ich das zumindest aus Doppelte bzw. vielfache Hausnummern vertstanden.
Der Sendemast bekommt somit eine object:*=*
.
Keine ahnung ob die bei OSM drin sind - Ich hab halt lange mit DatenbestÀnden der Telekom gearbeitet Beruflich. Und die Masten, vor allem ausserhalb der Ortschaften, und auch die grauen KÀsten MFG/KVZ haben mitunter Addressen.
Hab gerade nochmal gesucht - Dachte die KvZ Liste wÀre wenigstens öffentlich. Aber - soifz - nein.
Spontan gefunden habe ich WEAs mit Addressen - die kommen aus dem ALKIS die Addressen. Ist ja auch klar - Wenn der Betreiber eine Addresse möchte lĂ€sst er sich halt eine fĂŒr das FlurstĂŒck durch die Gemeinde zuteilen. Hausnummer stimmt ja schon vom Wort auch nicht.
https://www.openstreetmap.org/node/260556793
https://www.openstreetmap.org/node/1835478882
Also das âBauwerkeâ oder âObjekteâ im Aussenbereich Addressen haben ist relativ gĂ€ngig. Es gibt auch EVUs die den Umspannkompaktstationen Adressen zuweisen lassen.
Flo
Warum bekommt das Haus ein addr:* und der sendemast ein object:* ?
Verstehe ich nicht die Argumentation.
Weil wir es nicht besser können. Das Schild hĂ€ngt am Haus, selten am GrundstĂŒck.
Wir sehen vor Ort auch auch keine GrundstĂŒcksgrenze.
Und ausserdem, weil ich i.d.R. in das GebÀude will, und nicht in der Toreinfahrt stehen.
Deswegen hĂ€nge ich Hausnummern oft sogar nicht an das Haus, sondern die TĂŒr, wenn eindeutig und sinnvoll.
addr:*
verwendest du, wenn das die Hauptposition der Addresse ist, object:*
verwendest du, wenn das Objekt nicht der TrÀger der Addresse ist, sondern dazu benutzt wird, das Objekt zu lokalisieren. Im Fall deines Sendemasten kannst du also genau dann addr:*
setzen, wenn der irgendwo in der Pampa steht und tatsĂ€chlich seine eigene Addresse hat. Wenn er neben einem Haus steht und dessen Address âerbtâ, dann sollte es object:*
sein.
Warum das ganze? Weil es Datenuser gibt, die gerne Addresslisten aus OSM-Daten berechnen wollen. Dann muss man unterscheiden können, ob dieses addr:*
-Tag jetzt die primÀre Stelle identifiziert oder nicht. Oder anders gesagt: das mit dem object:*
wurde angefangen, nachdem die Leute sich beschwert haben, dass sie Hydranten zurĂŒckbekommen, wenn sie nach Addressen suchen.
In Deutschland sind wir da noch etwas konservativ und bestehen auf object:*
nur, wenn die Objekte wirklich ausserdehalb des Bereichs fĂŒr die eigentliche Addresse sind. FĂŒr GeschĂ€fte in GebĂ€uden ist addr:*
okay. In Frankreich sind sie da radikaler und es gilt: es kann nur ein Objekt geben, dass addr:*
-Tags fĂŒr eine gegebene Addresse hat.
Okay - also addr: nur fĂŒr die primĂ€raddresse - d.h. es sollte eigentlich keine POIs geben die in einem building outline liegen mit addr: tags und die ebenfalls addr: tags tragen - Geschweige denn das diese vom outline abweichen.
Da muss ich mal noch drauf rumkauen. Im moment validiere ich ja so zeugs - also addr: tags auf dem POI liegen in einem outline mit anderen tags. FĂŒr die fehlersuche/validierung mĂŒsste man also noch object:*
und contact:*
mit in die auswertung nehmen die dann zum outline mit addr:*
passen mĂŒssen. örgs Und dann mapper die beliebige mischformen taggen contact:city
+addr:postcode
grunz
Warum haben wir uns dagegen entschieden einen einfachen weg wie addr:primary=yes
zu benutzen?
Flo
Weil wir FuĂwege an StraĂen auch als âsidewalkâ erfassen und nicht mit âhighway=residentialâ + âhighway:primary=noâ. Tags sind dafĂŒr da, Dinge zu beschreiben, und nicht um durch andere Tags wieder eine völlig andere Bedeutung zu bekommen.
Das Taggingschema mit addr:, contact: und object: ist simpel und sauber auswertbar.
Wenn du so ein Schema fĂŒr Adressen haben willst, musst du nach Litauen gehen, die haben das vor 7 Jahren erfunden: Key:addr:contact - OpenStreetMap Wiki
Es geht aber nicht darum etwas komplett anderes zu beschreiben (Was beim sidewalk so wÀre)
Es geht darum ein und dieselbe Addresse an mehrere osm objekte zu hÀngen und EINE davon ist gleicher.
Und ein und dieselbe information fĂŒr denselben zweck in unterschiedliche prefixe zu verstecken - ist aehm - ziemlich contraintuitiv.
Und ich baue gerade am validator - und ich habe bisher nur kaputte konstellationen gefunden. Mischungen zwischen addr: und object: oder auch alles doppelt. Offensichtlich ist das nicht so total âsimpel und sauberâ wie du so meinst.
Flo
Wieso? Wenn addr:*=*
dann kein object:*=*
und kein contact:*=*
, und eben anders herum. Mischformen sind nicht korrekt.
Wenn du da nur Mischformen findest, dann wurde das bisher nicht ordentlich erklĂ€rt bzw. geklĂ€rt - wurde es ja bisher nur in Frankreich, wie es aussieht. Wundert mich also nicht, das âhierâ (etwas weiter gefasst ) Kraut und RĂŒben sind. Aber wenn du da am Validator etwas macht, bessert sich das ganze ja womöglich.
Hab auch schon ĂŒberlegt diese Diskussion in Ăsterreich anzufangen, weil ich persönlich das schon gut finde.
addr:city=Foo
contact:postcode=4711
oder sogar
addr:city=Foo
contact:city=Foo
Du findest alles - exakte dopplungen das hÀufigste. Immer nach dem motto "Viel hilft viel.
Und ich hab noch nicht drĂŒber nachgedacht wo bei POI in Building die addr: tags sein sollten.
Also ich wĂŒrde sagen das auf dem umgebenden immer die addr: tags sein sollten. Auf dem POI dann contact: oder object:
Check kommt dann.
Flo
Aber nicht abschlieĂend! Der Starter des Beitragsfadens hat nicht hinlĂ€nglich erklĂ€rt/ eingesehen, wer primĂ€r fĂŒr die Adessvergabe zustĂ€ndig ist! Die primĂ€re Adessvergabe machen die Ămter/ Gemeinen/Kommunen. Der postalische Teil einer Adresse ist primĂ€r lediglich die Postleitzahl⊠Der Starter des genannten Beitragsfadens hat bis Heute nicht erklĂ€rt, welche komischen Quellen er zum Adressabgleich verwendet hat, direkt nutzbare amtliche Quellen wie hier in Brandenburg waren es nicht.
Ich selbst wĂŒrde eine strengere Trennung von addr:*
, contact:*
und object:*
bevorzugen.
Also in den Daten der WEA Brandenburgs ( Windkraftanlagen im Land Brandenburg - MetaVer) stehen keine echten Adressen drin, es gibt nur PLZ, Ort und höchstens noch Ortsteil⊠Wenn es fĂŒr Brandenburg weitereund detailiertere Adress-Angaben in OSM gibt, betrachte ich das als hinzugedichtetâŠ
Sven
Auf einer Node am Umriss und 2 nodes innerhalb der buildings sollte aber auch möglich sein. Wir haben zumindest in Ăsterreich EckhĂ€user, die haben von beiden StraĂen ein StraĂenschild am Haus hĂ€ngen - wenn auch die Adresse auf der HaustĂŒrseite die fĂŒr die Post ârichtigeâ ist.
Könnte man âumgehenâ, indem man die Hauptadresse auf den Umriss pappt und die zweite als Node - aber dann hat man wieder ne node.
Und dann bleiben noch die ReihenhĂ€user, wo man Ă€uĂerlich keine Unterscheidung sieht.
Also um addr:
=` nodes innerhalb eines buildings kommt man, denke ich, trotzdem nicht wirklich rum.
Die âAdressenâ von Solarparks und WEA verdanken wir vermutlich zumindest teilweise dem MaStR, denn dort wird bei der gesetzlich vorgeschriebenen Registrierung entweder eine Adresse (Ort und StraĂe) oder eine FlurstĂŒcknummer gefordert, da verwendet wohl der eine oder andere Anlagenbetreiber einfach den Namen der nĂ€chstgelegenen StraĂe.
Und der eine oder andere Mapper wird genau so verfahren, wenn er vom Editor nach einer Adresse fĂŒr das neu angelegte WEA oder den Solarpark gefragt wird, da stimme ich dieser Vermutung zu
Ich selber habe schon ein paar Dutzend solcher Anlagen aufgesucht, aber eine Adresse habe ich bei keiner vor Ort feststellen können, was schon alleine daran liegt, dass die Zufahrtwege zu diesen Anlagen im Normalfall keinen Namen haben.
ok⊠danach muss auch mal schauen:
einzelne gibt es wo abweichende Adressen drin sind beim contact⊠aber das meiste ist eine Doppelung âViel hilft vielâ
Mfg Miche
Das gibt es einfach nicht. Es gibt die offiziellen addressen - Da macht der Staat respektive deine Kommune das.
Aber alle infrastrukturanbieter haben eigene Addressen. Es gibt dazu noch alte Adressen, Addressen die ersetzt wurden, etc.
Wollen wir die haben oder nicht?
Ich sage - Ja!
Denn wenn heute eine StraĂe umbenannt wird dann wollen wir das auf absehbare Zeit die alten Addressen auch noch gehen. Das ist dann aber keine offizielle Addresse mehr.
Wir wollen auch das Infrastrukturanbieter ihr zeugs wiederfinden.
Das kann ja jeder Betreiber selber entscheiden. Du hast ein FlurstĂŒck. Du gehst zur Kommune und sagst: âIch hĂ€tte gerne eine Adresseâ - Und dann klebst du die an deine WEA. Machen oder lassen.
Ich halte object:* und contact:* fĂŒr totalen mumpitz. FĂŒr ein und dasselbe Datum haben wir jetzt 3 Namespaces. Was fĂŒr ein unsinn.
Flo