Hier bei mir im Ort besitzt eine etwas größere Firma mehrere Gebäude entlang einer Straße, die nicht alle baulich miteinander verbunden sind.
Normalerweise zeichne ich in so einem Fall einfach das Firmengelände ein und gebe diesem dann den Namen der Firma.
Nur in diesem Fall geht das nicht, da das Firmengelände durch das Betriebsgelände einer anderen kleinen Firma in 2 Teile gespalten wird. Von dem einen Teil der Firma in den anderen kommt man nur über die öffentliche Straße.
Kann man mehrere voneinander getrennte Firmengebäude in einer Relation zusammenfassen und dieser den Firmennamen zuweisen?
Das Ticket ist verwegen, da die Site-Relation fernab aller Standards ist. Es gibt einen ganzen Haufen Vorschläge, wie Objekte zusammenzufassen sind. Ich bevorzuge type=collection.
Für disjunkte Firmengelände sind solche Experimente nicht nötig, ein stinknormales Multipolygon genügt völlig. Wenn man aus irgendeinem Grund nicht die Firmengelände, sondern nur die Gebäude mappen will, funktioniert ein Multipolygon ebenfalls, auch wenn es genau genommen nicht ganz richtig ist, da es sich nicht um 1 disjunktes Gebäude, sondern um verschiedene Gebäude handelt.
Genauer gesagt kann ein Multipolygon mehrere unzusammenhängende Flächen enthalten. Das geht indem man für jede Fläche die/den Rand-Weg(e) in die Relation aufnimmt. Die Renderer werden den Namen wahrscheinlich in die Mitte aller Flächen setzen, was nicht immer gewünscht oder sinnvoll ist.
@Atalanttore
Ich würde einfach beide Gelände einzeln mit jeweils dem Firmennamen erfassen. Dann hast du zweimal den Firmennamen, was aber nicht wirklich stört, da es ja zwei verschiedene Standorte sind. Gegebenenfalls kann man auch einen Standort-Namen ergänzen, falls das bei der Firma so unterschieden wird.
In Bonn haben die Telekom und die Post (Post, Postbank, DHL) eine große Zahl von Gebäuden über eine weite Fläche verteilt. Da machen wir kein Heck-Meck mit, sondern geben eben jedem Gebäude seinen Namen. Das kann der generische Name sein oder ein spezifischer wie “Postbank ServiceCenter” oder “TCom Systems”, je nachdem wie es am Gebäude angeschrieben ist.
Im Prinzip richtig, wobei die site-Relation halt mehr Möglichkeiten bietet. Du kannst einen Perimeter angeben und
sagen wo das Label hin soll, punktförmige Objekte hinzufügen etc.
type=collection kenne ich bis jetzt nur zur zusammenfassung thematisch verwandter elemente. zB “alle krankenhäuser in der stadt XYZ”. für geografisch naheliegende elemente ist sehr wohl type=site besser. und einige akzeptierte proposals die das genauso auslegen gibt es auch bereits (playground equipment, parking spaces,…).
Mapnik beschriftet jedes Teilareal einzeln, Osmarender setzt die Beschriftung in den Mittelpunkt des Hüllrechtecks. Richtig wäre ein Mittelweg: Wenn die Teilflächen wenig Abstand zueinander haben im Vergleich zu ihrem Flächeninhalt, sollte der Osmarender-Ansatz verfolgt werden, sonst der Mapnik-Ansatz.
Wo das Label hin soll, soll und kann der Renderer entscheiden, s.o. Es wird zu viel Aufwand fürs Tagging betrieben und zu wenig für die Weiterentwicklung der Renderer. Gerade mit der rasant wachsenden Datenmenge wird die Entwicklung intelligender Renderer immer wichtiger. Renderer-Regeln sollte man aus einer großen Datenbank tunlichst heraushalten.
Was mit einem Perimeter gemeint sein soll, ist mir unklar.
Nodes sind in MP nicht vorgesehen, ebensowenig wie lineare Objekte und Unterrelationen. Das ist der Grund, warum wir einen Relationstyp brauchen, mit dem man beliebige Objekte zusammenfassen kann. Dafür ist Site das falsche Wort, collection passt besser.
So eine Relation ist sinnlos, denn alle amenty=hospital in einer Fläche lassen sich leicht automatisch ermitteln.
Was heißt “geografisch naheliegend” genau? Bei wieviel m ziehst du die Grenze und warum?
in der theorie schön und gut, aber wenn ich das tagging bei ca 400 haltestellen einer stadt ändern muss, weil sich zB der name des öffi-betreibers geändert hat, will ich in josm nicht die ganze bbox runterladen müssen. sollte irgendwann mal die api überarbeitet werden und das selektive runterladen von daten, basierend auf diversen filterkriterien ermöglichen, kann man nochmal drüber reden.
Wie ich in meinem Beitrag schon beschrieben habe, liegen die Gebäude einer etwas größeren Firma alle entlang der selben Straße. Etwa in der Mitte wird das Firmengelände durch das Betriebsgelände einer anderen kleinen Firma (ca. 50 m breit) in 2 Teile gespalten. Von verschiedenen Standorten kann also keine Rede sein und sind es auch nicht, da es nur eine Verwaltung gibt.
Da lese ich jetzt keinen zwingenden Grund raus, warum man die nicht einfach getrennt erfassen sollte. Bei meiner Firma hier sind die beiden Firmenteile durch eine Eisenbahnstrecke getrennt. Für die Firma ist das hier zwar nur ein Standort, aber trotzdem wird der eine Teil als Werknord und der andere Teil als Werksued bezeichnet.
Ich wuesste jetzt nicht, welchen Mehrwert es haette, wenn man das irgendwie aufwendig zu einem Konstrukt zusammen fassen wuerde. Das ist reiner Spielkram, da interessiert sich letztendlich keiner fuer. Viel wichtiger ist es dagegen, zu erkennen, welcher Teil von beiden denn nun derjenige ist, mit dem man zu tun hat (als Lieferant, Besucher oder was auch immer).
Wichtig sind m.E. deshalb folgende Punkte:
beide Flaechen sind als zur Firma XYZ gehoerend markiert
der Haupteingang ist markiert
die verschiedenen Zufahrtstore (falls sie benannt sind) sind markiert
die einzelnen Gebaeudebezeichnungen (falls sie bekannt sind) sind markiert