"Komische" Building-Relationen in Lübeck

Erklärt dieser Link Deine Frage?

http://wiki.openstreetmap.org/wiki/Lübe … n_Adressen

Oder weil zwei Gebädeteile enthalten sind?

Jan

Also für mich könnte es der Link beantworten ... wenn denn dort auch die Adresse, also in dem Beispiel von wambacher erfasst wäre .. und dann kommt es aber noch besser, diese zwei Gebäudeteile sind dann auch noch in der Relation http://www.openstreetmap.org/relation/2342924 erfasst, die auch KEINE Adresse hat ... also wäre es dann auch für mich unsinnig...

EDIT: Ok, vielleicht habe ich den Text aus dem Link doch nicht ganz verstanden, da die Adresse nur an einem Gebäudeteil (http://www.openstreetmap.org/way/167974448) erfasst ist 🙄

EDIT2: Ok, den Text aus dem Link nochmals durchgelesen und gesehen, dass die Adresse doch nur an den "einen" Gebäudeumriss getaggt werden soll

Lübeck wrote:

Erklärt dieser Link Deine Frage?

http://wiki.openstreetmap.org/wiki/Lübe … n_Adressen

naja, 4-5 Jahre alte Speziallösung. Ob die wer auswertet?
nun, mir ist es egal. Bin halt drüber gestolpert und muss mich damit ja nicht rumschlagen.

Oder weil zwei Gebäudeteile enthalten sind?

nö

gruss
walter

Mhh. Also ich blick da nicht durch.
Es gibt 3 Gebäude
Ein Gebäude davon hat eine Adresse. "In" diesem Gebäude liegt ein Shop.
Eine Relation enthält 2 Gebäude, eine 3, beide Relationen enthalten wieder den Shop und überschneiden sich thematisch (wenn man von Thema sprechen kann).

So weit so "übersichtlich", was mich aber ganz konfus macht (nee Joke, bin schon ganz konfus), warum der Briefkasten in keiner der Relationen enthalten ist.

Ich weis heute aber auch nicht mehr warum hier so gemacht.

Wenn einige Gebäude sich eine Nummer teilen und weiter auseinander stehen, dann sind diese aber auch auf diese Art und weise zusammen gefasst.

Jan

Lübeck wrote:

Wenn einige Gebäude sich eine Nummer teilen und weiter auseinander stehen, dann sind diese aber auch auf diese Art und weise zusammen gefasst.

Ich bin da nicht so tief drin in der Materie, ich würde schlicht erwarten, dass die Adresse in der Relation steht, die die Gebäude "umfasst". Diese Relation "vererbt" diese Eigenschaften dann auf die Gebäude. In dem hier besprochenen Fall ist es aber umgekehrt, da soll die Relation die Eigenschaften eines Kindes erben (wenn ich das richtig verstehe)?
Und: warum gibt es 2 nahezu identische Relationen?

Edit: Ein Beispiel, was ich meine und sofort logisch nachvollziehen kann: http://www.openstreetmap.org/relation/6134610

MKnight wrote:

Und: warum gibt es 2 nahezu identische Relationen?

Und ich frage mich: Warum gibt es diese Relationen überhaupt? 😉

Gruss
walter

PS: ja, der Wikiartikel hat mich nicht im geringsten überzeugt.

Lübeck wrote:

Wenn einige Gebäude sich eine Nummer teilen und weiter auseinander stehen, dann sind diese aber auch auf diese Art und weise zusammen gefasst.

Und warum nicht einfach ein einfacher Ring um das Ganze*, wenn sich die Adresse anscheinend auf das Grundstück und nicht ein bestimmtes Gebäude bezieht? Dann könnte man bei Bedarf "ganz einfach" jedem beliebigen Objekt darin die Adresse zuordnen - wenn das überhaupt jemand braucht. Oder wird das nach dortigem Ortsrecht tatsächlich so geregelt? Dann will ich nichts gesagt haben ;-)

• Die Objekte werden ja wohl nicht so weit auseinander stehen, dass eine andere Adresse dazwischenliegt.
  

Moin!

wie Ihr an dem Beitrag gesehen habt ist der schon etwas älter.

Es ist sicherlich für Datenbankanwendungen möglich die Punkte in der Fläche des Umrings auszuwerten und so die Adresse zu übertragen. Bei uns war aber einer der Leitgedanken die Auswertung direkter zu verknüpfen um auch über einfache Werkzeuge (ohne DB) eine Verbindung herzustellen.

Werde es aber nochmal auf dem nächsten Stammtisch ansprechen, ob wir dabei bleiben wollen.

Gruß Jan

IMHO kann man das in die Tonne kloppen. Osmand kann heute automatisch Nodes den zugehörigen Gebäudeumrissen zuordnen, eine Relation braucht es nicht mehr.