Hello Sarah, Just a quick look at taginfo and you are informed. Hear me, I'm no specialist on the subject, but having given up reading the extensive documentation that is currently building up on the nodes network concept, I wonder how Joe mapper can handle it. From two extremes, I'd prefer a simple way to map. After all, it's not so hard to build a network from elements sharing a same set of tags automatically if the data consumer has a need for it. For rendering, the user eyes and brain is sufficient when reading a map. However this does not mean higher level concepts as routed or network should be excluded from the data when it fits. Regards, Yves
Le 4 septembre 2021 00:19:25 GMT+02:00, Sarah Hoffmann lonvia@denofr.de a écrit :
On Fri, Sep 03, 2021 at 11:12:14PM +0200, Yves wrote:
Why not just osmc:symbols=yellow_diamond on the ways? *=designated would be more for acces rights.
Because using anything but relations creates an exception that data users have to know about and handle.
Sarah
Yves
Le 3 septembre 2021 21:09:24 GMT+02:00, Raphael dafadllyn@gmail.com a écrit :
Hi Matthijs, hi everyone
It seems that a consensus hasn't been reached yet - at least not on this list.
The Swiss hiking network is a bit peculiar. It's not a typical node network as the intersections (or nodes) aren't numbered and very often are unnamed. On the other hand the hiking trails (not including the routes from SchweizMobil) aren't typical routes as they are unnamed, unnumbered, have countless possible starts and ends and often have multiple variants from one named place to the next.
In my opinion, the simplest way to map the Swiss hiking trails is by adding a tag to the corresponding paths (maybe trail=hiking or hiking=designated) and using route=hiking routes only for the "real" SchweizMobil routes.
Best regards
Raphael (dafadllyn)
On Mon, 23 Aug 2021 at 20:21, Matthijs Kooijman matthijs@stdin.nl wrote:
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_NetworksIf this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice:
- The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn).
- That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute).
- That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes).
- That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems.
- That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton.
- That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular:
- How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki?
- How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number.
- Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost.
- How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here?
- Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers.
- Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch