I’ve arrived in New Zealand last year and I’ve noticed that there’s been an amazing job done on the OSM ways that are linked to a path (foot or hiking), where each individual way has been correctly tagged (with the accurate name and other tags). Nevertheless most of them (take Waitakere Ranges for instance) are lacking a relation to link each of those individual ways together and make a hiking route.
Let’s take those 2 different examples:
1 - Omanawanui Track
are 2 ways related to Omanawanui Track, but not part of a relation that would be named Omanawanui Track and that would gather those 2 paths + all the other ones.
2 - Gibbons Track
This way covers the entire hike
In other words, I’d like to know what’s best practice for paths in NZ?
In my opinion:
For 1 - Omanawanui Track, a relation should be added to gather all ways related to this track.
For 2 - Gibbons Track, a relation should be added and gathers this unique way.
This relation is a good example:
relation/6964826
it gathers multiple ways (path and steps) into a single relation that covers the entire hike. Most of the ways have been tagged with the name of the hike, but not the steps - but what’s important at the end is to have the relation.
Hi, The three sections of track you mention above and several more named tracks/trails are gathered in a hiking route relation. Namely the Hillary Trail, relation number 371816, https://openstreetmap.org/relation/371816. It can be best visualized, along with all the other worldwide route relations here:- Waymarked Trails - Hiking
I suppose a route relation could be made separately for the Omanawanui Track. But then, if this is done what about all the other named tracks/trails? If they are all made into individual route relations then the Hillary Trail relation I think should be made a Super Relation of all the individual relations. A Super Relation is described here:- Super-relation - OpenStreetMap Wiki
here in France, a small group of contributors (the OSM Plein Air group) is slowly working its way through the complexity of our hiking network. Here are a few lessons that may or may not be transposable to other parts of the world:
apparently, giving ways the name of a route was at some point an acceptable technique for mapping routes: we find lots of ways tagged with “name=GR 9” or similar, for instance. The same technique is still documented for ski pistes. Unfortunately, this leads to conflicts between hiking routes using the same ways, between routes for different activities (hiking vs biking vs riding vs…), and even more notably with the “proper name” of ways (e.g. “chemin de la chapelle Saint Jean”). Therefore we tend to remove route names from the tags of ways.
the “superroute” tag does not appear to have any useful significance, compared to just nesting route relations. It is not uncommon here to have 3 of even 4 levels of nesting, what with European hiking routes, national segments, local routes, etc.
applications and renderers tend to have inconsistent behaviours when rendering nested hiking relations. Some render both the name and symbol of the parent and children relations, some (like Waymarkedtrails) have a published set of rules for choosing what is rendered, etc.
we find that the experimental Monitoring feature of knooppuntnet.nl is very useful for maintaining long routes, but unfortunately its management of nested relations is still incomplete.
Some of us are convinced that more standardisation and documentation is necessary if we are to improve the management of long routes.
It does show up (at least in the editor that I normally use for relations) and prompts me to add any missing way segments to the local route, not the superroute. That also makes it easier to do QA - I know that generally speaking superroutes should not appear in a rendering database, and if they start appearing, someone has made a mistake.
For the sake of clarity of our exchanges, do you use “superroute” as a general term for route relations that contain other route relations, or as a specific term for relations that have the superroute tag? I’ve seen both uses of the word
With regard to “showing up in the editor”, it’s the latter. Generally, however, it’s the former (and sometimes these just have “type=route” rather than “type=superroute”, perhaps in error). However as @StC says it can be complicated - there are sometimes multiple levels of routes especially when (as in Europe) there are local signed routes that are part of national signed routes that are in turn part of international ones.
See also the wiki here for advice about creating them. I disagree with this page where it says “Nested relations are virtually undocumented and rarely used”. Whoever wrote that has clearly never looked at OSM data in detail!
This was my point in my original post: having the tag seems of little benefit for those who do not use Potlatch
On a more general note, it is probable that NZ won’t need all the bells and whistles but:
I advise to look into knooppuntnet.nl. It brings QA analysis to non GIS wizards (e.g. a route operator from a local authority or from a hiking community), and in France we put most of our hopes in it to engage route operators into OSM data maintenance.
I’m using this thread as an opportunity to discuss improvements of the wiki, including more precise description of how nested routes should be understood and rendered.
Coverage seems limited to a few western European countries? The website’s pretty impenetrable too. This page suggests it’s for node networks only, which isn’t really relevant here.
Coverage did not include France originally, but the maintainer of Knooppuntnet was very responsive in adding it. Same when we asked to add French overseas islands located in various oceans very far from mainland Europe.
And yes, Knooppuntnet was originally dedicated to node networks. But its Monitoring function is aimed at long distance routes.
Actually, there are more and more links between node networks and linear routes, at least in France, because long distance routes are now implemented “on top” of node networks in various regions (long distance symbols are displayed on network signs, and only there, which helps local route maintainers to minimize efforts when modifying ways).
This really entirely depends on how hiking trails have developed in a country. For instance the idea that Rights of Way (or even Sustrans National Cycle Network) in the UK make up a co-ordinated interlinked network is just not true.
Even where they have been tagged in Switzerland I’ve not been convinced that the points so tagged have that purpose even though they do seem to fit, but I haven’t read the manual (yet).
Not sure if you’re talking about node networks or about long distance routes here. As I said, Knooppuntnet has a new fonction that is not related to node networks. It’s pure QA for long distance hiking routes, and therefore might be relevant for NZ.
Not sure either how this relates to Rights of Way. I’d guess we can surmise that published hiking routes mean that rights have been established or negotiated with land owners?
Yes, but access may, and does change: stroppy landowners, paths falling into the sea. Also some trails involve long road sections where access hasn’t been established.
Indeed. Here we found that route operators spend a fair amount of time maintaining routes and signs (when rights change, when bridges fall, etc). That is why we are approaching them to propose collaborations, using OSM and tools like knooppuntnet.nl to help them maintain their data. This is early stage, but promising.
In one mode it tells us visually if the route has discontinuities or not, lists all the resulting segments, and provides shortcuts to edit them.
In the other mode it displays and lists differences with a reference line that has been provided earlier, either as GPX (for comparing with source-provided references) or as a snapshot of the relation itself (for detecting changes in OSM).
In the page where all the relations we chose to monitor are grouped, these two analyses are summarized and a smiley indicates that a route is still routable and unchanged.
There are various things that can be elaborated in this experimental version, but it has changed how we communicate with route operators. It has also changed our ability to monitor thousands of kilometers of routes.
Just heard that JOSM too has a bonus reserved for users of the “superroute” tag: the relation editor performs continuity checks between subrelations only when the “superroute” tag is present in the parent relation.
First of all thank to all of you who are jumping on this topic! I was guessing it was not going to be an easy answer.
I was planning to rely on the official DOC (Department of Conservation - Walking and tramping: things to do) website to define those “hiking” relation in OSM. I also assumed that most of the existing “hiking/foot” ways currently set in NZ OSM were based on this database since they’re, for most of them (90% or more) matching the exact same description/name/route.
My main concern was that the “relation” (that connects all these ways) were missing, while some Super Relation were already defined, such as “Hillary Trail”.
So I would agree that the ways should not need, in my opinion, to carry the name of the route (there are just a bunch of nodes connected together) while more work should be done on the “relation” (hiking route) themselves.
I’d like to understand, how/who would take that kind of decision, since I’m willing to improve the routing in NZ while living around. As proposed in some comments as well, I could try to get DOC involved (if not already) such that we would make sure those are up-to-date. I just have the feeling that they already have their own database (unless I’m wrong) and that it might not be as easy as it looks.
Anyway, just a short message to thank you all, and to hopefully continue the discussion to harmonise as much as possible OSM data handling worldwide.
Let me focus on the “how”, because I guess “who” is “you, as soon as you understand how”:
what I find to be the main rule is “what do we map?” Our understanding of that here is “what is observable on the ground and/or officially documented”. We interpret that as "trailblazed and/or operated by a public body or an organization endorsed by a local authority. The “operator” tag reflects the latter criterion.
here in France we need to take into account the local jurisprudence that says that route geometry is protected by copyright law. So we must obtain authorization to reproduce it (even if we do it from local observations). Your mileage may vary regarding that. For instance we are lucky enough that French law states that public bodies do not fully benefit from copyright law.
be aware that according to local law map makers may carry a legal responsibility about what happens to hikers. Ensure that your data source is up to date, and think about how updates will be made. That is why we engage local authorities about their role in updating the database. You might find the source tag to be important (and also tools like Knooppuntnet, I won’t come back to this)
the network tag is important. Here we are lucky enough that the French Hiking Federation has defined a similar scale (routes of local/regional/national interest)
maintaining continuity and relation order is a major pain, but it’s needed by applications. Relations often get broken (when splitting ways, when using tools that do not preserve relation order, etc) You may find that 1) splitting routes into subroutes helps, 2) the JOSM relation editor is your friend here.
it’s better if subrelations match “official” route splitting (e.g. starting at places where you can find accomodation) but this is often not possible.
finding names, refs, and managing osmc:symbol, for subrelations is a major pain too because each tool has its own idea what they mean and how they should be used when rendering or editing. I dream of gathering app developers to define common semantic rules that we can use as guidelines when mapping.
oh, also be aware that the management of hiking routes is a complex business made of equal parts of infrastructure management and tourism management. You may find that some route operators are deeply entrenched in their opinions on how their place in the tourism business is maintained (e.g. they sell maps and/or have partnerships with publishers). Finding how to engage them is a tricky challenge, sometimes.
I was planning to rely on the official DOC (Department of Conservation - Walking and tramping: things to do) website to define those “hiking” relation in OSM.
ultimately it is the current situation on the ground that is most relevant for OpenStreetMap , trails that are found in official data but not marked on the ground may not be added for instance. Did you check this data against the real situation to confirm it is good?
