Hallo Tracy, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: > Liebe OSM Gemeinde, > > Wir wollen euch noch mal genauer erklären was wir machen. Das ist super ;) [...]
> Einige Daten sind allerdings noch unvollständig für unsere > Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam > mit der OSM Gemeinde. Das klingt gut. > Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote > oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen > Verkehrsbetrieben, wir können die Informationen von dort bekommen und > nachpflegen. Das klingt gut - aber nach Import, deshalb bitte die Import-Richtlinien berücksichtigen, wenn ihr nicht jede Haltestelle selbst kontrolliert dabei. Eine Alternative ist oft, die Daten öffentlich und für die Nutzung freigegeben zu hinterlegen, damit man "verteilt" die Haltestellen anhand dessen überprüfen kann. >[...] > > Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die > Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder > deren Haltepositionen rechnen wir mit einem Punkt). > > Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit > Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben > oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine > für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der > Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und > Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). > > Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, > ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente > müssen „ways“ sein, sonst kann man nicht darüber routen. Fast richtig. Ein Aufzug muss nicht zwingend ein way sein, um darauf route zu können. Beispiel: .____x-----' .x und ' seien Nodes, ____ und ---- jeweils dazwiscchen ways. x sei ein Aufzug und als solcher getagged (auf einem Node. ____ trägt außerdem level=0, x trägt level=1 (was jeweils das Stockwerk angibt). Das Routing mit Berücksichtigung des Aufzugs ist hier problemlos möglich. Ebene Wege, Treppen, Rolltreppen und Rampen sind üblicherweise ways in OSM, Aufzüge aber nicht, weil sie kaum eine horizontale Ausdehnung haben. Technisch ist das aber kein Problem auch im Routing zu berücksichtigen. > Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen > von Plattformen gefunden: > > · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich > bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner > Platz/Hohe Straße) stimmt, und sollte für euch kein Problem darstellen. > > · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, > eignet sich bei Seitenbahnsteigen (Beispiel, ….) auch das sollte kein Problem sein zu nutzen. > > · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an > beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München > Ost) Falsch: Wieso sollte das Splitten notwendig sein? Die Plattform ist die von den Gleisen (z.B.) 2 und 3. Die linke Seite bietet den Zustieg zu Gleis 2, die rechte zu Gleis 3. Es bleibt aber erstmal trotzdem ein Bahnsteig. Wieso man diesen horizontal aufsplitten muss, verstehe ich nicht. Wenn ich zu GLEIS (!) 2 route (da fährt der Zug ab), dann route ich (so machen das bei Adressen auch alle gängigen Router) zum nächsten Punkt, der erreichbar ist. Das ist in diesem Fall der Bahnsteig 2/3, und da die linke Seite. Wo ist das Problem? Warum muss dafür der Bahnsteig gesplittet werden? und vor allem: Warum in den Rohdaten? > Keine der drei Modellierungsarten ist unsere Erfindung, statt der > gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten > (Multipolygonen), das ist aber noch komplizierter und das haben wir noch > nirgends gesehen. Ich find auch kein Beispiel; logisch wäre es aber meines Erachtens schon, und es würde mit Multipolygonen auf ein etabliertes OSM-Schema zurückgreifen, ohne dass neue Erfindungen mit falschen Daten gemacht werden müssten. > > Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man > in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann > Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel > kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen > wir diese Teile in einer Relation zusammen. Also trennt ihr erst um dann wieder per Relation zu verbinden... Selbst wenn ihr trennen müsstet (was ich bezweifle), wäre die Relation unnötig, denn die lässt sich einfach aus der Geometrie herleiten (die beiden Bahnsteige sind miteinander verbunden über eine gemeinsame Kante). Meine Empfehlung (darf gerne von anderen noch kommentiert werden) wäre: Eine Plattform ist eine Plattform und kein Gleis. Eine Plattform gehört z.B. zu zwei, manchmal auch zu drei oder mehr Gleisen, und das ist erstmal gar kein Problem. Ein Gleis ist ein Gleis und hat eine Nummer. Wenn ein Zug auf Gleis 2 einfährt, dann kann man an der Plattform 2/3 in Richtung Gleis 2 einsteigen, aber der Zug fährt nicht auf Plattform 2 ein, sondern auf Gleis 2. Um zu Gleis 2 zu routen, muss ich wissen, dass ich zur Plattform routen muss, die dem Gleis 2 am nächsten liegt (und falls das mehrere sind, die, die in ref auch (!) auf Gleis 2 referenziert). Auf dieser Plattform kann ich dem Nutzer dann noch sagen, wo sein Gleis liegt (links oder rechts, z.B. für Blinde notwendig). > Wir brauchen also die Plattformen und alle Treppen, Rolltreppen und Aufzüge > einzeln. Für Plattformen s.o. Beim Rest einverstanden. > Der VRR will auch Echtzeitanpassung für Rolltreppen und Aufzüge. > Wenn diese außer Betrieb sind, z.B. durch Wartungsarbeiten, dann muss das > im Routing berücksichtigt werden. Wir brauchen da noch eine eindeutige > Identifikation. Die ist nur dann sinnvoll, wenn ihr sie öffentlich zur Verfügung stellen könnt, und auch dann nur, wenn es sonst unklar ist.7 Bitte im Hinterkopf behalten, dass ihr leider vermutlich nicht dauerhaft über die nächsten zig Jahre eure Daten pflegen könnt, geschweige denn jede Änderung in der Realität schneller mitkriegt als die OSM-Community. Und: Für Wartungsarbeiten etc., die nicht sehr lange dauern, bitte vorsichtig in OSM selbst. Das ist ein immer wiederkehrendes, offenes "Problem", aber führt eher zu negativen Effekten. Auch bei OSM-Daten haben Navis nicht ständig eine aktuelle Karte, sondern z.B. alle paar Monate neu generierte Offline-Daten. Das ist prinzipiell schneller möglich als bei anderen Anbietern, aber das heißt nicht, dass es schneller aktualisiert wird. Wenn dann eure 3-Tage-Wartung der Rolltreppe im Kartenmaterial von Max Mustermanns Navi für die nächsten 6 Monate festgelegt ist, ist das Mist. > Die OSM Modellierungen dieser Verbindungselemente sind im OSM Wiki > beschrieben. > > Tunnel sind oft schon in den Daten vorhanden. Die sind für uns als > Wegelemente sehr hilfreich. Allerdings wollen wir auch Karten für den > Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen > ist das irreführend. Wir brauchen also zusätzlich Flächen. Generell wollen > wir alle öffentlich begehbaren Flächen in den Bahnhöfen darstellen und > deshalb wollen wir sie erfassen. Damit schneidet ihr ein weiteres leider noch weitgehend offenes Thema an, bitte im Detail ausdiskutieren (auch wenn das Arbeit bedeutet). Letztlich geht es hier um die flächige Erfassung von Verkehrswegen. Das ist auch jetzt schon auch für Straßen möglich, aber bei weitem nicht etabliert. > Über den VRR und die Verkehrsbetriebe > haben wir Zugang zu den Bahnhöfen. Wir bekommen auch Erlaubnisse zum Messen > und Fotografieren und oft auch Einblick in Pläne. Stimmt, ich erinnere mich an Zeiten vor meiner OSM-Aktivität, dass Bahn und Co da sehr eigen sind. Die meisten Mapper stören sich daran allerdings vermutlich sehr wenig. Einblick in Pläne kann praktisch sein, kommt aber darauf an, was man draus macht. OSM ist kein CAD-Repository für detaillierte Baupläne, und ich bin mir auch nicht sicher, ob es ein solches werden soll. > Weitere Datenelemente die wir brauchen, sind die oben erwähnten Haltepunkte > auf den Schienen oder die Haltepunkte der Busse vor dem Bahnhof. Dies > Punkte brauchen wir um einen Weg auf die Karte zeichnen zu können. Dort ist > Anfang oder Ende des Wegs im Fahrzeug und der Übergang auf den Fußweg. Das > sind bekannte OSM Objekte ( > http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position) ja. > Als letztes Datenelement brauchen wir die Eingänge. Die gibt es auch als > OSM Objekt (http://wiki.openstreetmap.org/wiki/Entrance). Damit bestimmen > wir, ob ein Bahnhof überhaupt barrierefrei ist oder nicht. Er ist dann > barrierefrei, wenn es zu jeder Plattform einen Eingang gibt, von dem aus > ein Rollstuhlfahrer auf die Plattform kommt. Fehlannahme: Der Bahnhof beginnt nicht zwingend mit dem Eingang. Normalerweise dürfte als entrance die Tür eingetragen sein, eine Stufe VOR der Tür ist damit noch nicht berücksichtigt. > Wenn wir Indoor-Karten erstellen wollen, brauchen wir eine vollständige > Gebäudemodellierung. (Link..) Soweit sind wir aber noch nicht. Wir werden > berichten, wenn wir mit dem Konzept fertig sind. Indoor-Modellierung ist gefährlich, viel diskutiert und recht stark umstritten. Hauptsächliche Herausforderung: Das ganze muss im Editor (jedem größeren Editor, also zumindest iD und JOSM, evtl. noch Potlatch2) bearbeitbar bleiben. Aber es gibt noch einige andere Punkte, die dabei zu berücksichtigen sind. > Generell gehen wir bei der Datenerfassung extrem vorsichtig vor. Wir wollen > niemand etwas kaputt machen. Wir sind schon seit einiger Zeit mit der > Münchner OSM Gruppe in Kontakt und haben viel gelernt. Speziell achten wir > auf folgende Punkte. > > · Wegelemente die bereits vorhanden sind müssen erhalten bleiben, > da sonst die OSM Router Probleme bekommen Versteh ich so nicht, was du meinst. Kannst Du (oder jemand aus München ;) ) ein Beispiel dafür geben? > > [...] > > Wir kontrollieren unsere Erweiterungen in Keep Right zum größten Teil. Keep Right kann nur bekannte Fehler finden. Was keep right nicht findet, muss nicht korrekt sein. Also: Wenn da Fehler auftreten, muss man sehen, woran das liegt. Wenn da keine Fehler auftreten heißt das noch gar nichts. > > Wir sind jederzeit bereit Fehler sofort zurück zu bauen, wenn wir was > falsch machen und das uns jemand meldet. Das klingt gut. > Einfache Bauwerke: > > Objekt: Schiene (Type: Way) > > Schienen werden von uns nicht angefasst. Das einzige was wir machen, wenn > zu wenig Schienen eingezeichnet sind, wie es bei U-Bahnlinien der Fall ist, > dann erweitern wir diese möglichst nach der genauen Lage. Klingt gut, setzt aber auch für euch voraus, dass ihr die Daten unter den Lizenzbedingungen von OSM freigeben dürft. Das ist nicht selbstverständlich, selbst dann nicht, wenn ihr sie habt. (das gleiche gilt für alle anderen Daten, die ihr einpflegt, natürlich auch) > Objekt: Haltepunkt (Type: Node auf dem Way Schiene) > > - railway = stop (vorher haben wir station getaggt, es war uns nicht ganz > klar was der unterschied zwischen Station und Stop in diesem Fall ist) Das ist nach dem alten Schema der Unterschied zwischen einem Bahnhof und einem Bahn-Haltepunkt. >[...] > In den vorhandenen Daten sind Bahnsteige aus Routinggründen > häufig zweigeteilt. Um diese wieder zu vereinigen, werden sie durch eine > Relation zusammengefasst. Wir benutzen die Relation stop_area. Falls dies > nicht gewünscht wird könnten wir auch eine eigene Relation anlegen. s.o., Relation dürfte nicht notwendig sein. > Objekt: Treppe (Type: way) > - highway = steps > - level = 0,1 > > Treppe bekommen bei uns immer das Level von dem aus sie beginnen zu dem > Level wo sie hinführen. Sinnvoll, falls ihr das wisst: - Geländer: http://wiki.openstreetmap.org/wiki/Key:handrail - direction: up/down (mag mit level gemeinsam redundant sein, ist aber der üblichere weg, siehe > Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Steps ) > Objekt: Rolltreppe (Type: way) > > - highway = steps > - escalator = yes > - level = 0,-1 direction: siehe oben. > > Rolltreppe bekommen bei uns immer das Level von dem aus sie beginnen zu > dem Level wo sie hinführen. > [...] > Gebäude mit weiteren Flächen: > > Objekt: Tunnel (Type: Fläche) > > - area = yes > - tunnel = yes In dieser Kombination stellt sich die frage: Wo ist der Tunnel offen? Wenn der Tunnel eine Fläche ist; wo ist rundrum dann der Tunnel offen, und wo sind Mauern? > - level = ... > - layer = ... > - building = yes (es handelt sich um ein Indoor-Element und soll in der > Karte angezeigt werden) was soll die Beschreibung denn hier? Das klingt nach taggen-für-den-Renderer. building=yes heißt, es handelt sich um ein Gebäude, nicht um etwas in einem Gebäude. also: FALSCH! > - designation = Unterführung Bitte nicht. designation ist definitiv kein Freifeld-Tag, und "Unterführung" als deutsches Wort außerhalb von Namen oder Beschreibungen haben in OSM erstmal nichts zu suchen, vgl. auch http://wiki.openstreetmap.org/wiki/Key:designation > Objekt: Bahnhofshalle (Type: Fläche) > > - name = München Ostbahnhof > - railway = station > - building = yes > - area = yes area=yes ist unnötig, weil building=yes und railway=station auf geschlossenem way ein area implizieren. > Um uns mit den unterschiedlichen Modellierungsarten vertraut zu machen und > um unseren Kunden aussagekräftige Beispiele zu liefern, haben wir bisher > folgende Bahnhöfe modelliert: > [...] da guck ich mir den ein oder anderen demnächst mal genauer an, mal sehen. Gruß Peter _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
