Proposal talk:Basic network (2021)/Archive 1

Hier sind die Diskussionen während der Erstellung des Proposals archiviert. Somit wird sichergestellt, dass auf der Diskussionsseite nur die Diskussionen zum Inhalt des Propsals stehen und gleichzeitig die Erstellungs-Diskussionen erhalten bleiben.

Bilder mit Routensequenz

Hallo Jochen, ich hatte leider nichts mehr unter die Bilderfolge als Erläuterung geschrieben. Mir war noch einmal wichtig, klarzustellen, dass das, was mit basic_network getaggt wird, mit Fug und Recht als Route zu bezeichnen ist, auch im strengeren Sinne - weil es eben auch die Zwischenwegweiser gibt. Ich wollte eine Sequenz der Schilder, die so eine Route ausmachen, darstellen, nicht die Schilder als solche... (im Gegensatz zu bloßen Wegweisern).

Das stimmt. Ich bin mir halt nur nicht so sicher, ob wir das brauchen. Das Proposal ist schon jetzt recht lang und es ist an den Zwischenwegweisern halt nicht zu erkennen, ob es sich um einen Themenradweg oder ums Grundnetz geht.

Das Beispiel der grünen Wanderwegweiser gefällt mir noch nicht so, da gibt es sicher bessere. Da muss ich auf der nächsten Wanderung mal besser aufpassen.

Eine Diskussion, für die es jetzt vielleicht noch zu früh ist, bleibt zu führen: Ob im Radverkehrsnetz nicht alle Routensegmente zusätzlich als basic_network vorhanden sein sollten, auch wenn Knotenpunkt- oder Themenrouten darüber laufen. Die Routen des basic_network sind quasi die Atome, aus denen die längeren Routen zusammengesetzt sind. Da Routenmerkmale, die über die Streckenpiktogramme dargestellt werden, sich nur auf diese "Atome" beziehen, kann es Situationen geben, in denen nur ein Teil einer längeren Route dieses Merkmal aufweist, und das sollte dann auch renderbar sein ("Freizeitroute", "Steigung", "Bahntrasse" etc.), dafür muß aber definiert sein, wo man die Information über die Strecke herbekommt. Das geht am besten über die Route des "basic_network".

In das Wiki sollten wir die weiteren Taggingmöglichkeiten auf jeden Fall aufnehmen. Wenn dort zusätzliche Informationen ggü. den Themenrouten dranstehen, so ergibt das einen Sinn. Im Proposal geht es ja vor allem um die drei Tags network:type=basic_network und lcn=basic_network lwn=basic_network. Wichtig ist mir nur, dass es keine Erwartung gibt, dass alles doppelt aufgenommen werden muss. Das ist dann schnell ein Argument dagegen und ich möchte schon, dass das angenommen wird .

Wenn das hier der falsche Ort für diese Rückmeldung ist, lösch den Eintrag einfach wieder, dann melde ich mich im Zweifel per Nachricht - oder Du löschst das alles, wenn Du das proposal einreichst, falls Du das für sinnvoll hältst.

Passt schon, ist ja eine inhaltlicher Hinweis zum Vorschlag. Grüße, Jochen --Jo (talk) 21:09, 22 June 2021 (UTC)

Grüße erst einmal, Sebastian --Segubi (talk) 15:21, 22 June 2021 (UTC)

Rendering von Fahrradrouten

Hallo Jochen, das Rendering von Fahrradrouten ist sicher ziemliche Geschmackssache, aber die vorgeschlagene Hierarchisierung würde so überhaupt nicht meinen Alltagsvorlieben entsprechen. Wenn ich im Alltag von Stadt A nach Stadt B radeln will (bis ca. 50 km Distanz nutze ich, wenn die Zeit reicht und ich nichts Größeres transportieren muß, meist das Fahrrad), vielleicht sogar im Dunkeln, und schnell vorankommen will, aber gleichzeitig noch den Anspruch habe, nicht totgefahren zu werden, dann bevorzuge ich die Routen des basic_network deutlich vor nicht zum Netzwerk gehörigen Routen, aber auch vor den Freizeitrouten, weil die mich durch die schönsten Umwege durch den Wald usw. schicken, wovon ich aber Nachts ja gar nichts habe.

Ich benutze im Moment vor allem AAT zum Radeln, das u.a. auf Waymarkedtrails zurückgreift. Ich bin schon versucht, alle basic_network Routen in osm auf rcn umzustöpseln, weil er ab einer bestimmten Zoomstufe sonst die Routen nicht mehr rendert, die mir gerade für die längeren Strecken so wichtig wären... Die Darstellung von Straßenstücken (Kategorie 2 aus Deiner Aufstellung) mit abgesetztem Radweg usw. außerhalb des Netzwerkes ist für mich relativ irrelevant, weil ich dann die ganze Route durchschauen muß, ob die Strecke nicht doch irgendwann fahrradunfreundlich wird.

Und natürlich, für die Freizeit wäre es umgekehrt. Da will ich vielleicht das basic_network gar nicht sehen, außer für einen Abstecher.

Zur Hierarchie zwischen 4 und 5 benannte Routen und Knotenpunktrouten - die stehen eigentlich nebeneinander und nicht untereinander. Auch das kommt auf den Verwendungszweck an. Für den Fernradler sind natürlich die Fernrouten mit höchster Priorität, aber eventuell auch wiederum die Knotenpunkte, falls es keine adäquate Fernroute für sein Ziel gibt. Da stören die benannten kurzen Routen nur. Jemand der eine Freizeittour anhand Knotenpunkten fährt (werden zumindest in Bielefeld auch mit Flyer als Tourentipps mit Nummernfolge beworben), der braucht auch keinerlei anders benannten Routen.

Ich träume noch ein wenig von einem Rendering in dem ich die unterschiedlichen Aspekte umschalten könnte. Das geht allerdings ein wenig über das proposal, das nur basic_network beschreibt, hinaus. Aber dahingehend sind meine Ergänzungen im Rendering gemeint. Ich glaub, ich versuch das demnächst noch etwas besser zu formulieren und in das Proposal einzubringen (also, dass mit der Einführung von basic_network auch verschiedene Arten von Kartendarstellungen ermöglicht werden, die derzeit nicht definierbar sind).

Grüße, Sebastian --Segubi (talk) 14:48, 26 June 2021 (UTC)

Welche Strecken sollen getaggt werden? Vorschlag:

Hallo Jochen, ich setze diesen Textabschnitt mal hierhin, wenn Du das auch passend findest, kannst Du es gerne ins Proposal rüberkopieren...

The tag basic_network should at least added to routes belonging to the basic network (as visible by the style of signposting) that aren't part of any named routes like theme routes or numbered node network routes of the same style of signposting (in Germany the named routes are usually part of a bigger basic network) Additionally it would be useful to set this tag at routes (parts between branches) that are part of theme routes. There are the following advantages: 1. The theme routes are occasionally subject to changes. This is easily accomplished by changing the route insertions at the signs. In this way only the theme routes change but not the routes of the basic network. You wouldn't have to change the routes of the basic_network 2. The signposting of the basic networks includes information about the sections between the branches like inclines or quality of the route. These are valid for all theme routes that use this section and could be defined by the tagging of the route of the basic_network and then be rendered in a map.

Mindestens sollten die Routen (Wegeketten zwischen Abzweigungen) das Tag network:type=basic_network erhalten, die zwar von der Ausschilderung her dem Gesamtnetzwerk angehören, aber nicht zu speziell über ihren Namen oder Nummern definierten Routen (Themenrouten, Routen eines Knotenpunktnetzwerkes) gehören. Zusätzlich ist es wünschenswert, dass auch Routen, die Teile von Themenrouten sind, das tag network:type=basic_network erhalten. Dies hätte folgende Vorteile: 1. Die Themenrouten werden gelegentlich geändert, dies geschieht durch Austausch von Routeneinschüben an den Wegweisern. Hierdurch können sich die Routenverläufe der Themenrouten ändern, wobei die Streckenabschnitte des Grundnetzwerkes gleich bleiben. In osm kann die Relation des basic_network dann bestehen bleiben. 2. In der Ausschilderung werden auch Routenmerkmale, wie Steigung, Wegqualität mitgeteilt, die dann jeweils nur für den Abschnitt bis zum nächsten Abzweig gelten. Über die Route des basic_network können dann diese Merkmale für alle Themenrouten, die über diesen Streckenabschnitt laufen, definiert und z.B. in einer Karte gerendert werden.

Hallo Sven,

ich finde den Vorschlag gut, Danke. Ich denke das können Textbausteine für die Umsetzung im Wiki sein. Ich würde die im Proposal aber nicht anbringen aus zwei Gründen:

1. Im Proposal möchte ich den Schwerpunkt auf das Wesentliche setzen. Das sind für mich die Tags network:type=basic_network und lcn=basic_network bzw. lwn=basic_network auf der einen Seite und die Art wie ein Netz in Relationen aufgeteilt wird auf der anderen Seite. Desto mehr Facetten man zusätzlich beschreibt, desto mehr gibt es Dinge, warum man das Proposal in Gänze ablehnen kann und desto weniger wird der Blick auf den Kern gelegt. Eine Diskussion darüber, ob gleichzeitiges Mappen von Themenrouten und Grundnetz einen Mehrwert bringt würde vom Kern ablenken. Deswegen habe ich das gleichzeitige Mappen nicht ausgeschlossen, aber auch nicht viel dazu geschrieben.
2. Das Proposal ist bereits sehr lang und würde durch den Text noch länger. Ich befürchte, dass das abschreckt, sich an der Abstimmung zu beteiligen.

Ich kann aber die Formulierung der Anwendungsfälle für das Taggen des Grundnetzes offener schreiben, also statt

"Das Grundnetz sollte vor allem dort kartiert werden, wo keine benannten Routen oder Verbindungen von Knotennetzwerken verlaufen. Darüberhinaus ist ein Taggen sinvoll, wenn an diesen Relationen zusätzliche Informationen stehen. "

nun

"... Ein Taggen darüber hinaus kann sinnvoll sein, zum Beispiel wenn an diesen Relationen zusätzliche Informationen stehen."

Ich hoffe das ist OK für dich.

--Jo (talk) 19:20, 13 July 2021 (UTC)

Hallo Jochen, das finde ich sehr gut so! Grüße, Sebastian (hab' die Unterschrift vergessen... Sorry ;-) --Segubi (talk) 21:25, 13 July 2021 (UTC)

Rendering (Piktogramme, strukturiertes Netzwerk, Routensymbole)

Hallo Sven

du hattest u. a. Folgendes hinzugefügt.

1. Das kann die niedrigste Ebene eines durch exakte Wegweisung strukturierten Netzwerkes markiert werden.
2. Da über Routen des Grundnetzwerkes auch andere Routen geführt werden können, sollte die Darstellung des Weges dieser Grundnetzwerkroute unterdrückt werden, sobald eine benannte Route (einschließlich einer Route eines Knotenpunktnetzwerkes) über diese Route geführt wird.
3. Sollten zukünftig auch die im Grundnetzwerk ausgewiesenen Streckenpiktogramme als Streckenattribute in das Tagging mit aufgenommen werden, sollten diese sich trotzdem in der Karte darstellen (Steigungen, Routen mit besonderem Freizeitwert, Bahntrassenweg, Radschnellwege).
4. Eine Routensymbol oder eine Benennung der Route in der Karte sollte unterbleiben, auch wenn ref=*, name=* oder osmc:symbol=* gesetzt sind. (Ausnahme: Überregionale Karten, die tatsächlich mehrere Netzwerke enthalten, also in der Regel auch mehrere Länder enthalten).

Ich habe das sehr gestrafft bzw. rausgenommen. Ich weiß, dass das blöd ist, aber ich will es dir begründen:

Ich möchte mich auf das Wesentliche konzentrieren. Das sind die drei Tags und die Art der Aufteilung des Netzes in einzelne Relationen. Weiteren Details wie Piktogramme oder die Darstellung von name=* in Spezialfällen möchte ich nicht als Teil des Proposals adressieren und daher auch hier nicht erwähnen. Damit will ich Ablehnung des Proposals vermeiden, weil jemand andere Ansichten zu den weiteren Details hat. Daher z. B. statt "Ausnahme: Überregionale Karten ..." ein "in der Regel".

Das Proposal ist schon sehr lang, auch deswegen Konzentration auf das Wesentliche

Im Abschnitt "Darstellung" will ich nur Dinge beschreiben, die direkt das Rendering betreffen

Ich will den Renderern nicht zuviel vorgeben. Wenn z. B. ein Renderer das Grundnetz mit breiteren Strichen darstellt als die Themenrouten, so kann das Grundnetz auch unter den Themenrouten dargestellt werden. Auch hier das Wesentliche: Wichtig ist, dass die benannten Routen nicht durch Grundnetzverbindungen unterbrochen werden, obwohl sie durchgehen. Das hab ich so jetzt zusammengefasst:

"Werden benannte Routen und Verbindungen von Knotenpunktnetzwerken dargestellt, so sollten in der Darstellung

• benannte Routen Vorrang haben gegenüber Verbindungen von Knotenpunktnetzwerken (5. vor 4.)
• Verbindungen des Knotennetzwerkes Vorrang haben ggü. Verbindungen des Grundnetzes (5. und 4. vor 3.)

Somit kann sichergestellt werden, dass benannte Routen durchgängig dargestellt werden und das Knotenpunktnetzwerk nicht von Grundnetz-Verbindungen verdeckt wird.."

Wenn das gesamte Grundnetz ein Symbol hat (z. B. grünes Fahrrad, oder gelbe Raute), dann soll der Renderer selbst entscheiden, ob er grüne Fahrräder und gelbe Rauten malt. Daher keine Empfehlung, auf Symboldarstellung generell zu verzichten.

(Vermutlich ist es doch besser, wenn du mir kurz ein Hinweis gibts, wenn du etwas anderes oder mehr drinn haben willst, bevor du Texte ausformulierst, die ich dann doch wieder ändere oder lösche. Ich kann mir vorstellen, dass sich das nicht so gut anfühlt.)

Viele Grüße, --Jo (talk) 21:30, 13 July 2021 (UTC)

Hallo Jochen,

war viel Netzfrei draußen unterwegs, daher eine etwas spätere Antwort.

Vorab: Ich habe keine Probleme, wenn Du viel von dem, was ich fabriziere, löschst, da ich über die Versionsgeschichte ja an alles wieder drankäme, wenn mir etwas daran liegt. Ich fühle mich ausreichend wertgeschätzt - auch unabhängig davon... Ich hoffe eher, dass es Dich nicht nervt, immer wieder herumkürzen zu müssen, aber ich hoffe, dass einzelne Fragmente brauchbar sind... ;-)

Ich bin mit Deinen Straffungen sehr einverstanden, Du hast ja recht... die anderen Aspekte betreffen ja nur die Situation des deutschen Fahrradnetzwerkes.

Grüße, Sebastian --Segubi (talk)

Harmonisierung mit der Schweiz

Grundsätzlich finde ich das Proposal pragmatisch und gut anwendbar. Ich werde es gerne unterstützen. Vielen Dank für die Erstellung. Schön wäre es noch, wenn es mit dem Schweizer Vorschlag harmonisiert werden könnte. Die Thematik ist so ähnlich, dass mir ein Austausch der Ideen sinnvoll erscheint.

Proposal „Hiking path network“: https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork#Hiking_path_network
Diskussion auf [talk-ch] “Changes to HikingNetwork wiki page”: http://lists.openstreetmap.ch/pipermail/talk-ch/2021-July/011053.html

Auf [talk-ch] möchte ich auf dieses Proposal hinweisen.
Viele Grüße --RobHubi (talk) 19:51, 31 July 2021 (UTC)

Das finde ich seinen sehr guten Hinweis - ich war gerade auch in der Schweiz und habe mir das Wandernetzwerk angeschaut. Das ist wirklich sehr parallel. (Offtopic-Randbemerkung: Was mich sehr beeindruckt hat, ist der öffentlich zugängliche Kartenbestand, der mir auch recht aktuell erschien. Das funktioniert in Deutschland mit dem Radverkehrsnetz überhaupt nicht, zumindest nicht in Nordrhein-Westfalen).

Interessant fand ich nebenbei, dass im genannten Wiki explizit empfohlen wird, auf name=* gezielt zu verzichten, und from=* und to=* als optional zu lassen. Pragmatisch finde ich es allerdings ziemlich mühsam, mit JOSM mit unbenannten Routen zu hantieren, so dass ich ihnen über note=* einen internen Namen verpaßt habe, der nicht gerendert wird. Das ist offensichtlich auch in der Schweiz bei den Grundrouten mit network=lwn nicht ganz unüblich.

Offensichtlich gibt es mehrere Möglichkeiten, wie man damit umgeht, dass Wegabschnitte zu mehreren Routen gehören können. Nach der Definition auf dem Schweizerischen Wiki kann es vorkommen, dass Wegabschnitte des Grundnetzwerkes (wenn sie nur zwischen benannten Wegweisern liegen) sowohl untereinander als auch mit größeren Routen überlappen können. (Der Hinweis "Map however you like, but be tolerant of each other" gefiel mir besonders.)

Dafür kann das Tag network:type=basic_network gut helfen, indem es den Status einer Relation noch präziser definiert, und Renderen den Hinweis gibt, dass es für diese Routenrelation nichts besonderes zu rendern gibt, andererseits aber Routing-Anwendungen mitteilt, dass der Streckenabschnitt nach einem bestimmten Standard ausgeschildert und insofern auch zu finden ist.

Grüße, Sebastian --Segubi (talk)

Die Schweizer Wiki-Seite zum Wandernetz finde ich richtig gut! Die ist mir bislang entgangen, vermutlich weil ich vor allem aus Sicht der Radwegweisung denke!

Die grundsätzliche im Wiki beschriebene Vorgehensweise betreffs der Erstellung der Relationen ist m. E. weitgehend identisch mit der hier beschriebenen. Die hier vorgeschlagenen Tags könnten kombiniert werden. Den einzigen Unterschied sehe ich im Hinweis, dass auch mehrere Grundnetzrouten auf einem Weg liegen können (und dass man da tolerant sein soll). Dazu hatte ich hier nichts gechrieben.

In der verlinkten Diskussion (Danke!) geht es m. E. darum, ob man die Verbindungs-Relationen immer am Verzweigngsknoten beginnen und enden lässt, auch wenn der Wegweiser dort keinen Namen ausweist. Alternativ kann man die Relation immer bis zum nächsten Wegweiser mit Namen fühen. Letzteres hat den Vorteil, dass man der namenslosen Relation ein from=* & to=* mitgeben kann, das hilft vor allem beim Mappen. Der Nachteil ist, dass sich zwischen Verzweigungspunkt und Endpunkt mehrerer Grundnetzrouten überlappen können. Das ist auch bei Netzwerken interessant, wo die Verkzweigungsknoten keinen Namen haben, immerhin erhalten sie oft durch die Wegweiser der benachbarten Knoten einen Namen.

Ich habe zur Überlappung von Grundnetzverbindungen im Proposal nichts geschrieben, insofern gibt es mit beiden Varianten keinen Widerspruch. Im Proposal würde ich dazu auch eher nichts schreiben. Neben den neuen Taggs geht es hier erstmal nur darum, dass wir nur "lineare" Relationen erstellen, keine Sammelrelationenen wie bisher im Radverkehrsnetz üblich. Jede Relation darf dann pro Richtung nur einen Anfangs- und Endpunkt und muss dazwischen eine durchgängige Wegekette haben. Darüber hinaus gehende Taggingpraxen sind nicht Teil des Proposals, das wird sonst zu vielschichtig.

@RobHubi, siehst du etwas, wo ich oder die Schweizer etwas anpassen sollten? Sie verwenden statt "Verbindungen" den Begriff "Segmente". Aber das ist m. E. Geschmachkssache. Im Wiki sollten wir dann auf der Seite, die die Taggingpraxis umfassend beschreibt auch die Hinweise zu from und to übernehmen.

--Jo (talk) 16:03, 8 August 2021 (UTC)

Nach etwas Nachdenken sehe ich doch Einfluss der schweizer Diskussion auf den Text hier. Es geht ja darum, der Relation etwas mitzugeben, woran der Mapper sie in eine Liste leichter von anderen Relationen unterscheiden kann. Einen name=* gibt es ja nicht. Hier sage ich bislang, es soll das description-Tag verwendet werden. In der Diskussion ging es darum, dafür besser from=* & to=* zu nehmen, wo möglich.

Um da neutral zu bleiben, würde ich das mit dem description=* aus dem Proposal rausnehmen. Die Möglichkeiten kann man dann auf der Wikiseite immer noch darstellen.

--Jo (talk) 16:19, 8 August 2021 (UTC)