Hallo allerseits, ich habe mich in den letzten Tagen mit dem Fahrradknotennetzwerk in Bielefeld beschäftigt und Änderungen vorgenommen und dann als Neuling festgestellt, dass ich weitere Schritte hier eher diskutieren sollte, ich hoffe, ich habe nicht einige Schritte voreilig unternommen, die Änderungen halten sich aber im Rahmen dessen, was noch einigermaßen gut wieder rückgängig zu machen ist. Was die Knotenpunktnetzwerke angeht habe ich in den verschiedenen Wikis folgende Aspekte gefunden: Zur allgemeinen Struktur der Knotenpunktnetzwerke habe ich mich vor allem zunächst an diesen beiden Seiten orientiert https://wiki.openstreetmap.org/wiki/DE:Fahrradroutentagging#Fahrradknotenpun... https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging (insbesondere für die split nodes). das ist ähnlich, wie JohnH es beschrieben hat am 16.6.: "Kreuzungspunkt wie folgt zu taggen: cycle_network=Bielefeld lcn_ref=41 network=lcn network_type=node_network" Abweichungen von mir: rcn_ref statt lcn_ref (damit in waymarkedtrails cycling die Punkte erscheinen - in opencyclemap erscheinen lokale und regionale Punkte in verschiedenen Farben, da es in Bielefeld gegenwärtig gar keine regionalen zusätzlichen Punkte gibt, benötigt man die Unterscheidung nicht), Entsprechend der Vorschläge im wiki (DE) gab es dann noch folgendes: expected_rcn_route_relations (Achtung: expected_lcn_route_relations ist bislang nicht vorgesehen). network:type statt network_type (wohl eher als Tippfehler zu werten) cycle_network weggelassen (da dies durch die übergeordnete Relation klar wird) network weggelassen Wegweiser habe ich selbst nicht hinzugefügt. Die Routen habe ich wie auf den o.g. Seiten in Relationen zusammengefaßt: End-Knoten und Wegweiser habe ich NICHT zu diesen Relationen hinzugefügt (gibt es in z.B. Heinsberg inkonsistent, ist als "kann" beschrieben), hierbei ggf. an manchen Stellen Rollen forward und backward verwendet. Ich finde die Anmerkung von Peter Czaja ("Was mir grad noch generell zum Mappen von Radrelationen einfällt: bei diesen ist es IMHO wichtig, nicht die an der Straße verlaufenden Radwege aufzunehmen, sondern die Straße selbst. Denn auf welchem Straßenteil (Fahrbahn, Radweg, freigegebener Bürgersteig) man dann unterwegs sein kann will, hängt von aktueller Beschilderung, Richtung, persönlichen Präferenzen sowie Gruppengröße, etc. ab.") hierzu auch passend. Bei größeren Straßen, wie z.B. der Vilsendorfer Straße außerhalb der geschlossenen Ortschaft macht es allerdings schon Sinn, die obligaten Straßenübergänge abzubilden, oder wenn mal die Routenführung doch ein bißchen auseinander gehen sollte (wie an der Uni mit den Einbahnstraßen bei 39-40) Getaggt habe ich folgendermaßen: network=lcn (dachte bis gerade eben, dass sie dann in waymarkedtrails dünner und rot gerendert würden, scheint aber doch 'node_network' abzuhängen). network:type=node_network name=x-y ref=x-y (ich werde künftig noch from und to verwenden, wie empfohlen wird, die auch noch empfohlenen Leerzeichen zwischen den Zahlen im name-Tag habe ich weggelassen, da sie eigentlich nur zwischen Worten Sinn machen). Komplexe Kreuzungen werden unter der oben genannten englischen Seite genauer beschrieben. Dass sich Wege ohne Knotenpunkt gabeln, ist eigentlich kein Problem, dann gibt es halt zwei Relationen, die sich überlappen, als Routen (ist z.B. auch in Heinsberg so: Relationen 2370059 und 2366477). Gesplittete Knotenpunkte sind z.B. in Babenhausen der 37, an der Kurt-Schumacher-Str. der 39 ist eventuell auch nur gesplittet logisch, da man je nach Fahrtrichtung auch mal durch den Tunnel geschickt werden kann. Da ist allerdings die Beschilderung auch unklar). Die Routen und Knotenpunkte habe ich der übergeordneten Relation Knotenpunktnetzwerk Bielefeld (11177857) hinzugefügt. Das ist auch das Vorgehen in Heinsberg, ich weiß nicht, wo die Schmerzgrenze für die Größe liegt, die dortige Relation hat 346 Elemente, davon sind 212 Routen. Was meint Ihr? (Oder ist es Zeit für den angesprochenen Stammtisch?) Viele Grüße, Sebastian