Proposal talk:Trailhead
Revival to gain approval
Tag:highway=trailhead has been promoted to "de facto", based in actual usage. I am preparing a vote on this proposal, to reach "approved" status. I have retrofitted the proposal to match the tagging page. Links to the discussions on mailing list and forum have been added (thanks!), and I copied the examples, the onNode and onArea indications, and the wording to accommodate the use of the tag on an area. Some mappers argue that "de facto" is even better than "approved", and maybe that's true, but taginfo usage plus "approved" is equally strong, I think. --Peter Elderson (talk) 10:50, 24 February 2023 (UTC)
Clarification needed
I checked only 2 Top's in Limburg, and neither is added to a hiking/cycling route. So your proposal is just: "here is a good place to start something". I think that this is a good idea not to pollute to routes. In your proposal I would add car parking space/fee.
Personally, I am thinking about linking a site-relation to a route. Then it would possible to gather start points/parking/public transport/cafe/etc/attractions and link it to the 'pure' hiking/cycling/horse route. So this would include your TOP and mode. Until now I did not find a way to make a site-relation a child of a route-relation. Anybody knows about it? --Waldhans (talk) 23:46, 21 December 2018 (UTC)
I agree TOP nodes should not be added to the route relations. You would have to add them to a bunch of relations for different mode routes which all make use of the TOP for facilities, making them error-prone and hard to maintain. I would like to keep basic tagging as simple as possible, so any mapper can just tag what's on the ground, without worrying about complex things like site and route relations. For now. Complexities and refinements can be added later.--Peter Elderson (talk) 00:11, 22 December 2018 (UTC)
Proposal Rework
Its been almost two years since this proposal was submitted by geobrando. I agree that a formal trailhead designation is definitely needed in OSM, however the proposal could still use some work. I have read through people's comments on this talk page and in the mailing list, and have made the appropriate changes to the proposal. See details below: Amykyta3 (talk) 05:55, 26 January 2017 (UTC)
Clarified "Proposal" section
Moved definition of trailhead here since it did not belong in "rationale" section. I removed the statement about trailheads being able to be inferred by OSM from any intersection of a path & non-path. I don't think it would be appropriate for OSM to infer this since trailheads have some pretty distinct features. I have incorporated other peoples feedback to hopefully make a more precise description.
Any additional suggestions? Amykyta3 (talk) 05:55, 26 January 2017 (UTC)
"Rationale" to actually give rationale
The rationale section should answer the question "How will OSM and its users benefit from this tag?"
Reworked to drive more towards that answer. Amykyta3 (talk) 05:55, 26 January 2017 (UTC)
Only applies to Point
Based on feedback, highway=trailhead doesn't make sense for any other elements except for "Node" and maybe "Area". (See Trailhead Area discussion below)
Removed all except "Node" for now. Amykyta3 (talk) 05:55, 26 January 2017 (UTC)
Additional comment: use case The Netherlands.
--Peter Elderson (talk) 16:10, 12 May 2018 (UTC) In the Netherlands we have official trailheads, they are called TOPs. And lots of unofficial places giving access to trails, mostly roundtrips but other routes as well. This proposal fits those nicely. The node could be on the route or separate, as far as rendering is concerned. We would need hiking=yes, cycling=yes, riding=yes tags with that, because many of the hop-on points are for different modalities. Canooing... distance marked marathon running trails... MTB-trails... For the other modalities we can find suitable icons, I'm sure. Hope this helps.
--Peter Elderson (talk) 07:20, 20 October 2018 (UTC) Additional: More trailheads have popped up since I wrote the above comment. They are mostly areas designed as trailhead voor all kinds of trails, for which there are separate guideposts and information boards and the like. On other locations specific simple trailheads for one modality exists, usually with limited parking space and one guidepost at a sort of gate or entrance. I'll start mapping the larger ones as highway=trailhead areas separate from any trail, because I see no reason to put them in all the route relations starting near or passing by the area. The smaller ones will be nodes, and if there are only one or two routes starting on the same point which is actually marked or designed as a trailhead, I'll tag the starting node highway=trailhead. This way I think some 200-300 trailheads will be tagged in Nederland.
--Peter Elderson (talk) 08:52, 21 December 2018 (UTC) All "TOPs" and "Nature Gates" in Nederland are now trailheads. They are all multimodal: at least for bicycle riding and hiking. Most of these also give access to one or more of the following: canoo trail, yaughting, horse trail, running trail, skeeler trail, walking node network, cycling node network, ... They all have in common that there is a stele or pole marking the place, seats or benches and an information board including a map, and free parking space nearby. Some are small, some are big if you count all the amenities including Horeca, toilets etc. We have made the choice to map only the marking pole/stele as highway=trailhead, name=<official name on the board>, tourism=information, information=board or map, and optionally add other amenities and objects separately to the map. A few areas have additionally been marked as small pedestrian areas (circles) around the pole/stele. Previous mappers had done that to make the name show up, and we saw no compelling reason to change it. Currently, the trailheads show up on Carto as a board with a name, because of the information=board tag. The position of the board always is within 5 m of the pole/stele, which fits the 5m guideline for marking a feature as a node. In other words, we see the pole + seats + board as one node feature.
A few pre-existing tryouts are still present. Some of the trailhead nodes are also included in a route relation, with role=start. Some are also walking nodes and/or cycling nodes. At one point, a site relation exists, combining all the objects and amenities of the trailhead. This may become useful in the future, e.g. if the operators adopt OSM as a data source for maintenance or publication.
We are still looking for a suitable symbol for display on waymarkedtrails.org, on the maps indicated by the modality tags. The generic hiker does not fit, because of the multimodality. We were thinking of some sort of gatelike symbol, or an adaptation of a signpost with many hands. The icon for an information board used by standard Carto is not bad actually, because it shows as a sort of gate or start banner: e.g. https://www.openstreetmap.org/search?query=top%20reeuwijk#map=19/52.05767/4.73925 Maybe simply use that and add some arrows on the board?
Relation option
I added an image and (re?)added the option for this tag to apply to a relation. The rationale for this is that at least in my area, a trailhead is often understood to be the entirety of amenities that is found at the start of a trail or group of trails, including for example toilets, informational signs, parking. An advanced mapper could group these as a relation. with the individual amenity nodes / ways being members.
Route role
Would be great if the proposal could add the trailhead as a role in routes, just like guideposts. As trailheads are more than just a guidepost I think the distinction is justified. The description should make clear that a starting/ending guidepost is not sufficient to apply the role trailhead. --Trapicki (talk) 18:19, 15 May 2023 (UTC)
Open Questions
Trailhead Area
Previous discussions in the mailing list mentioned that it may make sense to be able to support trailhead as an area element. Even and splitting into a leisure=trailhead area that is related to an entrance=trailhead.
Thoughts? Amykyta3 (talk) 05:55, 26 January 2017 (UTC)
- In some cases where the trailhead is a significant region, I guess I can see the argument where it may be appropriate to define an area of leisure=trailhead (Mt Fuji 5th stations?) However I haven't seen too many cases for this. Either way it would probably have to be a separate proposal.
- Some in the mailing lists have suggested using entrance=trailhead. On paper it looks OK, but I disagree. entrance=trailhead would be severely out of place with existing entrance=* tags as they all tend to describe access points to an enclosed man-made structure. IMO, highway=trailhead continues to fit better since highway=* Node tags all describe specific features of a transportation way. Amykyta3 (talk) 05:55, 26 January 2017 (UTC)
- I have added the option of defining a trailhead as a relation back in the proposal, see the rationale there. That option would give the option of defining the boundary as part of that relation. To me this mostly makes sense if there is for example a fence defining the trailhead area, or if it is a well-defined clearing in a forest for example, but others may see other uses for it. Martijn van Exel (talk) 15:50, 13 June 2019 (UTC)
This proposal seems to have been accepted by the community. A quick check on [overpass-turbo](http://overpass-turbo.eu/s/lI5) shows 665 nodes in the US alone. Let's move this from proposed to accepted. Glassman --Glassman (talk) 23:55, 4 February 2017 (UTC)
Name Tag
Please note that the name=* tag should be used when the trailhead's name may not be clear or when a trailhead name that is very different from the name of the trail itself. Some trailheads have multiple trails at stemming from one trailhead. If a trail is long enough it may have multiple trailheads with different names along the route, and name=* could help to distinguish those trailheads.
A name should NOT be required because there may be no name for the trailhead or it may be obvious based on the trail's name. So, "Green Trail" may have the "Green Trailhead". Pretty obvious, so the name=* is not needed. -- Micahcochran (talk) 18:15, 9 May 2017 (UTC)
- In most cases a name is perhaps unnecessary but it wouldn't hurt to include it in the proposal as an optional tag so that a search result for trailheads would also return the name of the trail. Also, some trails might have a trailhead at both ends that are named slightly differently to differentiate them in trail guides or brochures. AlaskaDave (talk) 00:25, 22 December 2018 (UTC)
Archive
Discussion from original 2015 RFC
Can we see some use cases as a node, way, area, and relation?
I don't like this proposal. It is unclear what a trailhead is. It implies it should be on every trail and I am not sure it should be. Surely the first and last nodes of the ways are trailhead by default. They start and end trails. I dislike having another highway tag too. --Rovastar (talk) 04:39, 13 April 2015 (UTC)
I'd like to see it as single nodes which would be used to render the beginning of trail systems at a small scale, it wouldn't be at every intersection or fork. On a trail specific render they should be tagged in ways to tell users what sort of trail system they're getting onto, who is responsible for it, a name. The tags should allow for searching for trail systems, possibly by activity? By having these features you could view a map at a small scale and see where you could start hiking in that area. It should be connected to a path, but the trailhead may be mapped before the trails are in OSM.--Timdine (talk) 13:46, 16 April 2015 (UTC)
Not every trail has a trailhead. Typically trailheads are found in remote areas but can occur in urban areas. Trailheads can just be places to access a trail somewhere along the way. They are usually found on a road or track. Saying a the first and last node is a trailhead by default isn't correct since the last node of a trail can be a connection to another named trail. What's nice about tagging trailheads is you can search for places to start your hike. You can also search for other trailheads on the same trail. For example, if a trail leads to a viewpoint on top of a mountain, there could be another trailhead further up the road for a shorter hike. Glassman (talk) 15:03, 21 April 2015 (UTC)
I like the idea of tagging a lot of information about the trailhead in a node. However, over time, mappers will want to add features of this node as diferent nodes. For example, the exact location of the toilets, the drinking water, the parking as an area. Some thought should go into how to deal with these more complicated situations. Should the trailhead in this case become a relation, containing these extras? Or is the trailhaed and the other extras all part of a route relation? Will your visualizing still work? Will your data still be exchangeable between OSM and the external dataset. Reminds me a lot of the new campsite proposal and a possible relation with the iOverlander database. --Joost schouppe (talk) 13:42, 26 April 2015 (UTC)
Tagging for trailheads is definitely needed. A trailhead is not the same as the junction between a road and a trail. There are trailheads that are not connected to a trail, and there are junctions between roads and trails that are not trailheads. highway=trailhead seems somewhat odd, I would have gone with amenity=trailhead, but I wouldnt disagree with highway=trailhead since it's already being used. --JesseCrocker (talk) 13:50, 7 June 2015 (UTC)
- After reading the current definition ("the point or place at which one can access a trail") and visiting the Observable trailheads link, I'm still confused. From comments, I reckon that a trailhead is not generally the starting/end point of a trail, nor it is a any connection point to a road or another trail. Otherwise, what characterizes a trailhead it still unclear to me, probably just because the concept of trailhead is not common in the areas I'm familiar with. Nevertheless, I think that we need a more elaborate definition of trailhead. --Kaitu (talk) 07:29, 18 September 2015 (UTC)
This proposal is sorely overdue and needs to be accelerated. Today there is no way to search for trails using off-line GPS! Look at trail guides sites such as alltrails: every trail begins with a starting point (trailhead), usually same as parking lot. The main use case is the ability to search for decent hiking/biking trails. OsmAnd (on Android) can only search for points, not ways. overpass-turbo.eu allows search for ways: users would have to do 3 searches: highway=footway, highway=cycleway, highway=path, and may be highway=track -- this is not a user-friendly approach, plus that requires internet access while on a trail. Next use case: as a mapper, if I am putting down that this is a trailhead, I am making a point trying to direct hikers/bikers there. Multiple trail user types should be considered: hikers, wheelchair-bound, cyclists, horse-rides, cross-country skiers, snowmobilers, motorcyclists, off-road 4x4 cars. Another variation of trailhead: if it is a long long trail with many access points, should all of those be also marked as trailheads or as something else? I think even 2 trailheads for a back-and-forth trail sounds like too many. Lastly, it is probably too late to start talking about highway=trailhead vs amenity=trailhead -- https://wiki.openstreetmap.org/wiki/US_National_Park_Service_Tagging already uses highway=trailhead, I have seen many and added many instances of that on the map.--G264020 (talk) 22:11, 17 September 2015 (CST)
Amendment of the revival proposal
It's easier for me to comment here than in the tagging list, so this is where I put my comment on the revival of this proposal.
I would be in favour of relaxing the definition of a trailhead in that they don't have to be official, whatever that means. Any place where you arrive by non-recreational transport and switch to a recreational transport mode (park your car and start riding your trail bike, get off a local train and start hiking, etc) would fit in my opinion. Øukasz (talk) 04:59, 30 December 2018 (UTC)