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

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.

Ich hab bezüglich des Verschiebens auch ein schlechtes Gefühl. Aber der Algorithmus braucht es nicht, für den muss man nichts verschieben. Es ging da nur um Probleme der Mapper beim Editieren.

In meinen Augen und nach meiner Erfahrung lassen sich touching-Rings, also wenn sich das Outer an genau einem Punkt berührt, in der Regel immer vermeiden. Bei Gebäuden halte ich es für äußerst unwahrscheinlich, daß sich die Umgrenzung des Gebäudes auch in Realität an genau einem Punkt berührt. Entweder haben die Gebäude da immer eine größere Lücke, oder das Gebäude hat einen Innenhof. Ähnlich ist es auch bei Landuse-Polygonen/Multipolygonen, hier kann man touching-Rings immer vermeiden.

Einzig bei Grenzen, also z.B. admin-Grenzen, Schutzgebietsgrenzen beobachte und kenne ich Grenzen, die sich an genau einem Punkt berühren.

Um zum Ausgangspost zurückzukehren, halte ich type=multipolygon für den falschen Relationstyp. Siehe https://forum.openstreetmap.org/viewtopic.php?pid=682335#p682335

Sven

Nochmals vielen Dank für Eure rege Diskussion! Da das Ergebnis für das genannte konkrete Beispiel recht klar ist (Lösung (1) empfiehlt sich), werde ich dort – und bei 2, 3 anderen mir bekannten ähnlichen Fällen – gelegentlich die Kollegen ansprechen, ob wir (sie/ich) das nicht entsprechend einfacher mappen und das MP entfernen sollen. :wink: