unmittige Flächen

Wie kann man Flächen erfassen, bei denen die Bezeichnung immer an einer anderen Stelle als der Mitte der Fläche erscheinen soll?
Beispiele dafür wären Grenzrelationen, Bahnhöfe oder Inseln. Ich hätte es es mit einem MP mit der Rolle “label” gemacht, aber das wird wohl zu wenig unterstützt.

Das mit dem Multipolygon und dem label ist mir auch die einzig bekannte vorgesehene Möglichkeit. Je mehr dieser benutzt wird, desto wahrscheinlicher wird eine Beachtung dieses Schemas (hoffentlich), also ruhig fleißig verwenden. :slight_smile: Und bei Grenzrelationen kann ich das teilweise auch nachvollziehen (bspw. damit der Gemeindename auf bebautem Gebiet liegt), aber warum bei Bahnhöfen oder Inseln?
Möglich wäre es evtl. auch einfach den Inhalt der Fläche in einen Knoten zu packen und diesen dann dort zu platzieren wo man ihn haben möchte. Aber das dürfte unerwünscht sein.

Eine Grenzrelation ist eh eine Relation, da dürfte es trivial sein, ein Label einzufügen. (Das wird bisher leider viel zu selten gemacht und daher gibt es ein schönes Nebeneinander von place-nodes und Grenzrelationen.) Bei Bahnhöfen und Inseln kann ich es hingegen weniger nachvollziehen. Gibt es da konkrete Beispiele, wo die Bezeichnung an einer unpassenden Stelle erscheint?

Bahnhöfe haben oft seltsame Formen, Inseln vermutlich auch (da kenne ich mich nicht so aus) :wink:

Ui, das ist aber böses Mappen für den Renderer. Die Fläche ist ja kein Multipolygon und die Schrift steht da auch nicht mitten in der Gegend rum (in echt meine ich). Also bitte bloß keine Multipolygone etc. dafür anlegen. (Wenn das Merkmal für die gesamte Fläche gilt, dann kann auch die Beschriftung überall angezeigt werden. Wenn die Beschriftung nur für einen bestimmten Punkt gilt, dann hat die Fläche nichts mehr damit zu tun.)

Die Platzierung von Beschriftungen und Symbolen ist eine Wissenschaft für sich und automatisiert gibt es da nichts absolut zufriedenstellendes.

Nein, weil es für alle Renderer ist :wink:

Ok, das ist natürlich ein schwieriger Fall. Andererseits ist die Frage ob der Bahnhof wirklich so weit geht und wenn ja, ob man das so weit, bis zur Ettlinger Allee, mappen muss. Schätzungsweise ist der ursprüngliche Gedanke des “Bahnhofs eintragen” nicht so weit gegangen. :wink: Auch stellt sich dann ja die Frage ob nicht eine Menge mehr Bahnhöfe solche Ausmaße haben?

Eben genau deswegen wäre ja ein “label”-Tag nicht schlecht. Dann kann der Renderer es selber machen oder wenn er möchte auch den Vorschlag eines Mappers beachten.

Die Grenze eines Bahnhofs sind die Einfahrsignale (in OSM erfasst), wo nicht vorhanden die Einfahrweichen (hier im Norden zutreffend), also ja. Und zum Mappen: Es ist eben die Fläche des Bf, wie auch ein Parkplatz eine Fläche hat. Einfach irgendwo abschneiden, damit die Mitte da ist, wo man den Marker haben will, wäre jedenfalls fälscher.

Ganz einfache Bf meist nicht, bei grösseren Bf wird das häufiger.

Ok, wenn das so korrekt ist, dann ist das korrekt. Aber, sehe ich das richtig, dann stellt sich neben der Frage nach der richtigen Platzierung des Namens auch die Frage, wie ein Kartennutzer zu den Bahnsteigen/in die Nähe/zu den üblichen Zugangsstellen gelotst werden kann. Oder? Ein normaler Kartennutzer, der zum Bahnhof Karlsruhe Albtalbahnhof möchte, will wohl eher weniger in die Nähe des Parkplatz Hauptbahnhof P7, sondern wohl eher in die Nähe von Bezos Grill. :slight_smile: Und das Problem wiegt wohl um einiges schwerer als das der richtigen Namensplatzierung (auch wenn man ggf. das eine mit dem anderen (halbwegs) lösen könnte, oder?

Kommen denn alle Renderer und insbesondere deren Importprogramme mit einem Label am Multipolygon zurecht? Bisher war das ja nur bei site-Relationen und bei Grenzen aller Art verbreitet… Wenn der Renderer das ignoriert ist es ja ziemlich egal. Aber wenn der Importer ein Multipolygon wegwirft, weil er alles als “kaputt” betrachtet woraus er keine Fläche bilden kann, wäre das schon doof.

Falls ihr euch für Labels entscheidet, sollte das dann auch ins Wiki. Der nächste, der was mit Multipolygonen programmiert, orientiert sich vielleicht daran und erwartet linienartige “outer” und “inner” als Members, keine zusätzlichen Punktobjekte.

Grüße, Max