I am volunteering to help map the Efeler Yolu long distance hiking route in Turkey (https://www.efeleryolu.com/). They have established a network of so-called “Efeler Yolu Friendly Establishments” in the villages that the route passes through that work as information and assistance points for hikers and hold the stamps that hikers can collect in a passport to prove they completed the route. It is not one single type of place: it can be a café, a restaurant, a small shop, a hotel/guesthouse, a private home in a remote place, etc.
I am wondering how to map such establishments.
To invent a new tag for it, something like Efeler_Yolu_Friend=yes
To group the nodes of the establishments into some kind of relation
Both
None: such things should not be on OSM
They are not likely to be of general interest so probably won’t be shown on general purpose apps, but the organisation behind Efeler Yolu might decide to develop their own app where this information is given based on OSM data. The data should be stored in OSM in a way so that it should be easy to develop such an app.
There was a discussion recently about the initiative to install “Happy to chat benches” in different countries and one result was that it could be helpful to use the key initiative=chat_bench for those benches. Maybe this approach could be helpful for your network as well by using
initiative=Efeler _Yolu_ Friendly_Establishments?
For those establishments offering a stamp service see
Thanks! I’ll add tourism=checkpoint + checkpoint=hiking + checkpoint:type=stamp + course=efeler_yolu That should enable them to stand out on a dedicated map of the hiking route.
In a similar situation, we added those checkpoints to the route relation with the stop role. Although Wiki suggests it should be used only on transport routes, I don’t see why it should not apply to hiking routes as well, particularly as no suitable alternative has been offered.
Re-using a tag/member role key for a different purpose just because it already exists is not a good idea. The stop member role has no established meaning for hiking route relations, so there is absolutely no benefit in using it over any other key.
I’d argue that it’s actively detrimental to use stop for this purpose. The use cases described here have nothing to do with stops. Using stop for multiple different kinds of points of interest related to the route makes the label even more useless.
If you want to add e.g. checkpoints to a route relations, why not simply call the member role checkpoint? (Or for the case here: find another appropriate key name, maybe something with information in the name since that’s what these are for)
And no other role for a point (other than guidepost) has been defined for hiking routes, so stop is as good as anything, until we get something established. Yeah, using checkpoint would probably be better in retrospect, but I tagged those, like, 5 years ago. I’m not even sure if iD supported non-standard role names back then.
No, there are lots in use - just have a look at taginfo, sort by member nodes and mentally subtract the bus stops! guidepost is indeed by far the most popular, but route_marker, start, marker, board, milestone, end and information all have 1000s of uses.
I can’t believe that this is a new concept - what does the Camino de Santiago do?
The Camino has so many branches and variations that I hesitate to generalise. But from what I have seen, the mapping focuses mainly on including ways in relations, with little attempt to include other elements/roles.
I did find one relatively short section with quite a few guidepost roles, which turned out to all have been added by … me.
information sounds like a good description of what these establishments mainly do (except holding the stamp, which can additionally be expressed by adding a checkpoint tag to each of them). It’s described here as “Information board, information stand about the route (and only the route)” so I suppose it can also include human-operated information points.
I’m planning to re-organise the route into a parent relation containing child relations for each day stage, and add another child relation containing the information points because these points are typically at the beginning&end of stages so don’t really belong to a particular stage (or to two stages at the same time, which would duplicate them). Is that a good idea?
route=hiking I suppose. If guideposts can be members of a relation together with ways, then why not have them (and information points) as the sole members of a hiking route relation that is a child of a hiking route relation?
I guess I would expect any route=hiking relation to represent a route that can be followed, regardless of whether it is a child relation. It may include other types of data that support hiking those ways, but removing the ways completely seems to me like stretching the definition of a hiking route relation to the point it’s something completely different.
If the issue is that one point belongs to two stages, couldn’t it simply be added to both stage relations? The point itself would not be duplicated. Many guideposts belong to multiple hiking route relations as they point along multiple routes. I don’t see that it matters if two of those relations are stages of the same route.
Neither the taginfo page nor this wiki page are particularly helpful in this case because they refer to type=route in general and the roles/members for recreational routes, public transport routes and road routes are mixed up in those sites. In reality there is not much overlap between those route types.
I’d go for a checkpoint role for the places where you’ve added tourism=checkpoint and leave it at that. Add them to the relation of the stages directly. And make sure to add only node members with this role or data users might do strange things with your hiking route.
