DE talk:Bicycle/Fahrradrouten kartieren

Wo genau ist der Knotenpunkt?

Ich geh’ mal schwer davon aus, dass der Node auf dem Weg liegt. Oder soll er da hinzugefügt werden wo das Schild steht? --Adiac 09:15, 19 August 2009 (UTC)

• Ich nehme immer das Schild als Knotenpunkt --ChristianKnorr 15:10, 25 April 2010 (UTC)
• Den Definitionen über Verkehrsschilder zufolge DE:Road signs in Germany ist auf der Straße bzw der Kreuzung aber auch nicht verkehrt. --User:Ajoessen 10.11.2010
• Das Netzwerk besteht ja aus den Wegen, die Knoten miteinander verknüpfen, die Beschilderung beschreibt das Netzwerk von Wegen und Knoten (Ziele), ein Schild selber ist ja kein Ziel, es sei denn für Beschilderungsfreaks. Drum halt ich die Kreuzung für besser.--Jo 21:52, 21 August 2011 (BST)

Knotenpunktnetzwerk als rcn?

Ich hätte gerne gewusst, warum ein Knotenpunktnetzwerk generell als rcn getagged werden soll. Gibt es darunter noch ein lokales Netz oder einzelne Strecken mit lcn? Ich sehe bisher nicht, dass aus der Art des Netzes (Waben, Knotenpunkte,...) geschlossen werden kann, um welche Netzart (lcn,rcn,ncn) es sich handelt. --KartoGrapHiti 14:37, 25 April 2010 (UTC)

Du hast Recht! Ich habe die Beschilderungsform von der Bedeutung des Netzwerkes getrennt und m. E. auch deutlicher beschrieben, was ein Knotenpunktnetzwerk ausmacht.--Jo 00:45, 22 August 2011 (BST)

Wie ist den nun der allgemeine Konsenz zur Einordnung eines Fahrradknotenpunktnetzwerkes? Im LK Vechta wurde jetzt in allen Gemeinden/Städten Knoten gekennzeichnet. Drei Gemeinden sind bereits eingetragen.

Da der Operator der LK Vechta ist, habe ich alles als "lcn" eingeordnet. [siehe https://www.openstreetmap.org/relation/9447784] --Tyran 19:36, 05 Juli 2019

Mit einigen mappern der Telegram gruppe Infrastuktur habe ich dikutiert wie radwege mit ensprechend grünen Schild aber ohne Routen bezeichnung oder sonstiges zu mappen sind.In der Gruppe wurde mir geraten lcn=yes zu verwenden auch hier habe ich keine Antwort gefunden bzw wiedersprüchliche Informationen. Laut Artikel ist kein network=lcn angebracht... hier ,wiederum sollte ich lcn=yes verwenden. Welches der beiden ist nun richtig? Da es keine direkte Netzwerk referenz/name giebt einfach nur mit bicycle=yes?

Hallo Jonycoo (?)

Wie man mit dem ausgeschildertem Radverkehrsnetz umgeht ist tatsächlich noch nicht im Wiki beschrieben, nur die ggf. darauf verlaufenden Fahrradrouten.

Praxis sind rcn/lcn=yes an den Wegekanten oder network-Relationen mit route=bicycle (aber bitte keine Sammelrelationen wo die Wegekanten alle Fahrrad-Verbindungen eines Kreises in einer Relation landen.!).

Ich bin bereits seit Ewigkeiten am Erarbeiten einer Seite "Fahrradnetze kartieren" analog zu dieser Seite "Radrouten kartieren", bin aber noch nicht dazu gekommen, sie zur Diskussion zu stellen.

Viele Grüße,

--Jo (talk) 21:48, 23 May 2020 (UTC)

(PS: Diskussionsbeiträge bitte immer unterzeichnen, Taste "Signatur" mit dem Schreibschriftlogo drauf).

DE:Key:trail_visibility

Sollte nicht auch DE:Key:trail_visibility mit erfasst werden? Die Kaiserroute (Aachen - Paderborn) ist da ein Beispiel für miese Erkennbarkeit.--Zuse 07:31, 26 August 2010 (BST)

Welchen weg markieren?

Welchen Weg soll ich taggen? In der Kaiserroute ist einiges in Mettmann anders in OSM als es auf der Strasse markiert ist. Die OSM Strecke ist teilweise sinnvoller, aber widerspricht dem Kartenmaterial und der Strassenmarkierung. Es ist ein (50 meter entfernt) parallel laufender Fahradweg, wo offiziell neben der Strasse gefahren wird.--Zuse 08:05, 26 August 2010 (BST)

Grundsätzlich immer das in der Relation aufnehmen, was man draussen in Form von Schildern sieht.

Ausnahme: Durch Vandalismus zerstörte oder verdrehte Schilder. Dies eventuell als note an den Knoten setzen.

Ob ein anderer Weg nun schöner zu fahren ist, bleibt deinem subjektiven Empfinden, Wetter, Tagesform usw. überlassen. Sollte die ausgeschilderte Route langfristig unpassierbar sein, ist ein Hinweis an den Routenbetreiber sinnvoll.

--User:Ajoessen 10.10.2010

Internationale Routen icn auf keiner Karte gerendert

Eine internationale Route network=icn wird bisher auf keiner Karte gerendert. Durch Berlin führt zB die Euro Route R1 Relation 1208296. Sie ist in Deutschland identisch mit D3, da sie aber extra ausgeschildert ist und auch weiter führt, sollten beide gerendert werden. Es scheint auch noch keine Farbe für icn festgelegt worden zu sein. Schön wäre es, wenn der Strich breiter wäre, dann könnten darauf auch noch parallel laufende nationale und regionale Routen sichtbar sein.--geozeisig 09:42, 24 November 2010 (UTC)

Seit kurzem können die Internationalen Routen auf cycling.lonvia.de verfolgt werden. Die Karte ist sehr schön gemacht, da sie auch weitere Information anzeigt. Ich habe daraufhin den R1 weiter vervollständigt.--geozeisig 18:09, 27 August 2011 (BST)

Geplante, bzw. konzipierte Routen ('state=proposed')

Größere Kommunen, Kreise und Länder haben in der Regel Radverkehrskonzepte mit ihrem geplanten Zielnetz von touristischen oder Alltagsfahrradrouten. Oftmals ist ein großer Teil dieser Routen erst in früher Planung, also noch nicht ausgeschildert und teilweise garnicht gut zum Fahrradfahren. Entsprechend der Vorgehensweise, nichts zu taggen, was es draußen nicht gibt, sollten nicht ausgeschilderten Routen auch nicht in OSM aufgenommen werden.

Nun gibt es aber die Praxis, solche Routen mit 'state=proposed' zu versehen, die eigentlich der oben genannten Grundregel widerspricht. Solche Routen werden in manchen Renderern auch entsprechend dargestellt (in OpencycleMap gestrichelt). Weil 'proposed' in der Praxis verwendet wird, sollte man hier auch Empfehlungen dazu aufnehmen.

Ein Mehrwert für den nach Kartenbenutzer ergibt sich eigentlich nur, wenn geplante Routen dargestellt werden, bei denen in Kürze mit der Realisierung begonnen wird, so dass er das in seinen Routenplanungen berücksichtigen kann oder er vorbereitet ist, eine nagelneue Wegweisung zu finden, die noch nicht in der Karte enthalten und ggf auch noch nicht vollständig ist.

Informationen über Planungen, deren Umsetzung noch nicht absehbar sind oder die erst in vielen Jahren umgesetzt werden sollen, sind für die Hauptfunktion von Radkarten - die Routenplanung bzw. die Orientierung - ohne Mehrwert.

Dementsprechend habe ich einen Hinweis aufgenommen, dass geplante Routen nur aufgenommen werden sollten, wenn ein kurzfristiger Umsetzungszeitpunkt bekannt ist und die Finanzmittel dafür bereitstehen. --Jo 00:09, 19 August 2011 (BST)

Abweichend von der obengenannten Regel kann es sinnvoll sein, geplante aber noch nicht ausgeschilderte Routen in die OSM-Datenbank aufzunehmen, wenn das Aufstellen der Wegweisung kurz bevor steht. In diesem Fall kann eine Route mit proposed:route=bicycle

Für "kurz vor der Beschilderung" = geplant steht planed und nicht proposed --Langläufer (talk) 13:51, 11 May 2023 (UTC)

--Langläufer (talk) 13:51, 11 May 2023 (UTC)

DE:Bicycle/Weg oder Route

Folgenden Text habe ich von DE:Bicycle/Weg oder Route hierher verschoben. Die Informationen gehören nicht auf „Weg oder Route“, sind auf „Fahrradroutentagging Deutschland“ aber schon in kurzform vorhanden.

Radrouten gibt es auf verschiedenen Ebenen und sie werden von verschiedenen „Betreibern“ ausgewiesen.

• Städtische und lokale Radrouten (network=lcn)
  • kurze, meist auf eine Stadt oder einen Landkreis beschränkte Routen
  • oft als Rundtour angelegt, bei der Start und Ziel der gleiche Punkt sind
  • oftmals in einer Tagesetappe (40 km) fahrbar,
  • werden meist von der Stadt, den Kreisbehörden oder dem lokalen Fahrradverein betrieben

• Regionale Radrouten (network=rcn)
  • längere Routen, verbinden oft größere Städte,
  • führen oft an längeren Flüssen entlang (z.B. Main-Radweg)
  • an einem Tag oder mit mehreren Tagesetappen befahrbar,
  • oftmals durch Verbünde von Tourismusregionen betrieben

• Nationale Radrouten/Radfernwege (network=ncn)
  • mehrere Bundesländer werden be-/durchfahren,
  • hierbei handelt es sich in Deutschland um die D-Routen (1-12),
  • in der Schweiz siehe Veloland Schweiz)
  • generell in mehreren Tagesetappen befahrbar,
  • D-Netz-Routen im Wiki mit Status

• Internationale Radrouten
  • in Europa die "EuroVelo-Routen" (1-12)
  • andere Beispiele für internationale Radwege wären PanEuropa-Radweg, Nordseeroute, Donau-Radweg
  • bisher noch kein Tag vorhanden, Vorschlag wäre natürlich network=icn

--KTim 09:50, 29 December 2011 (UTC)

Ich habe die Informationen nun in den Artikel eingepflegt. --KTim 16:24, 30 December 2011 (UTC)

Quelle für ref?

Bei rcn und lcn ist mir in vielen Fällen nicht klar, wo der Inhalt des ref-tag herkommt.

1. Der Betreiber hat seiner Route (z. B. auf der dazu gehörenden Webseite) eine Abkürzung angegeben, dann kann man die übernehmen.
2. Die Schilder an der Route enthalten eine Abkürzung, dann halte ich das auch für eine sinnvolle Benennung.

Was ist in den (vielen) anderen Fällen, z.B. dem [Aller-Radweg]? Die o. g. Möglichkeiten liefern keinen Hinweis. Der Wikipedia-Eintrag nennt "ARW" als Abkürzung, allerdings ohne Beleg für diese Bezeichnung. Miple (talk) 12:35, 25 July 2013 (UTC)

Ich habe den Eindruck, dass Derjenige, der zuerst kommt, sich ein Kürzel ausdenkt. Ich finde das nicht gut aber die Alternative wäre auf eine Bezeichnung in der Karte zu verzichten. Dann ist die Route in einem Netz von Routen aber nicht mehr zu unterscheiden.--Jo (talk) 22:41, 25 July 2013 (UTC)

Sich ein Kürzel auszudenken sehe ich als Information erfinden. Wir sollten mappen, was in der Realität existiert und nicht was wir am liebsten hätten. Um die Darstellungsprobleme sollte sich der Renderer kümmern. Dort kann man sich immer noch entscheiden, fehlende Markierung durch etwas künstliches zu ersetzen oder die Zugehörigkeit zu einer Route sonstwie erkennbar machen. --Nzara (talk) 16:18, 16 July 2014 (UTC)

Seite Radwegenetze und diese zusammengelegt - schaut aber auch in die Diskussionsseite von Radwegenetze

Die beiden Seiten waren in großen Teilen redundant. Ich habe nun die Inhalte, die hier nicht vorkamen, kompromiert und hier hinzugefügt und bei DE:Radwegenetze eine Weiterleitung auf diese Seite eingerichtet. Trotzdem lohnt ein Blick auf deren Diskussionsseite, da wurden einige Dinge andiskutiert, die für diese Seite interessant sein können, insbesondere die Benennung von Radroutenrelationen und die Art und Weise, wie man Radroutennetze in Relationen abbildet. --Jo (talk) 20:55, 27 July 2015 (UTC)

Kritik an Relationen für Fahrradknotennetzwerke berechtigt und hier sinnvoll?

User:Nakaner hat heute unter Fahrradknotenpunktnetzwerk folgendes hinzugefügt: Die benannten Knoten werden durch Streckenabschnitte verbunden. Um sie als Netzwerk zu markieren, gibt es zwei konkurrierende Ansätze (siehe unten). ... die Ways werden in Routenrelationen zusammengefasst. Diese Methode erhöht die Komplexität der Datenverarbeitung für Datennutzer und Mapper. Wenn mehrere Kanten eines Knotenpunktnetzwerkes in einer Relation zusammengefasst sind (ja, das gibt es), wird solch eine Relation gerne auch als Sammelrelation kritisiert. Deshalb sollte das vermieden werden (in BeNeLux wird es aber so gemacht). ... Danach wird beschrieben, wie eine Fahrradroute zwischen zwei Knotenpunkten als Relation angelegt wird.

Entweder verstehe ich den Text nicht oder ich kapiere nicht, was das Problem ist.

Ich verstehe die Kritik, dass es unübersichtlich und als Sammelrelation zu verstehen wäre, wenn alle Kanten eines gesamten Netzwerkes in einer Relation gefasst werden. Wenn die Ergänzungen das ausdrücken sollen, dann sind sie aber missverständlich. So wie es da steht wird schon kritisiert, die Strecke zwischen zwei Knoten in einer Relation zusammenzufassen.

Ist es so gemeint wir ich den Text verstehe, dann ist die Kritik für mich nicht nachvollziehbar. Es ist ganz normal und Standard, dass man Wanderwege, Buslinien und eben auch ausgeschilderte Radrouten in Relationen zusammenfasst. Das hat den Vorteil, dass man Informationen über die Strecke an einer Stelle bündeln kann. Dass das unübersichtlich oder als Sammelrelation kritisiert werden könnte verstehe ich nicht.

Die Diskussion, ob man Fahrradrouten über Relationen oder über tags an den Wegen markiert wurde vor vielen Jahren geführt und ist meines Erachtens durch dei Praxis hinfällig geworden, in der die Relation die Regel geworden ist, das taggen von ncn=yes usw. ist meines Erachtens daher veraltet. Daher verstehe ich nicht, warum das nun hier wieder beschrieben wird. Gab es irgendwo vorher eine entsprechende Diskussion?

Bis das geklärt ist, habe ich erstmal die wertenden Teile der Änderung wieder rausgenommen.

--Jo (talk) 22:18, 29 May 2016 (UTC)

Taggen von network an Radwegweisern, wenn diese auch Wanderwegweiser sind.

Bislang wurde hier geregelt, dass Wegweiser eines Fahrradknotenpunktnetzwerkes ein network-Attribut erhalten sollten, z.B. network=rcn. User Waldhans hat das mit folgender Ergänzung versehen: "FALSCH: nur die Knotennummer taggen, kann auch gleichzeitig ein Knoten in einem Wandernetzwerk (rwn=) sein!"

Ich kann den Einwand nicht nachvollziehen. Wurde das schon irgendwo diskutiert?

Wenn ein Wegweiser ein regionales Fahrradnetzwerk ausweist, dann kann es m. E. nicht "falsch" sein, network=rcn am Wegweiser zu vermerken. Es entspricht genau dem, was man draußen vorfindet. Sollte der Wegweiser-Mast neben Fahrradwegweiser auch Wanderwegweiser aufnehmen, so stellt sich die Frage, wie mit Attributen umgegangen werden, die doppelt belegt werden, z.B. network. Das ist m. E. ein Problem, das es öfter in Osm gibt. So kann eine Straße gemischte Beläge haben (surface=asphalt;cobblestone). Die Regel dafür findet sich im Wiki unter DE:Attribut: "Nur bei Bedarf sollten mehrere, per Semikolon getrennte, Werte gleichzeitig verwendet werden". So ist es m. E. auch hier, also z. B. network=rcn;rwn .

Eleganter ist es freilich, für die Wanderwege und Radrouten eigene Relationen anzulegen und den Wegweser in beiden aufzunehmen.

Ich habe daher die Änderung zurückgesetzt und stelle das hier zur Diskussion.

Viele Grüße,

--Jo (talk) 23:38, 25 February 2017 (UTC)

Es ist mir fast peinlich, die Diskussion zu führen, aber versuchen wir es.

Der Typ des Netzwerks steckt ja schon im key. hier "rcn_ref=09". Das muss sich also auf ein rcn beziehen und auch ein Mitglied einer solchen Relation sein. Die Angabe network=rcn ist also redundant.

Darüber hinaus ist der network-Key auch gefährlich. Was gilt bei

rcn_ref=09

network=rwn

Antwort: egal, die parent-relation entscheidet.

Und natürlich eine Katastrophe, falls der Knoten in mehreren Knotenpunktnetzwerken liegt. Weit verbreitet in den Niederlanden. Mit dem :"Semikolon"-Vorschlag wird ein Fehler halt noch potenziert.

Gibt es irgendein Argument für den network-Key ???????

--Waldhans (talk) 08:34, 27 February 2017 (UTC)

Hallo Waldhans, du hast die Diskussion gestartet, ich habe sie nur von der Seite hierher verschoben, wo sie besser aufgehoben ist. Musst du also mit dir selber abklären, ob dir das peinlich ist.

In deinem ersten Kommentar hattest du geschrieben, der Tag sei falsch, nicht er sei überflüssig. Bei "Falsch" gehe ich absolut nicht mit, bei "überflüssig" schon, die Begründung ist einleuchtend.

Bei deiner restlichen Argumentation verstehe ich nicht, was dein Problem ist. Beim Beispiel "rcn_ref=09 mit network=rwn" ist doch eindeutig, dass es ein Fahrrad- und Wanderwegweiser ist. Warum ein "network=rwn;rcn;" eine Katastrophe ist, warum das ein Fahler ist und diesen noch "potenziert", geht aus deinem Post nicht hervor.

Radwege als Relationen zu taggen ist besser und eleganter, aber das Taggen direkt an dem Weg ohne Relation oder an den Wegweiser ist deswegen nicht falsch.

Ist aber auch müßig und egal, denn der Tag network sollte in Kombination mit rcn_ref wegen der Redundanz einfach nicht verwendet und aus dem Beispiel gelöscht werden, was ich nun mache.

Grüße, --Jo (talk) 19:17, 1 March 2017 (UTC)

Danke für die Löschung.

Jetzt hätte ich noch folgende Bitten:

bei der Routen-Relation das Name-Tag auf optional setzen

in den Niederlanden / am Niederrhein wird note=* verwendet, nötig ist weder/noch!

bei der Netzwerk-Relation:

* operator bestenfalls optional

was genau ist hier gemeint:

die Behörde, die die Routen festlegt (z.B Kreis),

oder die Behörde, die die Beschilderung verwaltet (z.B. die Gemeinde)

* route=cycling löschen

falsch, die relation ist ein network und keine Route

Mit diesen Änderung nähert sich die Wiki-Seite der Realität.

Und schicke mir mal ein Beispiel für ein Knotenpunktnetzwerk mit "Taggen direkt an dem Weg ohne Relation".

--Waldhans (talk) 21:43, 1 March 2017 (UTC)

Änderungen sind erledigt. Hab auch die Relationen als Vorzugsvariante dargestellt, ohne das Taggen von network an Wegen als falsch zu bezeichnen.

Laut taginfo sind 1,96% der Wegweiser mit network=lcn und 0,99% mit network=rcn versehen.

Grüße,--Jo (talk) 23:36, 1 March 2017 (UTC)

Fehler im Abschnitt Fahrradknotenpunktnetzwerk

Knoten: network=rcn ist falsch

zwei konkurrierende Methoden: NEIN, genau eine, die Relationen

Routen-Relation:

• (Vorschlag) note statt name;
• die Ortsnamen nicht verwenden, in description oder note:de schreiben

In der Relation sind nur Wege, geordnet Start-Ende

Netzwerk-Relation:

• operator: weglassen, gibt Fehler
• route=cycling: ist total falsch, weglassen (ist ja ein Netzwerk...)
• ref=* ist die Abkürzung des Netznamens: MD, Rmnd, HS, NE, VIE (Kennzeichen Kreis)

In die Netzwerk-Relation kommen

• alle Routen-Relation (ohne role)
• alle Knoten (punkte) (ohne role)

sonst nichts; keine Wegweiser, keine Tafeln, keine isolierten Wege, etc.

Als Knotenpunkt können die Kreuzungsknoten selber und die dazugehörigen Wegweiser angegeben und in die Relationen der hier beginnenden Streckenabschnitte aufgenommen werden. Keine Ahnung, was das soll. Löschen!

Offene Punkte

• Routen doppelt erfassen (A→B, B→A) statt dem unprüfbaren forward/backward Trick (Vorbild PTv2)
• Verbindungen zur Nachbarnetzen: role=connection auf Routen-Relation (Vorschlag)
• Verbindungen innerhalb eines Knotenpunktes (ebenfalls connection?)

--Waldhans (talk) 17:36, 28 February 2017 (UTC)

Die Überschrift "Fehler" empfinde ich betreffs der Mehrzahl deiner Vorschläge zu hart.

Ich sehe nicht, dass eine network-Tag nur an einer Relation stehen darf nicht an einem Knoten, insbesondere, wenn dieser nicht in einer Route-Relation enthalten ist und nicht "rcn_ref=* enthält. Wenn du etwas als Fehler bezeichnest, dann begründe das bitte auch, siehe oben.

Das es in OSM zwei konkurierende Methoden gibt ist Fakt. Aber begründe doch bitte, warum die eine falsch ist. Ich mag das Taggen von Netzwerkeigenschaften direkt am Weg auch nicht und gehe mit, dass wir Relationen empfehlen sollten. Wenn man etwas löscht, sollte man das aber ordentlich begründen und einfach zu behaupten dass es falsch sei finde ich nicht ggü. dem, der es - vielleicht begründet reingeschrieben hat sehr unhöflich.

Ich denke, dass man insbesondere betreffs des name-Tags nichts ohne triftigen Grund ändern sollte, denn dann wäre viel Vorhandenes nicht mehr regelkonform und durch die neue Vorgehensweise würde die Vielfalt der Vorgehensweisen zunehmen.

Du hast nicht begründet, warum die Relation nicht durch die Ortsnamen benannt werden soll. Diese sind ja nicht erfunden sondern stehen auf den Wegweisern. Oder meintest du, dass man die Ortsnamen nur dann nehmen sollte, wenn sie auch auf den Wegweisern stehen? Das klingt schon plausibler, aber macht das Ganze nicht unbedingt übersichtlicher. Hier würde ich schon auf die Intelligenz des Mappers vertrauen. Er kann entscheiden, ob ein Ortsname eindeutig zuordenbar ist (vermutlich in weit über 90% der Fälle so). Vielleicht sollten wir ergänzen, das er den Ortsname dann weglassen soll, wenn er sich nicht sicher ist.

Zwingend ist m. E., dass irgendwie systematisch erkennbar ist, welche Knotenpunktnummern/-namen die Relation verbindet. Das muss auf eine systematische Weise erfolgen, als nicht irgendwo als Freitext in note oder description versteckt sondern so, dass es von Renderern einfach verarbeitet und auf einer Karte dargestellt werden kann. Bislang waren dafür ref (eher für Nummern/einzelne Buchstaben) bzw. name (eher für Text) üblich.

Warum ergibt operator einen Fehler? Wenn der Betreiber bekannt ist, kann und sollte man das m. E. auch vermerken. Das ist z. B. dann hilfreich, wenn man Schäden oder Verbesserungsvorschläge an den Wegweisern melden will.

Warum willst du die Wegweiser aus den Radweg-Relationen des Knotenpunktnetzwerkes rausschmeißen? Dann wäre das inkonsistent zu den anderen Radweg-Relationen. M.E. gehören die Wegweiser zu Radrouten unbedingt dazu, denn sie definieren draußen den Verlauf der Radroute an Kreuzungen und Abzweigen, der Zusammenhang kann offensichtlicher nicht sein. Die Relationen helfen, die zugehörigen Wegweiser zu finden. Das ist meines Erachtens seit langen gelebte Praxis. Wenn es das nicht gäbe, so müsste man an die Wegweiser schreiben, welche Radrouten an ihnen ausgeschildert sind. Das finde ich sehr unelegant und wenig übersichtlich (Radroutennamen ändern sich auch mal, z.B. Muldentalradwanderweg in Mulde-Radweg). Das sollte man im Forum ggf intensiver diskutieren.

Deine Begründung für das Weglassen von route=cycling bei einer network-relation ist für mich nachvollziehbar.

Ich kann mich an Diskussionen erinnern, wo ref=* bei Radrouten nicht akzeptiert wurde, wenn es eine vom Mapper erfundene Abkürzung ist. Genau diese Praxis ist aber sehr weit verbreitet und meist hilfreich. Vielleicht ein ", so vorhanden" dahinter geben.

Die Knotenpunkte eines Knotenpunktnetzwerkes in die Netzwerkrelation aufzunehmen klingt für mich plausibel. Dass sie ein wesentliches Element des Netzwerkes sind sagt ja schon die Netzwerkbezeichnung "Knotenpunktnetzwerk".

Allerdings wurden sie bisher zu den Routen gepackt. Sie sind ja die Punkte, die Anfangs- und Ende definieren. Was spricht aus deiner Sicht dagegen?

Es gab die Diskussion, ob der Knotenpunkt nun die Wegkreuzung ist (die kann sich auch über mehrere Kanten hinziehen) oder der Wegweiser, auf dem die Nummer steht, oder beides? Knotenpunkt sollte entsprechend genauer definiert werden. Ist Ansichtssache ob der Knotenpunkt durch ein Schild definiert wird oder das Schild nur auf den Routen-Abzweig bzw. die Routen-Kreuzung hinweist.

Genau aus diesem Grund steht der Satz da "Als Knotenpunkt können die Kreuzungsknoten selber und die dazugehörigen Wegweiser angegeben und in die Relationen der hier beginnenden Streckenabschnitte aufgenommen werden." Also nicht löschen sondern verständlicher formulieren, wenn es schwer verständlich ist.

Getrennte Relationen für jede Fahrtrichtung zu erstellen ist aufwendig, bin ja schon froh, wenn überhaupt Relationen verwendet werden. Das sollte nur gemacht werden, wenn es wirklich Abweichungen zwischen den Richtungen gibt und das bei Radwegen schon generell üblich ist, ansonsten würde ich das im Forum intensiv diskutieren.

Wenn es im Knotenpunktnetzwerk Radrouten ohne Knotennummern gibt, dann würde ich sie wie jede andere Route ohne Knotennummern im Namen taggen. Gibt es bereits eine analoge Verwendung von role=connection? [Edit: hab selber nachgeschaut: ja]

Viele Grüße, --Jo (talk) 21:25, 1 March 2017 (UTC)

-----------------------

Zum WIKI

1. bitte noch ref=* (optional) aufnehmen. Diese Abkürzung des Namens wird bei Auswertungen und bei Netz-übergreifenden Routen dem Knoten vorangestellt. (93-23-Rrmnd 88-45). Und LvPM ist handlicher als „Land van Peel en Maas“. Zur Diskussion: die Namen der ref=* werden hier auch von den Planungsämtern verwendet, sind also keineswegs eine vom Mapper erfundene Abkürzung.
2. Als Beispiel könnte man neben der unbenannten Sammel-Relation 373530 ja auch ein echtes Knotenpunktnetzwerk (z.B. Viersen) aufnehmen.

Allgemein

1. mir fehlt noch dein Beispiel für ein Knotenpunktnetzwerk mit "Taggen direkt an dem Weg ohne Relation".
2. Ortsnamen im Relationsnamen: widerspricht halt des Praxis in Benelux/Niederrhein und auch dem „Geist“ eines Knotenpunktnetzes, man radelt halt von 12 über 34 nach 13. Die Relation verbindet genau diese 2 Knoten, daher der Name 05-23. Hast du ein Beispiel für deine Variante?
3. Knotenpunkte als member der Routen statt des Netzwerks. Habe ich noch nie gesehen. Hast du ein Beispiel? Wie man in Benelux/Niederrhein sieht, ist das auf jeden Fall überflüssig.
4. Die strikte Trennung zwischen Routen (Knoten & Kanten) und der Beschilderung (amtlich Fahrradwegweisung, Pfosten + Pfeil + Plaketten) ist extrem hilfreich. Aus der Vermischung ergeben sind nah meiner Erfahrung die meisten Probleme, siehe auch diese Diskussionsseite.

Die amtliche Planung läuft (am Niederrhein) grob so ab:

1) die Routen werden in einem GIS-System festgelegt, als Knoten (Abzweigungen) und Wege zwischen den Knoten.

2) eine Software berechnet für einen Knoten dann die Beschilderung.

(in NRW) rot-weisse Pfeile mit Ortsnamen für das Grundnetz

Plaketten für die Themenrouten (Symbole) und für das Knotenpunktnetzwerk (Nummern)

Genau so kann man auch mit OSM-Daten verfahren: wir können die Beschilderung aus (korrekt) eingegebenen Relationen ableiten (habe ich getestet).

Also, die Beschilderung ist sekundär und, ja ich sage das immer so hart, unnötig.

Seit JOSM die Pfosten (information=guidepost) auf einem Weg nicht mehr zulässt, trat hier eine deutliche Entspannung in der Praxis auf.

Diese Trennung Knoten – Pfosten ist vielleicht schwer verständlich, aber essentiell für die Konsistenz der Daten.

mfg Kurt --Waldhans (talk) 11:30, 2 March 2017 (UTC)

Hallo Kurt, Danke für die Antworten

betreffs ref=*: Diese Abkürzung des Namens wird bei Auswertungen und bei Netz-übergreifenden Routen dem Knoten vorangestellt. (93-23-Rrmnd 88-45).

ref habe ich aufgenommen, danke für den Hinweis. Den Rest verstehe ich leider nicht. Welche Auswertungen? Wie genau setzt sich der Tag bei Netz-übergreifenden Routen zusammen. Wenn ich links ein Netz "abc" mit Knoten Nr 1 und rechts ein Netz "yxz" mit Knoten Nr 99 habe, wäre dann (ref=1-abc yxz-99)? Das finde ich wenig selbsterklärend und habe ich auch noch nicht gesehen. Warum nicht einfach ref=1-99 und type=connection?

mir fehlt noch dein Beispiel für ein Knotenpunktnetzwerk mit "Taggen direkt an dem Weg ohne Relation"

Hier http://www.openstreetmap.org/way/45574547, ist aber kein Knotenpunktnetzwerk. Ich weiß nicht, wie ich andere Beispiele finden soll, denn aus den Daten lässt sich nicht herausfiltern, was ein Knotenpunktnetzwerk und was ein normales Netzwerk ist, schon gar nicht, wenn es keine Relationen gibt. Im englischen Wiki wird diese Möglichkeit übrigens schon seit Langem beschrieben.

Ich habe mal nachgeschaut, eingetragen hat das am User Nakaner am 29. Mai. Ich selber habe im Diskussionspunkt oben drüber bereits angekündigt, das zu Löschen, wenn sich keiner meldet, es hat sich keiner gemeldet. in diversen anderen Sprachen wird die alte Vorgehensweise noch genannt, aber immer die Releation empfohlen. Ich habe das jetzt einfach mal gelöscht.

Ortsnamen im Relationsnamen: widerspricht halt des Praxis in Benelux/Niederrhein und auch dem „Geist“ eines Knotenpunktnetzes, man radelt halt von 12 über 34 nach 13. Die Relation verbindet genau diese 2 Knoten, daher der Name 05-23. Hast du ein Beispiel für deine Variante?

Widersprechen würde es nur, wenn man nur Ortsnamen und keine Zahlen verwendet, wie in diesem Beispiel.

Es gibt sehr unterschiedliche Knotenpunktnetzwerke. Ich kenne Netze in den Niederlanden, wo sehr viele Knotenpunkte außerhalb der Orte sind und die meisten keinen Orten zugeordnet werden können. Oft werden auf den Wegweisern nur die Nummern ausgewiesen, keine Orte oder die ausgewiesenen Orte sind nach dem nächsten Knotenpunkt. Dort sollten - wie von dir beschrieben - nur die Nummern verwendet werden.

Bei anderen Netzen, wie das in der Prignitz, sind einerseits sehr viele Wegweiser in Orten und andererseits weisen die Wegweiser i. d. R. den nächsten Knotenpunkt als Ortsname und im Einschub unten als Zahl aus. Ziel ist, beides zu ermöglichen: Radeln nach Zahlen und Radeln wie gewohnt. Deswegen macht es hier Sinn, beides in den Namen der Verbindungen aufzunehmen, so auf den Wegweisern vorhanden. Vielleicht sollte man empfehlen, den name-tag nur zu benutzen, wenn die Knotenpunkte neben den Nummern auch Namen haben oder die Orte auf den Wegweisern ausgeschildert sind, sonst nur das ref-Tag mit den Nummern.

Fazit: Weil es verschiedene Knotenpunktnetzwerke gibt, gibt es auch im Wiki die Wahl, beides zu tun.

Knotenpunkte als member der Routen statt des Netzwerks. Habe ich noch nie gesehen. Hast du ein Beispiel?

Auch das hat User Nakaner am 29. Mai hinzugfügt, frag ihn am besten. Ursprung ist sicher die Diskussion der Seite DE talk:Radwegenetze, wo das von Niederländern als übliche Praxis beschrieben wurde. Ich habe nach diesem Wiki schon mehrere Wege so eingetragen, z.B. hier, andere auch, z. B. hier in Belgien.

Die strikte Trennung zwischen Routen (Knoten & Kanten) und der Beschilderung (amtlich Fahrradwegweisung, Pfosten + Pfeil + Plaketten) ist extrem hilfreich. Aus der Vermischung ergeben sind nach meiner Erfahrung die meisten Probleme, siehe auch diese Diskussionsseite.

Welche Probleme genau meinst du? Wenn ein Algorithmus ein Problem mit Knoten in der Relation hat, dann gibt es eine extrem simple Lösung: Entweder Knoten ignorieren oder auswerten, was für ein Knoten das ist. Auf welche Diskussion beziehst du dich?

Das Aufnehmen von Wegweiser in Radrelationen ist seit Jahren gängige Praxis, so wie bei Busrouten die Haltestellen aufgenommen werden. Solche Änderungen sollten im Forum in größerer Runde diskutiert werden als nur zwischen uns beiden.

Seit JOSM die Pfosten (information=guidepost) auf einem Weg nicht mehr zulässt ...

Das scheint eher eine falsche Umsetzung des Validators in JOSM zu sein. Sie kann sich zumindest nicht auf die Wikidefinitionen berufen, denn sowohl im englischen als auch im deutschen Wiki sind Wegweiser als Member ausdrücklich genannt.

wir können die Beschilderung aus (korrekt) eingegebenen Relationen ableiten

Du meintest vermutlich die Beschriftung der Wege in der Karte? Darum geht es hier gar nicht. Es geht um die genauen Standorte der zugehörigen Wegweiser an den jeweiligen Kreuzungen. Wo diese stehen legen die Betreiber der Radrouten individuell anhand der örtlichen Begebenheiten fest, das kann man gar nicht anhand von Algorithmen ableiten.

--Jo (talk) 00:49, 4 March 2017 (UTC)

---

Bei den ref-tag habe ich mich unverständlich ausgedrückt. Dieser tag gehört zur Netzwerk-Relation. Unterhalb der Zeile 'beispielsweise name=Knotenpunktwegweisung Prignitz'

Tags	Beschreibung
ref=* (optional)	Kurzbezeichnung der Netzwerks. Bei einem kreisweiten Netzwerk z.B. das Kfz-Kennzeichen,beispielsweise ref=PR

Bitte ändere das noch. --Waldhans (talk) 08:44, 4 March 2017 (UTC)

---

Zuerst mal Danke für deine Geduld und auch für deine Ausführungen, ich habe jetzt genug zum Nachdenken. Noch ein Gedanke zu den Netzwerk-Relation:

Verschiedene Typen einer Fahrrad Netzwerk-Relation

„reine“ Sammel-Relationen

Kennzeichen: ungeordnete Liste von Wegen

Beispiel: Radverkehrsnetz NRW, Kreis Viersen (2003658)

Diese ist wieder Teil einer Sammel-Relation: Radverkehrsnetz NRW (33216)

Flapsig gesprochen, wird hier die Karte angemalt. Es bedarf eines Routers, hier eine Tour zu planen.

In NRW wird so das landesweites Radverkehrsnetz definiert. Wiki

Netzwerk-Relation

Kennzeichen: Liste von Relationen

komplexes Beispiel: NiederRheinroute (5406832)

besteht aus einer dreigeteilten Hauptroute und etwa 100 Nebenrouten

Jede Teilrelation ist eine geordnete Liste von Wegen; siehe Wiki;

Knotenpunkt-Netzwerk-Relation

Kennzeichen: Liste von Relationen und Knotenpunken

Beispiel: Knotenpunktnetzwerk Kreis Viersen (4257206)

Hier ist die Netzwerk-Relation unbedingt nötig.

Und natürlich gibt es alle Mischformen, das sind nur mal 3 Typen aus meiner Gegend. Das alles in einen Absatz im Wiki zu beschreiben, ist sicher nicht einfach.

Ich sehe aber aktuell keinen Bedarf, das Wiki zu ändern. --Waldhans (talk) 17:50, 5 March 2017 (UTC)

Wegweiser als Teil der Relation?

User:JochenB ergänzte im Text: Die Wegweiser werden in die zugehörigen Routen-Relationen mit der Rolle 'guidepost' aufgenommen.

user:Waldhans NEIN: die Beschilderung hat in den type=route Relation nichts verloren. Die Route muss ohne Bechilderung in OSM eindeutig sein. Falls man die Schilder erfassen will, dann als site-Relation mit der route als child!

Ich habe das nicht erfunden sondern das aus dem englischen Wiki entnommen, wo unter Relation:route#Members die Rolle 'guidepost' als eine mögliche Verwendung angenommen wird. Das ist ähnlich den Bussteigen bei Buslinien. Was spricht dagegen und wo kommt das her? --Jo (talk) 23:39, 14 September 2017 (UTC)

user:Waldhans Wir hatten ja die Diskussion schon; Auch in einer PTv2 Routen-Relation sind keine Pfosten/Schilder enthalten.

Hallo Waldhans,

Deine Antwort wirft mehr Fragen auf als sie beantwortet.

Bislang stand hier, dass Wegweiser in Routen aufgenommen werden können. Jetzt schreibst du, dass das nicht geht. Damit steht Deine Änderung im Widerspricht zur Definition von Routen, nach derer Wegweiser Teil der Route sind und diese sogar eine eigene Rolle haben. Eine wirkliche Begründung hast du bislang nicht gegeben außer "Wir hatten ja die Diskussion schon". Unbeantwortet bleibt: Wo wurde das diskutiert? Warum ist das schädlich? Wie willst du den Widerspruch zur Definition der Route lösen?

Du schriebst "Die Route muss ohne Bechilderung in OSM eindeutig sein". Offen bleibt: Warum ist eine Route nicht mehr eindeutig, wenn sie die Wegweiser enthält? Was ist daran schädlich?

In Bus-Relationen werden sehrwohl Dinge außerhalb der eigentlichen Route aufgenommen, z.B. die Bussteige - oftmals sind das draußen nur die Haltestellenschilder. Das ist nicht das selbe aber vergleichbar. Offen bleibt: warum ist das dort keine Problem aber hier eines?

Dein Stil ist merkwürdig. Du schreibst Disskussionsbeiträge direkt in die Seite und überlässt es anderen, das auf die Diskussionsseite zu schieben. Nun schreibst du auf die Seite, was man auf keinen Fall tun darf - auch nichts anderes als eine Fortsetzung der Diskussion direkt auf der Seite. Diskussionen gehören auf die Diskussionsseite.

Dein "Wir hatten ja die Diskussion schon" wirkt nicht sehr wertschätzend und ist zudem falsch. Wir hatten die Diskussion nicht. In meinem Mailfile ("wir" im Sinne "wir beide") habe ich keine Mails von dir gefunden. Hier auf diese Diskussionsseite ("Wir" im Sinne "Wir hier") ist auch nichts dazu. So ein Umgang verleidet einem dem Spass am Hobby.

Ich habe den gesamten Satz vorerst entfernt bis das hier geklärt ist.

Viele Grüße,--Jo (talk) 19:24, 15 September 2017 (UTC)

user:Waldhans Denk mal umgekehrt: welche Information bringt die Position des Wegweisers für die Route?

Weil jemand den Nutzen nicht sieht ist das kein Grund, es zu verbieten. Ich möchte trotzdem Beispiele bringen: Die Wegweiser sind z.B. wichtig, für diejenigen, die sie kontrollieren. Fehlt einer? Ist er gut sichtbar? Sind die Routensymbole noch da? usw.. Für Menschen wie mich, die die Wegweiser als Orientierung nutzen, kann das ebenfalls sinnvoll sein. Ich z.B. finde es hilfreich zu wissen, dass am nächsten Abzweig ein Wegweiser für die Route steht, die ich fahre. Ebenso wo er steht. Dann muss ich nicht ständig auf die Karte schauen sondern kann mich auf den Wegweiser verlassen. Das selbe gilt auch für die Informationstafeln mit der Karte der Route, die ich gerade fahre. Auch formell ist das sinnvoll: Die Routen werden draußen ja gerade durch die Wegweiser und aufgestellten Karten definiert, das ist das sichtbare Merkmal der Route. Somit ist auch gleich die Quelle der Information in OSM mit dokumentiert.

Wenn du auf die Fragen oben keine Antworten hast würde ich den Text gerne wieder reinnehmen, so wie er vor Deiner Änderung war.

Viele Grüße, --Jo (talk) 09:10, 16 September 2017 (UTC)

user:Waldhans

Also halten wir fest, dass die Wegweiser den Informationsgehalt der OSM-Route NICHT erhöhen.

Alles, was du beschreibst, ist ja durch die "information=guidepost"-Objekte abgedeckt. Die sind ja alle in der Karte, hier im Kreis Viersen über 2000. Ein Vergleich zwischen Realität und Karte ist da überall möglich.

Deine Vorstellung der Definition einer Route ist realitätsfern. Zuerst wird die Route im GIS festgelegt, dabei wird soweit als möglich ein vorhandenes Grundnetz genutzt. Dann werden die fehlenden Wegweiser festgelegt und beim Baulastträger in Auftrag gegeben. Die Definition der Route bleibt immer der Linienzug im GIS, alles andere ist Beiwerk.

Genauso machen wir das in OSM: wir bekommen die Routen als KML-File, und getrennt die Wegweisung ("Pfosten").

Also nochmals die Fragen:

• was hat ein Router (z.B brouter / OSRM/OsmAnd) von den Guideposts?

• welche IOS/Android App zeigt die Guidepost's einer Route an?

Und noch zu deiner "ich will die Pfosten kontrollieren".

Das geht ganz einfach in OsmAnd:

erzeuge eine Filter "Guidepost" (search, guidepost, select Guidedpost/Tourism, save Filter).

Navigation starten

dann Waypoints / POI; dort den neuen Guidepost-Filer wählen. Radius auf 50m;

Jetzt bekommst du zuerst eine Liste aller Wegweiser entlang der Strecke und während der Fahrt jedes mal einen Hinweis auf den aktuellen Pfosten.

Also das funktioniert bereist jetzt blendend, du kannst ganz ohne weitere Datenverschlimmerung bereits heute deinen Baulastträger beim Streckenerhalt unterstützen.

Hallo Waldhans,

mag sein, dass ihr das bei euch so macht und funktioniert und du deswegen den Nutzen nicht siehts. Diese Diskussion geht aber am Kern vorbei, denn es spielt keine Rolle, ob alle den Nutzen sehen. Viele Mapper machen Dinge in OSM, die andere als sinnlos ansehen, das ist so in einem solchem offenem Projekt. Es müssen nicht alle an OSM-Beteiligten vom Sinn überzeugt werden, bevor man etwas mappt und dafür Regeln beschreibt.

Nochmal: Ich habe hier keine neue Regel festgelegt sondern etwas Bestehendes zitiert. 'guidepost' als Rollenmitglied steht seit mindestens 2014 unbestritten im Wiki, in der Zwischenzeit wurde das bereits 43.653 mal in OSM so gemacht. Das würdest du nun nachträglich verbieten. Scheinbar gibt es viele Mapper, die einen Sinn darin sehen, welchen, kann uns egal sein.

Wenn du etwas verbieten willst, brauchst du eine andere Begründung, z. B. weil es Schaden anrichtet oder andern Regeln widerspricht. Deswegen meine Fragen, auf die du scheinbar keine Antworten hast. Dann sei bitte auch so fair, und lass mich den Text wieder herstellen.

Kannst du damit leben, dass wir schreiben "Wegweiser können in die Relation aufgenommen werden", so dass klar ist, dass es keine Muss-Angabe ist? --Jo (talk) 18:28, 17 September 2017 (UTC)

Grüße, --Jo (talk) 18:28, 17 September 2017 (UTC)

user:Waldhans

Wenn ich deine ganze Antwort zusammenfasse:

"Ich weiß auch nicht, warum guideposts in den Routen sein sollen. Aber das steht in irgendeinem Wiki ist muss deswegen richtig sein. Und man kann ja wohl sinnlose Sachen mappen"

Hast du irgendeine POSITIVE Begründung, warum das so ist? Deine bisherigen Argumente habe ich ja anscheinend vollständig entkräftet.

Und natürlich darf du sinnlose Sachen mappen. Nur schreibe das nicht als Vorschrift, auch nicht optional, in das Wiki! Liefere eine Begründung, warum das eine Option sein soll.

Vielen Dank für deine Antwort.

Du hast mit beiden Zusammenfassungen etwas anderes verstanden, als ich sagen wollte. Irgendwie gelingt es mir nicht, mich verständlich auszudrücken. Ich versuche es nochmal:

1. Ich habe nichts Neues hineingeschrieben. Es steht seit 2015 auf dieser Seite, dass Wegweiser in die Relation aufgenommen werden. Stammen tut das aus dem englischen Wiki, wo es seit 2014 unwidersprochen steht. Dort auch nicht "irgendwo" sondern in der Definition der Route-Relation, also genau da, wo es hingehört.
2. Ich habe den Satzteil "mit der Rolle 'guidepost'" aufgenommen. Auch das ist nichts Neues. Auch das steht seit 2014 unwidersprochen an genannter Stelle
3. Wenn ich nichts Neues hinzugefügt habe, muss ich es auch nicht inhaltlich begründen. Die Begründung "hab eine bestehendes Taggingschema auch hier erwähnt" reicht. Warum soll ich dir ein offensichtlich etabliertes Schema begründen, siehe 6?
4. Neu ist, dass du im Text geschrieben hast "Die Wegweiser werden NICHT in die zugehörigen Routen-Relationen aufgenommen, auch nicht mit der Rolle 'guidepost'.". Damit untersagts du etwas, was übliche Praxis ist, was seit Langem im Wiki steht und bislang ausschließlich von dir widersprochen wurde. Argumente für diese Neuheit nennst du keine, außer dass du vom Nutzen überzeugt werden willst, bevor es wieder aufgenommen wird. Das ganze im immer unangenehmer werdenden Ton.
5. Ich habe keine Argumente für den Nutzen geliefert sondern nur zwei Beispiele und das habe ich schon bereuht. Du hast die Beispiele auch nicht entkräftet, sondern nur erzählt wie man es anders machen könnte. Ich gehe absichtlich nicht darauf ein, dass das hier in Sachsen nicht funktionieren würde, weil das niemand weiterbringt, siehe 6.
6. Ich möchte die Diskussion um den Sinn oder Unsinn nicht führen, denn sie ist irrelevant und daher nicht zielführend. Warum soll ich Dich von einen Nutzen überzeugen? Die Entscheidung ist bereits in der Zwischenzeit 43.722 mal getroffen worden (Also 69 mal seit dem das aus dem Wiki genommen wurde). Du kannst jeden einzelnen Mapper fragen, warum er es gemacht hat, wenn es dich so stark interessiert. Aber jetzt zu fordern, dass etwas nachträglich aus dem Wiki genommen wird bis jemand dich überzeugt hat - das geht meines Erachtens nicht.

Wenn du eine bestehende Praxis ändern willst, dann mach bitte einen Proposal und diskutiere diesen in den Foren. Ich werde mich gerne an der Diskussion beteiligen. Aber Ändere die Informationen im Wiki erst dann, wenn es offensichtlich ist, dass dein Vorschlag großen Anklang findet. Jetz machst du es gerade umgekehrt.

Was sagen die Anderen hier dazu?

--Jo (talk) 21:45, 20 September 2017 (UTC)

user:Waldhans

1. gut, ist halt im englischen Wiki auch falsch; keine positive Begründung
2. gut, ist halt seit 2014 falsch; keine positive Begründung
3. natürlich musst du das nicht begründen, aber genauso gut darf ich das ändern
4. nur weil es schon lange im Wiki steht, mach es nicht richtig; keine positive Begründung
5. Warum soll OsmAnd in Sachsen nicht funktionieren? Hast du das mal getestet?
6. Da finde ich gar kein Argument, warum das so sein soll.

Zusammenfassung: Du siehst auch keine Sinn in Wegweisern als Relation-Mitglieder, außer das es schon gemacht wurde und im Wiki steht. Genau dass sagen deine Antworten 1-6.

Ein Proposal für Routen-Tagging würde voraussetzen, dass z.B. die von dir verteidigte Wiki-Seite auf einem Proposal beruht, die positiv abgestimmt wurde. Ich habe das nicht gefunden, bitte schicke mir den Link.

Im Kern liegt ein grundlegendes Missverständnis von Daten-Definitionen für Router-Programme vor.

• Die Daten für den Router sind nur die Wege (mit typ, surface, etc), geordnet in einer Relation, verarbeitet von einem Navigationsprogramm, z.B. OsmAnd

• Die Wegweiser gehören zur vorhergehenden Generation, Fahrt nach Karte und Augenschein

Ich finde auch das ganze Wegweiser-Tagging mit "direction_north", etc. (DE:Tag:information=guidepost) pervers. Anstatt den Wegweiser zu beschreiben, sollten in OSM alle Daten vorhanden sein, um den Wegweiser zu konfigurieren. Bei den Radrouten habe ich das getestet. Und ja, wir können zu jedem beliebigen Punkt einen Wegweiser erzeugen.

Ein Punkt, der für Zusatzdaten sprechen würde, ist eine Datengrundlage für eine Übersichtskarte, wie sie auf Parkplätzen und in Flyern verwendet wird. Dort wird oft der Weg zusammen mit Touristischen Sehenswürdigkeiten, Parkplätzen, etc. dargestellt.

Dafür bietet sich dann eine site-Relation an. Dort sammelt man alle "POI's" und fügt dann die Route als child-element ein. So kannst du auch deine Route mit allen Wegweisern garnieren, obwohl ich noch nie so eine Karte gesehen habe.

Also nochmals die Frage: Hast du irgendeine POSITIVE Begründung?

Ah ja, das englische Wiki ist also einfach falsch - so einfach ist das. Auch wenn du dort etwas löschen willst brauchst du eine Begründung und solltest erst prüfen, ob du dafür Unterstützung findest. Aber meine diesbezüglichen Fragen ignorierts du hartnäckig sondern wiederholst stattdessen immer nur die selbe, aus meiner Sicht irrelevante Frage. Auf meine Diskussion zu dieser Frage gehst du nicht ein, wird einfach ignoriert. Auch dass es bei OSM durchaus üblich ist, dass Schemas sich dadurch durchsetzen und gerechtfertigt werden, dass sie in Größenordnung angewendet werden interessiert dich nicht, auch darauf gehts du nicht ein. Du behauptest wiederholt, ich hätte etwas Neues erfunden und ignorierst, dass du hier Bestehendes änderst und es begründen musst bzw. gehts acuh hier auf meine Argumentation einfach nicht ein. Auf der Wikiseite hast du Dinge verboten - ohne Begründung. Diese musste ich dir erst aus der Nase ziehen. Das ist unfreundlich und alles andere als wertschätzend gegenüber denjeneigen, die etwas dort reingeschrieben haben. Du hälst dich nicht an Wiki-Konventionen (beginnst wiederholt Diskussionen auf der Wikiseite statt im Diskussionsbereich) und Wiki-Style (ich muss hier alles nachbessern). Dass du auf mein Geschriebenes nicht eingehst und deswegen immer wieder das Selbe behauptest wirkt extrem arrogant auf mich.

Es macht keinen Sinn und schon gar keinen Spaß, auf diese Weise zu diskutieren.

Ich würde gerne mit anderen OSMlern in Diskussion darüber treten, ob sie meine Sicht teilen, dass man Verbieten/Löschen von etablierten Tagginpraxissen im Wiki nicht damit begründen darf, dass man es persönlich für nutzlos hält, was andere Mapper tun oder dass man einen anderen vermeintlich besseren Weg kennt, zum Ziel zu kommen. Darum geht es hier. --Jo (talk) 09:34, 22 September 2017 (UTC)

schicke mir bitte ein Beispiel einer Radrelation mit Rolle 'guidepost'; ich habe keine gefunden, also muss ich meine overpass-Abfrage noch korregieren --user:Waldhans

und noch was: auf welche englische Wiki-Seite beziehst du dich? Ich kann da überhaupt nichts finden, was eine Verbindung Radroute-Wegweiser rechtfertigt. Bitte dokumentiere deine Quelle! --user:Waldhans

Wegweiser sind kein Teil der Relation

Falls du keine weiteren Argumente vorbringst, werde ich das Wiki wie folgt ändern:

---

Wegweiser

In einer route=bicycle Relation sind ausschließlich die Wege Mitglieder.

Falls es, zum Beispiel zum Erstellen einer Übersichtskarte, nötig ist, Sehenswürdigkeiten, Parkplätze, Wegweiser oder Hinweistafeln zu erfassen, kann dafür eine site-Relation verwendet werden. Die Radroute wird als Kind-Relation eingetragen.

---

--user:Waldhans

Mach bitte kenntlich, dass es nicht geklärt ist, ob die Wegweiser in die Relationen aufgenommen werden können oder nur in eine site-Relation oder begründe wenigstens deine Änderung und warum die aktuelle Praxis schädlich ist. Wenn du das nicht kannst, dann belass es einfach bei der Ursprungsfassung. (Hinweis: Deine Signatur kannst du hier auf der Diskussionsseite mit der zweiten Taste von rechts einfügen) --Jo (talk) 20:10, 13 October 2017 (UTC)

du hast meine Fragen nicht beantwortet:

1. schicke mir bitte ein Beispiel einer Radrelation mit Rolle 'guidepost'; ich habe keine gefunden, also muss ich meine overpass-Abfrage noch korregieren
2. auf welche englische Wiki-Seite beziehst du dich? Ich kann da überhaupt nichts finden, was eine Verbindung Radroute-Wegweiser rechtfertigt. Bitte dokumentiere deine Quelle!

Bitte dringend um Antwort! --Waldhans (talk) 20:49, 13 October 2017 (UTC)

Hallo Hans,

Du hast leider auch keine einzige meiner Fragen beantwortet und vor allem keine Begründung für deine Änderungen genannt, weswegen ich die Diskussion nicht weiter geführt habe.

Die englische Quelle habe ich oben mehrfach dokumentiert und verlinkt, hier nochmal der Link: Relation:route#Members

Die Zahlen habe ich aus taginfo, wenn du dort nach Member "guidepost" filterst.

Ein Beispiel hier: [1]

Und hier die Overpass-Abfrage, für Wege und Knoten mit der Rolle 'guidepost':

rel({{bbox}});
(
        node(r:"guidepost");
        way(r:"guidepost");>;
);
out body;

Schau mal in anderen Ländern, z.B. rund um Prag.

--Jo (talk) 15:44, 22 October 2017 (UTC)

Sind die hier beschriebenen Netzwerkrelationen wirklich nichts anderes als Kategorien?

User U30303020 hat bei "Routen eines Netzwerkes zusammenfassen" den Kasten "Netzwerk-Relationen gelten als technisch überholt. Bestehende Relationen sollten aufgelöst werden, wenn sie nicht mehr aktuell sind." reingesetzt. Der Kasten verlinkt auf die Seite "Relationen sind keine Kategorien"

Ich bin mir recht sicher, dass der Kasten ist hier falsch ist. Ich habe ihn daher rausgenommen und stelle das hier zur Diskussion.

Die Fahrrednetzwerke sind nach meinem Verständnis nicht die als "Kategorien" bezeichnete Ansammlung von lose in Beziehung stehender Objekten. Ganz im gegenteil, sie beschreiben eine sehr konkrete Beziehung, die anders nicht eindeutig ermittelbar ist. Die hier beschriebenen Netzwerke fassen alle Fahrradrouten zusammen, die gemeinsam vermarktet und/oder unterhalten werden und ein einheitliches Aussehen der Beschilderungen und oder Karten haben. Sie markieren also eine örtlich begrenzte Beziehung zwischen Objekten. Auch wenn Fahrradnetzwerke häufig an Bundesländergrenzen enden, lässt sich diese Beziehung nicht anhand von administrativen Grenzen ermitteln.

So umfasst das "Sachsennetz Rad" eben nicht alle Radrouten in Sachsen, die sich durch eine Overpass-Turbo-Abfrage leicht ermitteln ließen. Die Zugehörigkeit zum "Sachsennetz Rad" wird alleine durch die Staatsregierungvon Sachsen bestimmt. Es gibt viele Routen, die nicht dazugehören.

Auch das "Knotenpunktnetzwerk Viersen" wird nicht durch die Kreisgrezen bestimmt, sondern durch das Aussehen der Schilder und einheitliche Vermarktung u. a. auf den Karten, die an den Knotepunkten stehen.

Ich wüsste nicht, wie man ermitteln sollte, ob eine Fahrradroute Teil des Sachsennetzes Rad oder des Knotenpunktnbetzwerkes Viersen ist, oder ob es eine andere Fahrradroute ist.

Wie seht ihr das?

--Jo (talk) 22:25, 26 August 2018 (UTC)

Y Hat sich erledigt, war ein Missverständnis. Es wäre aber günstiger gewesen, das zusätzlich auf meiner Talk-Seite zu erwähnen, dann hätte ich das schneller gelesen (da gibt es einen Hinweis beim Einloggen). --U30303020 (talk) 17:22, 28 August 2018 (UTC)

Sorry, mich hat das Englische abgeschreckt. Ich hatte übersehen, dass du mich anderweitig erst kürzlich kontaktiert hattest. --Jo (talk) 18:47, 30 August 2018 (UTC)

Ok. Ich habe jetzt aber nicht verstanden, warum die Info-Box oben entfernt wurde. Ich habe eine Löschung der alten Seite beantragt. Das schließt normalerweise auch die dazugehörige Diskussionsseite mit ein. Da diese allerdings noch möglicherweise relevante Informationen enthielt, habe ich sie so verschoben, dass eine Unterseite zu dieser Diskussionsseite erstellt wird. Damit die alten Themen noch gefunden werden können, habe ich oben die Bemerkung eingefügt. Dabei habe ich mich an anderen Diskussionsseiten (z.B. Talk:Wiki) orientiert. Warum ist sie jetzt weg? --U30303020 (talk) 22:38, 30 August 2018 (UTC)

War wiederum ein Versehen von mir. Keine Ahnung wie das passiert ist.--Jo (talk) 06:24, 31 August 2018 (UTC)

Unterschied Wegweisung und Route

Vor allem in Städten mit einem ausgeschilderten Radstreckennenetz ist immer wieder eine Verwirrung zu bemerken, ob es sich um Routen handelt. Ich habe schon einen Mapper getroffen, der einen simplen Radweg mit lcn=yes getaggt hat. Die formalen Kriterien einer Route sind ja klar definiert:

1. durchgehend ausgeschildert
2. eindeutig Referenzierbar (Name, Nummer oder Symbol)
3. klar definierten Anfang und Ende oder Rundkurs

Aber der wesentliche Unterschied zwischen einer (auch dichten) Wegweisung und einer Route wird damit nicht begreifbar. Mir war das auch selbst lange Zeit nicht klar, bis mir folgende Idee kam:

Auf einer Route im OSM-Sinne ist man in 2 von 3 Dimensionen verortet. Mit der Angabe des Routen-Namens allein kann man gefunden werden. Im Kreuzungspunkt von zwei Routen ist die Verortung sogar eindeutig. Am Kreuzungspunkt mit reiner Wegweisung ist man i.a. nicht verortet. Der Unterschied ist IMHO wesentlich. --RobHubi (talk) 19:47, 23 April 2019 (UTC)

Die Route in OSM

Den folgenden Text würde ich gerne an den Anfang des Artikels Fahradroutentagging stellen. Gibt es Einwände?

Eine Route im OSM-Sinne ist ein eindeutig und durchgehend gekennzeichneter Weg zwischen 2 Punkten, die auch für einen Rundkurs zusammenfallen können. Routen zeichnen sich durch eine bewusste Zielführung aus.

Der Zweck der Route ist das sichere Ankommen im doppelten Wortsinn: ohne Verirrung und ohne Schaden. Die eindeutige Kennzeichnung ermöglicht eine einfache Verortung Wo bin ich und eine einfache Orientierung Wie geht’s weiter.

Genaue Karten sind nicht erforderlich. Auch in einem Routennetz reicht ein einfacher Netzplan auf Papier für die spontane Zielwahl.--RobHubi (talk) 21:13, 23 April 2019 (UTC)

Ich sehe ehrlich gesagt nicht den Mehrwert gegenüber dem bereits vorhandenen Text. Im Wesentlichen wiederholt er das bereits gesagte mit eigenen Worten und schafft durch die Wortwahl auch eher Verwirrung.

Was genau fehlte dir denn am vorhandenen Text?

So bleibt offen, was eine "bewusste Zielführung" ist. Was ist der Mehwert ggü. dem vorhandenen Satz "Es sollen Routen erfasst werden, die auch in der Realität existieren. Schlagendes Argument ist ihre Ausschilderung mit einer Wegweisung entlang der Route. Dadurch erhalten sie einen offiziellen Charakter."

Zu "ist ein eindeutig und durchgehend gekennzeichneter Weg": Routen konnen auch Verzweigungen und mehrere alternativr Führungen haben, z.B. beiderseitig eines Flusses dann gibt es mehrere Wege zwischen Anfang und Ende. Ist als m. E. falsch.

Das "Wo bin ich" ist bei der üblichen Routenbeschilderung nur selten erkennbar, da nur die nächsten Unter- und Hauptziele ausgewiesen werden, nicht de rName der Orte. Hauptmerkmal der Route sind Routensymbole oder Nummern. Wenn ich weiß dass ich auf dem Elbradweg bin weiß ich immer noch nicht, wo ich genau auf diesem Weg bin. Deine Aussage passt irgendwie nicht so richtig.

Worin siehst du den Mehrwert von "... gekennzeichneter Weg zwischen 2 Punkten, die auch für einen Rundkurs zusammenfallen können" ggü. dem bereits bestehenden Satz "Routen sollten entweder Anfang und Ende haben oder einen Rundkurs beschreiben"?

--Jo (talk) 23:32, 12 May 2019 (UTC)

“Was genau fehlte dir denn am vorhandenen Text?“ – Der Text ist ausgezeichnet, ich kann ihn nicht verbessern. Ein Dankeschön für dein Engagement. Deine Argumente kann ich nachvollziehen, sie zeigen mir, dass mein Vorschlag missglückt ist.

Mein Problem mit dem Text war die Länge. Ich habe die Idee erst begriffen, indem ich den ganzen Text sorgfältig durchgelesen habe. Ich befürchte, dass ungeduldige Mapper die Relevanz nicht auf Anhieb erkennen und weitersuchen. In meiner Umgebung sehe ich so viele Routen in OSM, die ganz klar keine Routen in OSM-Sinne sind. Woher kommt das?

Meine Motivation war es, eine Einleitung/Kurzfassung zu finden, die den „springenden Punkt“ der Route darstellt und so zum Weiterlesen anregt. Kurz und ansprechend sollte es sein. Mehrdeutigkeiten können hier auch gut sein, wenn sie zu Fragen anregen, die im Haupttext geklärt werden.

Was hältst du von folgender Formulierung der Einleitung:

(*Einleitung Start*)

Umgangssprachlich wird jede festgelegte Wegfolge als Route bezeichnet. In OSM ist der Routenbegriff viel spezifischer: Eine Route im OSM-Sinne ist eine bewusste Zielführung durch entsprechende Markierung von Wegen. Es unterscheidet sich damit deutlich von normalen Wegweisungen und Routenvorschlägen.

„Alle Routen sind ausgeschildert, aber nicht jeder ausgeschilderte Weg ist eine Route“

(*Einleitung Ende*)

--RobHubi (talk) 17:18, 13 May 2019 (UTC)

Hallo RobHubi,

Ok, das verstehe ich. Einige wichtige Aussagen kommen erst recht weit hinten.

Den Text auf deine Kernaussage begrenzen finde ich gut. Allerdings gilt die Aussage nicht für alle relation=route sondern nur für Fahrrad-Routen. Busrouten z. B. sind nicht zwangsläufig ausgeschildert. Ich würde dafür auch keine extra Überschrift machen, sondern es mit dem nächsten Absatz zusammenlegen, um die Redundanzen zu vermeiden.

Wenn du die Aussagen vom Abschnitt "=== Routenempfehlungen ===" bereits hier triffst, können wir den Abschnitt einsparen.

"Bewusste Zielführung" würde ich durch "markierte Wegeführung" ersetzen, denn eine bewusste Zielführung kann ich auch durch ein Navigationsgerät mit einem GPS-Track eines Tourismusverbandes erreichen - ohne Symbole an der Strecke: "es führt mich bewusst auf einer bestimmten Strecke zum Ziel".

Was hälst du davon?:

== Welche Fahradrouten sollen erfasst werden? ==

Umgangssprachlich wird der Begriff "Fahrradroute" oft weiter gefasst als in OSM, in OSM ist der Routenbegriff viel spezifischer: Eine Fahrradroute im OSM-Sinne ist eine Wegeführung, die durch eine durchgehende Markierung gekennzeichnet und eindeutig referenzierbar ist. Fahrradrouten im OSM-Sinne haben einen Namen, eine Nummer und/oder ein einheitliches Symbol. Die Fahrradroute in OSM unterscheidet sich damit deutlich von einfachen Wegweisungen ohne Symbolen, Nummern oder Namen. Auch private Routen oder Routenempfehlungen für bestimmte Touren (auch von Tourismusverbänden), die an der Strecke nicht ausgeschildert sind, gehören nicht in die OSM-Datenbank.

Es sollen nur Routen erfasst werden, die auch in der Realität existieren. Schlagendes Argument ist ihre Ausschilderung mit einer Wegweisung und der durchgehenden Markierung mit einer Nummer oder einem Symbol. Dadurch erhalten sie einen offiziellen Charakter. Routen sollten entweder Anfang und Ende haben oder einen Rundkurs beschreiben.

(Abschnitt "=== Routenempfehlungen ===" löschen)

--Jo (talk) 20:46, 15 May 2019 (UTC)

Hallo Jo,

mit Struktur und Text bin ich prinzipiell einverstanden. Ich halte zwar eine Einleitung für leichter zu lesen, als ein Abstract. Aber wenn du das anders siehst, ist es für mich auch ok.

Bedenken habe ich bei dieser (Neu-)Formulierung „Schlagendes Argument ist ihre Ausschilderung mit einer Wegweisung und der durchgehenden Markierung mit einer Nummer oder einem Symbol.“ Ich gebe ein fiktives Beispiel:

Für mich ist eine OSM-Route

• offiziell und durchgehend ausgeschildert
• eindeutig referenzierbar
• mit Anfang und Ende oder ein Rundkurs

Die Stadt yx schildert einen Weg zwischen See und Hbf aus. Die Ausschilderung ist durchgehend mit dem Hauptziel „Hbf“ und mit variablen Nebenzielen ausgeführt. Die Gegenrichtung hat durchgehend „See“ als Hauptziel genannt, die Nebenziele variieren ebenso. Sie kann mit der Bezeichnung „See-Hbf“ eindeutig referenziert werden.

Alle Kriterien einer OSM-Route sind erfüllt. Sie ist eine Route im OSM-Sinne, obwohl sie keine Markierung mit einem Symbol oder Nummer hat. Die Bezeichnung „See-Hbf“ könnte auch als Namen interpretiert werden. Im Fahrradknotenpunktnetzwerk wird ähnlich argumentiert.

Wir müssen das nicht hier diskutieren, da es besser in den Abschnitt „Radwegnetze mit Wegweisern aber ohne eindeutig zuordenbare Routen“ passt. Die Formulierungen hier sollten dem aber nicht widersprechen.

Was hältst du davon (1. Absatz unverändert):

== Welche Fahradrouten sollen erfasst werden? ==

Umgangssprachlich wird der Begriff "Fahrradroute" oft weiter gefasst als in OSM, in OSM ist der Routenbegriff viel spezifischer:

:

:

(Ende 1. Absatz).

Es sollen nur Routen erfasst werden, die auch in der Realität existieren. Schlagendes Argument ist ihre Ausschilderung. Dadurch erhalten sie einen offiziellen Charakter. Routen sollten entweder Anfang und Ende haben oder einen Rundkurs beschreiben.

(Abschnitt "=== Routenempfehlungen ===" löschen)

--RobHubi (talk) 20:00, 17 May 2019 (UTC)

Hallo RobHubi

Oh ja, du hast Recht. Symbole müssen nicht sein.

Wenn du es lieber in der Einleitung haben wilst, kann die Überschrift ja etwas später kommen, also zwischen "...OSM-Datenbank" und "Es sollen nur Routen ...".

Eine Extra Überschrift "Einleidung" o. ä. braucht es m. E. nicht. Der Text am Anfang ist immer die Einleitung.

Grüße, --Jo (talk) 20:38, 18 May 2019 (UTC)

Hallo Jo

hab es, so wie besprochen, geändert. Danke für die konstruktive Diskussion. --RobHubi (talk) 19:55, 21 May 2019 (UTC)

Wege in Radroute aufnehmen

Die Unterscheidung Wegweisung zu Route wird leichter, wenn man die zielorientierte Ausschilderung einer Route explizit beschreibt. Vorschlag für ein Ergänzung zu "Wege in Radroute aufnehmen":

Schleswig-Holstein beschreibt im Handbuch Radverkehrswegweisung in Schleswig-Holstein eine zielorientierte Wegweisung unter besonderer Beachtung der Zielkontinuität (s. Abb 20 auf S28). Derart ausgeschilderte Wege können als Routen im OSM-Sinne verstanden werden. Als Name kann „Ausgangspunkt A“ – „Hauptziel B“ verwendet werden.

Meinungen? --RobHubi (talk) 22:46, 25 May 2019 (UTC)

Überarbeitung der Seite betreffs Verwendung von network-Relationen im Forum

Im Forum wird ein Entwurf der Überarbeitung dieser Seite diskutiert, diskutiert gerne mit. Um Weihnachten herum würde ich die Vorschläge dann gerne unsetzen.

Es ist gelebte Praxis, für ausgeschilderte Radverkehrsnetze network-Relationen verwendet werden, wenn die Kriterien von Route-Relationen nicht erfüllt sind (kein Name, kein Symbol, keine Nummer oder wechselnde Ziele auf den Wegweisern). Die Art und Weise, wie diese network-Relationen getaggt wurden ist teilweise unzufriedenstellend - es entstanden riesige Sammelrelationen.

Ziel der Wiki-Ergänzung ist, die gelebte Praxis mit network-Relationen in handhabbare Bahnen zu leiten. Dabei soll bewusst keine Präferenz auf die Verwendung von network-Relationen oder das Taggen von 'network=*' an den Kanten gegeben werden. Beides hat Vor- und Nachteile, ist regional unterschiedlich verbreitet und am Ende Ansichtssache.

Mehr dazu hier: https://forum.openstreetmap.org/viewtopic.php?pid=810671#p810671

Viele Grüße, Jochen --Jo (talk) 00:22, 9 December 2020 (UTC)

Ich habe die Überarbeitung heute online gestellt. Ich wollte zudem den vorgeschlagenen Umzug nach DE:Bicycle/Fahrradrouten kartieren angehen, dazu muss ein Admin aber erstmal die leere Seite dort löschen. (Ziel: Einheitliches Namenschemata für Fahrradinfrastruktur, -netze und -routen im gleichen Namensraum)

--Jo (talk) 22:54, 21 December 2020 (UTC)