Node with names instead of numbers

[pelderson]

Request: support node names instead of numbers.

The Scharzwaldverein has implemented a signing system for walking that incorporates a node network. where the nodes have names instead of numbers. Examples of two nodes referring to each other: https://www.mapillary.com/map/im/JHsA93GEpA3eUM9xgzyvXw and https://www.mapillary.com/map/im/eIRS73pR_EzwiMm9uWxi2A . This covers a wide area.

The netwerk is represented by the symbol on the center shield: in this case the yellow diamond. All the routes of the network carry that symbol. The unique node name is above the symbol, The number gives height above sea. The upper destinations on the fingers are the adjacent node names.

I could plan a test for this one network with the German mappers to map node names as rwn_ref=, see how it works out in the analysis (old and new) and planner.

[pelderson]

Did a small test on one node in my area. The rwn_ref is "35 Test naam". Taken from the new planner, when zooming in, at zoom 13. At other zoomlevels and in the result list it looks like the ref is cut off after max 3 characters. Waymarkedtrails show it like this: , that's not ideal.

[vmarc]

Detail information on the example nodes above:

osm id	what	name
7590438451	guidepost	Hilsenberg
11168702	route	Hinterer Wasen - Hilsenberg
11168701	route	Katzensteiner Hof - Hilsenberg
11168698	route	Kreuzbuche - Hilsenberg

osm id	what	name
7590438450	guidepost	Katzensteiner Hof
11168701	route	Katzensteiner Hof - Hilsenberg
11168700	route	Katzensteiner Hof - Unterm Katzenstein
11168689	route	Katzensteiner Hof - Sandgrube

Observation: the guideposts are part of the routerelations but they are not nodes of the of the route ways. The knooppuntnet logic will have to be adapted for this (at this moment the nodes are expected to be nodes on the ways).

Current guidepost tags:

tag	value
tourism	information
information	guidepost
hiking	yes
name	Katzensteiner Hof

Current route tags:

tag	value
network	lwn
type	route
route	hiking
name	Katzensteiner Hof - Hilsenberg

[pelderson]

I think they should use the way intersections as (logical) junction nodes, and map the guideposts as separate features for display at the exact positions. It's an interesting development! I'll contact the German mappers now.

[pelderson]

I have a go-ahead to make a small network of say 10 nodes. that should be enough for a model. I'll take this on in two weeks time, after my vacation. Interesting: a swiss mapper asked the same about the swiss system. I'm not sure it actually works the same, but it sounded like it did.

[matthijskooijman]

I think the Swiss mapper your talking about was me, though I'm actually Dutch, but my brother moved to Switzerland, so I come there a bit more often lately :-p

In any case, the current Swiss practices are documented here: https://wiki.openstreetmap.org/wiki/DE:Switzerland/HikingNetwork and I believe it's pretty much identical to the german one shown here (even uses the same yellow diamond symbol and the same layout on guideposts). One thing is that not all nodes actually have names (nor numbers), consensus seems to be to invent a name for the node then (based on its location), see the talk page for the linked wiki page) about this. Also, they use name= now for guideposts, but also on the talk page someone argued the guidepost does not actually have a name, so maybe switching to a complete node network style and using lwn_ref instead of name could fix that as well. Though I wonder if you would still need to tag the junction and then additionally include the guidepost in the relation, or just use the guidepost as the node? I also recall people advocating that guideposts do not belong in a route relation at all (beter in a destination_sign relation, though that has a bit of a different purpose).

[pelderson]

Inmiddels wordt het in Duitsland opgepakt, men is te ongeduldig om even te wachten.... er verschijnen ontiegelijk lange rwn_refs op de kaarten, dat is niet geweldig. Ik zie ook een paar problemen in de tagnamen, die bij waymarkedtrails niet goed gaan vallen. Liefst heb ik eerst overeenstemming met zoveel mogelijk partijen over het taggebruik en hoe de knooppunten zich verhouden tot de wegwijzerpalen, welke tags waarop staan, etc. Ik overweeg om een wiki-pagina hierover te maken, een soort pre-proposal, en dan op de diverse landelijke forums daarover te diskussiëren en bij te schaven, voordat het naar de tagging list gaat en voor voting. Maar anders zie ik het niet goed komen. Dan gaan we natuurlijk ook door, maar drijven we weer af van de grote stroom, terwijl we net zo goed bezig waren om de uitzonderingen ongedaan te maken.

[pelderson]

I have created a draft proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_networks For now, I do not want to push the issue on the tagging list, in Nederland and in Belgium, but I would like to get the discussion going in Germany and possibly Switzerland. Is the Swiss community actively mapping recreational routes and networks?

[matthijskooijman]

Isn't this a bit off-topic for this issue? Maybe some forum thread would be more appropriate?

Anyway, good to see a proposal towards this, thanks for investing time into this! Should your proposal also reference the new node network wikipage your were working on, since it essentially extends that mapping scheme? I wonder if rendering these long node names is really meaningful by default, but I guess that might be something for the renderers to decide (unless we want to distinguish a "Short ref" (number of few letters) from a "Descriptive ref" (the names of nearby places used in .de and .ch)?

Is the Swiss community actively mapping recreational routes and networks?

Looking at the map, it seems that their walking network is pretty comprehensively mapped in a large part of Switzerland:. When I asked a question about their network mapping recently, I got a fairly swift answer, after discussing my question in the "Zurich stammtisch", which is apparently a monthly meeting for OSM-related things. So it seems that there is an active interest in mapping their hiking network there. This stammtisch might be a good entrypoint to get this discussion started, or maybe just post in the Swiss OSM forum?

[pelderson]

"Isn't this a bit off-topic for this issue? Maybe some forum thread would be more appropriate?" You are right. We'll come back to it later, if a proper tagging scheme has been established.

[pelderson]

I have a new French pilot area. They use null-refrences to make it work, as a temp setup, so they can go on entering the data into OSM. Based on the pilots, I have made a proposal and announced it on the Dutch, Belgian and German forums. Got no principal objections and a few suggestions. The Germans are adamant in that they will not implement a temporary solution. I would like Knooppuntnet to support the proposed setup: rwn_name= for the network node name, and ref=* optional for the routes (but should still match node number(s) if present). The result list in Planner should of course show node names if present. In Analysis, for nodes the Name column can be filled in. For routes, maybe use node1_name-node2_name for the ref column? The examples are in the proposal.

[Karthoo]

I would also propose to add support for the key lwn_name=, which could be used for more dense local networks.

[pelderson]

May I politely ask if/when this enhancement will be implemented? I still have the pilot site near Toulouse, but I'm getting complaints about the "phantom" tagging of non-existing ref and **n_ref numbers, and they are right!

If I can't give a perspective, I will have to end this pilot. The mappers in France, Germany and Switzerland then can still enter route data (Switzerland already has al the node2node routes mappen, I think), but they cannot use the full benefits of Knooppuntnet Analysis and Planner.

[vmarc]

Thanks for the reminder. I will move this issue back to the top of my todo list.

[pelderson]

I see a lot of commits, but I can't tell what the progress is! Can I help by testing something?

[vmarc]

@pelderson I have been making a lot of changes to the route analysis logic, and I am not yet finished with all the changes I wanted to do.

In order for you to be able to see some progress, I have just published the current state of the work-in-progress on experimental.knooppuntnet.nl (only look at the analysis, the planner will still be broken in certain areas at this moment).

As far as routes with nodes with names instead of numbers are concerned, you can look for example at the routes in Wanderwegenetz Oberkirch.

I am currently still working on getting a better result for routes where the node names do not match the route name like for example this route.

There is now a big difference in number of facts in the old de facts and the new de facts.

The new code also contains improvements for issue #126 (see route 75-75), issue #114 (see 04-04) and issue #109.

In the new code the fact RouteInvalidSortingOrder has been dropped. I am also considering dropping NodeMemberMissing (no longer encouraging to add each node to a network relation).

Fact RouteWithoutNodes is new.

A lot a facts on page NetworkExtraMemberRelation are caused by mixing lcn and rcn in network and route relations. I thought a moment about just allowing this (ignoring the scope 'l', 'r', etc), but that is not a good idea I guess?

I would like to get the route analysis completely sorted out before continuing with #147.

[Karthoo]

At the time of the last post I had noticed that network analysis already was included in the experimental version of knooppuntnet and it seemed to work pretty fine (great work!).

I used it for some network maintenance but unfortunately it has been removed again from the experimental site. Do you plan to include the feature again in near future so I can continue my maintenance?

[vmarc]

@Karthoo Later today (after some sanity checks), I will try to publish the current state of the development branch on experimental again.

[vmarc]

Implemented in experimental.knooppuntnet.nl (will come to knooppuntnet.nl in release v3.2).

Example with nodes mapped with lwn_name (11168701):

---

Example with nodes mapped with both rwn_ref and rwn_name (12012162):

---

Oberkirch:

[pelderson]

Question: in Oberkirch the routes have a name tag. Is there a check to see if the route's name tag matches the lwn_name tags of the nodes? Just asking, it's not a request!

[vmarc]

Yes, there is a check whether the route name matches the node names.

This is why there is a considerable number of routes where the analysis fails (generates various facts where a single RouteNodeNameMismatch would have been better), for example:

• 12893520 Über dem Kleingehren <--> Über den Kleingehren
• 12563835 Heschmattweg <--> Heschmattenweg

This needs to be improved I think...

[pelderson]

I think, since the route "name" is actually just taken from the node names anyway, it's in fact a check of the string copying skills of the mappers. That's why in the proposal I just said ref=mm-nn is no longer required, and not: add name=nodename1 - nodename2. I sort of recommended not to add a name tag in the pilots at all. I was surprised that the mappers actually insist on entering redundant name information! Question: if name and ref are not present in the route relation, is the route still valid en what do you present as the name?

[Karthoo]

Nice work! How often is the map data updated? I noticed that the nodes and routes on the map are not synched with the analysis and seem to be a few weeks or months old.

[vmarc]

@Karthoo I am glad you ask this question

The background tiles (containing all map details other than the nodes, routes and points of interest) are generated through a process which currently still requires a number of manual interventions and takes a couple of days to fully complete. I usually try to run this process about once per month. So, the details in the background will always be a bit outdated. The idea for the future is to automate this process so that the backgound is at most 1 week old, or to change to a different mechanism that can keep the background tiles more up-to-date.

But: the nodes, routes and points of interest that are shown on the analysis and planner maps are intended to be in sync with the information in the analysis. So when nothing else goes wrong you should normally see your changes in OpenStreetMap reflected in the maps after 3 to 10 minutes or so. However, a flag ("analyzerTileUpdateEnabled") has to be set in the server configuration for these tile updates to be done as part of the analysis.

This flag was set to "false" in the "experimental" server. This is why you did see outdated information. The reason for this was that until about 2 weeks ago the "experimental.knooppuntnet.nl" and "knooppuntnet.nl" servers both pointed to the same tiles, and the update had to be done from 1 of these servers only to avoid conflicts.

I have changed the server configuration, and as far as I can see the maps now seem up-to-date.

So, thanks again for asking this question. I would not have known about the problem otherwise.

[pyrog]

@vmarc

I thought a moment about just allowing this (ignoring the scope 'l', 'r', etc), but that is not a good idea I guess?

I think of simply ignoring the scope from the tags 😉 Use simply name (or ref) where it is appropriate .

In France hiking, mtb, riding (and probably snowshoe) use the same network. A guidepost don't have several names according to the local/regional/national network or hiking/riding/… network.

These two guideposts are distant of 0.8 km:

• Les Combettes
• Les tufs

So does knooppuntnet could display name or **n_name ?

[pelderson]

I support pyrog's request for using the name as a default if ..n_name is missing from the Node. This preserves the current use of ..n_name in situations where a particular node network does use different Nodes, or the same Nodes, but not all of them. With ..n_name you can then keep the networks separate, while you can simplify when the networks really use all the same nodes with the same names.

With ref, I would not recommend such a default. The Node refs are numbers or codes which (looking at existing networks and developments in various countries) tend to be different for networks of different types.

OTOH, I think analysis and map display have a problem if nodes have only name, not ..n_name. You don't know which scope or transport mode(s) the node is. That's part of the ..n_name or ..n_ref tag. You can say "the node is the same for all networks", but should the node appear on the map for inline skating or canooing? I think you somehow need to specify for which network(s) the node is valid.

[pelderson]

I support pyrog's request for using the name as a default ... All in all, I think it's an idea for a later release: multimode nodes, with the challenge: how to know which modes exactly, and which modes to exclude.

[pyrog]

With ref, I would not recommend such a default. The Node refs are numbers or codes which (looking at existing networks and developments in various countries) tend to be different for networks of different types.

In fact I don't recommend to support name or ref as default. I recommend to support also name and ref :smiley:

The order of selection could be:

1. display nxn_ref if available. If not display
2. rxn_ref
3. lxn_ref
4. and finally, simply display ref

Same with xxn_name and finally, simply name.

You can say "the node is the same for all networks", but should the node appear on the map for inline skating or canooing? I think you somehow need to specify for which network(s) the node is valid.

Or simply (like information=guidepost) use hiking=yes, riding=yes, snowshoe=yes… and so on ?

[pelderson]

The use of the network key and its values is approved. It gives geographical scopes and transport modes for all recreational routes and networks around the globe, and lots of applications use the system. So let's not go another way, for the moment. I suggest to first discuss this on a wiki page and/or forums, specify what exactly is proposed to get approval or consensus, then open another issue for multimode nodes in the Node Networks routing and navigating system.

[matthijskooijman]

This is probably the wrong place for this, but I suspect people here will be interested, so I'm posting this anyway. Through the swiss mailing list, I came across a proposal for "basic networks", which are similar to node networks but without (consistently) named or numbered nodes. I haven't read it properly yet, but at first glance this proposal seems to tag the ways (with or without relations) and not the nodes. The examples it lists suggest it could apply to routes that this issue also applies to.

https://wiki.openstreetmap.org/wiki/Proposed_feature/basic_network