Talk:Fahrradroutentagging Deutschland

From OpenStreetMap Wiki
Jump to: navigation, search

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)

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)

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 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 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)