Talk:Relation:route

Examples

Are there already any in OSM? --Keichwa 05:51, 13 October 2007 (BST)

• not yet, but I thought I might do a few round Cambridge soon to illustrate. Tricky without renderer support though. David.earl 17:21, 18 October 2007 (BST)

• NCN route 4 (a UK cycle route) is a simple first attempt at a simple route relation. (it's not actually the whole route, but a significant chunk of it). If you want to see it in all it's glory you can download the full data (90kB osm file) and load into JOSM.

Hiking routes

I'd like to start tagging hiking routes in Germany. I guess, I am allowed to reuse existing way nodes? Yes, I am aware that that's a bit dangerous because people like to move around existing nodes. --Keichwa 05:51, 13 October 2007 (BST)

• Only to correct things presumably though. Are these hiking routes things that would be signposted on the ground or described in a guidebook as coherent routes? David.earl 17:21, 18 October 2007 (BST)

Yes, they are signposted on the ground (on trees, walls, streets, etc.).--Keichwa 06:24, 21 October 2007 (BST)

Proposed_features/hiking_trail_relation_roles--Mfbehrens99 (talk) 09:02, 17 December 2019 (UTC)

forward/backward_stop_<number>

Can someone flesh out the details for this please, how is forward/backward determined?

If the stops are on opposite sides of the same road, but not directly opposite, say 50m apart, would this be appropriate?

How should <number> be determined?

--Edgemaster 18:59, 22 October 2007 (BST)

I'm not that sure whether this numbering idea will work at all. Often more than one bus line stops at a bus stop.

I use nodes besides the way ('===') as bus stops('o'):

        o xyz stop
=====================
              o xyz stop

For clarity we could connect the stop with service ways ('/' and '\') with the street ('==='); nodes in the street: '*'.

        o xyz stop
       / \
======*===*=*===*====
             \ /
              o xyz stop

--Keichwa 02:33, 27 November 2007 (UTC)

Numbered Members a Bad Idea

I think using a sequence number in the role code is not a good idea as it will make it difficult to insert new members (ok, an automatic editor could help), and also create a possible source of inconsistencies. Would it not be sufficient to mark the start node, and everything else can be deducted from there by looking at the ways? --Frederik Ramm 19:00, 22 October 2007 (BST)

I don't think numbered stops are a good idea either. There are too many public transport routes that won't fit into this scheme. --Andy 20:42, 31 October 2007 (UTC)

Bus and tram stops don't have numbers here (they have names though), so a generic "stop" member would seem much more logical. --Eimai 00:16, 21 December 2007 (UTC)

If we use a generic stop member, does this always refer (ie. the 'ref=' value) to a node? --Mungewell 22:45, 5 June 2008 (UTC)

I also think that sequence numbers should be removed. I understand that it might not be possible to get stops order without sequence numbers (and even knowing start/end stop might not be sufficient). Anyway I don't think osm should care about stops order.The only application where stops order is necessary is route planing application which include traveling by public transport. This kind of application needs to know timetables which also include order of stops so it's not necessary to include this information in osm. --Jttt 08:54, 5 June 2008 (UTC)

The root question here is whether numbering is necessary, or what purpose might it be used for; I think that the ability place a marker on a relation route is an important one, this could for example by a reference to a text write up in a guide book for a walking tour - "(2) Joe Bloggs born here 1242".

Whether the reference has to be numeric, or whether it has to be sequential is really irrelevant. People who enter Relation/Routes will know how to process them. I also think that it would be perfectly valid to have a 'stop' without a reference, there is no reason that they must be numbered they could just be some symbol/colour/blob/etc on the rendering of the route (if it is ever rendered graphically).

So simply put, use 'Stop_2' if you want or 'Stop' if you don't... --Mungewell 22:45, 5 June 2008 (UTC)

The other question to ask is whether a route has to contain any ways, or whether the nodes which are 'stops' have to be on ways in the Relation/Route. Going back to the guide book example the stops within a relation could be used to place markers (and not ways) on a map. --Mungewell 22:45, 5 June 2008 (UTC)

The nodes that make up bus stops should not be part the ways that make up the route. The ways should be roads. Having a bus stop part of that way means the bus stop is in the middle of the road. Map the stop as a node to the appropriate side of the way.

I still prefer the bus stop nodes to be part of the way. Reason: the stop is part of the street (usually some yellow marking), as well as the sidewalk beside it (timetable, bench, shelter). Both of which are part of the way. The direction of the bus stops could/should be marked with a little arrow for the service direction. If the bus stops for both directions are at exactly the same location, only one is needed for both directions anyway. Numbering becomes obsolete with that solution too, since the order of the stops should be obvious by following the ways which are part of the bus route (needs propper tagging and completely applied directions). I don't even see a reason why stops should be marked with "stop", since way members are the way of the route, and nodes obviously the stops.

Or otherwise: if the busstop is not part of the way, then railway=halt/station should even less be, as the platform is NOT even part of the railway line! RalpH himself 21:05, 16 March 2009 (UTC)

A sidewalk can and eventually will be a separate way - road/lane/median/whatever widths vary too much for a tagging scheme to be more flexible than separate ways (it could take years even in the most thoroughly mapped areas but I and several others are already doing it). Standing on the sidewalk under the shelter I'd say "I'm now at a bus stop" and if I were to walk to the highway center line (low traffic, hopefully) I wouldn't say "I'm at a bus stop" anymore, but "on the road near the bus stop". Alv 09:32, 17 March 2009 (UTC)

I agree that stop_<number> is a bad idea. In Dublin, Ireland, bus stops aren't numbered. I'm sure the bus company (Dublin Bus) has them numbered but there's no easy way for mappers to find that out. I also think it's confusing to have to keep track of all these numbers and it will make it hard to add or remove bus stops. Things like bus stops on different sides of the road complicate matters aswell. I'm mapping bus stops as nodes with highway=bus_stop then marking them with the role 'stop' in the relation. Rorym 16:40, 18 June 2008 (UTC)

add a start node and everything else works

I agree that with a start node associated with a node at one end of the route then the order is Ways should be completely clear and other ordering of other features (both Ways and stops) is not required. User:PeterIto 10am 26Oct07

Rendering support for UK National Cycle Network Map

See the ML post [1]

I've added some rudementary rendering to Osmarender, needs to be enabled with showRelationRoutes='yes' in the features file (level 17 only so far). Example image here: http://wiki.openstreetmap.org/index.php/Image:Osmarender_with_relationroutes.png

Should be configurable to do cycle route in colours, labelling will take some more work. --Mungewell 07:06, 29 May 2008 (UTC)

national IDs

For national IDs, please stick with the ISO 639 codes. Do not use "uk" for Great Britain, but use "gb". "uk" denotes the Ukraine. --Keichwa 18:07, 31 October 2007 (UTC)

ISO 639 is for language codes, not country codes. ISO 3166, which is the country code standard, doesn't specify a meaning for "uk", so there is no danger of a clash such as you suggest. Ukraine is "UA", the United Kingdom is "GB". Morwen 23:43, 31 October 2007 (UTC)

Concerning language and country codes, you are completely right. Nevertheless, I vote to follow ISO 3166 as close as possible and use "gb" instead of "uk". --Keichwa 07:32, 1 November 2007 (UTC)

Why roads?

Why would anyone use a route relation with

<tag k='route' v='road'>
<tag k='ref' v='A14'>

when ways by their own may be assigned reference numbers? Does anyone try to resurect three level system with nodes,segments and ways? I thought relations are rather meant to describe non-physical/obvious associacion between different ways. Steelman 22:29, 20 December 2007 (UTC)

• This is useful when one highway is shared by more than one road. For example lots of motorways have national ref number, but they are also part of european road network (ie E34). --Jttt 17:02, 30 May 2008 (UTC)

• For that case there's already ref, nat_ref and int_ref (E34). Alv 19:49, 30 May 2008 (UTC)

• also european-road-network-references need seperate relations for each line--Cbm 19:14, 18 June 2008 (UTC)
• This is another way how to do it. Also sometimes one highway is shared by more roads with the same type, like E19 and E42 in Belgium. --Jttt 20:11, 30 May 2008 (UTC)

• It's possible to assign more than one ref to a way using the semi-colon (;), eg ref="A123;A456" Rorym

• a very bad style IMHO. better creating 2 relations. one for the A123 and one for the A56--Cbm 19:14, 18 June 2008 (UTC)

• Actually I think route=road describes non-physical association between different ways. One road can consist of many ways with different type, one way can be shared by many roads. Simple ref=* is sufficient for most cases, route=road can be used for complicated cases. --Jttt 20:11, 30 May 2008 (UTC)
• State highways in Oregon and state routes in Oregon are two entirely different things. All Oregon State-owned roads, no matter how insignificant, have a ref that usually have nothing to do with the route number or numbers found on anything other than overpass and maintenance markers (and I have no reason to believe Oregon is unique in this). Route relations for roads are the only way to accurately reflect both the way's reference and the route numbers. Paul Johnson 04:41, 24 May 2009 (UTC)

Tourist/Scenic trail, etc. The are quite a few in Canada:Alberta --Mungewell 07:26, 29 May 2008 (UTC)

a road-relation deprecates the ref=* in the Member-Ways

For avoiding useless redundance it would be cool to delete the ref=* in the member-ways of the relation (only deviant ref-Tag should stay). So the renderer could generate ref-signs in a better way. But how does the renderer know, which is the primary ref? (e.g. in germany there is a A-road accompanies a motorway for several kilometers. So assign a Primary-road ref-Tag on a motorway would be confusing, I guess.

solution: We should mark these ways as role=hidden or better role=unlabeled --Cbm 12:49, 21 July 2008 (UTC)

Why? Have a look at that map. How many refs do you see? Good renderers (this excludes Osmarender) decide on their own. -- Eckhart 17:46, 21 July 2008 (UTC)

Wouldn't it be confusing if the B 1 (primary-road) is assign on the A 544, A 44, A 61, A 46, A 57, A 52, A 40... (all motorways)) ? Do we need a hierarchy? --Cbm 18:42, 21 July 2008 (UTC)

but you're right.

• highway=motorway show E-road- and motorway-refs
• highway=* show all refs

but for such a differentiation we need a hierarchy, i guess... --Cbm 21:43, 21 July 2008 (UTC)

I think it's fine to remove the redundant ref=* and there isn't any problem with joining routes. If an A-road joins a motorway, then that's it. So show it like here. The relations are pretty useful to handle this. --MasterMG 21:45, 23 July 2008 (UTC)

Member recurrence

Just a small issue, but is it necessary that a route has at least one blank member? We have cycle routes which are only going into direction, so they should have only forward/backward members... --Eimai 00:21, 21 December 2007 (UTC)

Subways

Would this make any sense for use with subway lines? Or Proposed_features/Network, which seems to have stalled, be more suitable? --Ebrelsford 04:54, 15 January 2008 (UTC)

I think yes. I use route=light_railway for lines in Berlin, where different lines use the same tracks in town and split up in the outer regions. Subway is the same in Berlin. --Bahnpirat 06:21, 30 May 2008 (UTC)

Role = alternative

For routes (hiking, cycling) sometimes an alternative is given. I would like to propose a role=alternative tag to create alternatives in a route... GercoKees 08:14, 20 March 2008 (UTC)

I'm using state=alternate (and similarly state=connection for connections between two routes, or from for example a city center or landmark to a route), as that's what was told to me on the mailing list when I talked about this issue, since it extends state=proposed that way. Role has perhaps an ambiguous meaning here, since "role" means the membership of each way to the relation (which can still be forward or backward). --Eimai 12:18, 20 March 2008 (UTC)

Using 'role=alternative' could be used to render particular ways in a different style, or mark optional 'additions' to the route (such as a short detour to a tourist route to see a particular vista) --Mungewell 00:17, 3 June 2008 (UTC)

When putting the "alternative" in a relation role, you have a problem in case the roles also have to be "forward" or "backward". So you could either then make a role like "forward_alternate" or "backward_alternate", but my preference is still for separate relations with "state=alternate". --Eimai 08:53, 3 June 2008 (UTC)

Rendering Support

The rendering style will be configured in different ways, depending the the renderer.

As (albeit primative) render support is now available in Osmarender, there is probably a benefit in trying to get a standardised set of colours and patterns defined. If a particular user wishes to render differently it would be easy for them to change local copies of their 'features' file.

I don't believe that all Relations Routes should be rendered on all levels, so what needs to be where and how should it be presented? --Mungewell 01:16, 30 May 2008 (UTC)

Route	Key/Ref	Z01	Z02	Z03	Z04	Z05	Z06	Z07	Z08	Z09	Z10	Z11	Z12	Z13	Z14	Z15	Z16	Z17
Bicycle	National (ie. NCR)					Red			box Labels					side Labels
Bicycle	Regional (ie. RCR)							Cyan			box Labels			side Labels
Bicycle	Local (ie. LCN)								Blue				box Labels	side Labels
Bus	?								Green
Road	Tourist Trail						Yellow
Hiking	Trail												Red Dotted

Text labels

Since the Relation/Route scheme doesn't really provide any technique for placing text associated with the Relation, let me suggest the following:

• 'stop_<nn>' be changed to 'stop_<*>', where the 2nd part is the number/text which is rendered onto the node (style dependent on features file). If the the role is set to just 'stop_', then no text would be rendered just the stop marker (a round blob in my features file).
• 'label_<*>' be added, where the 2nd part is a reference to the Relation/Route's own tags. For example 'label_name' would cause the 'name' tag to be rendered onto the node and 'label_weird_comment' would enable random text (stored in the 'weird_comment' tag) to be render which is specific to the Relation/Route.

(The prefix of 'Forward_' or 'Backward_' could be used to mark directional stops/labels.)

I did a little more digging around on how this could be implemented, it appears the XLST supports the '<xsl:when test="contains($str,$testString)">' and 'select="substring-after($str,$testString)"/>' functions which could be used to test the presence of 'stop_', etc in the role and split out the text for the renderer to output.

Route key values

I've noticed the table of 'In Use' key values appear, and noted that the foot ones in particular are not yet standardised upon. I've put together a quick summary of what route= values exist in the database at the moment. Relations/Routes/In use --Thomas Wood 15:57, 4 June 2008 (UTC)

Bus-Route along part of an existing way

I've been wondering how to tackle the problem "Bus follows Street A for a while (represented by a way) and then turns into Street B"

illustrated like this: (Bus-Route is noted with ".")

............
AAAAAAAAAAAAAAAAAAAAAA
          B.
          B.
          B.
          B.

• Can I apply a route-relation to only a part of a way?
• Or should I split way A? (would surely end up in much splitting-work all over the mapped areas)

I think, you have to split the way. Otherwise please inform me with a step-for-step description for JOSM. --HoH 23:11, 5 July 2008 (UTC)

Split the way at AB: Select the node at AB, and also select way A (use shift to select multiple things). Use the split way tool. Adjust the relation to be only on the appropriate half of the two new A ways. --Thomas Wood 17:23, 18 July 2008 (UTC)

I have just done this in the centre of Leeds for the Free City Bus route. I had to split the main street (Headrow) a few times, plus a number of other streets. This was just for one short route. If someone joins up the split ways again (ignoring the warning), my route will be wrong, correct? Also, I should really split a roundabout too for my route to be correct. --LeedsTracker 22:17, 22 September 2008 (UTC)

If you split a way Potlatch both ends will stay in the relation. I think JOSM does the same as well now. And yes, to be correct you often need to split up roundabouts as well (and apply the correct forward/backward roles to the ways if needed). --Eimai 14:54, 23 September 2008 (UTC)

Splitting roundabouts looks odd in JOSM now because it expects it to be one way, and an area that can be filled. I will try it and see what mapnik makes of it --LeedsTracker 15:47, 23 September 2008 (UTC)

Disability Access (primarily Bus/Railway)

I wonder if we should include information about disability access? It would be relatively easy to include and the benefits would be huge. Instead of tagging stations (where a renderer in many cases would have to get the information from a separate node), i would prefer to include this information in the route-relation. Other Arguments for the inclusion in route rather than railway/station are consistency (it can be "recycled" for a number of other routes -> hiking routes, tours, etc) and the possibility of having different levels of accessibility within a station (think of a big main station). I would propose using "disability" as a key with either a simple yes/no or more detailed information (levels could be "none", "full", "mobility", "hearing", "vision"). Alibi

Alibi, you can already use Wheelchair=yes/no/limited. See Category:Disabilities for more information. --Lulu-Ann 17:21, 7 August 2008 (UTC)

Hi! I am aware there is some debate around the use of "wheelchair" to denote accessibility - perhaps the language could be amended to reflect more inclusive tagging? I have seen "tramper" vehicles used at some sites, but another term that would allow for those using other types of mobility vehicle (eg. adapted cycles, hand cycles, clip-ons, mountain trikes, recumbent foot-pedalled trikes etc) on route relations might be more appropriate. Suggestions welcome! Olivia.ragone 15:00, 11 June 2024 (GMT)

Ways or stops used both forward and backward

I've started mapping some bus routes in my city. But sometimes there are ways or bus stops which are used both backward and forward. What role should I use for them? Maybe the blank could be a solution for the ways, but it can't be done for the bus stops, as they require a different number. --G.mascellani 16:33, 6 August 2008 (UTC)

Merging Routes

Is there a way to merge two routes? i.e., two different people working in two parts of the map create a bicycle route. Eventually when you work in an area that overlaps, both relations appear. They should be combined into one relation / route. RickH86 12:25, 12 September 2008 (UTC)

I guess the answer was no, and just to add the members of one to the other and delete the one.RickH86 10:06, 24 September 2008 (UTC)

Loops

How do we deal with a situation such as this[2]? A bus heading east traverses the length of A4240 between Llewelyn Road and Dilwyn Road twice. Also, because the route is operated the same in both directions, there is the small matter in calculating a route as to whether the bus turns left or right from Swansea Road. Chriscf 09:59, 25 September 2008 (UTC)

Merging routes - take 2

I think the issue of merging routes is really going to be a problem moving forward. When two people are mapping the same route in two countries, or in two parts of the same country, I don't know of a good way to a) find the existing relation, and b) add the new ways to that relation if it is not covered in the area I download to JOSM.

It would be great to have a tool that would allow you to use the list in this relation view: http://www.openstreetmap.org/browse/relation/14309 and be able to cut and paste the list of ways into the other relation.

Any ideas or solutions that I'm just not aware of?

RickH86 19:26, 8 October 2008 (UTC)

When I've encountered the problem (twice) I have used JOSM and the following sequence

1. Make sure nothing is selected before you start.
2. Select one route and click Edit.
3. Select all members (Click on the first then shift+click on the last) and press the Select-button.
4. Click on the other route and the Edit button.
5. Click "Add Selected" and the OK.
6. Delete the first route.

--Cohan 08:28, 21 October 2008 (UTC)

That's what I've done also. The problem is that a portion of each route must be in one area that you can download into JOSM, so you can select each one. RickH86 08:32, 27 October 2008 (UTC)

Be careful. If any of the members of the original relation had roles then you'll need to ensure that you preserve them when transferring them into the new relation. Also ensure that you've downloaded all members of the original relation first (kind of obvious, I know, but I thought it worth saying for completeness). As for ensuring dealing with two widely-separated areas you can do this as follows:

1. Load the area containing one of the relations in JOSM.
2. (Separately) Determine the ID of the other relation you'd like to merge with it (via a separate JOSM session, Potlatch, whatever...).
3. Download and save the full data for the relation you've determined above from the API: http://api.openstreetmap.org/api/0.5/relation/12345/full, replacing the number appropriately.
4. Load the saved file into the JOSM session identified in the first step.
5. Merge the layers using JOSM's merge layers button (The one to the right of the delete button in the Layers panel). All of the data is now in the same layer.
6. Merge the relations as described above, taking care to preserve the roles.

This technique, without the merge step, could be used to add to an existing relation in a completely different area as well.

As for determining the existence of a relation (and its ID), WikiProject United Kingdom National Cycle Network, WikiProject United Kingdom Long Distance Paths, and National Byway are good sources for UK cycling and walking routes. If you create a relation be sure to update these pages accordingly such that others may benefit. I'm sure that there are similar pages for other countries and types of routes. If not, why not create one? --Gregoryw 18:14, 27 October 2008 (UTC)

forward/backward system awful

As clever as it is, it is incapable (AFAICT) of dealing with a basic case of different one-way streets being followed in different direction, requiring that two stops receive the same number. In the first route I'm mapping, the end is a one-way loop with two one-way stops on each side of a terminus (it's also got several segments on double-carriageway streets). According to the current tagging format, this is impossible. For the time being, I'm using forward/backward to indicate circulation with regard to stop numbers rather than way direction, so that stop_1_backward and the matching ways are taken (understandably) on in the "backward" direction, which is toward stop_0, and vice-versa. Any thoughts? this is both more intuitive and more sensical to me.

This leaves an issue where the number of stops differ forward and backward. I'm using decimals until I figure something better.

See Relation 37415 for the whole dirty business. Circeus 22:11, 13 October 2008 (UTC)

The forward/backward scheme is quite limited indeed (nevertheless humans are quite good at interpreting the route :-) ). I guess ordered relations could be something useful for routes (which is a bit what you're trying to implement with decimal numbers, but which can be a pain when some extra halts are added for example). Relations as it is now also don't allow to have the same way or node more than once in it, which is also a limitation that has to be sorted out with ordered relations. Perhaps it could work "behind the screens" like your numbering scheme, but then the limitation of duplicate nodes/ways in a relation has to be removed. --Eimai 17:50, 8 November 2008 (UTC)

Why not separate forward and backward in two different relations? Where I have been living, the name of the route is different in the different directions, even if the ref is the same (ref=6 forward name=Buenget backward name=Dragvoll) as an example from Trondheim. All cities I have lived in follow this scheme. --Skippern 15:56, 22 February 2009 (UTC)

Busstops used forward and backward + Loops: solution idea

What if we take the bus route, and don't try to store the information about the loop in this relation, but add another relation that only captures the bus stops needed to describe the loop? Then we have a numbering only for these 3 or 4 bus stops, and the adding of a bus stop somewhere else in the bus route relation does not cause any trouble.

Example:

Bus goes A - B - C (forward) - D - C (forward again) - E - F 
The loop is C - D - C.
The additional loop relation would be
Relation = route
route = bus ( or route = busloop )
bus = loop
C: role= 1;3
C: direction = forward
D: role=2
D: direction = forward

Comments welcome --Lulu-Ann 16:18, 11 November 2008 (UTC)

Wait until they add ordered relations in the 0.6 API, that'll fix things nicely :-) --Eimai 17:13, 11 November 2008 (UTC)

Route overlay instead of rendering

The openstreetmap.org map can show overlays (it does this with data). Is there a way to specify that it should overlay a certain route? Ideally it should be able to overlay more than one route and allow you to specify the color. Something like this: http://openstreetmap.org/?lat=57.696413866697554&lon=11.968512799999997&zoom=11&relation1=52612&color1=blue&relation2=52617&color2=red this would be very useful for generating bus maps etc without having to render them.

MTB Routes

What value shall be used for Mountainbike Routes as network? I don't know what is used, but mtb routes are an important and often used type of routes. How shal it be best added to the main page (if it's not on main page there is danger that 50% tag route=mountainbike and the other halve route=mtb. Are the network abbreviations just invented for OSM or do they exist somewhere else to? otherwise I would propose using nmtbn, rmtbn, lmtbn (as for NationalMTBNetwork, Regional..., Local...)

There is already this for the moment German only page Mountainbiketouren listing several mountainbike routes. --Extremecarver 23:18, 26 November 2008 (UTC)

I think, it is very imptortant, NOT to use network=lcn/rcn/ncn for MTB-Routes. The MTB Route is very different in using to normal cycle-routes. The use of MTB-routes is nearer to walking-trails than to bicycle-routes. Therefore MTB-routes have to use there own network. I always tag the relations with network=mtb. It is not necessary to divide in national, regional and local. --KK-O 12:36, 11 April 2011 (BST)

Default roles

I've seen routes with no role for nodes. Should I change the roles, or could we have the convention that the default role for nodes is "stop"? Also I've seen nodes with role=forward. Could we have that mean the same as role=stop_forward? It makes sense to have defaults. Norpan 18:02, 2 December 2008 (UTC)

I wouldn't do anything with them if I didn't know what their meaning is. They could be starting points, they could be ending points, or rest points, or whatever... --Eimai 20:54, 2 December 2008 (UTC)

Divided highways

I'm making a relation of the E 4 road. When the road becomes a divided highway, should I have both northbound and southbound way in the same relation, or should there be one relation for each way? (I see both systems are currently in use.) --Cohan 04:30, 5 December 2008 (UTC)

As I understand it, both ways shall be added to the relation, and if appropriate tagged with forward or backward. --Erik Lundin 19:15, 14 February 2009 (UTC)

Symbol description

This symbol is used as a label along the route, e.g., "Red cross on white ground" for the "Frankenweg" in Franconia, Germany

• I think this would be better implied by the network tag - the network=Frankenweg implies that symbol David.earl 22:38, 23 October 2007 (BST)
• I concede that you could derive the symbol from the combination of name/ref and network; network alone is probably not enough. --Keichwa 18:18, 31 October 2007 (UTC)
• What if cycle routes within a regional network all have different symbols that are used on sign posts to guide the cyclists? Or do we need specialised route relations for cycling, hiking, etc? --Karouf 14:03, 10 November 2007 (UTC)
• In Poland most routes are marked with coulourful marks (one trail one colour, see the bottom of this page). For hiking trails they are alwas a colorful stripe beetween two white ones. However, bicycle routes' symbols haven't been yet standarised accross the country, they alway use colours. Steelman 22:18, 20 December 2007 (UTC)
• Some cycle tours in Germany use special icons (e.g. the Ruhrtalradweg). I think a symbol description is not good enough - for rendering purposes an icon url would be more suitable.

Proposal for new route: minibus

I propose to add a new "official" route type: minibus. This type of public transport is known in many developing countries. Viertually in every big city you will find minibusses (in Kenya called Matatus for example) who will often (but not always) ply the established bus routes but are used differently: They don't have dedicated stops but will pick you up and drop you at any given place along their route. But the main reason I think why they should get an own route, is that the vehicles themselves often do not betray their destination. The conductor will instead inform all potential customers by shouting codewords (like "Merkato" or "Mexico" in Addis Abeba). So it would be very useful to render Maps that would show the different MAtatu lines, and the locally used codewords (or route numbers or whatever).

If needed a new route type can be established, but I guess "minibus" will be misunderstood. --Lulu-Ann 09:32, 4 February 2009 (UTC)

Here in Brazil we call those as "van" or "kombi" services. Some of them do run the same path of regular city buses, but there are many who have their own route, where no buses goes or you'd have to take more than one bus. I also think it's a good idea to map those so called (here) "alternative transport" because no one maps them. Any suggestion about how to tag those? I'd say route=van or route=kombi, but I realize that it could be too much portuguese-centric, so I'm open to suggestions. I liked "minibus" but it could make confusion with, for instance, what we call here as "microbuses", that are smaller buses but still operated by the same bus companies. This is something entirely different, and the above person's comment (he/she didn't signed...) explains how it works. --Nighto 03:48, 26 April 2010 (UTC)

Sorry. I've still not understood why we need a new type of route, in what those routes are so different that they need they own tag, why the type=route with route=bus does not fit.

We can use the same type without giving bus stops if they are not planned. We can add a capacity=* to indicate the size of the vehicle. We can give the network=* and the operator=*. We can create a secondary tag for this kind of bus. But the tools would be more efficient if they dont have to manage too much different tags.

What on your mobile with an home made app that doesn't manage this type of route ? You will loose information.

--FrViPofm 08:04, 27 April 2010 (UTC)

Hm, I don't know. We should not tag for the renderer nor the "mobile tool". The thing is that those "minibuses" are different. First of all, they are not run by regular companies, but by cooperatives or group of people. You could catch a minibus that the driver is listening to rock music, for instance. Also, they could drop you everywhere on the path. But the most important thing is that they're not regular buses - the government calls it "auxiliary alternative transport". I think that if we use the same tag for buses, It'd be confusing. ::Nighto 10:40, 27 April 2010 (UTC)

Ok, we don't map for the mobiles but for having a strong semantic ! If the semantic is not strong, mobiles tools and other tools would be hard to code...

• driver is listening to rock music music=rock
• not run by regular companies, but by cooperatives or group of people operator=cooperatives/group of people
• they're not regular buses we have no timetable on OSM, so it doesn't make a difference. We can add regular=no
• It'd be confusing let us create the tag that would remove the confusion inside the different bus route minibus_or_what_so_ever=yes.

I still doesn't understant what make a differrence in the OSM point of view, and how this difference is such that we can't use the existing tags and we must create a new type of route.

Maybe we need new tags in OSM. But in this case I'm not shure. The fact that those minibuses have no schedules, departure time, stops... is not enough to make them different that classic bus route. They are not different as are hiking and biking.

--FrViPofm 14:06, 27 April 2010 (UTC)

Perhaps type=minibus then? --Nighto 02:40, 28 April 2010 (UTC)

No. The type=* tag must be set to route for being refered by other tools as route and the route=* must be set to bus for been used by public transport routing engines. Perhaps minibus_or_what_so_ever=yes or regular=no for taking in account the specificity, the difference with regular busses.--FrViPofm 08:23, 28 April 2010 (UTC)

Oops, of course the type=* is needed to be set to route. Sorry, my bad. :X What do you think of a bus:type=* then? It could be set to bus:type=minibus, bus:type=urban, those trip buses with chairs that incline (don't know an exact word in english for those) and so on. --Nighto 11:08, 28 April 2010 (UTC)

Public transport route relations already include route=bus, route=tram (, route=train?) so it doesn't have to be route=bus - both solutions work, where supported. Alv 13:01, 28 April 2010 (UTC)

I agree and digesting the discussion here: Do nothing. just create a new route and name it accordingly. The same way bus A is restricted to Line A, a "Lotação"/"Candongueiro"/"minibus"/etc is restricted to its own route. So just create a route for it and call it a "bus". It doesn't matter. Maybe add the local name to the route. E.g. Instead of creating a route "Ilha - Roque", create it "Ilha - Roque (Candongueiro)".

Other kind of routes !

Recently I added two kink of routes !

fitness trail

We have many « piste VITA » in Switzerland ([3], [4], [5], [6]) than i think that it is the beat way to tag it.

My usage : [7] (notes: the piste isn't complete ...)

sealskin skiing

Two days ago I mount the « Pic Chaussy » with sealskin ([8], [9], [10]) I don't know the exact name in English.

My usage : [11]

Is it correct, should it be a other name, should is be added to the route/types ?

Thanks in advance. Sarge 08:18, 23 March 2009 (UTC)

• Hello Sarge, just been looking through the discussions page and came across your question. Here is (one possible) answer: Route relations for ski touring, also known as mountain skiing, should be tagged as type=route + route=ski + piste:type=skitour [ + name=??? etc. ]. I have taken the liberty to re-tag your route relation (102939 = 'Les Mosses - Pic Chaussy'): [12] along these lines. --Neil Dewhurst, Lyon France 10:21, 11 December 2012 (UTC)

network=* tag format for type=route,route=road

Are there any standards for labeling this tag?

We're currently starting to relate polish road network using following scheme:

ref=#
type=route
route=road
network=pl:motorways / pl:express / pl:national

Some people say that we should use network=national instead, but watching through other country projects I can see that everyone is using own naming scheme for network.

route=power

What's the purpose of that? A route from power plants to each home and back? Electricity just doesn't follow simple routes like that, and I can't see any reason why something like this needs to be in OSM... --Eimai 13:18, 6 May 2009 (UTC)

Do you see the towers with all these cables? There are routes with names and attributes made up of these cables. A single tower can carry multiple cables that belong to different routes. Not everyone is interested just in streets. --MarcusWolschon 06:35, 7 May 2009 (UTC)

Map each line then as a separate way if you're interested to map every single line, that resembles reality a lot more then... But I don't see the need for a route relation here. --Eimai 10:25, 7 May 2009 (UTC)

They are one physical power-line and thus one line. That YOU don't see a need there does not mean that other don't. I see little point in ferry-routes but I respect others to map them. (Don't forget: The wiki does not define what is legal to map but document what people out there have mapped.) --MarcusWolschon 08:45, 8 May 2009 (UTC)

I didn't say there's no need in tagging information on the power lines, I've only said I don't see why this should be a route relation, as the feature is something physical (the wires). A route is for something making use of those wires (I guess the electricity here), but the routing is such a complex process, and it doesn't follow such nice simple routes from power plant to substation to user. So please, what is the information here you want to put in those route relations? --Eimai 12:33, 8 May 2009 (UTC)

As I understand:

1. this is not for the route of an electron form power plant to your home.
2. there are some named routes in the power network.
3. not every single wire (cable) at a power line will be mapped,
4. # some of these routes share the same line - it is not nice to have ways on top of each other - the use of a relation makes sense.

--Langläufer 13:16, 8 May 2009 (UTC)

So sad I discoved this not earlier. I'm Bahnpirat, and I had specialiced myself on power lines here. I've maped power lines in USA, France and Bulgaria, but mostly in Germany and I put the route=power in the list.

Once I came to the problem that two power lines joined to one line, but and later seperated again. The problem with power lines is the same like bus routes. They start at two ending points in the village, then both use the same road, and later end on different stations. On bus routes you can change the line. "Power line travellers" are not able to! Please notice this example. Two lines coming from north and go together to power station. On buses you change on first station where both lines meet. This is not posible for an electron. Imagine a map (or database) that can show where you electricity comes from and how far it traveled to you. I can also give you an example where different voltages use the same power towers over a long way. One of these lines share the route with two other power lines (and relations). Let's give another example: two lines on the same power towers. But different operators. How should I map this without relations? In this case two ways are over eachother. This is (from my point of view) a route-relation-thing. --Bahnpirat 15:54, 29 June 2009 (UTC)

Order of members

Suppose I have some ways like this:

          B      C
   A   <----- <-----    D
----->O      O      O----->
       -----> ----->
         E      F

(O's are nodes)

B, C, E, F are marked as oneway=yes.

I want to create a route=road relation for this. Now that we have ordered relations in 0.6, how should I sort the ways: A, E, F, B, C, D? A, E, B, F, C, D? Completely different?

What about the forward and backward roles? According to [Tag:route=road], I would tag E and F as forward, B and C as backward (or the other way round). But if I understand [Relation:route#Members] correctly, I should tag all 4 of them as forward. So which one is it? --UncleOwen 18:21, 17 May 2009 (UTC)

As far as I understand it: Just because the members of a relation have an order, it does not mean, that the order has any meaning. Just in special cases like the bus_stop the order is used to show the sequence of bus_stops. Normal way-members do not have any order.

If you want to order your elements anyhow, I would do it like this:

Condition 1: A -> B -> C -> D

Condition 2: A -> E -> F -> D

If you combine them, it does not matter, where you put B, C, E and F, as long as the two conditions are met. If you want to go from A to D, B and C are not important, as they can not be used anyway. Same Vice-Versa. So both your options should be fine.

For forward/backward: Only the direction of the way is important, not the "direction" of your relation. So B, C, E and F should have the role "forward". (Actually, I am not even sure if they need a "forward" because they are oneway, but it is not false to asign "forward".) In my opinion, the route=road-Site is wrong. -- T-i 22:12, 17 May 2009 (UTC)

Is it possible to have one node twice in one relation? Otherwise the sorting does not always work. --Lulu-Ann 08:45, 18 May 2009 (UTC)

Yes it is, but for many routes it is better to make two relations! Forward route AEFD and backward DCBA. If you want to use only one relation the members should be AEFDDCBA. The separated relations are easier to attend. --Phobie 09:51, 18 June 2009 (UTC)

What is a Pilgrimage?

I have been asked several times to include route=pilgrimage on my hiking map. In my opinion this does not make sense as a pilgrimage is just a long journey with religious motivation, but does not say anything about the mode of travel. It may include walking, bicycling, driving a car, horseback riding, riding in a train, bus, ship or plane. So it has basically no business on a hiking map. But since there were multiple requests, I'd like to discuss and clarify the nature of pilgrimage here. --Nop 10:12, 3 July 2009 (UTC)

In France there is a lot of historic ways, well documented, that are ways of pilgrimages. The most famous is the Via Podiensis, oldest way from Le Puy-en-Velay to Santiago de Compostella, part of a big network. A lot of pilgrimages are local : some kilometers. There is also the Via Romea Francigena, one of the ways to Roma. But there are other historical ways, like the Stevenson's way where the motivation was more romantic... Those ways were mainly for walking. Stevenson had a donkey. Even if today pilgrims go to Roma by plane or bus, the ways recorded as route:Pilgrimages are mostly for walking.

The great pilgrimages (ways to Santiago, Via Francigena) are also recorded as Chemins de Grande Randonnée or GR. But GR and Grande Randonnée are trade marks of the Fédération Française de Randonnée Pédestre. So mapping the pilgrimages, old enough to be in the public domain, is a way to avoid problems with the FFPR as we include the main churches that make the pilgrimage different from a hiking, from a GR. The ways to Santiago are very good for Hiking, and a lot of people start their ways as walkers and become pilgrims ;-) FrViPofm 23:13, 3 July 2009 (UTC)

Rail passenger services

Firstly, I think it is clear that for special services or rush-hour-only journeys, this scheme may not be appropriate. I am at a bit of a dilemma about what we should do with the ref tag for route=train relations.

Here in the UK, there are several ways the regular routes of passenger trains could be tagged. It is probably easiest in the south-east, where passenger services are allocated specific route codes, comparable with the route number on the front of a bus, and often displayed in a similar way. Various people have compiled a list of these, such as this example. I would have thought this is an obvious ref value, and I have started in this vein with the Brighton Express services from London Victoria (route code 4). I am also using the operator short code (in this case 'SN' for 'Southern') as the codes are not unique.

Away from London, route codes aren't really used except on trams. I have seen various ideas come up by looking at öpnvkarte.de, and there seem to be 2 main ideas.

1. Label each 'route' relation with the ref set to the operator shortcode
2. Label each 'route' relation with the ref set to the appropriate Table Number in the National Rail Timetable (list of tables).

Both have major shortcomings, which are as follows:

• The operator will normally run many different services, many of which will at least partly coincide. Example: (all names, Table numbers etc are fictitious. Operator is not as it makes life easier)

Fig.1 - basic layout

             / B
            /
A=======O===== C
     /
  D /

Imagine there are two regular bi-directional services to station X. The first runs from A to C and is in NRT Table 701, the second from D to B in Table 720. They are both run by operator GW. "O" represents a station. Using scheme 1, a potential passenger is not able to tell whether trains usually run as described, or opposite (A to B, D to C).

Fig.2 - shortcode scheme

              / B
             GW
            /
A==GW=====O===GW== C
     /
    GW
 D /

Using scheme 2, this basic example would be clearer.

Fig.3 - NRT Table number scheme

              / B
            720
            /
A==701=====O===701== C
     /
   720
 D /

So scheme 2 seems better overall. But if we have a more complex layout, with multiple operators and multiple tables, there might be an issue. Perhaps a refinement to work with is to use ref=SHORTCODE<space>Route Code in the South East (and anywhere else Route Codes might be available, and ref=NRT Table number<space>SHORTCODE outside these areas. That's what I'll be doing with any new route=train relations I set up, at least until a better idea is reached. Maybe a final refinement could be to have scheme 2 routes with the shortcode in brackets, such as:

Fig.4 - refined scheme 2, shown where previous version could be confusing

                                 / B
                             750/(SW)
   750 (GW)                    /
A==731=(SN)=============O========731=(GW)= C
          \           /          731 (SW)
        750\(GW)  750/(SW)      
            \    731/(SW)
             \     /
              \   /
               \ /
                |
                O
                |
             750|(GW)
             750|(SW)
                |
                D

That was a bit of a mammoth explanation - hope you followed that OK. If you have a better (or just different) idea, or you think this is brilliant, do please comment below. Thanks. --CunningPlan _{What's on your mind?} 22:31, 5 July 2009 (UTC)

I think the key is to make sure you set up a different relation for each service. Quite a lot of the tables in the NRT cover multiple services (even quite simple tables). If the services are all labelled just by operator for the moment, that's quite easy to change (elaborate) in due course. Whereas splitting relations is a fiddle. I think the only public label for most of these services is origin/destination (and if appropriate slow/semi-fast/fast). Eg London-Oxford fasts and London-Oxford slows.--RichardMann 20:53, 7 July 2009 (UTC)

In Germany and some other countries (e.g. Norway) we have numbered national time tables for rail and bus since decennials, long before they were displayed on the vehicles. If at least your operators use unique numbers (like in cities), you could use them (maybe combined with an operator id, in case there might be conflicts: XY12, AB34). But if none is given, you are really in a mess. I had proposed some ideas on Talk:Public_transport, but without any response. I fear the idea to use some kind of "natural order" (like that in route tables) is difficult to remember and prone to changes. Meanwhile I've spotted some examples for "snythetic, readable codes" like (invented) "Br-So" (for Bristol-Southhampton) or plain (and ugly) "Bristol-Southhampton". For express routes you could add an "x", but everything else (branches, shortened routes) will become confusing (cf. the codes used by Paris RER) --GerdHH (talk) 14:45, 8 February 2021 (UTC)

Better display of hiking routes on OSM Maps

I think the hiking routes should be more visible on the maps. The OSM Cyclemap are highliting routes with blue color in zoom level 16, but this map does not show tracks. The other maps does not show routes at all. My proposal are: 1. Make OSM Cyclemap show tracks/paths. 2. Make OSM Osmarender and/or OSM Mapnik highlite routes as OSM Cyclemap does and also add the name of the route along it as we do with borders.

Either of these would help me as of now.

--Startail 20:44, 7 July 2009 (UTC)

route=taxi?

Can the one adding route=taxi explain this? I was not aware that there was taxi routes. To me this sounds a little meaningless. --Skippern 08:15, 5 August 2009 (UTC)

In exUSSR and several other places in the world there is shared taxi mode of public transport -- routed taxicab. It follows some route but allows to jump in and out at any place. In soviet times these even carried check-mate taxi symbols. Most likely these are marked. -- Monas 07:55, 17 July 2010 (UTC)

So it would probably be better to use route=share_taxi, because it is not a "real" taxi. --Cartinus 11:38, 18 July 2010 (UTC)

Historic roads

There's a historic route Kuninkaantie (King's_Road,_Finland) running all the way through southern Finland, from Turku to the Russian border (and even further). It actually starts in Norway... It was "built" in or from the 14th century to connect the east and the west sides of the Swedish empire - and neighbors. At least in Finland there's a signposted touristic route following the original route as closely as possible, given current private properties it might pass through. For part of the journey there's even two variations, both of which have been actively used sometime in the past. Some parts of the historic route have been converted to modern roads but some have deteriorated to footways. None of the current route relation types seem fitting and the members would probably need to be in various roles;

• historic: the original way, which might now be on private property or built over
• (none): sections of the original way that are in "historic" condition and usable
• ? / converted: sections of the original way that have been rebuilt as modern roads
• touristic: the ways which are part of the route only because tourists (cars) are routed on them to get to the next converted section

There are other nationally known historic routes that aren't signposted but which historians could enter. Ideas? Alv 11:34, 5 August 2009 (UTC)

Splitting out public transport relations and reorgansing the sections on the page

There is a discussion on talk-transit about giving the transit/public transport area of the wiki a bit of a clean up and as part of this we agreed to identify a number of different transport modes, including Bus, Tram, Train and Ferry (we discussed rolling tram into train but concluded that they were significantly different). I have split out the bus, tram and train relations on this section because it will allow more appropriate links and information to be provided in each case.

While doing this I also promoted the sections dealing with different modes figuring that most people will have a route type in mind (cycling, hiking etc) and will be able to jump straight to the right section. I think included the big table at the end. PeterIto 08:20, 7 August 2009 (UTC)

but we shouldn't loose out of sight the commons of the public transportation. the small significant differences can be cleared at theire own wike-pages buses trams .... --Langläufer 08:28, 7 August 2009 (UTC)

Directional roles

With many road route relations, it's become common to use one relation to map both directions of a road route. When only one direction of the route is on a way — typically a way that is oneway=yes — roles such as "east" and "north" are used, depending on signage. It's become so common in many US states that I'm surprised this practice isn't even mentioned on Route Relations. However, in many cases (particularly Interstates and routes that contain a lot of divided highways) this is intended as a temporary, "better than nothing" solution until it can be done as this wiki page specifies. Vid the Kid 05:05, 28 November 2009 (UTC)

A minor issue

There are sometimes cases where one direction of a route follows a two-way road. In that case, using role=forward or role=backward would make sense, but if it's one relation for both directions of a route, then usually the directional role is used. In that case, it may seem as if, on that street, you're following one particular direction of the route no matter which direction you're actually driving on the street. Seems to me, by extension from what was done with the stop role, the solution is to do something like role=forward:south. (Another solution is simply to use a relation for each direction, and role=forward/backward, but the conversion is not very easy in certain editors.) Vid the Kid 05:05, 28 November 2009 (UTC)

role="forward" and role="reverse" are commonly used in Germany. Parts of the same road that consist of only one way for both directions have no role at all. --MarcusWolschon 07:12, 30 November 2009 (UTC)

IMO role=forward and role=backwards/reverse can be omitted by making separate routes, i.e. one route "A to B" and another "B to A". I also think this is a much cleaner way to do it, as often the sign on the bus/train/tram is different when going one way or the other. For hiking trails where no direction is of importance, than forward/backword doesn't make sense at all. Circle lines also have different references for clockwise and anti-clockwise direction. One real life example, in Tronheim Norway, the bus nr 6 goes "Buenget - Dragvoll" and "Dragvoll - Buenget" marked with destination in the window, the circle route "Sentrum - Jakobsli" have the references 36 (clockwise) and 66 (anti-clockwise). --Skippern 13:06, 30 November 2009 (UTC)

Remaining quirks

Some route relations that originally covered both directions have already been split into different relations by direction, and sometimes, by state. However, it appears that the roles aren't always changed. For example, see I-75 South in Ohio, 332641 332641; every member still has role=south. I believe, to make the relation match this page's specifications, all of those should be role=forward. Unless there happen to be one or two member ways that are oneway=-1, which should be role=backward. Vid the Kid 05:05, 28 November 2009 (UTC)

If the whole route is a oneway route (N.B. not a oneway road) then using forward/backward roles doesn't make sense to me. Simply put oneway=yes on the relation. --Cartinus 13:27, 28 November 2009 (UTC)

Sub-Relations for route's

Not sure if this is the right discussion - please redirect me if not.

I've seen plenty of references to super-relations but this doesn't seem to address the needs of walking, and probably other, routes. Many of these have nominal arbitrary sections based on the distribution of transport links, walk-lengths, administrative responsibility, etc., and there are many examples in my area of the same route having different, conflicting structures depending on who defines the arbitrary structure. It seems wrong that a single set of arbitrary structures should dictate the segmentation of the database representation of the route data.

To be of maximum use to users, the user should be in charge of how the route is represented when queried, whether it be in 5, 10, 15 mile sections, linear, circular or whatever, so that the walk can be selected on criteria presented by the user. Thus instead of seeking to combine smaller route relations into a super-relation we should define a route as a single, large relation covering its full extent, and then define sub-relations within that overall relation to specify individual walk sections based on the perspective taken.

Storage structures of these large relations should only be a matter of database efficiency and access algorithms. Presentational structures should be dynamic and decided by the user at time of query, ideally aided by database routines/queries to optimise this facility.

I'm thinking of the lines of master-relation:number/name; (new) sub-relation number & tags, [[from-way, to-way] | [from-way, to-way]]. Presumably this would reduce the storage overhead, and improve access time because the relation query would be limited by the search scope. Ways in the sub-relation would not need additional tagging for each different user perspective because the sub-route would be assembled at the time of query.

Perhaps this facility already exists. If so I'd be grateful for a reference. UrbanRambler 10:13, 31 January 2010 (UTC)

forward/backward_stop OR forward/backward:stop?

How should the bus stop relations (nodes) be tagged if a bus line stops as folowing:

Should I use "stop" on A1 and A2?
What should I use on B and C?
And what is the difference between forward/backward_stop and forward/backward:stop. Zawaq 19:14, 23 February 2010 (UTC)

Hejsan! On the Relation-Page it says that forward and backward should be used depending on the direction of the OSM-way. Nevertheless, renderer like ÖPNV-Karte use for-/backward globally, i.e. forward means in the direction of travel. (It's just much simpler than analyzing the direction of a OSM-way.)

_ or :? I use _, but I think, ÖPNV-Karte understands both (I think). --t-i 16:17, 1 March 2010 (UTC)

Hi! Okey, so "_" and ":" both works, and they do the same thing?

I think I know how to tag the bus stops now also (B and C as "forward_stop").

Thanks for your answer. Zawaq 14:26, 6 March 2010 (UTC)

My way of mapping is differrent.

I create 1 relation line and two distinc relation route with the same ref. And I don't mind of forward or bakward.

in the first relation route, I put A1 & B

in the second relation (the return) I put C && A2

in the relation line, Iput the two relation route

I can also make a relation stop_area witch contains A1 & A2, whose name is A

the scheme :

• line ref=N contains
  • route ref=N (forward) with
    • bus_stop A1
    • bus_stop B
  • route ref=N (backward) with
    • bus_stop C
    • bus_stop A14
• stop_area name=A contains
  • bus_stop A1
  • bus_stop A2

It's a little fastidious to create, but it's clearer in use. And it surely would prouve better in public transport routing. An it is welle rendered with övpnkarte. See (Besançon/Ginko)

--FrViPofm 20:18, 6 March 2010 (UTC)

from/to tags useful and decisive?

Some of the wiki pages suggest adding from=* and to=* tags to bus route relations. Alas, I can't translate German well enough to note whether DE:Öpnvkarte is unambiguous about which is "from" and which is "to". But I wonder, are these useful enough to have them recorded in the database, as opposed to calculating them? --goldfndr 04:14, 11 April 2010 (UTC)

ÖPNV-Karte recommends to have 2 relations, one for each bus route direction. --Lulu-Ann 07:33, 11 April 2010 (UTC)

As says Lulu-Ann the from=* and to=* tags are meaningfull when using two (or more) route relations gathered in one line relation. Those tags so into the route relation can indicate the from and the to bus_stops. I also use to give different names to the relations. For example :

• relation:line ; ref=24, {{tag tags, [[from-way, to-way] | [from-way, to-way]]. Presumably this would reduce the storage overhead, and improve access time because the relation query would be limited by the search scope. Ways in the sub-relation would not need additional tagging for each different user perspective because the sub-route would be assembled at the time of query.

Perhaps this facility already exists. If so I'd be grateful for a reference. UrbanRambler 10:13, 31 January 2010 (UTC)

forward/backward_stop OR forward/backward:stop?

How should the bus stop relations (nodes) be tagged if a bus line stops as folowing:

|name||24. Châteaufarine - Orchamps}}, including

• • relation:route : ref=24, name=24. Châteaufarine > Orchamps, from=Châteaufarine, to=Orchamps
  • relation:route : ref=24, name=24. Orchamps > Châteaufarine, from=Orchamps, to=Châteaufarine

--FrViPofm 20:34, 12 April 2010 (UTC)

Use on ways

I understand route=ferry is normally on ways, but should route=bicycle really be used on ways? I've seen it applied in addition to highway=cycleway (with type=route also on the way), for example on 30675449 30675449, and any uses on other types of highways should probably be bicycle=designated. --NE2 02:46, 22 May 2010 (UTC)

Most tags route=* must be used on relations only (and all could be used on relations).

The wiki describe currently:

• route=minibus
• route=ferry
• route=snowmobile
• route=wheelchair
• route=transhumance
• route=piste
• route=boat

Unfortunately taginfo show a big misuage of route=* on ways.

--Pyrog (talk) 09:22, 24 August 2024 (UTC)

Route sections that are not reversed

How should route section that are travelled in the same direction in both the forward and backward directions of the route? Mentor 00:44, 8 July 2010 (UTC)

Do not understand, what is the question. Can you explain more? --Langläufer 08:39, 8 July 2010 (UTC)

I believe the question is about a way that both directions of the route follow in the same direction. Here's an example, though since it's a US highway using east/west roles, it doesn't answer the question: http://www.openstreetmap.org/?lat=36.97903&lon=-76.42675&zoom=17&layers=B000FTFT&relation=420686 --NE2 09:21, 8 July 2010 (UTC)

Yes. For example, consider a one way system through a town centre.Mentor 00:16, 17 July 2010 (UTC)

It's actually very rare (might be a little more common on a bus route). --NE2 01:15, 17 July 2010 (UTC)

Be that as it may, /I/ still have a load of routes that I want to tag.Mentor 02:05, 17 July 2010 (UTC)

You could try using one relation for each direction, I guess. I've never done bus routes. --NE2 02:28, 17 July 2010 (UTC)

Numbers of people/cars on route,...

Hi,... specifically, has anyone broached the idea of having an amount tag applied to route tags. In my case, I'd be interested in knowing how many cars or how many people a ferry can accomodate? In a broader sense, it could also apply to the capacity of a route(people allowed on a trail), for example).

I guess the capacity key[http://wiki.openstreetmap.org/wiki/Key:capacity would be used but just isn't in usage for Ferries yet.

Merging super-relations of routes

An example to illustrate a possible algorithm of processing super-relations of routes, that is, merging them to a somehow flat hierarchy, depending on the particular purpose can be found in Super-Relation#Merging super-relations of routes. (I moved my post there). It is more of an example set of what we have and what we want but the magic in the middle is still missing. Anyway just a way of many I guess.--Guverneu 19:42, 14 October 2011 (BST)

New 'Routes' article

This is an excellent article about routes in general and as such probably should be called Routes (currently a redirect here). The article with this title should probably be much shorter and be focused only on the Route Relation itself and how to use it. This suggestion is part of a major effort to rationalise feature articles, key articles and relation articles to make them simpler to navigate. Any objections? If not I will get on with the move soon. PeterIto 13:59, 18 December 2011 (UTC)

Start/End of route

There is a question about start/end of routes: http://help.openstreetmap.org/questions/11132/how-should-i-indicate-the-startend-of-a-local-walking-route

My proposal to define start/end is: The ways in a route relation are ordered. The start of the first way is the start of the route. The end of the last way is the end of the route. The start/end of the first/last way in the route relation is the node not connected to the next way/previous way in the relation. If the route is incomplete or not ordered properly the start/end is undefined. --mmehl 11:46, 17 March 2012 (UTC)

If it's not ordered "properly" (which can happen through normal editing) you can still find the start and end by sorting it (JOSM does this automatically if you use forward/backward roles for one-way pairs). --NE2 06:02, 18 March 2012 (UTC)

pipelines?

When route=pipeline was added to the page today, there were no uses of that tag in the database. Also, there will never be two substance flows sharing a single pipe, so a relation should be unneeded. The tags on the pipes ought to be sufficient? Relations_are_not_categories Alv 08:40, 19 April 2012 (BST)

Relations are useful for verifying that there are no gaps in a route. --NE2 21:42, 19 April 2012 (BST)

That should be possible to do with other tools also --Skippern 23:50, 19 April 2012 (BST)

How? How would the tool know that two pipelines are supposed to be joined rather than having a gap between (perhaps for a large holding tank)? --NE2 06:48, 20 April 2012 (BST)

The same way the relation analization tool does. A pipeline analization tool should gather all pipelines of same product and list gaps in it give a certain alowance for tanks etc, and check what is in the holes. If no valid data is in the holes of the pipeline than there are an undesired gap. I agree that this might need somewhat more processing capacity than a relation analize but shouldn't necessary mean that relation is the best option. I don't see any other useful information coming out of such relation than your analize. --Skippern 08:41, 20 April 2012 (BST)

Headway, Interval or Frequency - about the value of a public transport route

I would like to add information about the headway of public transport lines. A bus route with a headway of 10 minutes has another role than a bus route with only 3 circles a day. This information can be used to make differences between the routes in rendering. A bus route with a better headway can be drawn thicker, than others. I have prepared a rule for Maperitive where the drawing depends on the service interval.

A big question has to be answered before continuing the work: Which term should be used? "interval" or "headway"?

• The term "frequency" was rejected in other discussions (Talk:Proposed_features/Public_Transport#Frequency_of_buses).
• In the moment "headway" is used for bus lines in Orlando (Florida) and the VRB network in Germany (my work).
• "interval" is used for some routes in Berlin, Rustavi (Georgia) and some ferry services.

Another question is which interval should be used. The peak hour, the midday off-peak period? Surely not the evening or weekend services. The goal is not to have the timetable in OSM.

--Vicuna 20:51, 25 November 2012 (UTC)

Running routes

At my neighbourhood, Bremen (Germany), are some running routes. Those are for instance signposted and are using raods which are shared with cyclicists or pedestrians. type=hiking does not fit here, so I am using type=running. Does somebody have a better idea or has something to add?--U715371 (talk) 22:58, 14 September 2014 (UTC)

Water related routes

Route=canoe has 208 ways mapped as of today 2 August 2015. Will additional water related routes be created? For example: rafting, tubing, water-skiing, snorkeling, diving, deep-sea-diving, sailing, long-distance-sailing.

Will water related routes be distinguished if they are "motorized" (e.g., route=ferry) or self-propelled (route=canoe)?

If route=ferry is already an option, what about route=commercial_boat, motorized_boat etc?

The following questions concern mapping "routes" or "trails" on waterways and rivers.

• If no riverbank or coastline is mapped then:
  • Is a "canoeing trail" or "kayaking trail" added as a secondary feature to an already existing river's way?
  • Or, is a trail added as a separate way (e.g., route=canoe or route=whitewater) next to the river's way?

• If there is riverbank and a river both mapped, then is adding routes inside the riverbank preferable, or is it preferable to add the route=canoe to the river instead of the riverbank?
  • What is the appropriate way to map trails in marshes or in the open ocean? These "waterways" do not have a river or a riverbank? This issue suggests that route=canoe should be distinct from a river or waterway.

• What if there are multiple overlapping and diverging canoe routes on one river?
  • If separate routes are added for each trail that is fine, but if each trail is a feature of the river, then each trail must be mapped as a separate relation. Is that how it is done, or is there another way to map multiple water trails on one river?

Thank you --Peace2 (talk) 16:49, 25 August 2015 (UTC)

See also: https://wiki.openstreetmap.org/wiki/Talk:Whitewater_sports#Please_add_a_section_.22How_to_map.22

Role indication for express/local or inner/outer lanes?

For roads like Roosevelt Boulevard in Philly or I-270 in the Washington, DC area, is there a proper way to indicate the express/local or inner/outer lanes with relation roles, or are both sets of lanes supposed to just be listed with plain north/south/east/west roles? I've seen, for example, roles "east (local)" and "east (express)". Are these acceptable or do they break things?

-- Roadsguy ^(talk)

route role essentially obsolete

The route role is not mentioned in any of the more specific route articles (such as road, bus, ferry, bicycle, hiking, foot). From discussions on the tagging mailing list, specifically this and this, it seems that it was only used occasionally in PTv1. If that's so, I think the wiki should say so more clearly to avoid confusion. So where it currently says:

The route role is invalid in PTv2.

I think it should say:

The route role was used in PTv1 but it is invalid in PTv2 and in other types of routes as well.

--Fernando Trebien (talk) 17:12, 13 January 2018 (UTC)

Handling areas (like squares) within route relations

I am putting quite some effort into straightening out hiking and cycling route relations for all the waymarked trails here in Switzerland (e.g. 65000 km waymarked hiking paths).

A lot of mistakes I bump into are related to the order of ways, and miniature sections of the route not being in OSM since a way is missing in the database. Especially cycling routes often have mistakes when some ways are used for one direction and others for the reverse direction. Generally this fixing is straightforward though in JOSM.

Less obvious, to me at least, is how to handle areas within route relations. Cycling and definitely hiking routes often cross squares in towns, tagged as highway=pedestrian and area=yes. This wiki on route relations does not at all mentions how to handle these within relations.

I see a few problems for just using areas within route relations.

• It does not give relevant, or even confusing data for distance and elevation calculation for the relation, like done by renderers like Waymarkedtrails for example.
• It is not relevant for what would actually be a sensible route to cross the square. An example is the Via Gottardo crossing the Piazza della Riforma in Lugano.
• It is not in line with the actual route marked by signposts or markings, so it is not in line with what is visible on the ground.

Related to this subject is also a forum topic among users from the Netherlands, which can be found here.

Concluding, I think there should be some information included in this wiki on how to approach areas where there is the conflict that no specific path can be seen on the ground (literally), while guidepost and markings show a path figuratively. I don't think it should be carved in stone, since situations may differ, but it would be good to have some information.

An option I see is the following.

• Ignoring the area, and drawing guiding lines which you use within the route relation. An example is the Trans Swiss Trail crossing the Piazza della Riforma in Lugano. The guiding lines have no tagging, and are only used within the route relations. Would it be relevant to add any further tagging?

I invite you to participate in the dialogue to come up with a shared vision.

Cheers, Dikkeknodel (talk) 12:24, 22 May 2018 (UTC)

For me the best way is to use untagged ways crossing the area along reasonnable paths as needed (to make intersections at some arbitrary point in the area where necessary), and not add any tag to these ways, which will only be used by route relations. The route will however not be able to determine easily which kind of path is used, but it one queries some points in the middle of the path to see in which area it is located, you may get info from the area such as the type of surface. Other info like elevation is easily infered (it always have to be estimated by triangulation anyway from the terrain data model or some explicit elevation tags added in a few surrounding nodes). To get the name of the area (e.g. a city square/plazza) crossed by this way, the geometric query should give that info (but it is not required that all places or even streets have names), or you'll tag only one node of your way with a relevant "place" name only (but it may conflict with similar place nodes located around under the same name). I think that Nominatim queries by coordinates are enough to get relevant local place names without needing to add any supplementary "place" name tag on such nodes. So I still think that even nodes of these untagged ways may remain untagged as well: it will be sufficient to just name and tag the area enclosing part or all of these untagged ways.

However some OSM contributors may not like the presence in their editor trool of what they consider as arbitrary strokes not matching any physical object (but the remark is also true when you split long riverbanks at arbritrary cutting segments which are also left untagged themselves. You just collect the multiple fragments of the riverbank in a riverbank relation where it is the only place where tagging and naming is really needed. If you want to avoid polluting too much the map data with arbitrary geometry, just make sure that you avoid multiple segments or nodes superposed, and don't use too many nodes for these single arbitrary segments (these nodes should also remain untagged so that they are easily movable when needed).

For pedestrian or cyling routes anyway, the exact geometry of tracks followed will always vary, and the distances given is just an estimation for some very idealistic track that no one really uses, and the time needed to use it always has large margins of uncertainty as we cannot really predict the speed: people can stop walking anywhere, we can jsut estimate some average speed, but the actual time may be twice faster along the same exact geometric track or could be drammatically slower, due to local conditions, or to other people on this way, or some garbage, or because of current health situation of the worker, just because of preferences and distraction: very few walkers is in an emergency run, and this is true as well for most cyclists that are not urged by a timed delivery mission!). — Verdy_p ^(talk) 16:30, 25 May 2018 (UTC)

Specifying single navigation points/waypoints/stops instead (all) way/route segments?

There are some kinds of routes like shipping routes, desert routes or remote hiking routes which do frequently not consist of exact paths but are specified by waypoints, orientation points, marks or similar. The way between those points might be variable, subject to various conditions.

In other cases, like long distance bus routes the exact path may be completely uninteresting, subject to change depending on traffic flow conditions and all that matters is the actual bus stops.

How do people map those? RicoZ (talk) 20:50, 9 October 2018 (UTC)

Hiking routes should only be mapped when they are physically signposted. The route version you describe with waypoints and the like sounds very much like a route described by somebody in a book or on a website, but not actually signposted in the real world. So I think at least for hiking routes this problem is purely theoretical. Dikkeknodel (talk) 18:56, 16 October 2018 (UTC)

About "Creating super-relations for routes"

Hi. I wonder if this section is up to date? Waymarked trails has no problems with superroutes. If they can render it, the missing rendering on the cyclemap seems to be a renderbug that is irrelevant. I would like to shorten down this section and link to Super-Relation instead. Could we agree on the following best practice:

1. a relation containing other relations should always be type=superroute
2. a relation should only be part of 1 superrelation if possible
3. a superrelation can contain superrelations see example.
4. avoid superrelation with the purpose of categorizing e.g. all lakes in a country or the like. A valid exception is the Great Lakes-relation with 5 lakes.
5. super-relations increases complexity and should be avoided e.g. on multipolygon of landuses where adjacent multipolygons could do the job well without a lot of members. (see this video for how to edit adjacent relations easily with JOSM and Relation Toolbox)--PangoSE (talk) 12:11, 29 October 2018 (UTC)

Forward/backward roles on Public Transport

The page currently says "These roles should not be used any more on public transport routes". Is this correct? This is definitely correct for PTv2 but I don't see why it would apply to PTv1.

Adavidson (talk) 00:29, 20 August 2019 (UTC)

I have edited to try to make this clearer --InsertUser (talk) 22:30, 14 October 2023 (UTC)

route=raceway?

There is a long stalled proposal for a new relation type, circuit, for racing circuits. I've been busy mapping race tracks and using the proposal, but I've been thinking that a circuit type may be better done as a variant on the route relation, e.g. route=raceway either approach would work for my purposes and since not enough people are interested in a new relation type maybe this would be easier to move to official status. Nfgusedautoparts (talk) 12:50, 16 June 2020 (UTC)

Splitting up routes by type?

@Multimodaal: - I don't see a benefit from splitting up the route list on Key:power into "Land based infrastructure and transport", "Public transport", "Recreational land based routes", and "Water based transport and recreational routes". First, a ferry route can be considered a type of public transport. Second, routes such as route=bicycle are not only used for recreation, but also for traveling from home to shops or work or school. By trying to artificially divide the values into a few sections, we will usually end up with mistakes. I'm not sure that categories are needed. But if this is considered necessary, they should be very clear distinctions such as "land transport" and "water transport" --Jeisenbe (talk) 06:54, 28 November 2020 (UTC)

Now that I tried fixing it, I also see that route=tracks and route=railway are confusing - are they public transport related or infrastucture or land transport? Maybe it's best to keep them all together in one table. --Jeisenbe (talk) 07:11, 28 November 2020 (UTC)

The huge alphabetic list of all values is rather confusing if you try to a suitable tag for a real-life route that you want to add to OSM. For instance: there are 5 types of routes for pedestrians, and the are scattered all through the alfabetical list amongst other types that are not relevant for a mapper looking for a tag. Splitting up the list makes finding a suitable tag easier. I added a reference to the alfabetical list, since that has its own uses as well. Cheers Multimodaal (talk) 13:29, 28 November 2020 (UTC)

I used your earlier suggestion (from Talk:Proposed_features/Recreational_route_relation_roles#Post-vote_cleanup for the distinction of motorized/non-motorized instead of recreational/non-recreational, you are right that that is a better defined distinction, thx! Multimodaal (talk) 13:42, 28 November 2020 (UTC)

When thinking about ferries, let's not forget there can be very small and insignificant ferry routes (at least compared to huge ferries that travel on the sea and carry vehicles). E.g. in Berlin there are several ferries which are operated by the local public transport operator (BVG) and may be only used by pedestrians and bicylces. One example is here, 200m over a river: https://www.openstreetmap.org/relation/9445410 a slightly longer one here: https://www.openstreetmap.org/way/23045303 There is also an overview page in wikipedia with some impressions: https://en.wikipedia.org/wiki/Ferry_transport_in_Berlin --Dieterdreist (talk) 18:33, 28 November 2020 (UTC)

Remove route=power?

I'm not certain if we should mention route=power on this page.

1) It doesn't match the other types of route, which are all about transport of some kind. Note that the description on the Key:route page of the keys is "A customary or regular line of passage or travel, often predetermined and publicized".

2) The proposal for route=power appears to have been abandoned in favor of using type=power + power=circuit for these relations. See old Proposed_features/Power_routing_proposal/Tagging_similar_to_Transportation_routes and new Proposed_features/Power_routing_proposal.

3) route=power has no documentation (no Tag:route=power page or similar).

So I would suggest removing route=power from the list on Key:power. --Jeisenbe (talk)

I understand that the tag is controversial (I do no like it very much myself), but it is one of the most used tags for Key:route (currently 18.382 times, it's in 8th place of most used values for this key, on a total of 1.113 values, see Taginfo. Since just hiding the references will not help, I have added a text about controversy of this tag. The wiki should describe which tags are used, so that people can form their own opinion and can take action if the think it is necessary (such as making a proposal for retagging these items to a better tag). Cheers Multimodaal (talk) 13:36, 28 November 2020 (UTC)

The first step would be to document the tag at it's own page (like Tag:route=power) which currently is only redirected to a subpage of a proposal. Note that on the list at Key:route there is no definition at all in the taglist, since there is no page. --Jeisenbe (talk) 07:55, 29 November 2020 (UTC)

Addition of rare water routes

@Kannix: and @DiGro: - who have recented added route=waterway and route=motorboat to the list on Key:route. These two tags have only been used a couple of hundred times each, and did not get discussed in the Proposal process. It appears that route=motorboat and route=waterway are quite similar: the first is defined as a "Signed recreational motorboat route" and the second as a "A signed route for motorboats and ships along a navigable waterway", but there is no clear definition given for what distinguishes a ship from a motorboat. Rather than adding both of these tags to the page, I believe the proponents should discuss which tag is prefered, since they appear to be quite similar. --Jeisenbe (talk) 07:18, 28 November 2020 (UTC)

This tag is now used more frequently than many other tags on this page and when looking at the work done on actual routes they cover very large areas. Mentioning this tag here makes other people aware of the existence of this tag, so they can form their own opinion and join the discussion on talk:route=waterway if they want. Cheers. Multimodaal (talk) 13:39, 28 November 2020 (UTC) 

School bus

I suggest adding value route=school_bus

Semi-colon separated route values

There is a lot of relation out there with semi-colon separated route values, such as route='hiking;bicycle;horse' and every flavor one can think off. I guess that as there is so many, this is probably not wrong, it's just a fact.

The obvious alternative is to create quasi-duplicated relations with a single route=* value. It seems simpler, easier to dealt with for data consumer and also to maintain (what if I'm a cyclist and don't know about horse-riding specificity ?).

In your opinion, what are pro and cons of each method? Is there a specific meaning conveyed by semi-colon separated values? --Yvecai (talk) 11:10, 23 January 2022 (UTC)

This was already discussed a while ago on the tagging mailing list, see How to tag recreational route with multiple route types? The semicolon sparated lists can help to avoid unnecessary redundancy, so I would not agree that the "obvious alternative [...] seems simpler, easier [...] to maintain". But data consumers do not only have to evaluate semicolon separated lists in key route=* but also in key network=*, example Bicentennial National Trail Bicentennial National Trail / [13] --Hufkratzer (talk) 13:45, 23 January 2022 (UTC)

role=information

Hi @Fred73000: Thanks for your "contribution" (essentially removing part of my work). I should've added examples. role=information for a tourist office makes sense for example on hiking routes where there is a tourist office right at the start of the route that serves information about this route. role=site makes sense for example at a hiking/walking route that has an educational theme about WWII with memorials along the way. I want to restore my edits, but I'd like to hear about your concerns before I do so. -- Martianfreeloader (talk) 16:19, 7 May 2022 (UTC)

information conflicts with other tourism=information + information=* eg guidepost. There are twice as many board, although there are only 3 touristoffice instances. https://taginfo.openstreetmap.org/relations/?rtype=route#roles

Can you tell us what is the actual usage site? I imagine it might also be used for eg the "site" enclosing a network=l*n. Examining checkpoint (cf checkpoint=*) or destination would be better.

--- Kovposch (talk) 08:10, 8 May 2022 (UTC)

Ok, maybe I should phrase this as a question. Which roles should the following things have if they are obviously part of a specific route? Memorials. Information boards. Tourist offices. Artworks. -- Martianfreeloader (talk) 19:34, 8 May 2022 (UTC)

attraction (67 instances), board (2134 instances), office (new), and exhibit (new) (exhibit=* is discussed in Talk:Key:exhibit#Standalone/Outdoor_exhibits)?

Maybe even create eg excursion_destination and approach_destination to correspond to excursion and approach in Roles for recreational route relations. --- Kovposch (talk) 03:13, 9 May 2022 (UTC)

I'm in principle fine with whatever. I just have some concerns that attraction for a memorial for KIA or victims of genocide may be inappropriate wording. I thought site could be more neutral and can be used for playgrounds/picnic areas/toys as well as memorials/monuments/sanctuaries/shrines (and many others...) that are clearly part of a (hiking) route. -- Martianfreeloader (talk) 12:32, 12 May 2022 (UTC)

@Kovposch:, @Fred73000: If you can think of a better scheme than mine, would you mind documenting it? I've tried to make a constructive contribution and document which roles certain things should have, but it was reverted. I'm not tied to the specific solution that I had documented but would appreciate if there were some documentation of how to do that. I just wanna know how to map hiking relations (because mapping them is what I actually want to do), so I'm happy to do that in any consistent, documented way that makes sense. -- Martianfreeloader (talk) 12:40, 12 May 2022 (UTC)

@Martianfreeloader. Sorry to have removed things with not enough explanations and thanks for your askings. My answer is a general answer = elements with a specific tag should talk about this tag and only this tag, no need to mix informations of different kinds. To be more clear, you have chosen to mix route elements with tourism elements. My question is now : what next ? For example, for a foot/bicycle route, it will be very interesting to know places where you can eat or places where you can sleep along this route. So do you think it will be a good idea to add restaurants, hotels, campsites with a specific role in the route relation ? Of course not because there are too many and route relations will be huge, probably incomplete, impossible to maintain. For tourism it is the same : the informations about tourism are in osm, someone who wants these informations will find them easily, no need to duplicate these informations because it will be obviously incomplete (with a suspicious of advertising : why to add this place and not another one ? just because the second has been forgotten ? Or because a user has a private interest and wants people come in his hotel, in his restaurant, in his museum and not in another one ?) and impossible to maintain (a museum goes bankrupt, the building is purchased by a compagny, in osm the element will stay but the tag museum is changed to office. Nobody will search/look in which relations this element is used, so you will have in your route an office with the role site). Best regards. Fred73000 (talk) 18:14, 14 May 2022 (UTC)

The route I want to map is this one (en) here. The path was specifically designed to pass by monuments and memorials and these are the major contents of the route (see this picture, where the logo of the path (POT in capital lettres) is on the monument). I find it strange that in situations like this, guideposts should be part of the relation but the monuments and memorials which are the actual content of the route aren't. -- Martianfreeloader (talk) 07:46, 16 May 2022 (UTC)

In this particular case, it is not the monuments/memorials which is part of the route but the monuments/memorials should be together in a site relation and the route should (could) be a part of the site with the role 'route'. The problem to add the role "site" for museums, artworks, tourist attractions on the wiki page "route" means that you tell to every mappers that, for a bus route in Paris, you allowed to add all museums, all artworks, all attractions along this bus route. With the question : where to stop ? A museum at 100 m from the route is ok ? 500 m ? 1 km ? The answer for me is clear = 0 m (meanwhile = none). A site should not be a part of the route but yes, a route may be a part of a site. Best regards Fred73000 (talk) 14:51, 28 May 2022 (UTC)

I disagree and don't find your reasons for reverting my edit convincing. But I find this discussion nonconstructive and exhausting; I'll just continue mapping. Thanks for your opinion. -- Martianfreeloader (talk) 15:01, 28 May 2022 (UTC)

Maybe you could read the 4 first lines of the page 'relation:route" and then read the 7 first lines of the page 'relation:site' to understand that your example (Pot spominov in tovarištva) is not a route (according to wiki definitions) but a site which contains a route (the trails) and others elements. Best regards. Fred73000 (talk) 15:53, 4 June 2022 (UTC)

Should tourism=yes be added to relations?

There is conflicting information as to whether the tourism=yes tag should be added to relations. See: https://wiki.openstreetmap.org/wiki/Relation:route which states that this is an optional tag when adding new relations, and https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dyes which indicates it should not be used on relations. It would be good to gauge the opinion for how this tag should be used amongst the community as this has not otherwise been clarified. Thanks