I think it makes sense to map preference routes as route relations, same as node2node routes within node networks. I am not a fan of network relations if they are just collections of elements, but if the information about how they are organised and used is also present and verifiable by survey (which is the case in the present example) it's not wrong and could be useful for maps, planners and routers. How to use the elements in a network can be tagged by a suitable value of network:type. Currently, network_type=node_network is used, the system is increasingly adopted for all recreational transport modes. If many cities use verifiable preferential route networks, a suitable value for network:type could be added, making the route relations and network relations a system reflecting actual use rather than just collections.
A network relation without the node2node or signpost2signpost relations makes no sense to me. The signposts and arrows denote actual routes, that is the basis of the system. Just adding lcn=yes to the ways loses the information about the routing/network system(s) they are part of. If that's fine, no problem. If people want to map the routes and maybe the network, I think it's OK too. We have the means. Fr gr Peter Elderson Op do 12 sep. 2019 om 12:01 schreef Volker Schmidt <vosc...@gmail.com>: > I see similarities of this approach with the hiking paths of the alpine > clubs, but with the important difference that the routes do not have a > reference. > And it's very similar to a node network, except that the nodes are not > numbered. > It's a 1:1 copy of the road network signposting (and please allow the > comment, has the same drawback in the sense that is not helpful to people > who are not familiar with the area and don't know the names of the places > and their relative positions) > > I fear the only sensible thing to do is to put the lcn and REF on each > way, but no relation, and map the signposts (even if there is no routing > software at the moment that makes use of this information, as far as I > know). > Not the best solution, but the signposting in this way does not work well > either for the end user (talking from experience). > > On Thu, 12 Sep 2019 at 11:21, Janko Mihelić <jan...@gmail.com> wrote: > >> I don't think this is good mapping. Firstly, this is not a route. A route >> is something that gets you from one place to another. This is a network of >> routes, and there is a tag for it, type=network[1] But this type of a >> relation breaks the "Relations are not Categories" rule [2]. That's why I >> think this network relation should be broken up into route relations with >> the appropriate network tag. >> >> If this is allowed, then what stops someone from making a "Bicycle routes >> in Germany" relation ? >> >> >> [1] - https://wiki.openstreetmap.org/wiki/Relation:network >> [2] - >> https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories >> >> čet, 12. ruj 2019. u 11:05 Martin Koppenhoefer <dieterdre...@gmail.com> >> napisao je: >> >>> >>> >>> sent from a phone >>> >>> > On 12. Sep 2019, at 10:49, Peter Elderson <pelder...@gmail.com> wrote: >>> > >>> > If there is agreement that this actually is something worth mapping, I >>> don't see a problem there. >>> >>> >>> this is how wikipedia works, in OpenStreetMap you do not need approval >>> of others that something is “worth” mapping, the osm question is whether >>> something is verifiable. >>> >>> >>> Cheers Martin >>> _______________________________________________ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >>> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
