Proposal Indoor- Beschilderung Relation

Hallo zusammen,
ich heiße Julia und schreibe meine Masterarbeit über Indoor- Beschilderungen in Zusammenarbeit mit der Firma Mentz Datenverarbeitung GmbH. Beim letzten Stammtisch in München konnte ich mich bereits mit andren OSMlern austauschen. Ich dachte ich mach mal ein Forum auf, damit ich mehrere Mapper erreichen kann.
Zu meinem Vorschlag:
Es gibt ja schon viele Relationen die Beschilderungen anzeigen, aber für eine Indoor- Beschilderung nach meiner Meinung vielleicht noch nicht ausreichend. Deshalb habe ich hier mal einige Sachen für euch und ich freue mich über konstruktive Kritik.
• Es sollte für jedes Ziel eine Eigene Relation erstellt werden, wobei die to´s das Ziel markiert.
• Es wird in Symbolen und Text unterschieden, demnach sehen Relationen für Text anders aus als für Symbolen.

Mitglieder der Relation
OSM-Elemente sollten nur Punkte sein. An dem Sign Punkt muss die Levelangabe vergeben werden. Und hier wäre ein neuer Tag nicht schlecht, das man weiß, wo sich das Schild befindet im Moment gibt es nur das Key:traffic_sign, ich hatte überlegt Key=signpost=yes, oder so ähnlich.

sign, mit einem einzigen Mitglied welches den Ort des Wegweisers anzeigt. Das Schild kann mit dem Fußweg verbunden sein, muss aber nicht, es kommt auf die Örtlichkeit drauf an und wird davon abhängig gemacht.
from, eins oder mehrere Mitglieder verbunden mit dem Fußweg. An der Stelle, von wo aus man aus das Schild lesen kann.
to, eins oder mehrere Mitglieder verbunden mit dem Fußweg. Kommt dahin, wohin das Schild den Fahrgast leiten soll.

Beispiel Bild

Attribute für ein Symbol

type= destination_sign
destination=Tram
destination:symbol=Tram_red
destination:url=https://wiki.openstreetmap.org/w/images/thumb/a/a6/Tram-Logo.svg/240px-Tram-Logo.svg.png
foot=Yes

Attribute für ein Text

type=destination_sign
destination=Ausgang Zweibrückenstraße
foot=yes

Hallo!
Sehe ich das richtig, dass für jedes Ziel auf dem Schild (WC, V-K-Musäum, Tram, Bus, SEV, Zweibrückenstreaße, Dt. Museum, Muffathalle etc) je eine Relation angelegt werden soll?
Und das bei jedem Schild im Bahnhof?
Da sind wir schnell bei >100 Relationen in einem mittelgroßen Bahnhof.
Welcher Otto-Normalmapper wird sich an den Bahnhof noch rantrauen!?

Edit: Was wäre bei “Tram” eignetlich genau das Ziel? Die platforms? Das wären am Isartor 23-4, können vor einem Hauptbahnhof aber auch schon mal 6 oder 8 sein. Oder den zentralen Punkt (public_transport=station) in der Mitte? Dann wäre das Fußgängerrouting gestört.

Ja, so würde ich das auch aus Relation:destination_sign rauslesen, was dem o.g. Vorschlag ja ziemlich nahe kommt

EDIT: Ich habe das mal für einen Wanderwegweiser, wie er unter information=guidepost zu sehen ist, gemacht … Hölle … und nein, ich will es nicht mehr tun

Und wieder mal wird ein access -Tag (foot=*) missbraucht.

ich möchte nur vorbeugend darauf hinweisen, dass keine sammelrelationen erwünscht sind.

Hallo,
ich würde hierbei nur entscheidungstragende Ziele als Wichtig erachten, hier also gehe ich nach links oder rechts. Folge Ausgang Zweibrückenstraße oder Ausgang Isartor.
Die restlichen Ziele WC, Treppe…) würde ich gar nicht als Relation aufnehmen. Wer detaillierte Informationen braucht, könnte sich das ja ausbauen.
Und das to müsste gar nicht unbedingt an das entsprechende Ziel, sondern da anbringen, wo man weiß das Fußgänger -Routing teilt sich hier den Weg um genau zu dem Ziel zukommen. Oder als Ziel das nächste Schild, welches demjenigen eine neue Entscheidung abnimmt auf dem Weg zum Ziel.
Das sich niemand mehr ran traut hatte ich auch bedenken, deswegen wollte ich nur Punkte und keine Ways als Mitglieder nutzen.

Hallo Julia,

du willst doch eigentlich nur die schon existente, aber spärlich verwendete Relation type=destination_sign für unterirdische Stationen anwenden, oder?

Prinzipiell habe ich nichts dagegen einzuwenden, denn förmlich spricht nichts dagegen. Vor gut einem Jahr habe ich selbst mal auf der Bundesstraße 293 zwischen Wössingen und Gemmingen eine größere Anzahl solcher Relationen erstellt. Meiner Meinung nach hat der Relations-Ansatz gegenüber dem Ansatz mit destination=* einige Nachteile:

(1) Relationen schrecken Mapper ab und sind einfach schwerer zu handhaben.
(2) Wegweiser-Relationen brechen genauso leicht wie Abbiegebeschränkungs-Relationen. In einem U-Bahnhof rechnet niemand mit Wegweiser-Relationen (außer er schafft bei Mentz DV oder interessiert sich für ÖPNV-Mapping).
(3) In vielen Fällen sind sie einfach überflüssig. Wenn das Ziel eine Einbahnstraße ist, kann man einfach destination=* verwenden, wie es auf Autobahnen und autobahnähnlichen Straßen üblich ist.

Eigentlich braucht man diese Relationen gar nicht. Wenn das Ziel keine Einbahnstraße ist, kann man ja einfach destination:forward=* bzw. destination:backward=* verwenden. Mittlerweile tun sowohl iD als auch JOSM Keys mit forward- oder backward-Suffix automatisch reparieren, wenn der Way gedreht wird. Außerdem ist das für die Mapper leichter verständlich.

Viele Grüße

Michael

Wenn es nur um die Existenz der Schilder und ihren Standort geht, dann braucht man keine Relation - man könnte sie dann z.B. als Node mit entsprechenden Tags mappen. Auch um den Weg zu den ausgeschilderten Zielen zu finden, braucht man keine Relation. Daher würde mich interessieren: Was genau ist denn der geplante Anwendungsfall?

spekulier Ich glaube da geht es um dasselbe, wie demjenigen, der die Idee zur destination_sign-Relation hatte – in einem Navi oder einer App anzeigen/ansagen: “Folgen Sie der Beschilderung zum Südausgang.” Nützlich fände ich das als Ortsfremder in großen Bahnhöfen schon.

@EJ_: Wie lautet eigentlich der Titel der Arbeit? :slight_smile:

Viele Grüße

Michael

Hallo Julia,

So wie ich das Corporate Design der Deutschen Bahn kenne, dürfte dieses Schild auf einem Bahnsteig hängen. Ich würde in diesem Fall die rechte Treppe so taggen (OSM-Way-Richtung zeigt vom Bahnsteig weg):
destination:forward =Ausgang Isartor;Valentin-Karlstadt-Musäum
destination:symbol:forward=conveyor;stairs;tickets;information;toilets

Linke Treppe:
destination:forward =Ausgang Zweibrückenstraße;Deutsches Museum;Muffathalle
destination:symbol:forward=conveyor;stairs;tickets;information;bus;tram;SEV

Ob man conveyor und stairs taggen an die Treppe taggen möchte, weiß ich nicht. Eigentlich ist es unnötig, andererseits will man vollständige Schilder rendern können.

Die obigen Tags destination:symbol*=* stammen vom Proposal Destination Details von User imagic (im Entwurfsstatus seit 2012).

Welches Symbol man dann als Datennutzer nimmt, sollte man vom operator=* der Station (operator=* vielleicht an den Way taggen?) abhängig machen. Meistens haben die städtischen Verkehrsbetriebe andere Beschilderungen (bzgl. Farbe und Symbolik) als die DB.

Gibt es außer Stuttgart Hbf eigentlich noch einen großen Bahnhof, der keine weiß auf dunkelblauen Schilder hat. Ich war die letzten zwei Jahre nur selten in Stuttgart, aber dort hingen recht lange noch die alten weißen Schilder mit hellblauem Rand und schwarzer Schrift. Solche Theme-Wechsel sollte man irgendwie taggen können, ich halte es aber erstmal für unwichtig.

Viele Grüße

Michael

Für diesen Zweck würde es genügen, jedem Ausgang einen Namen (“Ausgang Zweibrückenstraße”) oder eine Richtungsinformation (“Ausgang Richtung Deutsches Museum”) zu geben.

Hallo,
der Titel heißt Indoor-Navigationverfahren auf Basis von OSM, mit der Ausgabe von Wegweisungen. Und wie Nakaner schon richtig vermutet hat, soll es im Großen und Ganzen die Wegweiser den Fahrgästen bei der Fahrplanauskunft angezeigt werden, zu welchem Ausgang sie gehen sollen auf welchem Gleis sie sich stellen sollen usw… das kann man später auch für Smartwatch verwenden, wenn die Indoornavigation mittels Bluetooth Beacon oder integrierte W-LAN Netze ausgebaut wurde. Deswegen ist die Position der Schilder schon wichtig, ich würde sie ungern an Treppen anbringen.
Gerade weil es so viele unterschiedliche Schilder gibt, wollte ich einen Link mit dem jeweiligen Symbol in dem TAG symbol:url anhängen.
Zum Anfang wollte ich das ganze Schild in die Relation bringen, weil es fast immer ein gleiches Schema hat. Mit den Zusatztags=
:end ==> Reiseinformation (Gleis, Ausgang,…)
:psv==> Verkehrsinformation (TRAM, BUS…,.)
:service ==> Serviceinformation (Ticket, WC…)
Aber das würde die ganze Sache zu sehr aufblähen…, wie seawolff schon geschrieben hat, reicht es vollkommen den Reisenden ein Ziel der Richtung anzusagen.

Hallo Julia,

Es gibt in den Stationen der DB (egal ob ober- oder unterirdisch) ja min. zwei Arten von Beschilderungen:

(1) Schilder unter dem Schild des Bahnhofnamens (siehe Bild von dir von München Isartor). Sie zeigen dem Fahrgast welchen Bahnsteigabgang er nutzen sollte, um zum gewünschten Ausgang/Stadtteil/POI zu gelangen. Bei diesen Schildern ist die Position des Schildes doch egal, wenn man kein 3D-Rendering der Station erstellen möchte (z.B. auf dem Handheld-Gerät des Kunden)?

(2) Schilder am Bahnsteigabgang (hängen über der Treppe am Treppeanfang). Bei diesen Schildern würde ich ein Tagging an den Way der Treppe bevorzugen (wenn die Treppe an den Bahnsteig direkt anschließt und kein kurzer Footway dazwischen liegt).

Dresden-Klotzsche:

Bild: Mapillary/ubahnverleih, CC-BY-SA

Hamburg Dammtor:

Bild: Mapillary/ubahnverleih, CC-BY-SA

Viele Grüße

Michael

Hallo Julia,

ich habe gerade eben in Karlsruhe Hbf die level=*-Angaben an Nodes, Ways und Multipolygonen überarbeitet (obwohl Bahnhofshalle und die Unterführung auf derselben Ebene liegen, war die Halle mit level=0, die Unterführung mit level=-1, die Bahnsteige 1 bis 14 mit level=0 und die Bahnsteige 101 und 102 mit level=1 getaggt). Dabei ist mir aufgefallen, dass ihr (haytigran) im April 2014 Wegweiser-Relationen gemappt habt.

Ich würde die Relationen natürlich auch gerne umstellen, verstehe aber den Sinn von level=* an der Relation nicht. Eure Dokumentation im Wiki meint level=*, käme an den Ziel-Node, nicht an die Relation.

Btw, Anstoß dieses Aufräumens, war eine unvollständige Darstellung auf OpenLevelUp!

Viele Grüße

Michael

Hallo Nakaner,

diese Relationen von ihm, beruhen auf dem Relation- Schema des normalen Wegweisers im Outdoor Bereich. Da im innen Raum neue Aspekte wie Level und erhöhte Anzahl an Wegweisern hinzukommen, habe ich es mir zur Aufgabe gemacht diese Relation anzupassen.
Deswegen würde ich sie nun folgendermaßen umändern.
Das Level kommt an den Knoten mit der Rolle des Sign und hier würde ich den Tag= guidepost anbringen.
Die Rollen via sind meiner Meinung im Innenraum zu viel und würde sie daher löschen, gerade um die Bahnhöfe nicht mit Relationsmitgliedern zu “vermüllen”. Des Weiteren müssten die “to” und “from” Rollen an den Objekttypen Node und nicht an Ways angebracht werden.

Wenn ich ehrlich bin, traue ich der Wahrheitslage der Schilder auch nicht ganz. Mit dem Hintergrund, dass wir, als das gemappt wurde, noch im Anfangsstadium (was die Wegweiser angeht) waren, ist es gut möglich, dass hier einige Fehler vorhanden sind. Es sieht ja leider auch so aus, dass die Positionen der Signs nicht stimmen, sodass ich vorschlagen würde, die Wegweiser-Relationen dahin gehend NEU zu modellieren.

Viele Grüße
Julia

Dem stimme ich zu. Ich werde wohl mal selbst (Bahnhof liegt 7 Fußminuten von mir entfernt) Schilder mappen gehen (nachdem mapper999 dort schon die Einspeiseleitungen in die Oberleitung und jeden einzelnen Masttrenner mappt).