We have considered node_network=yes. But other network configurations are already present. We now map two network setups, but the default one (chained ways) is by no means uniform, and we have already seen colour choice networks. So all emerging network configurations would need a separate key.
So it's more generic and future proof to use one key with values for different network setups. For now we only want to distinguish node_network from the rest, to free up rXn in Nederland, Belgium and Germany for the intended use. So we propose one value, but we want to facilitate the option for more network setups. We've used network_type because it's an existing key. Very very low usage, though. (network:type is used in one smaller network in Nederland, for a pilot, so that is not regular usage. To be removed if another solution is chosen. Still, network:type usage is higher than network_type) Maybe the key should be network_setup=* or network_configuration=* ? Or the namespaced variants, network:setup=* or network:config=* ? For renderers and other data users the string does not matter very much as long as it's uniquely defined. They need to know for a particular route what setup it's part of, preferably by an attribute of the route itself. A renderer then can decide how to render different network configurations. A node network planner needs to find the node network routes connected to a particular node. The safest way to know which routes to use and which not to use, is by looking at an attribute of the routes. A node network router also needs to distinguish exactly which ways to use, so has the same need. Fr gr Peter Elderson Op do 5 sep. 2019 om 07:00 schreef Warin <61sundow...@gmail.com>: > > On 5/9/19 2:42 am, Richard Fairhurst wrote: > > Peter Elderson wrote: > > The network values identify transport mode and scope of routes, and > these "dimensions" also apply to node networks. We do not want to > add another dimension (configuration type) to the network=* > values of routes. > > Instead, we are thnking about just adding a tag to identify segment > routes as parts of a node network. The nodes themselves do not need > this, since they ARE nodes and have a xxn_ref tag. > > In short, we are thinking to simply add the tag network_type= > node_network (or network:type=node_network) to the node2node > network routes. > > I have a strong interest in this proposal. :) [1] > > If I understand you rightly, a route > likehttps://www.openstreetmap.org/relation/1844941 would get an extra > network_type=node_network tag. Nothing else would change. (Correct me if I'm > wrong.) > > You say "we don't want to add another dimension" but you are effectively > doing that; you're just doing it by adding a new tag rather than adding a > value. That's not _necessarily_ a problem but it would be better done in an > extensible way that might be useful for other tagging scenarios, rather than > special-casing this one scenario. > > We currently have the "network=ncn|rcn|lcn" tag which broadly identifies the > _importance_ of the route. > > What we do not have is a tag to identify the _character_ and _purpose_ of > the route. All bicycle routes (except MTB) get lumped together as a generic > route=bicycle. This is increasingly a problem as routes are devised and > signposted for performance cycling, bikepacking, and so on. For example, > there are two new performance cycling routes in Wales which I'd like to map > (https://www.visitsnowdonia.info/ffordd-brailsford-way), but which would be > misleading if tagged in the same way as other NCN/RCN/LCN routes in Britain. > > You're proposing a tag called "network_type", but it's a tag for the route, > and what you're using it to describe is the character and purpose of the > route. (The network is already mapped in the network super-relation.) > > So I'd suggest that instead of network_type=, you add route_type= . > > > 'Type' does not add information. If the key is only to have one value .. why > not use the proposed value as the key? > > node_network=yes/no ? > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
