You are not logged in.

#226 2021-05-06 19:17:47

segubi
Member
From: Bielefeld, NRW, Germany
Registered: 2020-08-19
Posts: 26

Re: Knotenpunktnetzwerke

klnkengi wrote:

Nur als Idee: Wenn Du die Beschilderung der Wegweiser nicht mit direction_xyz=... einträgst, sondern mithilfe von "destination_sign"-Relationen, könnte man das Steigungs-Symbol unter destination:symbol=... eintragen.

Hab' ich mir nun mal angeschaut. Stimmt im Prinzip, aber das ist gigantisch aufwändig, ich nehme mal einen aufgeteilten Knotenpunkt zufällig heraus (noch nicht einmal ein besonders umfangreiches Beispiel) Knoten 70 Süd, Bielefeld, es gibt immerhin nur 2 Wegweiser (es gibt auch Knoten mit 3 oder 4 Wegweisern). Auf dem beiden habe ich je Verweise auf 7 Ziele und 4 Knoten. Im Standardfall bekommt jedes Ziel eine Relation, man scheint die Ziele auch zusammenfassen zu können, so dass es immerhin je 3 Richtungen werden (es gehen auch 4-5 wenn man Pech hat). Also muß dieser Knoten mindestens 6 destination_sign Relationen bekommen (statt 2 nodes als guidepost). Das schaffe ich nicht ohne Plugin, das ich nicht selbst programmieren kann. Die Knotendichte ist hier so dicht, dass ich für das Abfahren einer Strecke mit dem Fahrrad weniger Zeit brauche als für das mappen nachher (selbst wenn ich die Hälfte der Strecke durch bereits bekanntes Gebiet fahre), also 4 Stunden Fahrradfahren sind locker 5-6 Stunden Zeit am Computer, wenn ich es halbwegs vollständig machen will.

Aber die Datenstruktur wäre natürlich deutlich besser. Für auswertende Software hübscher zu parsen als die Umkreissuche nach irgendwelchen hoffentlich passenden guideposts... Also wer schreibt's Plugin? Oder gibt's das schon? Ein Fenster, schnell die Richtungen angeben, er findet selbst heraus, welche Wege gemeint sein müssen (Fahrradbefahrbare auswählen, nichts über den Fußweg schicken, oder anbieten, den Fußweg schnell noch mit bicycle=yes zu taggen, vielleicht doch auf die Straße, wenn sie ein cycleway:left:oneway=no hat...) wink

Oder eine Software, die aus umstehenden Guideposts Wegweiserrelationen bastelt und vorschlägt? Das wäre durchaus denkbar, wenn das zugrundeliegende Netzwerk bereits gut vorstrukturiert ist. Damit wäre ich bei meinem nächsten post: ...

Offline

#227 2021-05-06 20:36:23

segubi
Member
From: Bielefeld, NRW, Germany
Registered: 2020-08-19
Posts: 26

Re: Knotenpunktnetzwerke

JochenB wrote:

Wenn sich die Infos nur auf einen Teil der Route beziehen, so müsste man die Route splitten. Das ist es oft bei den Neigungsangaben so. In einem anderen aktuellen Diskussionfaden wurde sich darüber aufgeregt, dass man Wege viel zu viel splittet. Wenn wir jetzt auch noch Relationen in viele Teilrelationen splitten, dann wird das echt unübersichtlich. Da sollten wir uns genau überlegen, ob es das wert ist oder ob wir die Angaben nicht lieber nur an die Wegekanten schreiben.

Das betrifft hier übrigens nur eine knappe Handvoll Routen. Es läuft aber da auf eine andere grundsätzlichere Frage hinaus: Man müßte sich Gedanken machen, ob man Routen lieber splitten will, oder Abschnitte mehrfach abbilden möchte. Ich bin da nicht 100% entschieden. Das Radverkehrsnetz NRW ist strukturell erst einmal EIN Netzwerk, das, wenn es nicht fehlerhaft ausgeschildert und aufgebaut ist, ziemlich eindeutig ein Knotenbezogenes Netzwerk ist, an jedem Knoten stehen Wegweiser mit Zielen. Zwischen den Knoten stehen nur Zwischenwegweiser ohne Ziele, ohne spezifische Routenmarkierungen (außer dem reservierten Logo, dem roten Pfeil für eben das NRW-Radverkehrsnetz, mit der Landesgrenze nach Norden wechselt z.B. die Farbe, das ist dann klar ein anderes Netz). Zwischen den Knoten liegen Wege, die gut Routen im osm-Sinn entsprechen. Sie haben Attribute, die durch die Wegweiser an den Enden definiert werden, dazwischen sind keine weiteren Informationen ausgeschildert. Die Knoten können Nummern haben, dann ist es ein "node_network".

Auf diese Minimalrouten setzen auf der nächsten Ebene längere Routen auf:
* Das sind die Routen zwischen nummerierten Knoten,
* die durch die Landkreise unterhaltenen Themenrouten
* die durch das Land unterhaltenen/organisierten Themenrouten
* manche Bundesländerübergreifenden Routen, die sich auch hier aufsetzen. (Z.B. BahnRadRoute WeserLippe)

Von der Logik der Daten wäre es so, dass das kleinste Teilchen die oben genannten Routen ohne eigenen Namen sind. Jede andere Art Route setzt sich aus diesen Unterrouten zusammen.

Das erzeugt aber Probleme. Es ist nicht üblich, eine benannte Route sehr vielen Unterrouten zusammenzusetzen, obwohl Langstreckenrouten durchaus aus mehreren Unterrelationen bestehen.

Besonders die Struktur der aktuellen Knotenpunktnetzwerke ist inzwischen zwischen den Niederlanden, Belgien und Deutschland recht großflächig vereinheitlicht, in Frankreich, Österreich und Spanien gibt es auch einzelne Knotenpunktnetzwerke, die diesem Schema folgen. Eine gewisse Abstimmung wäre hilfreich, und/oder Mitarbeit z.B. an dem knooppuntnet Projekt. Man sollte sich da nicht aus der Struktur rauskicken.

Vorteile wären allerdings: Änderungen der Routenführung vor Ort würden unmittelbar in alle betroffenen Routen (Themenrouten, Nummernrouten, Überregionale Fahrradwege) übernommen, die Kartendaten wären leichter aktuell zu halten. Im Moment bin ich dabei mit jeder Strecke, die ich fahre und korrigiere, locker mal 5 weitere Relationen von verschiedensten Fahrradrouten mit korrigieren zu müssen. Auch temporäre Umleitungen könnten markiert werden (gelbe Verkehrsschilder). Auch die Aktualität einzelner Abschnitte ist besser sichtbar. (survey:date=xyz)

Die Eigenschaften der Unterabschnitte könnten auf Karten schnell sichtbar gemacht werden: z.B. Grüne Abschnitte für die "Bäumchen"-Logos, andere Farben für die starken Steigungen.

Ich benutze im Moment zunächst in Bielefeld eine Mischform: Ich bearbeite das Knotenpunktnetzwerk nach den üblichen Regeln, eine Relation für eine Route zwischen zwei Nummern. Die benannten Routen haben eine komplette Relation (wenn sie sich nicht verzweigen), die unabhängig von den anderen ist. Was dann noch übrig bleibt, bekommt Routenrelationen zwischen zwei Wegweisern, die in das Netzwerk ("Radverkehrsnetz NRW Stadt Bielefeld") aufgenommen werden.

Im Moment lösche ich aus der Relation "Radverkehrsnetz NRW Stadt Bielefeld" nach und nach alle Einzelwege, die entweder durch das Knotenpunktnetzwerk oder durch Routen in dieser Relation bereits dargestellt sind. Wenn ich das so mache, müßte ich eigentlich auch die Themenrouten in die Relation mit aufnehmen, um dann nur noch ganz wenige unbenannte Routen übrig zu haben. Was aber würde ich mit den überregionalen Resten machen, sowohl in Bielefeld aufnehmen als auch z.B. im Kreis Gütersloh? Die Route nach Kreisen teilen? Das ist alles nicht so elegant. Insbesondere würde das wieder zu nur bedingt sinnvollen Sammelrelationen führen, z.B. wenn man die NRW-Themenrouten auch anfangen würde zu sammeln...

Ich stelle mir vor, dass ich, wenn ich mir die Relation "Radverkehrsnetz NRW" mit allen Unterrelationen anschaue, dann auch das komplette Radverkehrsnetz NRW habe. Da im Moment eine Relation "Knotenpunktnetzwerk NRW" alle Knotenpunktnetzwerke in NRW enthält und diese im "Radverkehrsnetz NRW" enthalten ist, benötige ich für dieses Ziel keine doppelte Anführung von den Routen.

Irgendwie empfinde ich es als ungünstig, wenn "ways" doppelt enthalten sind. Bei Routen fällt mir das nicht so schwer. Im Moment kommt es oft vor, dass ein identischer Streckenabschnitt je nach Route unterschiedlich gewählt wird. Wenn ich von A nach B auf der Themenroute fahre, werde ich vielleicht über den Pfad an der Seite geführt, muß zwischendurch absteigen, weil plötzlich der Radweg nur noch in eine Richtung befahren werden darf etc.. Fahre ich den gleichen Abschnitt auf dem Knotenpunktnetzwerk, wird der Weg über die Autostraße geführt, die mit use_sideway markiert ist. Dabei können unterschiedliche errechnete Zeiten und Entfernungen herauskommen, oder ein Weg auch mal gar nicht durchgängig sein. Oder man bekommt Alternativen beim Routing angeboten, die gar keine sind.

Aus diesem Grund bin ich dagegen, Informationen, die sich auf eine Route beziehen (also auf dem WegWEISER und nicht auf dem WEG sind), an Wegen zu taggen.

Ein wichtiges Kriterium fürs Taggen ist mir auch, dass man eine Struktur schafft, die man automatisiert möglichst einfach in eine andere überführen kann. Das reduziert letztlich die Gefahr, dass Änderungen massiv arbeitsaufwändig und dann ggf. unmöglich würden. Da darf es ruhig auch etwas kleinteilig in manchen Dingen sein. Zusammenführen geht automatisiert einfacher als umgekehrt.

(zu viel Text, ich weiß... ich schaff heute Abend kein Kürzen mehr. Sorry)

Grüße, Sebastian

Offline

#228 2021-05-06 21:55:45

JochenB
Member
Registered: 2012-01-24
Posts: 329

Re: Knotenpunktnetzwerke

segubi wrote:

Aus diesem Grund bin ich dagegen, Informationen, die sich auf eine Route beziehen (also auf dem WegWEISER und nicht auf dem WEG sind), an Wegen zu taggen.

Das sehe ich auch so. Ausnahme: Wenn es noch keine route-Relation gibt, der Mapper nicht den gesamten Verlauf kennt oder mit Relationen nicht gut umgehen kann, wäre z. B. ein lcn=* an die Kanten eine Alternative, bis sich jemand findet, der die Relation anlegt.

segubi wrote:

Von der Logik der Daten wäre es so, dass das kleinste Teilchen die oben genannten Routen ohne eigenen Namen sind. Jede andere Art Route setzt sich aus diesen Unterrouten zusammen.

Das wurde hier kürzlich auch irgendwo diskutiert, finde es aber nicht mehr. Dort fand das nicht so Anklang. Ein Argument war glaub ich, dass die Themenrouten nicht immer deckungsgleich sind mit den Netzverbindungen.

Ich finde es problematisch, dass man diese Routen beim Bearbeiten der Wege bzw Verbinungs-Relationen nicht sieht. Das die Themenroute dort lang geht erfährt man erst durch einen Blick in die Elternrelationen der Netzverbindung. Das birgt Gefahren und erschwert die Pflege.

segubi wrote:

Was aber würde ich mit den überregionalen Resten machen, sowohl in Bielefeld aufnehmen als auch z.B. im Kreis Gütersloh? Die Route nach Kreisen teilen? Das ist alles nicht so elegant. Insbesondere würde das wieder zu nur bedingt sinnvollen Sammelrelationen führen, z.B. wenn man die NRW-Themenrouten auch anfangen würde zu sammeln...

Im Prinzip sind die Master-Relationen reine Sammelrelationen. Die Kreisrelationen helfen aber, beim Mappen des Netzes den Überblick über alle Verbindungen zu halten, Verbindungen zu Nachbarkreisen mit Rolle 'connection'. Insofern sind für mich solche Kreisrelationen für das Netz OK, egal es ein Knotenpunktnetzwerk ist oder ein Grundnetz ohne Routen-Symbole.

Die Themenrouten würde ich nicht in kreis- oder länderspezifische Masterrelationen aufnehmen. Das macht die nur unübersichtlicher.

Eine master-network-relation für Themenrouten würde ich nur machen, wenn es ein spezielles Netz eines besonderen Betreibers ist und es nicht durch administrative Grenzen definiert ist. Ein solchens Beispiel wären die Routen des "Rad- und WanderParadies Schwarzwald und Alb". Dann hat man das problem des Teilens an Grenzen auch nicht.

segubi wrote:

Ich benutze im Moment zunächst in Bielefeld eine Mischform: Ich bearbeite das Knotenpunktnetzwerk nach den üblichen Regeln, eine Relation für eine Route zwischen zwei Nummern. Die benannten Routen haben eine komplette Relation (wenn sie sich nicht verzweigen), die unabhängig von den anderen ist. Was dann noch übrig bleibt, bekommt Routenrelationen zwischen zwei Wegweisern, die in das Netzwerk ("Radverkehrsnetz NRW Stadt Bielefeld") aufgenommen werden.

Das ist doch gut so. Nur dass es zwei Master-Relationen für das Netz gibt, finde ich verwirrend, insbesondere, wenn das Netz des Kreises in großen Teilen in ein Knotenpunktnetzerk aufgegangen ist.

Das Tagging-Schema der Knotenpunktnetze sieht ja auch route-Relationen mit 'state=alternate' vor. Damit könnte man die Verbindungen ohne Knotenpunktwegweisung versehen. Wenn sich mein Vorschlag mit dem 'network:type=basic_network' durchsetzt, wäre das eine wesentliche Anwendung dafür.

Diese Verbidnungen könnten alle in eine Master-network-Relation. Die unterschiedliche Wegweisung würde anhand des 'network:type' an der Relation erkannt, so dass Renderer die unterschiedlich darstellen können. Fänd ich übersichtlicher.

Offline

#229 2021-05-07 09:49:55

Peter Elderson
Member
From: Nieuwerkerk aan de IJssel
Registered: 2018-02-08
Posts: 2,009

Re: Knotenpunktnetzwerke

JochenB wrote:

segubi schrieb:
> Von der Logik der Daten wäre es so, dass das kleinste Teilchen die oben genannten Routen ohne eigenen Namen sind. Jede andere Art Route setzt sich aus diesen Unterrouten zusammen.

Das wurde hier kürzlich auch irgendwo diskutiert, finde es aber nicht mehr. Dort fand das nicht so Anklang. Ein Argument war glaub ich, dass die Themenrouten nicht immer deckungsgleich sind mit den Netzverbindungen.

(The Belgian forum has just discussed this again). Here is (slightly edited) what I posted:

1. I have tested building 2 longer routes out of existing node2node routes, because the operator claimed they were absolutely following the node network. Turn out they didn't, but that was not a problem: I just added some extra ways and sections. The problem was: you can't sort the parts, and you can't see the order of the parts in the superrelation.  It turns unmaintainable very quickly. 

2. The other test was with roundtrip local walks (colour loops). That particular walking network was built by combining all the existing local 'colour loops'. Everywhere the loops cross or touch each other, a Network Node was placed.  All the node2node routes are part of one or more loops and every loop can be made from a limited number of node2node routes. I created the loop relations by collecting a few (2-6) node2node relations into a loop relation. The node2node relations were rwn and the loops were lwn, but that posed no problem.

So the first use case (long theme route) failed: unmanageable for long routes with many node2node sections.
Example (look at the sections in the information panel): https://hiking.waymarkedtrails.org/#route?id=9576945


The second use case (local loops) turned out to be beneficial. The node network actually benefits from the colours, and the loops benefit from the node planner. You can see the colours (colour=* on the node2node relations)  in the output of the Knooppuntnet Planner.
Compare:
https://hiking.waymarkedtrails.org/#sea … 936!7.0487
https://knooppuntnet.nl/nl/map/hiking#6 … 8on-5777a2

Offline

#230 2021-05-07 15:31:44

segubi
Member
From: Bielefeld, NRW, Germany
Registered: 2020-08-19
Posts: 26

Re: Knotenpunktnetzwerke

Peter Elderson wrote:

1. I have tested building 2 longer routes out of existing node2node routes, because the operator claimed they were absolutely following the node network. Turn out they didn't, but that was not a problem: I just added some extra ways and sections. The problem was: you can't sort the parts, and you can't see the order of the parts in the superrelation.  It turns unmaintainable very quickly. 
[...]
So the first use case (long theme route) failed: unmanageable for long routes with many node2node sections.
Example (look at the sections in the information panel): https://hiking.waymarkedtrails.org/#route?id=9576945

I agree, one has to be careful not to create difficulties in doing that. But I don't exactly know what you mean by "can't sort" and "can't see the order". In the mentioned relation 9576945 the members seem to be ordered correctly and I see it in JOSM. It isn't indicated next to the relations, but the order is sorted and visible. And even waymarkedtrails shows the elevation profile in the proper order and has no difficulties. The sections there are ordered alphanumerically, if waymarkedtrails left them unsorted they had the proper order I assume.
Hm. I see an issue: there are no roles forward an backwards set for the relations. That would be necessary I think. My comment on the elevation profile is incomplete. It looks fine because there are so many fragments that I don't see, whether these are sometimes reversed...
So its a matter of the editing or rendering software and not of the data. I agree that sorting relations would be more difficult than sorting ways and more error prone, and a connection between routes is difficult to define if there are split nodes not just a binary value connected/not connected! Maybe it's some project for the future if the structure of the networks still would suggest that way.

Offline

#231 2021-05-07 15:58:50

Peter Elderson
Member
From: Nieuwerkerk aan de IJssel
Registered: 2018-02-08
Posts: 2,009

Re: Knotenpunktnetzwerke

segubi wrote:

The sections there are ordered alphanumerically, if waymarkedtrails left them unsorted they had the proper order I assume.

True. I have asked for that, but got no response. Maybe you could try? The same goes for other sectioned routes, that's why they get names with a section number in it.
The elevation profile (and the export gpx) actually solve most ordering problems, unless there are too many errors: gaps, crossing ways, or unsolvable puzzles such as closed way roundabouts, pedestrian areas, or if roles are involved, then it fails.
The same is true for sorting in JOSM (yes, if you know the order you can see it's allright, but the continuity line is not correct and if the order is messed up, you need external sources and individual placement of the members to get it right again).

segubi wrote:

So its a matter of the editing or rendering software and not of the data. I agree that sorting relations would be more difficult than sorting ways and more error prone, and a connection between routes is difficult to define if there are split nodes not just a binary value connected/not connected! Maybe it's some project for the future if the structure of the networks still would suggest that way.

True, better tools could do a lot, but I can't build them and I don't see much enthousiasm of programmers for this niche... so until the brighter future arrives,  we'll have to manage without. And, if I look at other challenges in OSM, I have to admit this is not the highest priority.

Offline

Board footer

Powered by FluxBB