Ist das ein Problem? Es gibt keine Knotenpunkte, die in zwei verschiedene Richtungen auf 99 zeigen.
Nein, es ist kein größeres Problem. Allerdings sollte der Netzbetreiber die Nummern so vergeben, dass gleiche Nummern möglichst weit auseinanderliegen.
Wenn du z. B. Punkt 99 als Ziel hast und siehst wenige Kilometer vorher einen Wegweiser zum 99, dann denkst du vielleicht dass das eine Abkürzung ist oder du vorab nicht richtig geplant hast. Wenn du dich dann spontan entscheidest, die Route zu ändern, dann hast du dich verfahren.
Na ja, sie tun was sie tun, ohne uns zu befragen!
Wohl eher 1-3h reine Fahrzeit, je nach Geländeform, Untersatz und Windverhältnissen.
… kann man wohl sagen… Der Anteil der korrekten Abschnitte war auch schon einmal größer, als ich erst die Hälfte der Routen eingegeben habe. Da ich aber die Strecken abfahre, auch um zu schauen, ob sie wirklich befahrbar beschildert sind (es ist auch vor Ort noch ziemlich neu und hat viele Fehler), dauert es. Und soweit ich das überblicke, habe ich im Moment nicht viele Mitstreiter. Einige Probleme bestehen aber tatsächlich: es gibt viele Baustellen, Strecken sind hierdurch nicht befahrbar, und manche Tentakel sind wirklich unlogisch oder zumindest kompliziert ausgeschildert mit mehreren Split nodes und überkreuzten Tentakeln, da kommt knooppuntnet nicht immer ganz hinterher, auch wenn es auf der Straße wirklich so ist, wie ich es gemappt habe.
Es wartet aber tatsächlich noch viel Korrekturarbeit. Ich stelle im Moment weiter die Routen zusammen, an die Anpassung an die Anforderungen von knooppuntnet mache ich mich erst in einem weiteren Arbeitsgang, das ist viel Arbeit…
Besonders mühsam ist es, die Durchgängigkeit für das Fahrrad zu überprüfen, also ob die Tags bicycle yes/no oder use sideway usw. vernünftig gesetzt sind. Wenn nicht, wird es nämlich schnell sehr aufwändifg, wenn man die Fahrradwege links und rechts der Fahrbahn jeweils mappen muß und dann noch mit den entsprechenden Rollen versehen - und dann sind diese Wege halt primär oft nicht komplett gemappt, so dass es nicht reicht, die Relationen zusammenzustellen. Und manche Sachen sind nicht ohne eine neue Besichtigung vor Ort nicht zu klären.
Sie haben es tatsächlich fertig gebracht, kurze Abschnitte in das Fahrradknotenpunktnetzwerk einzubauen, in denen man gar nicht Fahrradfahren darf (eine enge Brücke z.B.). Ich habe mich jetzt entschieden, hier noch bicycle=dismount einzufügen, um zu signalisieren, dass es trotzdem eine Fahrradroute sein soll…
Danke dafür!!!
Und ich habe noch eine Ergänzung. Ich weiß nicht, ob irgend ein Renderer das verwendet, aber ich werde mal die Routen, soweit ich die Beschilderung zur Verfügung habe, mit den Tags “incline=up” und “incline=down” ergänzen. Das ist leider nirgendwo explizit empfohlen, und auch vielleicht nicht verallgemeinerbar.
Aber in NRW haben sämtliche Streckenabschnitte den Charakter von Knotenabschnitten. Schilder stehen nur an bestimmten Punkte, dazwischen gibt es nur kleine Pfeile ohne jede Zusatzinformation. Die Routen werden also durch die Beschilderung zwischen je zwei Wegweisern definiert. Unter den vorgegebenen Routentypen ist für NRW vorgesehen, dass Steigungen und Gefälle > 4% pauschal angegeben werden. Das bezieht sich dann immer auf den kompletten Abschnitt zwischen zwei Punkten (vielleicht gibt es auch Stellen mit beiden Symbolen? muß ich mal drauf achten). Einige der Routen sind auch als “Freizeitroute” mit einem Baum-Symbol charakterisiert. Das bedeutet hier in Bielefeld effektiv, dass der Weg durch Wald geht, ungepflastert ist, ggf. nicht für Rennräder geeignet sein dürfte, oder vielleicht auch nur größere Umwege in Kauf nimmt. Da weiß ich noch nicht genau, wie ich das tagge.
Wenn jemand bessere Vorschläge hat, wie man diese Information von den Wegweisern den Routen zuordnen kann, gerne…
Und hier fällt mir gerade auf: Das könnte tatsächlich ein Grund sein, die NRW-Einzelwege von Wegweiser zu Wegweiser als je eine Relation zu mappen, und die Knotenpunktrelationen zusätzlich zu mappen, auch wenn dann die Wegabschnitte doppelt vertreten sind. Eine Knotenpunktroute geht nämlich oft über mehrere Wegweiser mit Abzweigen, die Steigungen sind dann natürlich nur auf den unmittelbar auf den Wegweiser folgenden Unter-Abschnitt bezogen.
Im Moment hatte ich leider gerade begonnen, alle doppelt gemappten Abschnitte aus der Relation “Radverkehrsnetz NRW Stadt Bielefeld” zu beseitigen. Es wird wohl noch ein bißchen dauern, bis das alles einigermaßen konsistent ist. (Nebst so Kleinkram, dass Richtungen von Radwegen verkehrt herum sind, so dass beim Tag oneway=yes plötzlich für den Router Linksverkehr angesagt ist und eine Strecke nicht mehr durchgängig ist - das ist eine der Hauptfehlerquellen dafür, dass knooppuntnet so viele issues hat…)
Good idea! I think it is much requested information about a route, so if it’s visible on the ground it’s worth tagging.
The relations are ordered, so you can use incline with yes, no, or even positive ande negative values, with respect to the order of the ways within the route. This would then (I think) represent the average incline of the route. The individual ways within can of course have very different inclines of their own.
If more detailed incline/decline patterns witthin a route are given on the signs, e.g. [#Km] incline + [#Km] decline, max incline / max decline, I think a special value syntax would be required. But I guess that could be a later addition.
If this community decides to do it this way, I would be glad to pass it on and document it as “in use”.
Why wouldn’t it be verallgemeinbar?
Ich sehe incline eher am way als an der Route. Bei so manchem Abschnitt zwischen 2 (Ziel-)Wegweisern im Bergland müsstest Du sonst auswürfeln, ob Du die lange mäßige Steigung von der einen Seite oder die kurze knackige von der anderen Seite aus unterschlägst.
Das ist überall in Deutschland so, wo die Verbindungen mit Wegweisung ein Netz bilden. Um das von Themenrouten zu unterscheiden, habe ich ja die andere Diskussion gestartet.
Ich habe in meinem Vorschlag als Endpukte für die Routen folgendes geschrieben: “Knoten, an denen sich diese Wege kreuzen, verzweigen oder enden”. Wobei man - im Gegensatz zum Knotenpunktnetzerk - die Relation auch auch über mehrere solcher Knoten hinweg führen kann, Hauptsache sie bildet eine durchgängige Wegekette und verzweigt sich nicht. Das verringert die Zahl der zu pflegenden Relationen. zudem kann man so z. B. Minirelationen von einer Kante vermeiden.
Die Kreuzungs-, Abzweig und Endpunkte sind üblicherweise auch die Punkte, an denen Vollwegweiser stehen (Tabellen oder Pfeilwegweiser). Dazwischen gibt es meist nur Zwischenwegweiser mit kleinen Pfeilen und ohne Ortsangaben.
Allerdings wird an Kreuzungen mit größeren Straßen oft ebenso ein Vollwegweiser gesetzt, ohne dass andere Wege des Fahrradnetzes kreuzen oder abzweigen. Hier die Relation enden zu lassen und eine neue zu starten bringt m. E. eine Schwemme an Relationen mit sich, die sich schwerer überschauen lassen.
Das wirkt auf mich eher komliziert und ich vermute, für andere wird es schwer nachvollziehbar, warum du die Verbindung auf mehrer Relationen aufteilst udn poppelt erfasst. Da ist die Gefahr groß, dass das jemand das zusammenfasst und Dupletten löscht.
Die Neigungssymbole am Wegweiser sind draußen hilfreich, weil man dafür nicht auf die Karte schauen und diese interpretieren muss.
Die Neigungsangaben in OSM an die Relation zu schreiben halte ich für nicht notwendig und ungenau. Wenn, dann sollte das direkt an die Kanten, die in der Neignung liegen.
Aber selbst das ist nicht notwendig, denn gute Navis / Kartendarstellungen bekommen das anhand der Höhenlinien selber und genauer raus.
keep it simple 
Thank you for your encouragement. The precipitating idea was just trying to map the visible situation and its logic seen in the guideposts.
In fact: secure would be only to describe the guideposts. The transfer of the information of the guideposts to the routes implies an interpretation and depends on the correct place and content of the guideposts - which is not completely given, as we are confronted with reality. It is possible to place any posts with any information at any place without relation to anything real (they did so last year 
)
So I really think, we really should wait before such a method would be stated as “in use”. If the state keeps this system: dividing the net into single routes between nodes that have clear properties - “Freizeitroute” “Schnellweg” “Incline” … then it would be appropriate to apply it to the network. But I’m not quite sure whether they’ll really stick to this structure.
An advantage of my tagging scheme is that it can be changed very quickly. I think it could be a good idea to later involve also marc (vmarc) from knooppuntnet.nl. An application of the tags could obviously be to create schematic maps with symbols between the nodes. But this would imply that the routes between the nodes can be subdivided. The “incline” information applies to a route between two nodes of the “Radverkehrsnetz NRW” and not two nodes of a “Knotenpunktnetzwerk” which are less dense.
With “nicht verallgemeinerbar” I want to say that these tags only fit to a whole route if the operator uses the same sign on both ends of the route. In Bielefeld it seems to be the case. The operator (Straßen.NRW, that’s Land Nordrhein-Westfalen) claims to show stronger inclines on the guideposts. But they don’t suggest exact values, only >4% and >10%. So the tagging scheme had to include expressions with inequations as well as maximum values. And I’m not sure, whether it could happen that on a guidepost also could occur an incline AND a decline. This could be the reason for the operator to put nodes on the passes, even if there is no branch there. (eg. node 76 - btw. the route tagged bicycle uphill there is a bit nonsense. There are no signs for bicycles there and it leads over stairs. I didn’t delete it for the Stadt Bielefeld shows it in their description of one bicycle route and it looked like they made the entry by themselves. Just added notes and a fixme.)
Das schöne ist: Ich muß es nicht auswürfeln, es ist bereits ausgewürfelt und auf die Wegweiser gedruckt. Das wäre in diesem Fall nicht das Problem. Damit kann man sogar abbilden, dass die Wegweiser auf einen Anstieg verweisen (über die Route), und dass in Wirklichkeit auch Gefälle dabei sind (über die Wege). (Or in other words: The dice have already been used - by the operator. I don’t see a real problem. One uses the tags in the route to show the description of the guideposts that is intended by the operator - this is the logic of the route, just a virtual thing that is the logical representation of the content of guideposts. And one can use tags in the ways to describe the characteristics of the street in real life, there we also have the description of the surface and so on).
… ja, sorry, Deinen Vorschlag muß ich wirklich mal durcharbeiten. Hatte den Link versust. Danke für den Hinweis. Das ist übrigens genau die Frage, ob man es nicht doch so wie im Knotenpunktnetzwerk machen sollte. Du hast natürlich recht mit dem keep it simple. Ich werde sicher als nächsten Schritt erst einmal die zahlreichen Inkonsistenzen im Knotenpunktnetzwerk Bielefeld reduzieren, bevor ich neue Baustellen aufmache…
Agreed. If the signs consistently give attributes of the node2node routes, they can be tagged on the routes. By the way, this is is no different from any other recreational route, but on longer routes I think it is only useful on shorter routes/sections. Nederland had motorboat networks where minimal passage height/width (to be compared with vessel heigth and width) and minimal water depth (compared with vessel depth) and even max allowed boat length (for turns) are given, and we recorded those values on the node2node routes.
Planners could show this on the network map, similar to current display options for quality, unpaved or last surveyed. For incline display, an arrow or a double pointy bracket could show light/heavy incline or decline. Planner output could show this information in the node strip.
It all depends on what the operator puts on the signs, it should be verifiable by survey.
Die Idee, starke Neigungen in die Karten zu bringen, finde ich verlockend. Gute Radkarten haben dort einen Pfeil in Richtung der Steigung oder Ähnliches. Das vermisse ich bei den OSM-Radkarten.
Das an die Relationen zu schreiben birgt die Gefahr, dass dieser Pfeil an die falsche Stelle gezeichnet wird. Häufig wird die Neigung ja nicht den gesamten Abschnitt betreffen und nicht überall gleich stark sein. Das ist dann ärgerlich, wenn ich einen Umweg fahre um diesen Pfeil zu umgehen, um dann doch vor dem Berg zu stehen.
Um das zu vermeiden, müsste die Relationen auch noch zwischen den Wegweisern zerstückelt werden (und man sollte den anderen Mappern im 'note='* erklären, warum das zerstückelt wird).
Die Pfeile sollten nur an Steigungen dargestellt werden, wo eine Radroute oder Netzverbindung langgeht. Will man alle Steigungen darstellen, ergäbe das unübersichtlich viele Pfeile. Es sollten je nach Länge und Schwere der Steigung auch nur ein oder wenige Pfeilssymbole sein.
Ich denke völlig unkritisch ist es, den Inhalt des Wegweisers am Knoten des Wegweisers zu taggen. Nur muss man dabei die Richtung angeben. Wäre das so korrekt?:
incline:northwest=down
Das ist für eine Kartendarstellung aber kaum brauchbar.
Dafür wäre das Vorhandensein einer route-Relation mit ‘route=bicycle’ der Auslöser, eine solche Darstellung zu prüfen. Der Renderer müsste dann entweder incline-Angaben an den Kanten auswerten. Wenn es die nicht gibt dann die kreuzenden Höhenlinien.
Wenn eine Mindestdifferenz und Mindestneigung erreicht wird, sollte der Pfeil gezeichnet werden. Bei steileren Neigungen ein Doppelpfeil. Wenn die Neigungen länger gehen sollten nach einem Mindestabstand weitere Pfeile gezeichnet werden, ansonsten sollte der Pfeil mittig zwischen Beginn und Ende der Neigung sein.
Anders kann ich mir es schwer vorstellen.
Die Steigung betrifft nicht nur Radfahrer sondern ist eine Eigenschaft des Weges, sollte also auch nur genau dort gemappt werden. Das hat in einer Route bzw. in einer Relation nix zu suchen. incline muss nur gemappt werden und Router und Renderer müssen das gescheit auswerten.
Vielleicht ist es auch mißverständlich. Mir geht es darum, den systematisch angewendeten Inhalt der Wegweisung zu mappen. Das ist auch auf dem Boden (“on the earth”) noch einigermaßen in Entwicklung, die Nachbarkreise sind nur teilweise so konsequent darin, aber es ist letztlich das gesamte Netz hier als Knotenpunktnetzwerk aufgebaut, auch wenn die Knoten nicht alle benannt sind. Das heißt, die Wegweisung zeigt nicht nur in diffuser Form in eine Richtung, sondern verbindet streng zwei Punkte miteinander und zusätzliche Eigenschaften zwischen diesen Punkten werden auf beiden Seiten der Wegweisung markiert. Das betrifft auch noch ein Symbol mit einem Bäumchen für “Freizeitroute”, was heißt, die ist nicht zum schnellen Fahren geeignet, sondern geht über Waldwege, benötigt wegen ggf. ebenfalls vermehrt anzutreffenden Fußgängern auch ein langsameres Tempo (also das genaue Gegenteil von z.B. einer MTB-Route).
Diese Marker beziehen sich, sofern keine Fehler in der Beschilderung gemacht werden, auf den gesamten Routenabschnitt. Es stimmt schon, ein Routenplaner muss das wissen. Und das ist gewährleistet, wenn das Tag in der Route steht. Es eignet sich für schematische Karten, die z.B. voraussetzen, dass ein Fahrer auf dem NRW Wegenetz bleiben möchte, das zwischen zwei Knoten nur immer durch die roten Zwischenwegweiser ohne jegliche Zusatzinformation zusammengehalten wird. Da könnten dann die Logos oder Äquivalente mit verwendet werden. Wenn die Informationen in dem Fall aus den Wegen rekonstruiert werden müßten, würde es komplexe Algorithmen erfordern, und die Situation der Wegweiser würde auch nicht abgebildet werden können.
Das über die Wegweiser regeln zu wollen, wäre zwar inhaltlich sauberer (weil man dann nicht mit den z.T. auftretenden logischen Fehlern in der Beschilderung in der Realität kämpfen müßte, und wirklich nur 1:1 abbildet, was da ist), würde aber erfordern, diese Information noch in die direction_xyz=… unterzubringen, womit diese Tags nicht mehr ohne parsing vernünftig lesbar wären oder sehr umständlich und wahrscheinlich uneinheitlich würden. Die aktuelle Syntax ist noch menschenlesbar.
Ich will mich auch gar nicht darum schlagen, so ein Tagging einzuführen. Für mich als Freizeitmapper ist es schon so aufwändig genug, das bisherige Tagging anzuwenden. Ich finde es nur ein bißchen schade, diese Informationen, die so offen auf der Straße liegen, einfach zu ignorieren.
Ich empfehle auch durchaus, die HBR NRW - Hinweise zur wegweisenden Beschilderung für den Radverkehr zu lesen. Ich weiß nicht, ob es für die anderen Bundesländer ähnliche Publikationen gibt, aber es ist m.E. eine große Hilfe in den Entscheidungen, wie man das Netz abbilden könnte. In den Gebieten, in denen das in NRW noch nicht so sehr umgesetzt ist, kann man sich dann auch schon darauf einstellen, was kommt, statt nachher alles neu strukturieren zu müssen.
Es gibt hier übrigens einen Punkt, der auf EINEN anderen (51) in zwei verschiedene Richtungen zeigt (alternative Routen). Weiß auch nicht genau, was planner damit anfangen sollen… Rückwärts ist übrigens nur eine Richtung angegeben.
Ja, das sehen wir auch in Nederland. Eigentlich sollte es einen Zwischenpunkt geben, aber Operatoren vergessen das manchmal. Die Kreuzung hat oft ein Schild “Alternative mit Hochwasser” oder ähnliches, damit der Reisende wählen kann. Mit Knooppuntnet und anderen Planern kann man einfach die richtige Route auswählen.
Die Aufgabe besteht darin, das zu markieren, was wir sehen. Wir können nicht alle Mängel lösen.
Ich finde es sehr gut, dass du dir Gedanken machtst und die hier zur Diskussion stellst. Irgendwann wird jemand sowas mappen und dann hat er das vielleicht nicht so durchdacht und dessen ungünstige Lösung setzt sich womöglich durch. Dann lieber gemeinsam dagegentreten und schauen ob es stehenbleibt oder auch gemeinsam verwerfen (und das dann ggf. im Wiki dokumenmtieren).
Die Zusatzinfos auf den Schildern haben den Vorteil, dass sich jemand intensiv damit beschäftigt hat. Es ist sehr viel wahrscheinlicher, dass die Angaben richtig und relevant sind.
Sie haben den Nachteil, dass sie bereits eine Verallgemeinerung sind und Informationen fehlen, z. B. wo genau die Steigung ist.
Wenn die Informationen sich auf den gesamten Abschnitt der Route beziehen, dann ist die route-Relation schon ein möglicher Platz dafür (neben den Wegweisern), insbesondere wenn es Dinge sind, die sich nicht leicht aus den Wegen ableiten lassen, wie z. B. das Bäumchensymbol.
Selbst die Steigungsangaben wären nicht falsch an der Relation. Die Datenverwerter können ja entscheiden, ob sie diese abstrahierte Information verarbeiten oder sich die Infos detailliert aus den Wegen herleiten. Detailierte Angaben an den Wegen sollten globale Angaben in den Relationen überschreiben. Die Frage ist nur, ob es einen Mehrwert gibt und wie groß die Wahrscheinlichkeit der Missinterpretation ist. Und das sehe ich bei den Neigungsangaben kritisch.
Wenn, dann sollte das m. E. nicht einfach mit ‘incline=down’ gemappt werden sondern vielleicht mit ‘incline_symbol=down’. Somit wäre die Quelle der Angabe gleich mit dokumentiert. Bei ‘incline=down’ könnte man denken, jemand hat das händisch aus den Wegekanten abgeleitet. Das wäre löschenswerter Quatsch.
Wenn sich die Infos nur auf einen Teil der Route beziehen, so müsste man die Route splitten. Das ist es oft bei den Neigungsangaben so. In einem anderen aktuellen Diskussionfaden wurde sich darüber aufgeregt, dass man Wege viel zu viel splittet. Wenn wir jetzt auch noch Relationen in viele Teilrelationen splitten, dann wird das echt unübersichtlich. Da sollten wir uns genau überlegen, ob es das wert ist oder ob wir die Angaben nicht liebr nur an die Wegekanten schreiben.
Ja finde ich auch. Für die Informationen, die sich aus den Wegekante besser ableiten lassen, ist der Mehrwert aber begrenzt. Für alle anderen finde ich es sinnvoll, solange man die Routen nicht splitten muss.
Nur als Idee: Wenn Du die Beschilderung der Wegweiser nicht mit direction_xyz=… einträgst, sondern mithilfe von “destination_sign”-Relationen, könnte man das Steigungs-Symbol unter destination:symbol=… eintragen.