Den Wunsch (2), (3) und (4) voneinander abzugrenzen, habe ich auch. Auch über ein Knotennetzwerk kann eine Themen-Radroute gelegt werden. Auch hier sollten Renderer die Möglichkeit bekommen, sie vom Knotennetzwerk zu unterscheiden.
Bei (2) sehe ich auch, dass es oft schwierig ist, zu entscheiden, ob Netze nun örtlich oder regional sind. Kurze Streckenteile des Netzes liegen innerhalb einer Kommune oder eines Kreises, längere aber auch landkreisübergreifend. Einzige sinnvolle Grenzen in Deutschland wären i.d.R die Ländergrenzen, weil die Fahrradwegweisungestandards hierzulande länderspezifisch standardisiert sind. Es sei denn, es gibt begrenzte kleinere Netzwerke mit abweichender Beschilderung.
Wenn die Grenzen des Netzes draußen eindeutig erkennbar sind, würde ich bei (2) die network-Relation mit dem Tag ‘network=rcn/lcn’ versehen. Wenn nicht, so wird es bisher oft mit ‘network=lcn’ versehen. M. E. wäre besser ein allgemeinderes Tag ‘network=bicycle’.
Bei (3) sehe ich das anders. Knotenpunktnetzwerke haben einen Betreiber. Die Regionale Ausdenhnung ist begrenzt und i.d.R. für den Radfahrer sowohl in Karten auch draußen erkennbar. Diese Netzwerke orientieren sich nicht zwangsläufig an den Kreisgrenzen, sondern häufig an Tourismus-Regionen, z. B. in Brandenburg. Die Netze haben meist auch ein eigenen Namen und werden gesondert vermarktet, ähnlich von Themenrouten, siehe z. B. dieprignitz.de.
Hier macht network=lcn/rcn durchaus Sinn, jenachdem, wie weit das Knotenpunktnetzwerk geht.
Um das Knotenpunktentzwerk dennoch von (2) und (4) abzuheben, bräuchte es einen neuen Tag.
Ich würde dafür plädieren, (2) und (3) als network-Relation zu taggen, wobei (3) einen neben ‘network=rcn/lcn’ noch ein ‘nodenetwork=yes’ oder so bekommt. Route-Relationen wären dann ausschließlich für (4) vorgesehen.
Dann müsste man allerdings alle bestehenden Knotenpunktnetzwerke umtaggen, die einzelnen Verbindungen innerhalb des Netzwerkes sind heute alle route-Relationen.
Will man das nicht, definiert man (3) als eine Untermenge von (4) und belässt es bei den route-Relationen. Auch hier würde wieder ein zusätzliches ‘nodenetwork=yes’ den Renderern helfen, Knotenpunktnetzerke von (4) zu unterscheiden.