Nodes without roles generate unnecessary warnings in walking relations, specifically Node2Node routes in Node Networks.

[eldersonmuziek@…]

What steps will reproduce the problem?

1. Open a Walking Node Network relation in the relation editor (type=route + route=foot + network:type=node_network + network=rwn)
2. Add the first node of the first way as a member. (The node is tagged rwn_ref=* + network:type=node_network)
3. Save the relation and try to upload.

What is the expected result?

The edit should be accepted without a warning. According to descriptions and definitions of Node Networks, Network Nodes without roles may be members in these relations.

What happens instead?

A warning is generated that a rule about roles in walking route relations is broken.

Please provide any additional information below. Attach a screenshot if possible.

The same warning is raised when editing OSM objects belonging to such relations. In fact this happens very often in Nederland, where Node Networks are very very common.

Note that these Nodes are *not* guideposts.

Revision:19017
Build-Date:2024-03-18 12:32:31

Identification: JOSM/1.5 (19017 nl) Windows 11 64-Bit
OS Build number: Windows 10 Home 2009 (22631)
Memory Usage: 4024 MB / 4024 MB (1862 MB allocated, but free)
Java version: 17.0.10+7-LTS, Azul Systems, Inc., OpenJDK 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 1920×1080 (scaling 1.25×1.25)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: nl_NL
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Djpackage.app-version=1.5.19017, --add-modules=java.scripting,java.sql,javafx.controls,javafx.media,javafx.swing,javafx.web, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED, --add-opens=java.base/java.lang=ALL-UNNAMED, --add-opens=java.base/java.nio=ALL-UNNAMED, --add-opens=java.base/jdk.internal.loader=ALL-UNNAMED, --add-opens=java.base/jdk.internal.ref=ALL-UNNAMED, --add-opens=java.desktop/javax.imageio.spi=ALL-UNNAMED, --add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED, --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED, -Djpackage.app-path=%UserProfile%\AppData\Local\JOSM\JOSM.exe]
Dataset consistency test: No problems found

Plugins:
+ ElevationProfile (36226)
+ MapRoulette (26)
+ OpeningHoursEditor (36226)
+ PolygonCutOut (v0.7.3)
+ apache-commons (36176)
+ changeset-viewer (0.0.7)
+ ejml (36176)
+ geotools (36176)
+ jackson (36176)
+ jaxb (36118)
+ jts (36004)
+ opendata (36200)
+ openqa (v0.3.3)
+ reltoolbox (36226)
+ reverter (36230)
+ rex (53)
+ utilsplugin2 (36226)

Tagging presets:
+ http://mijndev.openstreetmap.nl/~allroads/JOSM/Presets/NL-Fiets.zip

Map paint styles:
+ https://josm.openstreetmap.de/josmfile?page=Styles/Potlatch2&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/NumberedWalkingNodeNetworks&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/NumberedCycleNodeNetworks&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Enhanced_Lane_and_Road_Attributes&zip=1
+ https://josm.openstreetmap.de/josmfile?page=Styles/Osmc&zip=1
- https://josm.openstreetmap.de/josmfile?page=Styles/Waterways&zip=1

Last errors/warnings:
- 00138.866 W: Kan geen ondersteunde projectie vinden voor laag AHN4 maaiveld hillshade (OSM + Private Licence !! OK)(wms). Gebruik EPSG:3857.
- 00217.923 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8402/5415
- 00217.925 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8400/5414
- 00217.925 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8401/5413
- 00217.927 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8402/5413
- 00217.928 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8401/5414
- 00217.929 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8402/5414
- 00217.929 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8400/5415
- 00217.930 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8400/5413
- 00217.931 E: Region [TMS_BLOCK_v2] : Failure getting from disk--IOException, key = OpenStreetMap Carto (Standaard):https://tile.openstreetmap.org/{zoom}/{x}/{y}.png/14/8401/5415

[skyper]

Currently, we only have a preset for the collective type=network network:type=node_network relation but not for the actual route relation (type=route route=* network:type=node_network).

[pelderson@…]

Replying to skyper:

Currently, we only have a preset for the collective type=network network:type=node_network relation but not for the actual route relation (type=route route=* network:type=node_network).

Well, something generates this warning, and it shouldn't. Maybe a preset for foot routes, not specific for node_networks. If so, could this preset be altered to allow setting network:type=node_network, and if set allow nodes without roles?

[skyper]

The roles are defined and restricted in the presets. I'd say, we need an additional preset for node network routes but I am not sure if the code checks more tags besides type=route and route=*, e.g. network:type=node_network in this case.

[pelderson@…]

Would it be easier to allow nodes with a new explicit role, eg role=network_junction or role=netnode or whatever? Then the format resembles the guidepost nodes. If so, I can propose this change in tagging.

[skyper]

No, tagging is fine. It is the editor which needs to be enhanced.
I do not want to mix the different types of relation, type=route, as it would be almost impossible to warn about improperly use or missing roles (including the tags of the objects). These relations have different concepts and should be strictly separated.
See also #20731 which is about two different concepts of "common" routes.

[GerdP]

See also #20210 which was about cycle routes in node networks

[skyper]

Replying to GerdP:

See also #20210 which was about cycle routes in node networks

Copied from 20210#comment:10:

It does not handle/fix the similar validator warning about the route relations: Type 'node' of relation member with role '' does not match accepted types 'way/closedway' in preset Bicycle Route (458) which would need another own preset for node network route relations.

Almost it was about the network relations:
Replying to skyper:

Currently, we only have a preset for the collective type=network network:type=node_network relation but not for the actual route relation (type=route route=* network:type=node_network).

[pelderson@…]

Replying to skyper:

The roles are defined and restricted in the presets. I'd say, we need an additional preset for node network routes but I am not sure if the code checks more tags besides type=route and route=*, e.g. network:type=node_network in this case.

1. I would like to point out that node network routes in themselves are not special route relations. They can be linear or roundtrip, they can be unidirectional or bidirectional with backward/forward sections, they can have excursions/alternatives, and they can have nodes as members: guideposts nodes with role guidepost and other nodes without a role. And this is generic for the node2node routes in node networks of all transportation methods.

2. I have had a closer look at the preset for Walking Routes. I assume the presets for the other transportation modes are alike. As for the tag network:type=node_network, this could simply be added as a check box toggle to the route relation presets for walking, bicycle, horse, boat, paddling, and what have you. It does not alter the route, it just says it's part of at least one node network, besides being a route of its own.

3. The preset lets the user add/alter some tags, and it summarises the members. This list is also used by the validation to check the members. Nodes without a role are checked to have certain identifying tags such as natural=peak etc. This list is limited.

Knowing that, I propose to simply allow a node without a role with the tag 'xxn_ref=y' where xx can be any two characters and y is any simple string. I think a regexp can be used?
Because that is the generic identifier of a Node_network Node. If made specific for walking node networks, xwn_ref=y. Where x can be i, n, r or l. w is for walking; other transport methods are h for horse, b for bicycle, i for inline skating, m for motor boat, p for paddling including canoe and rowing, and others may arise.

Now this would also allow a Node_netork node to be included in a non-Node_network route. Which is comparable to adding the other allowed POIs to these routes (by 'allowing' I mean, not warning). The Nodes are indeed visible on the road as markers with a number, code or name, and the operators of the pack of longdistancepaths I manage uses the Nodes as markers in their descriptions.

Would it be an idea to test this (toggle the network:type=node_network tag and adding xxn=y regexp as allowed node without a role) on the walking route preset, or a copy of it? (I have two Walking Route presets in my list already, temporarily having one more doesn't hurt).

[skyper]

Replying to pelderson@…:

Replying to skyper:

The roles are defined and restricted in the presets. I'd say, we need an additional preset for node network routes but I am not sure if the code checks more tags besides type=route and route=*, e.g. network:type=node_network in this case.

That was more a question I asked myself and other developers.

1. I would like to point out that node network routes in themselves are not special route relations. They can be linear or roundtrip, they can be unidirectional or bidirectional with backward/forward sections, they can have excursions/alternatives, and they can have nodes as members: guideposts nodes with role guidepost and other nodes without a role. And this is generic for the node2node routes in node networks of all transportation methods.

I am not deeply into mapping node network route relations but what I read about it is that they should be limited to numbered node networks and maybe named node networks which do not have excursions or alternatives. I am pretty sure that mix of "common" roles (backward/forward) with the newer recreational route roles (alternative/approach/connection/excursion) is wrong see ​osmwiki:Roles_for_recreational_route_relations#Apply_to_ways:_only_in_single_strand_routes_without_forward/backward_roles

2. I have had a closer look at the preset for Walking Routes. I assume the presets for the other transportation modes are alike. As for the tag network:type=node_network, this could simply be added as a check box toggle to the route relation presets for walking, bicycle, horse, boat, paddling, and what have you. It does not alter the route, it just says it's part of at least one node network, besides being a route of its own.

Sorry, but the hiking preset is the special one as it does not include forward and backward.

Knowing that, I propose to simply allow a node without a role with the tag 'xxn_ref=y' where xx can be any two characters and y is any simple string. I think a regexp can be used?
Because that is the generic identifier of a Node_network Node. If made specific for walking node networks, xwn_ref=y. Where x can be i, n, r or l. w is for walking; other transport methods are h for horse, b for bicycle, i for inline skating, m for motor boat, p for paddling including canoe and rowing, and others may arise.

That is interesting. I guess we currently miss some route=* and a lot of xxn (especially the water vehicles) for network=*

Now this would also allow a Node_network node to be included in a non-Node_network route. Which is comparable to adding the other allowed POIs to these routes (by 'allowing' I mean, not warning). The Nodes are indeed visible on the road as markers with a number, code or name, and the operators of the pack of longdistancepaths I manage uses the Nodes as markers in their descriptions.

If it is a guidepost use the appropriate role. Roles for route_marker and trail_blaze need to be discussed, see also #21602.

Would it be an idea to test this (toggle the network:type=node_network tag and adding xxn=y regexp as allowed node without a role) on the walking route preset, or a copy of it? (I have two Walking Route presets in my list already, temporarily having one more doesn't hurt).

Sure, you can create and publish your own external presets: Presets#PublishanewAvailablepresetsitem

---

One major problem for me is the little documentation of the tagging system in the OSM wiki. I find little about roles and members on ​Tag:network:type=node_network and ​Cycle_Node_Network_Tagging#The_members_of_this_relation_are: even tells to exclude the nodes from the route relations as they are not needed.

Overall, would you mind to talk the topic about roles and members of node network route relations over at the forum or the tagging mailing list, please. We probably reach more people interested and experienced in the matter and we could then update the OSM wiki and JOSM.

[pelderson@…]

Sorry, I am not discussing roles and members of Node Network relations, I'm just explaining that Node Network routes are regular routes. Great care has been taken to comply with regular route tagging and to make the system generic across all transport methods.
The whole idea is that regular routes are used, just additionally strung together in a network. So all other things apply, including roles and tags, with the only addition of the tag network:type=node_network. This tag does not make it a different kind of route, it just indicates that it is used in a certain kind of network.
I wrote and expanded the article on Node Networks ​https://wiki.openstreetmap.org/wiki/Node_Networks, compiling the many discussions and developments resulting in the current system.

As for the functional roles (alternative etc), I wrote the wiki article you mention and got these roles approved. It does not exclude forward and backward roles for any recreational route, it just says do not mix forward/backward with the other roles in one route, and it expresses a preference to use functional roles on member routes in superroutes, rather than on way members in routes.

Routes can have al kinds of nodes in them, some with and some without roles. As far as I know there is debate but no consensus/approval about which type of nodes, with or without roles, are acceptable. Nevertheless, apparently a limited list has been built into JOSM validation based on a preset. This causes JOSM to warn about a type of node that is used very often in many routes of the network=xxn type.

So I would like this warning to be prevented, for all network=xxn recreational routes, by allowing these nodes in the existing preset based validation(s) for these routes.

Are they guideposts? No, these nodes are not the guideposts, they are connection nodes of crossing ways; the end points/start points of the route relations. It would be wrong to assign the role guidepost, because that is meant for the actual guidepost nodes which usually are beside the roads.