Zusammengehörige Gebäude als MP gemappt – ist das sinnvoll?

Um die Zugehörigkeit mehrerer tlw. direkt aneinander angrenzender Gebäude zu einer Firma (hier: „Just Pack GmbH“) zum Ausdruck zu bringen, hat ein Kollege diese Gebäude zu outer-Flächen eines Multipolygons gemacht:

https://www.openstreetmap.org/relation/7537777

Im selben Industriegebiet gibt es noch mehrere ähnlich gelegene Fälle.

Da ich immer mal wieder über solche MP-Konstrukte stolpere, möchte ich Euch nach Eurer Meinung dazu fragen. Denn ich finde zwar die Absicht gut, aber die Umsetzung mit einem MP problematisch. Erstens ist das eine unnötig kompexe Konstruktion, zweitens sind MPs mMn für andere Dinge gedacht, drittens sollten sich meines Wissens mehrere outers eines MPs niemals berühren – sobald sich zwei outer-Flächen eine Kante teilen, wie das hier der Fall ist würde ich sie normalerweise zu einer einzigen Fläche mit outer-Rolle verschmelzen, was hier aber nicht geht. Daher würde ich in einem Fall wie diesem:

(1) Entweder die Gebäude einfach einzeln mappen (die MP-Relation entfällt) und um das gesamte Firmengelände einen neuen Zeichenweg ziehen, an den dann die gemeinsamen Tags für die Firma kommen. Ganz simpel und auch für Anfänger verständlich und bearbeitbar. Und wenn man unbedingt die Grenzen der Firma sichtbar machen will, kann man ja ggf. noch einen Zaun mappen (falls vorhanden).

(2) Oder vielleicht über eine site-Relation nachdenken, was auch immer das sein mag. Aber das ist, selbst wenn es geht, doch wohl unnötiger Aufwand. Daher würde ich bei (1) bleiben.

Was meint Ihr?

PS: Ich erwähne/betone den Namen des Kollegen nicht, weil ich keinesfalls den Kollegen, der diese MPs angelegt hat, kritisieren möchte (ich schätze seine Arbeit sehr), sondern grundsätzlich klären möchte, ob diese Verwendung von MPs gut bzw. zumindest OK ist oder eben nicht.

Ich sehe keinen Grund wieso es nicht möglich sein sollte, hier eine Fläche über das gesamte Firmengelände zu ziehen und dort alle notwendigen Tags anzubringen, zzgl. landuse=industrial oder von mir aus auch man_made=works.

Relation vom type=site halte ich bei Unternehmen für wenig sinnvoll, denn OSM ist nicht die Gelben Seiten. Bei Schulen/Unis kann man das machen.

building=commercial am MP ist hier auf jeden Fall falsch, das gehört an die einzelnen Gebäude.
Diese könnte man dann mit einer Relation zu einer Firma zusammenpacken, aber (1) finde ich hier eindeutig besser.

Ich verwende für solche Betriebsgelände ebenfalls Lösung (1).

Grüße

site-Relationen dienen dazu räumlich getrennte Objekte, die ein logisches Objekt/POI bilden, zusammen zu fassen.

Site halte ich nur für erforderlich, wenn man (unbedingt) mehrere getrennte Flächen eines Betriebes erfassen will. Ist bei Schulen/Unis auch nicht anders.

Na da hättest du aber bei Großunternehmen wie Siemens eine site-Relation, die einmal um den gesamten Globus geht. Das will doch wirklich keiner.

Ist gottseidank noch keiner auf die Idee gekommen. :sunglasses:

OK, vielen lieben Dank für Eure schnellen Rückmeldungen! Also spricht in einem simplen Fall wie dem Beispiel alles für Lösung (1). :slight_smile:

Ich warte mal weitere Stimmen ab (vielleicht gibt es ja noch andere Meinungen ;)). Falls die Tendenz bestehen bleibt, werde ich gelegentlich den Kollegen, der das Beispiel-MP gemappt hat, darauf ansprechen, ob wir (= er/ich) das im Beispiel angesprochene Firmengelände entsprechend Lösung (1) vereinfachen und das MP beseitigen können.

Nein, ich würd dem Vorgesagten auch zustimmen.

+1 für (1). Betriebsgelände sind bei mir einzelne landuse=commercial/industrial (wenn sie eine zusammenhängende Gewerbefläche ergeben, einfach miteinander verkleben) mit name=Pahlgruber & Söhne dran. Die einzelnen Gebäude bekommen nur dann ein name=*, wenn sie auch ein eigenes haben wie „Versandhalle“ oder „Gebäude B”.

Etwas unschlüssig bin ich dann immer, wo ich die Adresse hinpappe. An Einfahrt oder Empfangsgebäude? Dann hängt sie nicht mit dem Namen zusammen. Oder an das ganze landuse? Oder einen separaten node auf die Einfahrt mit man_made=works + Name + Adresse, quasi als place-node für das Gelände?

–ks

entrance=main mit man_made=works, Name, Adresse, Webseite, …

Dort wo man hin muss, wenn man (das erste Mal) auf das Gelände möchte. Auch wenn auf dem Lieferschein steht - Einfahrt E; Versand - weiß ich nicht wo es ist (wenn es - noch - nicht eingetragen ist).

EDIT:
PS: sonst landuse usw. wie von kreuzschnabel vorgeschlagen.

zusammengehörige Gebäude als MP halte ich für eine falsche Lösung. Meiner Ansicht nach ich MP nicht dafür gedacht… Ich hatte auch erst type=site im Kopf… Aber…

Wie ist es mit type=building mit den Rollen outline für die Umgrenzung und part für die Gebäudeteile…?

Sven

Zu diesem Thema sind mir vor etwa einem Jahr bei einer neu hinzugekommenen Auswertung in der Area-View des OSM-Inspctors zu einem MP zusammengefasste Gebäude aufgefallen, die im MP die Adresse stehen haben. Diesem Fehlertyp hat sich scheinbar kaum jemand angenommen, ihn zu reparieren.

Bei einem MP ohne inner-Rollen ist es doch so, dass, wenn zwei outer-Rollen sich ein Segment zwischen zwei oder mehr Knoten teilen, man diese Outer-Rollen bei keinen oder gleichen Merkmalen auf den Umrissen zu einer gemeinsamen Fläche zusammenfassen kann.

Franz

Ob sie sich in einem Punkt berühren dürfen ist nicht ganz klar (laut deutschem Wiki und laut OGC ja, laut englischem Wiki müssen sie disjunkt sein), eine gemeinsame Kante ist aber auf jeden Fall verkehrt.

Nur keine Panik :slight_smile:
Auch Unis haben teilweise Dependancen auf der ganzen Welt. Die trägt auch niemand in eine site-Relation ein. Ich behaupte sogar, dass es keine Uni gibt, bei der alle in der Stadt verstreuten Institute komplett in eine site- Relation eingetragen sind.
Dasselbe dürfte für die Standorte großer Firmen innerhalb einer Stadt gelten. Ist auch nicht nötig.
site-Relationen sind eine Mögllichkeit unter bestimmten Bedingungen, kein Muss, bei Gebäuden auf einer zusammenhängenden Fläche (wie hier) schon gar nicht.

Wenn sie sich in einem Node berühren und dieser Endpunkt der Linien ist, dann ist es sicher illegal, denn dann ist garkeine Fläche definiert. Es gibt dann ja mehrere Möglichkeiten, diese zu outer-Ringen zusammenzusetzen.

Ist der Node in beiden Linien und ist er irgendwo kein Endpunkt, dann tritt das Problem so nicht auf. Aber ganz normales Aufteilen beim Editieren ohne jeden Bezug zum MP, kann dann zum Problem führen. Ohne Laden der Umgebung kann da auch kein Editor warnen. Das ist eine beknackte Situation.

Gibt es eine Berührung in einem Punkt einer der Linien, so dass nur eine der Linien den Node hat und die andere nur durch geht, dann kann die Zulässigkeit von der Genauigkeit der Berechnungen abhängen. (Überlappt es oder überlappt es nicht?) Auch das ist eine beknackte Situation.

Praktisch gesehen sollte man also Berührungen meiden wie die Pest.

Es gibt zwar theoretisch mehrere Möglichkeiten, outer-Ringe zu bilden, aber meines Erachtens definieren diese immer die gleiche Fläche. Wenn man diejenigen Möglichkeiten verwirft, die Ringe mit doppelten Nodes bilden, sollte die Lösung sogar eindeutig sein.
Daher sehe ich keinen Grund, dies zu verbieten. Wenn man real existierende Flächenverteilungen aufgrund solcher Verbote nicht mehr exakt mappen kann, ist dies auch eine unglückliche Situation.

Die Flächen sehen nur für Menschen gleich aus. MP-Algorithmen basieren aber gewöhnlich darauf, dass “Innen” und “Außen” in einem Ring nicht mitten im Umlauf die Seite wechseln. Nehmen wir eine “8”: Wenn man hier zwei Ringe sieht oder in Form einer “3” beginnt, dann wird die Fläche normal berechnet. Geht man dagegen oben im Uhrzeigersinn und unten gegen den Uhrzeigersinn, so wird die Differenz der beiden Flächen berechnet.

Dann müssten bei der Verarbeitung jedesmal sämtliche denkbaren Ringsysteme ermittelt werden.

Ich denke, dass OGC das schon verbietet. Es geht also um die Frage, ob OSM eine zweite Ausnahme zu OGC erlauben sollte.

Ja. Aber man kann z.B. in der Mitte der “8” zwei Nodes statt einem machen und der Übersichtlichkeit halber einen auch noch ein paar Millimeter verschieben. Das schränkt die Abbildbarkeit der Realität nicht wirklich ein.

Da habe ich ein ungutes Gefühl: Wenn ein Algorithmus die Realität nicht abbilden kann, besteht die Lösung normalerweise nicht darin, das Abbild der Realität zu ändern (on-the-ground-Regel).
Außerdem ist diese Lösung nicht ganz ohne Probleme: Dann hängt es nämlich von der internen Darstellung der Koordinaten (Integer/Real/Bitzahl/Rundung) ab, ob die Flächen als getrennt oder zusammenhängend gesehen werden.
Bei identischen Koordinaten (Berührung im Punkt) kann das nicht passieren.