knooppuntnet icon indicating copy to clipboard operation
knooppuntnet copied to clipboard

Named Nodes and Routes not visible on map.

Open pelderson opened this issue 4 years ago • 10 comments

https://knooppuntnet.nl/nl/analysis/node/1280253436 Node Le Villard is shown and handled correctly. Just south of it is another node Le Villard, connected to each other with a node2node route relation. The second node and the route are not shown.

This has something to do with the tagging. The northern Le Villard still has the rwn_ref=0 tag, I removed this from the southern one, So the southern Le Villard has only lwn_name=Le Villard.

In the relation, I removed the name tag, changed the ref=0-0 tag to ref=Le Villard - Le Villard, and network-rwn to network=lwn.

Do I make mistakes here, or doesn't it work like we planned?

pelderson avatar Oct 07 '21 17:10 pelderson

Issue reproduced with Route Carrefour des Planches - Croix des Clos

Initially all objects have a ref

Object Tag
Node rwn_ref=Pl
Node rwn_ref=Cr
Route ref=Cr-Pl
  • Changeset 112347367 : I removed rwn_ref to the Nodes. Following facts were introduced 😞
    • RouteBroken
    • RouteRedundantNodes.
  • Changeset 112394751: I removed ref to the route. The facts where resolved 😃

So the route is not really broken, knooppuntnet should only report a warning

pyrog avatar Oct 12 '21 06:10 pyrog

@pyrog thanks for providing this additional example

I agree: the route should not have been considered broken.

The problem is now also reproduced in code: casestudy. This unittest looks at the situation of route 13305500 (see: overpass query).

Walking through the analysis logic using the debugger I can see the following:

  • the analysis finds "Cr-Pl" as the name of the route (the "ref" tag takes precedence over "name" tag)
  • the analysis likes the route name to match the start node and end node names, this means that it expects the start node to be called "Cr", and the end node "Pl"
  • the start node with name "Cr" is found in node 3781978722 which has "rwn_ref=Cr"
  • node 3781978722 also has "rwn_name=Croix des Clos", but "rwn_ref" has precedence over "rwn_name"
  • no end node with name "Pl" is found
  • the actual end node is 5159542364
  • node 5159542364 has "rwn_name=Carrefour des Planches", this does not match "Pl", the analysis considers node 5159542364 to be a "redundant node"
  • so overall, the result of the analysisr at this point is:
    • RouteRedundantNodes
    • RouteNotForward
    • RouteNotBackward
    • RouteNotContinious
    • RouteBroken

In changeset 112394751, both the "ref" and "name" tags are removed from the route relation.

  • the analyzer now no longer derives start- and endnode names from the route name
  • start and end nodes are now derived from the node definitions itself
  • analyzer happy: no facts anymore

The situation with route 12219285 is similar: based on the route name, the analyzer expects the end node 1280253436 to have the name "Le Villard", but if finds "rwn_ref=o". The tag "lwn_name=Le Villard" is ignored ("lwn" does not match "rwn").

Conclusion: the analysis logic should probably be changed to no longer try to derive the node names from the route name, but instead always directly look at the node definitions themselves instead. When the route name does not match the node names, at most a warning should be generated (or perhaps better no error/warning at all?). The logic to match the route name to node names should also be more relaxed: allow matches of route "ref" or "name" tags with node "_ref" or "_name" tags.

Until the analysis logic is changed (this make take a while, other changes have to be finished first), the knooppuntnet analyzer as-is will be happy when the route name matches the node names, taking into account:

  • "ref" takes precedence over "name" for route name
  • "_ref" takes precedence over "_name" for node name
  • cannot mix "rwn" and "lwn" nodes in route
  • cannot mix "rwn" and "lwn" nodes and/or routes in network

vmarc avatar Oct 16 '21 12:10 vmarc

Translated to tagging instructions, is this right?:

  • Use either ref/..._ref or name/..._name on the Routes and Nodes, not both at the same time
  • Use either lwn/lwn_... or rwn/rwn_... on all Routes and Nodes of one network, matching the network.

I am not sure what would happen if e.g. the start Node has rwn_ref and and the end Node has rwn_name, where the route has a. no name=, no ref=, no from= and no to=; b. Only a name tag, matching rwn_ref - rwn_name c. Only a ref tag, matching rwn_ref - rwn_name d. Only from=rwn_ref and to=rwn_name

If d. works, I would recommend that for tagging instruction when mixing Nodes with names and nodes with refs.

When I say "works", I think primarily of the planning tool. Analysis is important for maintenance, but the planning tool is critical for usability.

pelderson avatar Oct 16 '21 13:10 pelderson

Use either ref/..._ref or name/..._name on the Routes and Nodes, not both at the same time

Translation for humans: use either named or numbered nodes, never both 😅

Use either lwn/lwn_... or rwn/rwn_... on all Routes and Nodes of one network, matching the network.

For me *_ref or *_name should simply replaced by ref or `name' according to the KISS principle. Currently JOSM… couldn't display the name/ref of the node or relation.

I got a lot of 'facts' simply because I forgot to rename name to appropriate *n_name.

Also, at least in France, route could be used by hikers, but MTBikers, riders… So how to tag these nodes?

  • lcn_name=Golf
  • lwn_name=Golf
  • lrn_name=Golf

or simply name=Golf ?

I suggest to support actual *_ tags for countries likes Netherlands, Belgium… but also "standards' tags like ref or name too.

pyrog avatar Oct 16 '21 14:10 pyrog

Translation for humans: use either named or numbered nodes, never both

I don't think that is right!

  1. ..n_ref can contain codes or mnemonics, not necessarily numbers.
  2. the point is that you can use both named and numbered nodes, just not both tags on the same node.

pelderson avatar Oct 16 '21 14:10 pelderson

..n_ref can contain codes or mnemonics, not necessarily numbers.

You're right (for me numbered is a synonym of mnemonic)

the point is that you can use both named and numbered nodes, just not both tags on the same node.

Is it an exception or the rule in some countries?

I think that in France we should use names only (except in north where cycling or hiking networks are connected to belgian networks)

pyrog avatar Oct 16 '21 16:10 pyrog

Closing this issue. See https://github.com/vmarc/knooppuntnet/issues/217#issuecomment-2172873627.

vmarc avatar Jun 17 '24 09:06 vmarc

More than 99% of the nodes in the world have only one ref or name.

@pelderson and @vmarc Please, could we tag them only with name ? …and for the "few" exceptions could we continue to use legacy tags like lwn_name and lcn_name ?

See https://github.com/vmarc/knooppuntnet/issues/217#issuecomment-2173047532.

pyrog avatar Jun 17 '24 11:06 pyrog

Look again at this issue within the scope of the knooppuntnet re-design.

vmarc avatar Jun 17 '24 11:06 vmarc

The name tag is for actual names. The guidepost actually has a name. The connection node does not. We assign it a "name" only for the node network. Therefore name is the wrong key here. The same goes for ref, although most people are less touchy about ref.

pelderson avatar Jun 17 '24 12:06 pelderson