DE talk:Relation:route

symbol

Ideen zu symbol=*:

• I think this would be better implied by the network tag - the network=Frankenweg implies that symbol David.earl 22:38, 23 October 2007 (BST)
• I concede that you could derive the symbol from the combination of name/ref and network; network alone is probably not enough. --Keichwa 18:18, 31 October 2007 (UTC)
• What if cycle routes within a regional network all have different symbols that are used on sign posts to guide the cyclists? Or do we need specialised route relations for cycling, hiking, etc? --Karouf 14:03, 10 November 2007 (UTC)

If each cycle-route is a relation, then for one route would be one symbol. (As i understood the relation).--Manfred P 22:43, 28 December 2008 (UTC)

• In Poland most routes are marked with coulourful marks (one trail one colour, see the bottom of this page). For hiking trails they are alwas a colorful stripe beetween two white ones. However, bicycle routes' symbols haven't been yet standarised accross the country, they alway use colours. Steelman 22:18, 20 December 2007 (UTC)
• Some cycle tours in Germany use special icons (e.g. the Ruhrtalradweg). I think a symbol description is not good enough - for rendering purposes an icon url would be more suitable.

Bisher verwendet

Wäre es nicht sinnvoll, eine Tabelle mit den "empfohlenen" routen aufzustellen? Für Themenkarten, wandern, reiten, Rad, (mtb), Ski ..... wäre das doch die Art zu definieren was auf bestimmten Karten eingetragen werden soll (kann, wie auch immer). --Manfred P 14:55, 24 December 2008 (UTC)

network

Das meint doch eigentlich: "diese Relation ist Kind einer übergeordneten Relation". Wenn das so ist, dann gehört dies nicht hier, sondern in der übergeordneten Relation beschrieben, als deren Mitglied. --Markus 15:52, 27 September 2008 (UTC)

Wenn network = lwn, beschreibt das nur die Art der route, die lwn's sind ja nicht verbunden. --Manfred P 14:48, 24 December 2008 (UTC)

Etwas Redundanz ist schon ganz gut. Bisher interpretieren recht wenige Programme übergeordnete Relationen, wobei network-Relationen noch nicht einmal etabliert sind. Außerdem lassen sich in den network-Relationen fehlenden Routen einfacher Zuordnen, wenn diese schon einen Hinweis auf das passende Netz liefern. --Langläufer 13:00, 16 January 2009 (UTC)

@ Markus Das sehe ich genauso. @ Langläufer Was meinst Du mit Redunanz?

Der Network-Schlüssel ist meines Erachtens in jedem Fall sinnvoller Bestandteil einer in einer Relation geschriebenen Routen-Definition. Denn der Schlüssel sagt etwas darüber aus, mit welcher Art von Route wir es zu tun haben. Wenn der network-Schlüssel konsequent angewendet wird, ergeben sich allerdings für die Auswertung Möglichkeiten, die mit der Routen-Relation tatsächlich nur indirekt zu tun haben und eher übergeordneter Natur sind. Von daher ist es sinnvoll, diesem Schlüssel zusätzlich auf anderer Ebene Aufmerksamkeit zu schenken. Ausgewertet wird der Schlüssel bereits:

• In der Wander-Reit-Karte von Nop dient dieser Schlüssel unter anderem dazu, die Liste der gerenderten Routen [1] zu ordnen. Darin werden die Routen ihrer Klassifikation entsprechend gruppiert. Wer immer an dieser Karte interessiert ist, erkennt an der Liste, ob dieser Tag korrekt gesetzt wurde. Tippfehler und fehlende Angaben schieben die Route in die Rubrik "unklassifiziert". In der (automatisch generierten) Liste kann man über die Nummer der Routen-Relation leicht auf die Routen-Daten zugreifen, diese prüfen und korrigieren.

• Setzt sich das Tag durch, läßt es sich für eine Karten-Signatur auswerten. Jeder Routen-Klassifikation könnte eine spezielle Farbe und Linienform (Breite, durchgezogen/unterbrochen/gepunktet)zugeordnet werden. Auf Wanderkarten, Rad-Karten oder Karten für ÖNV-Routen sind solche Signaturen üblich, um Routen aus dem Wegenetz hervor zu heben und verschiedene Systeme von einander abzugrenzen.

Die Listung aller network-Schlüssel bisher erfaßter Wegenetze ist ein wichtiges Thema, das zwar der Übersichtlichkeit wegen eigenständig behandelt werden sollte. Bei der Behandlung des Themas "Routen-Relation" muß es aber ebenso deutlich angesprochen werden, damit das Tag bei der Erstellung einer Routen-Relation nicht nur nicht vergessen sondern auch korrekt angewendet wird. --elmada 15:07, 7 February 2009 (UTC)

Mit Redundanz meinte ich, die Information liegt mehrfach vor. Ich denke aber das Netz sollte ruhig doppelt - über das network-Tag und über die (Gesamt-)Relation - erfasst werden. --Langläufer 20:26, 7 February 2009 (UTC)

forward/ backward

Die Rolle forward / backward wird ja für Wege oder Wegteile und die Rolle forward_stop bzw. backward_stop für Bushaltestellen verwendet. Sinnigerweise ist die Rolle für Haltestellen relativ zur Richtung der Bus-Linie. Klar, eine konkrete Haltestelle wird nur auf der entsprechenden Strassenseite bedient. Für mich ist es jetzt jedoch ziemlich unlogisch, dass die forward/backward Rolle der Wegteile sich auf die Richtung des Wegelementes bezieht. Es ist doch klar, dass ein Bus in einer Einbahnstrasse nicht rückwärts fährt. Auf der anderen Seite ist es unerheblich ob eine Strasse von links nach rechts oder andersherum in osm eingetragen ist, sofern sie in beide Richtungen befahren werden kann. Es macht aber sehr wohl einen Unterschied, ob die Buslinie auf der Hinrichtung einen anderen Weg nimmt, als auf dem Rückweg. Konsequenterweise muss sich die forward/backward Rolle ebenfalls auf die Bus-Linien-Richtung beziehen. Es stellt sich die Frage in welche Richtung forward ist. Mein Vorschlag dazu ist die Richtung, die tendenziell von Nord nach Süd, bzw. von Ost nach West geht als forward zu bezeichnen. Der Rückweg ist entsprechend backward. User:Delasmurf 22.09.2009 20:43

Nein! Die Rolle ist NICHT relativ zur Richtung der Bus-Linie! Forward/Backward bezieht sich auf die Richtung des betroffenen Weg-Elementes! Das ist sowohl beim Erstellen als auch für die Renderer die einfachste Lösung und hat sich so durchgesetzt. Inzwischen warnt z.B. JOSM auch davor, wenn man die Richtung eines Weges umdreht, der eine forward/backward-Rolle hat.

Bitte unterlasse in Zukunft solche "grossen" Änderungen von Wiki-Seiten ohne vorherige Diskussion. --T-i 13:21, 24 September 2009 (UTC)

Einfach ändern sollte man natürlich nicht, aber inhaltlich stimme ich der Änderung voll zu. Es macht keinen Sinn die Wegrichtung und eine Rolle in einer Relation in einen festen Zusammenhang zu bringen. Schließlich sieht man es einem Weg nicht an, ob er irgendwo in einer Relation irgendwas mit forward/backward eingetragen hat und kann die Richtung jedes Wegstückes jederzeit umdrehen. Im Extremfall lassen sich auch mit mehreren Relationen widersprüchliche Kombinationen erzeugen.

Aus technischer Sicht macht es absolut Sinn, forward/backward ausschließlich an der Relation festzumachen und völlig unabhängig von der Wegrichtung zu halten. Und umgekehrt die Tags am Weg, die sich auf die Wegrichtung bezhiehen, unabhängig von allen Relationen. Wenn die Verquickung von Weg und Relation tatsächlich weit verbreitet ist, sollte das schleunigst korrigiert werden. --Nop 14:11, 24 September 2009 (UTC)

Zumindest JOSM und Potlach zeigen die Relationen-Rollen eines Weges an und auch mit Wegrichtungs-unabhängigen Rollen lassen sich Widersprüche konstruieren; dieses Argumente gelten also nicht.

Es mag sinnvoll sein, Relationen und Wege zu trennen, aber es ist immer auch eine Frage der Umsetzbarkeit und der momentanen Verbreitung des "alten" Systems.

Mit der alten API gab es keine geordneten Relationen und somit war es nicht möglich forward/backward auf die Relation selbst zu beziehen; ein Bezug auf die Richtung des Weges war also nötig. Somit sollten alle Prä-API-0.6-Relationen diese "Verquickung" aufweisen.

Beispiel zur Umsetzung: Bus 33 in Zürich

Ich glaube, es ist einiges komplizierter für die Renderer zu analysieren, was bei einem Weg vorwärts/rückwärts bezüglich der Relation ist; vorwärts/rückwärts bezüglich Weg-Element ist als Zeichenregel sofort umsetzbar. Und was geschieht bei unterbrochenen/nicht vollständigen Relationen? Bei einem beidseitig unverbundenen Wegstück kann der Renderer nur raten, in welcher Richtung der Bus nun durchfährt... --T-i 14:49, 24 September 2009 (UTC)

Sorry für die grosse Änderung ohne vorherige Diskussion. Ich glaube ich kapier es immer noch nicht. Wenn eine Strasse in beide Richtungen befahren werden kann, aber aufgrund der XML Datenstruktur eine Richtung haben muss, dann hat diese Richtung doch nichts mit der Busroute zu tun, sondern ist völlig willkürlich. Deswegen auch die (unnötigen) Probleme, wenn mal jemand ein Wegstück umdreht. Bei einer Einbahnstrasse hingegen muss man nicht extra sagen, dass der Bus diese nur in einer Richtung abfährt. Es würde also viel mehr Sinn machen forward/backward, genau wie forward_stop und backward_stop, auf die Fahrtrichtung der Linie zu beziehen. Wenn eine Strasse in beide Richungen befahren wird und der Bus sie auch auf dem Hin- und Rückweg abfährt, bekommt dieses Element keine Rolle, wenn der Bus diese Strasse nur auf dem Hinweg abfährt, dann forward. Ich bin in der Rendermaterie nicht so drin, aber das erscheint mir durchaus machbar und auch logischer. -- Delasmurf 06:55, 25 September 2009 (UTC)

Ich sehe da kein Problem: Bei Einbahnstraßen und beidseitig befahrenen Staßen brauchen die Wegestrücken keine Rolle. Wenn die Route auf dem Stück nur gegen die Wegerichtung verläuft bekommt der Weg die Rolle backward, wenn nur mit der Wegerichtung, dann forward. Das ist durchaus auch logisch. Es müsste jedoch einheitlich von den Editoren unterstützt werden, damit bei Drehung der Wegerichtung auch die Rolle gedreht wird. --Langläufer 08:34, 25 September 2009 (UTC)

Ich verstehe. Dennoch halte ich es für bedenklich, dass {forward,backward}_stop sich auf die Relation bezieht, während die Rolle {forward,backward} ein reines Hilfsmittel für den Renderer ist, welches auch noch Probleme bereitet, so dass Bearbeitungssoftware angepasst werden muss, wenn mal einer einen Weg umdreht. Ich persönlich sehe in dieser Verwendung eine fragile, inkonsequente Krücken-Lösung.

Aber selbst wenn hieran nichts geändert wird, gibt es immer noch die Frage was ein forward_stop und was ein backward_stop ist. Was haltet ihr von dem Nord-Süd-Vorschlag (siehe oben)? Eine Alternative wäre es noch in der Relation festzuhalten welcher Richtung forward entspricht --Delasmurf 12:14, 25 September 2009 (UTC)

Klar, die Way-Richtung einer Nicht-Einbahnstrasse ist zufällig. Darum wird die Richtung aber auch selten bis nie geändert (Einziger Fall der mir gerade in den Sinn kommt: Verschmelzung von zwei Way-Elementen mit unterschiedlicher Richtung). Mit Unterstützung der Editoren wird man aber darauf aufmerksam gemacht. (Bei JOSM bereits integriert.) Ein forward/backward ist daher nicht Buslinien-logisch sondern nur Datenbank-logisch. Diesen Kritikpunkt verstehe ich. Ich bezweifle aber, dass für Router und Renderer die Buslinien-Logik genau so einfach umzusetzen ist wie die Datenbank-Logik. Wen könnte man dazu befragen?

Zudem: Bisher wurden die Linien nach diesem Schema erstellt. Wenn Du nun die Bedeutung der Rollen umstellen möchtest, dann heisst das auch, dass _alle_ bereits vergebenen Rollen überprüft werden müssten! Auch in Zukunft würde es noch User geben, welche nach dem alten Schema taggen, da man die Wiki-Seite nicht ständig besucht. Daher fände ich es idealer, wenn Du Dir neue Rollen-Namen für Deine Art des Taggens überlegen würdest..

Ob sich der Aufwand überhaupt noch lohnt? Mit dem neuen OXOMOA-Schema ist sowieso vorgesehen, dass jede Richtung ihre eigene Relation bekommt; eine Kennzeichnung von forward/backward würde sich dann erübrigen. --T-i 11:30, 25 September 2009 (UTC)

Wenn ich einfach nur mappe und mich nicht für Buslinien interessiere, dann kann ich die Richtung eines Weges jederzeit umdrehen. Anwendungsfälle dafür sind: Zusammenlegen von Wegstücken, Angleichen an Nachbarwegstücke, Einzeichnen von richtungsabhängigen Tags wie incline, oder Ändern eines oneway=-1 Konstruktes. Dabei weiß ich nix von irgendwelchen Richtungsabhängigkeiten von irgendwelchen Relationen und prüfe sowas auch nicht. Die sehen dann halt hinterher etwas merkwürdig aus. Das sollte nicht verquickt werden, schon gar nicht wenn es keine technische Notwendigkeit mehr gibt. --Nop 12:11, 25 September 2009 (UTC)

Genau weil es so viele verschiedene richtungsabhängige Keys/Tags gibt (forward/backward, up/down, left/right, etc), ist es wichtig, dass die Editoren dies unterstützen! Ob ich einen Weg umdrehe, an den Du ein incline=10% gemacht hast (für das ich mich nicht interessiere) oder Du einen Weg umdrehst, an den ich eine forward-Rolle vergeben habe (die Dich nicht interessiert) macht da ja keinen Unterschied. Da der Mensch Fehler macht/Unachtsam ist/nicht alles weiss, sollte die Programm-Logik den Benutzer darauf aufmerksam machen. --T-i 12:13, 1 October 2009 (UTC)

Siehe dazu auch den erläuternden Eintrag auf Öpnvkarte#Rollen_der_Mitglieder.

Ich weiss, wir mappen nicht für bestimmte Render, aber hier geht es auch darum, was technisch überhaupt umsetzbar ist. Und da ist es momentan halt so, dass es viel einfacher ist, bei Wegen das forward/backward auf die einzelnen Segmente zu beziehen als auf die gesammte Route.

Bei Nodes hingegen (die ex definitionae keine Richtung haben können) muss sich das forward/backward auf die Richtung der Relation beziehen.. Hier wäre eine Bezug zur Richtung des zugehörigen Ways zu kompliziert. Welche Richtung forward ist und welche backward ist eigentlich egal, solange es konsequent innerhalb der Linie durchgehalten wird.

--T-i 00:24, 22 October 2009 (UTC)

Hier liegt das gleiche Problem vor wie bei Rolltreppen. Sie sind sowohl nach oben / unten als auch mit oder entgegen der Wegrichtung.

Siehe Elevator --Lulu-Ann 19:29, 22 September 2009 (UTC)

verstehe nicht welches Problem du meinst. --Langläufer 08:34, 25 September 2009 (UTC)

previous discussion(s)
... ist derzeit problematisch, da die Rollen in den Editoren beim Umkehren der Wegerichtung nicht automatisch angepasst werden. Dreht als jemand im nachhinein einen Weg ist die Richtung falsch. --Langläufer 13:23, 16 January 2009 (UTC)

• Meines Erachtens ist dieses System sowieso viel zu aufwendig, weil man jedes Wegelement getrennt betrachten muss. Ich fände es wesentlich sinnvoller Start/Ziel zu definieren und dann einen Teil den Teil der Route als forward zu bezeichnen, der von Start zu Ziel führt und umgekehrt. Bei Routen die einen "Forward Stop 123" etc. haben braucht man auch nicht mal Start/Ziel. Weil so wie es jetzt ist, ist es einfach nur total umständlich. Xeen 14:57, 27 February 2009 (UTC)
• Ich hab irgendwie Probleme mit einer Relation, die ich erstellt habe Camino de Santiago. Verstehe die Fehlermeldungen nicht und befürchte, dass es mir forward/backward zu tun hat .... kann das jemand aufklären? --braegel 14:18, 7 June 2009 (UTC)

Um forward/backward korrekt taggen zu können, muß die Richtung der Relationsmitglieder kontrolliert werden. In Potlach erkennt man diese an dem kleinen Kompass-Pfeil direkt neben der Schere. Nur wenn die Wege plausibel aneinander gereiht sind, kann die Relation funktionieren. Um der Fehlermeldung auf den Grund zu gehen, wirst Du wohl sämtliche Relationsmitglieder prüfen müssen.

forward/backward ist eine "Einbahn-Option". Ihre Anwendung macht bei Wanderrouten im allgemeinen nicht viel Sinn, da man die Routen grundsätzlich in beide Richtungen laufen kann. Beim Jakobswanderweg mag man darüber streiten, ob es sinnvoll ist, mit Hilfe dieses Tags das Ziel Camino de Santiago anzuzeigen. Die Jakobswege bilden inzwischen ein sich über mehrere Länder erstreckendes Netzwerk, an deren Erfassung viele Mapper beteiligt sind. Nicht jeder davon kennt die Regeln, nach denen die "Einbahn-Option" der Routen-Relationen funktionieren. Die Gefahr, daß es zu Fehlern kommt, ist daher sehr groß. Der Aufwand, die Fehler zu korrigieren, steht meines Erachtens aktuell in keinem Verhältnis zum Nutzen. Ich empfehle daher, das Tag wegzulassen. --elmada 10:36, 8 June 2009 (UTC)

Und was ist mit den bestehenden forward/backwards? Soll man die entfernen? --braegel 19:39, 8 June 2009 (UTC)

Wäre eine ziemliche Arbeit. Oder? Wenn ich mit Hilfe des OSM-Composers eine Karte generiere, ignoriere ich das Tag. Von daher kann ich nicht beurteilen, ob es wichtig wäre, dies zu entfernen. Mach einfach, was Du richtig findest. Entweder verdrehte Wege korrigieren, oder das Tag entfernen. --elmada 22:27, 9 June 2009 (UTC)

• Kann man diese forward/backward tags benutzen um eine Radroute, die über einen Kreisverkehr läuft, klar zu mappen? Oder weiß jemand, wie man das machen soll? Wenn man den gesamten Kreisel in die Route aufnimmt, ist sie nicht mehr in einem Stück, da ein Teil ja "doppelt" befahren wird. Kaeru 13:02, 3 August 2009 (UTC)
  • Ja, das sollte man so machen, wenn sich der Weg für die Fahrtrichtungen (z.B. im Kreisel oder aufgrund anderer Einbahnstraßen aufspaltet). Allerdings zeigt der Relation-Analyzer trotzdem eine Unterbrechung an. Aber der lernt das bestimmt noch ;-) --KartoGrapHiti 18:18, 5 August 2009 (UTC)
    • Solange der Kreisel komplett mit drin ist, ist das Ganze halt nicht routing-fähig. Aber genau dafür will man die Tracks doch benutzen...Kaeru 17:38, 6 August 2009 (UTC)

Öffentliche Verkehrsmittel

Bahnlinien

Fahrweg oder Zug?

Wird/soll mit einer Relation der Fahrweg (Ausbauzustand der Strecke) oder eher der Zug, der auf der Linie fährt beschrieben werden? Ich plädiere für den Zug, da es bei Buslinien ja auch nicht um den Fahrweg (secondary, residential,...) beschrieben wird. Von daher ist der Hinweis auf die Railway-Schlüsselwerte wohl nicht sinnvoll. --KartoGrapHiti 20:07, 30 January 2009 (UTC)

Der Link sollte lediglich auf die Erklärung zu den ersten 4 Begriffen (rail, light-rail, tram, metro) verweisen. --Langläufer 20:39, 30 January 2009 (UTC)

Einteilung der Bahnlinien

Habe die Verwendung von rail und light-rail etwas genauer verdeutlicht, ich denke so kommt es am besten mit den Übersetzungen und auch den bisherigen Verwendungen überein. Gruß - Fips Schneider 19:47, 27 January 2009 (UTC)

wenn ich die englischen Umschreibungen richtig verstehe, hätte ich die Stadtbahn hätte ich eher zu light-rail gepackt. (Beispiel dafür wäre wohl die Stadtbahn von Karlsruhe. http://de.wikipedia.org/wiki/Stadtbahn_Karlsruhe

subway ist wohl eher nur U-Bahn, die auch mal aus dem Tunnel auftauchen darf (Berlin), aber nicht Straßenbahn, die zum Teil unterirdisch fährt (Hannover) --Langläufer 21:26, 27 January 2009 (UTC)

Soweit ich die Diskussion hier verstanden habe, ist light_rail mittlerweile wirklich zur Stadtbahn geworden? Entsprechend sollte dies hier dann auch angepasst werden.--KartoGrapHiti 21:09, 30 January 2009 (UTC)

Die Differenzierung zwischen Stadtbahn/S-Bahn und Schnellbahn halte ich an dieser Stelle für übertrieben. Alle drei "S" haben den gleichen Character des schnellen Ein und Ausstiegs, Abteile sind selten vorhanden und es ist meißtens eine Vorortbahn. Die Abstände zwischen den Halten sind länger als bei der U-Bahn aber kürzer als bei Regionalzügen. Es gibt natürlich Ausnahmen. Eisenbahntechnische Spitzfindigkeiten helfen dem Nutzer dieser Daten aber glaub ich nicht weiter. Ein Blick in 3-4 Dictionaries und Fachbücher spricht auch für eine Zusammenfassung. Überschneidungen sind eh nicht zu vermeiden. Ich schlage vor die "S" zusammenzufassen und mit ligth-rail zu taggen. Das würde dann 4 Klassen für den tag "train" ergeben. Mit dem "ref" tag (RE1, S2, etc.) kann der Interessierte dann ja eine weitere Differenzierung vornehmen.

• train (Regional bis Fernzug)
• ligth-rail (S-Bahn,Stadtbahn,Schnellbahn)
  • Berlin, Hamburg
  • S-Bahn Hannover ?
• subway (U-Bahn die auch mal oberirisch fahren darf)
  • Berlin
• tram ( Straßenbahn/Tram (engl. tram/street car) die auch mal unterirdisch verkehrt)
  • Berlin, Potsdam, Leipzig, Dresden, Hannover (Stadtbahn)

Gruss--Makracht 10:35, 6 February 2009 (UTC)

Bis auf die Bezeichnung light-rail würde ich dem Zustimmen. Die steht m.E. für eine Leichtbauweise bei den Zügen, was eher der Karlsruher Straßenbahn entspricht. Finden wir hier vielleicht was anderes? Und damit klar wird ob es funktioniert - sollten wir hier mal die S-Bahnen und Stadtbahnen der dt. Städte probehalber einsortieren? --Langläufer 11:08, 6 February 2009 (UTC)

Nach welchen Kriterien soll einsortiert werden? Der Übergang ist oft fließend. Zählt der vom Betreiber gewählte Name? Die S-Bahn Hannover ist nicht weit von einer Regionalbahn entfernt. S- und U-Bahn in Berlin unterscheiden sich eigentlich auch kaum. --Langläufer 11:56, 6 February 2009 (UTC)

Die oben angedeuteten Kategorien halte ich für sinnvoll, wobei das Wort Stadtbahn im Klammerzusatz vom "light rail" besser entfallen sollte, weil es ja sehr unterschiedliche Stadtbahn-Systeme gibt (z.B. verwendet Karlsruhe als einzige Stadtbahn das S-Bahn-Symbol und die Stadtbahnen von Hannover, Köln, Stuttgart, Düsseldorf). Bei der Benennung der Kategorien wäre ich allerdings skeptisch: Zum einen wegen der Übersetzung von S-Bahn/Schnellbahn als "light-rail" zum anderen, weil die Begriffe (außer bei "train" im Vergleich zu "rail") nicht zwischen dem Verkehrsmittel und dem Fahrweg unterscheiden, was die Kategorien klarer machen würde.--KartoGrapHiti 13:06, 6 February 2009 (UTC)

Ja- stadtbahn ist nicht eindeutig. Aber wie möchtest du den U-Bahn und Straßenbahn benennen, wenn nicht Tram und Subway? Hier sind doch Verkehrsmittel und Verkehrsweg miteinander verbunden. Wenn wir Metro Nehmen, dann wandern einige S-Bahn-Systeme wieder mit in die Kategorie!. --Langläufer 13:28, 6 February 2009 (UTC)

Wenn ich bessere Namen hätte, hätte ich sie vorgeschlagen. Mag sein, dass wir das wir das sprachlich nicht differenzieren können. Dann bleibt es so.--KartoGrapHiti 13:47, 6 February 2009 (UTC)

Ich verstehe den Einwand, dass Stadtbahn aus Hannoveraner Sicht nicht zu den 3 "S" gehört. Die Hannoveraner S-Bahn ist im klassischen Sinne (zumindest außerhalb des Stadtgebietes) auch eine Regionalbahn. Ich habe mich eher um einen generellen und auch international brauchbaren Ansatz bemüht. Deshalb bleibe ich bei dem Vorschlag der Zusammenfassung. Die Bezeichnung ligth-rail ist sicherlich suboptimal und schwammig. Meines Wissens gibt gibt es nichts internaional verständlicheres als das. Letzlich bleibt die Entscheidung beim Kartierer. Wir könnten uns vielleicht auf den Level of Service wie oben schon beschrieben als Entscheidungskriterium einigen. Im Sinne kurze Entfernung zwischen den Halten = tram bis dutzende/hunderte Kilometer = Regional Fernbahn. Jetzt gilt es sinnvolle Schwellenwerte vorzuschlagen. ;-)--Makracht 14:11, 6 February 2009 (UTC)

wir könnten unseren derzeitigen Diskussionsstand mal auf die englisch-Sprachige Seite übertragen. Vielleicht kommen dort dann noch Verbesserungen für die Namen. --Langläufer 14:40, 6 February 2009 (UTC)

Hallo Langläufer. Wir haben parallel an der engl. Version gearbeitet. Hoffe ich habe alles von Dir übernommen.--Makracht 14:56, 6 February 2009 (UTC)

dito, hab es mit den Bussen zusammengefasst - ist ja quasi das gleiche (nur ohne schiene) --Langläufer 15:14, 6 February 2009 (UTC)

Nah und Fernverkehr

Langläufer hat wohl die Unterscheidung zwischen Nahverkehr und Fernverkehr eingeführt. Die dafür verwendeten Worte "rail" = Regionalverkehrszug und "train" = Fernverkehrszug leuchten mir nicht ein: Nach meinen bescheidenden Englischkenntnissen würde ich rail als die Schiene (Fahrweg) und train als Zug übersetzen. Ich habe auch hier die Befürchtung, dass wir für die relationen neue Typen brauchen, die nicht aus dem Taggen der Fahrwege entstammen und sauber getrennt werden sollten. Mir schwebt z.B. vor: route=train (für Nah- und Fernverkehr) und dann ein extra Zusatz: train=commuter oder train=local für Zuglinien des Nahverkehrs und train=long_distance (oder was auch immer) für Zuglinien des Fernverkehrs. --KartoGrapHiti 21:09, 30 January 2009 (UTC)

ich habe das nicht eingeführt, ich habe das lediglich hier so dokomentiert, wie es von vielen anderen verwendet wird. Schau doch einfach mal in die öpnvkarte. Deinen Vorschlag finde ich gut. Vielleicht sollten wir den Entwickler der ÖPNV-Karte (Melchior Moos) mit in die Diskussion einbeziehen. Ich denke er hat den besten Überblick über die derzeit verwendeten Tags und die Stimmung dazu in talk-de. Die Erfasser orientieren sich in der Regel sowieso mehr nach dem Ergebnis in der Karte, also nach der Doku hier im Wiki! Wenn wir zu einer Einigung kommen, helfe ich beim umtaggen. --Langläufer 05:41, 31 January 2009 (UTC)

mittlerweile wurde rail in der öpnvkarte gestrichen. nun ist light-rail der Regionalzug ?! --Langläufer 05:47, 31 January 2009 (UTC)

Melchior schrieb mir dazu mal: "Da müsste man sich mal irgendwas einfallen lassen, vielleicht wenn kein ref angegeben ist den Namen rendern oder soetwas..." Er scheint also unsere Ergebnisse gerne aufzunehmen, wenn sie sinnvoll erscheinen. --KartoGrapHiti 16:32, 31 January 2009 (UTC)

Ich würde auch für alles train + Zusatztag plädieren, da z.B. in Belgien Bahnstrecken als rail getaggt werden und in Tschechien Bahnstrecken als railway. train ist da nicht so missverständlich, deshalb hab ich die anderen aus der Legende genommen. Bei light_rail wäre eine unmissverständliche alternative meiner Meinung nach auch sinnvoll. --Nimix 16:52, 31 January 2009 (UTC)

Wäre es nicht sinnvoll in Analogie zu den Rad- und Wanderrouten das Network-Tag für die Klassifizierung nach (i)nternational, (n)ational, (r)egional und (l)okal zu benutzten? Das wäre nicht nur für Bahnen sinnvoll, sondern auch für Busse. --Langläufer 08:07, 31 January 2009 (UTC)

i,n,r,l wäre sicher besser. Allerdings sollten wir ehrlich sagen, dass wir bei den Radwegen auch nicht wissen, wie wir i,n,r,l trennen - zumindest fehlt dort bisher die Definition. Schwierig wird es vor allem, wenn ich auf Staaten wie Luxemburg schaue: Deren ncn-Radwege entsprechen z.T. den lcn-Radwegen und machen die Sache nicht übersichtlicher. Das Saatsgrenzen (die quasi in Europa nicht mehr existieren) zwischen i und n-Linien unterscheiden halte ich also für problematisch. Kriterien wie "Linienlänge" und "hält an jedem Bahnhof" halte ich für besser, weil sie international vergleichbar sind. Allerdings habe ich auch nichts dagegen, wenn es zusätzlich nationale Tags gibt, wo man dann auch RE und ICE taggen kann, weil dies ggf. auch die Infos sind, die die nationalen Nutzer haben wollen. --KartoGrapHiti 16:32, 31 January 2009 (UTC)

die Administrative Einteilung ist doch eigentlich reicht eindeutig nachvollziebar. Probleme sehe ich nur darin, das es je land verschieden viele administrativel Level gibt. administrative Grenzen wird es in Europa noch lange geben und Radwegenetze werden i.d.R. von irgendeiner Administration angelegt. somit ist für viele Netzte international und national relativ eindeutig zuzuordnen - es sei denn es handelt sich um ein "lokales" Netz im Grenzgebiet. die frage dann ist, was ist lokal und was ist regional. --Langläufer 14:00, 5 February 2009 (UTC)

Die Diskussion über Radwege sollten wir besser bei den Seiten der Radfernwege führen. Genau Dein letztes Argument halte ich aber für relevant: Es ist nicht verständlich, dass die S8 und die S9 im S-Bahn-Netz des Rhein-Main-Gebietes anders eingeordnet werden, nur weil eine von beiden für wenige Kilometer nicht durch Hessen verlässt und damit zwei Bundesländer verbindet. Ich sehe hingegen einen Unterschied zwischen der Regionalbahn 64 von Münster nach Enschede und dem ICE von Frankfurt nach Paris. Ich halte also die administrativen Grenzen durchaus für ein eindeutiges Einordnungskriterium. Das Kriterium ist allerdings für mich nicht sinnvoll für eine Systematisierung der Bahnlinien. Die oben genannten Kriterien halte ich daher für besser.--KartoGrapHiti 09:52, 6 February 2009 (UTC)

Verkehrsverbund

Der Verkehrsverbund wäre dann in ein anderes Tag zu übertragen. --Langläufer 08:07, 31 January 2009 (UTC)

In vielen Verkehrsverbünden (z.B: GVH, VBN gibt es jede Busroute nur einmal und die Nummer wird somit vom Verkehrsverbund vergeben. Somit ist die Zusammensetezung von Verkehrsverbund und Nummer ein eindeutiges Identifizierungsmerkmal und sollte behalten werden, wenn die Linie in nur einem Verbund ist. Es aber auf jeden Fall Sinn, die Haltestellen und Bahnhöfe mit dem Verkehrsverbund zu taggen. --KartoGrapHiti 16:32, 31 January 2009 (UTC)

der Verkehrsverbund muss bleiben, dass ist schon klar, nur evtl halt nicht in network. --Langläufer 16:41, 31 January 2009 (UTC)

Das Übersetzungsproblem erscheint mir zu schwierig: [2]--KartoGrapHiti 17:01, 31 January 2009 (UTC)

Die Referenzbezeichnung der Bahnlinie

Mag jemand beantworten, was die Referenzbezeichnung der Bahnlinie ist? Das variiert derzeit in der Praxis zwischen Kursbuchnummern und Bezeichnungen wie "RE 12" Das Problem ist, dass es durchgehende Züge bzw. Zuglinien gibt, die so lang sind, dass sie mehrere Kursbuchnummern haben. Außerdem soll ref ja der Orientierung diesen, so dass vielleicht eher diese Regel sinnvoll wäre: ref="Das was auf dem Zug steht" (und wenn da kein Kürzel oder keine Nummer steht, dann gibt es kein ref(?)). Das Problem mit den "RE 12"-Bezeichnungen ist, dass diese z.T. zwischen Bundesländern wechseln, wie man am Beispiel des Main-Sieg-Express sehen kann. Zum Teil sind in Netzplänen auch Bezeichnungen für die Strecken aufgeführt (z.B: VBN, GVH, RMV), die aber das Problem haben, dass eine Zuglinien über mehrere Nummern läuft (Zugverbindung Norddeich-Braunschweig wechselt im VBN-Gebiet von R7 zu R1 und wechselt dann im GVH von R2 nach R10). Im RMV-Netzplan Schiene gibt es hingegen Linienbezeichnungen, wie "SE 30" (für Regionalexpress), die ireeführend sind. Eine letzte Idee wäre, einen Teil der Zugnummer zu verwenden, die im Fahrplan steht (Sinnvoll könnte sein, die letzten beiden Nummern abzuschneiden, die sich innerhalb einer Linie wohl stets ändern.) Das Zugnummernsystem wird hier beschrieben, macht aber auch deutlich, dass man aus der Nummer nicht so einfach auf die Liniennummer schließen kann. Andererseits ist die Zugnummer in den Fahrplänen stets angegeben. --KartoGrapHiti 21:09, 30 January 2009 (UTC)

• also ich hätte kein Problem mit den RE /SE Nummern - auch wenn sie sich an der Verkehrsverbundsgrenze ändern. --Langläufer 04:34, 31 January 2009 (UTC)

• Gerade in der Verbandsgemeinde Altenkirchen kommt es vor, dass die Bahnstrecke(n und Busstrecken) von privaten Unternehmen betrieben werden, und (jede ihre eigene) unterschiedliche Bezeichnung haben - es sind aber die selben Bahnen, nicht wie im angrenzenden Rhein-Sieg-Kreis, der eine RE und eine S-Bahn auf dem gleichen Gleis fahren lässt - bei der RB28 und der Bahn461 ... Limburg-Altenkirchen-Au handelt es ich um zwei offizielle, gleichwertige Bezeichnungen. Oder: Rheinland-Pfalz hat dann für den RE9 aus NRW kommend die Bezeichnung Bahn460.
  Sollen die dann mit Semikolon getrennt bezeichnet werden? - Wird das auch 'richtig' gerendert? cptechnik - Peter Coenen - Windeck (talk)
  PS: Verwirrende Bezeichnungen auch unter http://de.wikipedia.org/wiki/Bahnhof_Altenkirchen_(Westerw)#Personenverkehr... nicht nur Bahn461 oder RB28 sondern heisst auch RB98 und KBS461...

Buslinien

Tages- und Nachtnetz

In vielen Städten gibt am Tag und in der Nacht unterschiedliche Linienverläufe. Wohlwissend, dass der Übergang von Tagesbetrieb in den Nachtbetrieb zu unterschiedlichen Zeiten stattfindet und dass auch die Nachtlinien in manchen Städten jede Nacht fahren und in manchen Gebieten nur am Wochenende, würde ich vorschlagen, dass man ein Zusatztag für Tag und Nacht einführt. Die Renderer könnten dann z.B. eine Tages- und eine Nachtkarte erstellen. Es fragt sich nur, welche Tags dafür verwendet werden sollen...--KartoGrapHiti 10:01, 6 February 2009 (UTC)

Wie wärs mit schon bestehenden Tags: http://wiki.openstreetmap.org/wiki/Key:access#Time_restrictions --R2D2 01:03, 10 June 2009 (UTC)

Zu kurz gedacht: Nicht nur Unterschiede in Tag und Nacht, es gibt auch Linien, die die gleiche Nummer haben, aber alle 1-2 Stunden eine leicht andere Route haben, vor allem im ländlichen Bereich. Die haben die exakt gleiche Bezeichnung ... und nicht nur 2 unterschiedliche Routen - ich habe eine Linie eingetragen, die 3 oder 4 unterschiedliche am Tage über hat - OVAG 340 - ich nenne den jetzt - Oberbergischer-Achter-Bus... cptechnik - Peter Coenen - Windeck (talk)

Tags

Ihrgendwo habe ich gelesen, das man den Haltestellen auch eine uic_ref geben soll. Soll man jetzt sowas verwenden oder nicht? --findus05 09:21, 13 December 2009 (UTC)

Geordnete Relationen

Wie ordne ich denn nun die Bushaltestellen in meiner Relation? Mit welchem Tool? --Lulu-Ann 23:25, 15 May 2009 (UTC)

In JOSM (Version 1566): Im Relationen-Fenster (Doppelklick auf Relation) hats auf der linken Seite neu zwei Buttons um die Elemente zu ordnen. Was vorher an der Stelle war, das weiss ich nicht mehr -- T-i 23:58, 15 May 2009 (UTC)

gelöschte Relationen wieder sichtbar machen?

http://osm.cdauth.de/route-manager/relation.php?id=70989 Diese Relation wurde ohne Angabe von Gründen von Lodda ersatzlos gelöscht. Es ist eine sich bereits über viele Kilometer erstreckende Wanderroute, die von mehreren Mappern zusammengetragen wurde. War die ganze Arbeit nun vergebens? Wer weiß, wie so eine Löschung rückgängig gemacht werden kann? --elmada 01:32, 24 June 2009 (UTC)

so gings unter API 0.5. Probiere mal ob es immer noch so geht.

1. erstmal das xml runterladen :http://www.openstreetmap.org/browse/relation/70989/history
2. gewünschte version mit action=modify markieren
3. mithilfe von JOSM wieder hochladen.

siehe: http://wiki.openstreetmap.org/wiki/Talk:Relations#undo_edit --Langläufer 10:19, 24 June 2009 (UTC)

... aber ist doch schon wieder da! --Langläufer 10:19, 24 June 2009 (UTC)

Ah, danke! Da war aber jemand schnell. Prima! --elmada 11:36, 24 June 2009 (UTC)

• weil vieles sich ändert:
  
  • http://wiki.openstreetmap.org/wiki/Talk:Relation#Undo_edit
  • http://wiki.openstreetmap.org/wiki/Undoing_Deletions

Nodes

Bei Ways kann man die Rolle in der Relation frei lassen. Warum sollte man also nicht konsequenterweise das selbe für Nodes machen können. Es ist ja dann automatisch klar, dass es sich um eine Haltestelle handelt und es macht viel weniger Aufwand. Irgendwelche Einwände? Wenn nicht ändere ich das in einiger Zeit hier im Wiki. Meine Daten trage ich jetzt schon so ein.

Eltern/Kind -Relationen

Wie macht man eine Relation zum Teil einer anderen? --MattGPS 15:52, 7 July 2010 (UTC)

Ah, kaum hier gefragt, hab ichs in JOSM doch noch hinbekommen (Limesradweg). Aber eher ein Zufallstreffer, eine versierte Anleitung könnte nicht schaden. --MattGPS 15:59, 7 July 2010 (UTC)

Alternativrouten

Ich habe eine Frage zu den ÖPNV-Routen: Wenn eine Buslinie zu bestimmten Zeiten eine andere Route befährt, muss nur der abweichende Routenabschnitt als eigene Route gekennzeichnet werden (also ab/bis zum Auftreffen auf die Standard-Route) oder muss ich den gesamten Linienverlauf (also unter Einschluss der mitbenutzten Streckenteile der Standard-Route) als Alternativ-Route zusammenfassen?

Letzteres.--Der-martin (talk) 17:41, 17 September 2015 (UTC)

Tabelle für Wanderwege in ein Template verschoben.

Ich habe die Tabelle mit den Relationen für Wanderwege in ein Template Relation_Wanderweg verschoben. Damit kann man die fast inhaltsgleiche Tabelle unter DE:hiking abgleichen und eine doppelte Quelle vermeiden.--Rudolf 22:46, 1 April 2012 (BST)

Lehrpfade

Ich konnte nichts finden um Lehrpfade als solche zu kennzeichnen. Was haltet Ihr davon sie mit route=hiking bzw. route=foot und route:didactic_trail=yes zu kennzeichnen? Ogmios (talk) 12:08, 1 October 2013 (UTC)

Barfußpfade

Kennzeichung von besonderen Relationen Barfußwegen, Waldlehrpfaden usw. Ein Barfußweg ist teilweise auch mit Schuhen begehbar, Schlamm- Wasserstellen.

route=barefoot

leisure=barefoot dito für Wald-, Bienen-, Bio-, Geo-, Lehrpfade, Nordic Walking uva. +++ 8. Juni 2015 / Okt 2015