Proposal talk:Destination Signs

A clarification

The idea is not to help the software making a route, but to help the user following it once it's made.

Members like Relation:restriction?

Maybe we should have the relation members close to what we have in Relation:restriction? Mappers shouldn't have to learn a new tagging system for each feature, and in a way they are similar. --Cohan 04:43, 5 December 2008 (UTC)

except that for this proposal there's no need for a "from" member, only a "to". --Eimai 12:13, 5 December 2008 (UTC)

No, consider this:

If at B you have signs to D, E and F, and at F have signs to A, B, and C you'll get incorrect results only using a "to"-member regardless wheater you're using nodes or ways as member. However, I could agree that you don't need a from and a via-member. But B->D will be different signs than F->D. --Cohan 03:01, 10 December 2008 (UTC)

You need a minimum of two members in this, the node where you need to know which direction to take (the intersection), and something to go to. To give the routing software as much to work with as possible, preferably the first way leading from the intersection, the from node is only interesting when a destination is marked from only limited directions in the intersection, the via member is only needed when to is not a way, for instance when the sign is to an amenity. If you are looking for a sign pointing you to a tourist attraction, to should point on the attraction, and via should point at the way. --Skippern 03:35, 10 December 2008 (UTC)

Reference

If the sign refers to road number (A11 / E6 / RV123), why not allow for a ref tag in the relation? --Skippern 12:58, 8 December 2008 (UTC)

Likewise, you could have every amenity (hospital, police, town hall, airport...) or every touristic "something" (a touristic river valley, a monument, a theme park, ...), or restaurants, industry parks... --Eimai 13:38, 8 December 2008 (UTC)

Then comes the question how we should handle multiple signs pointing in the same initial direction. Should they all go in one relation, or should there be one relation for each sign? In the latter a ref=* is a splendid idea! An example is a crossing nearby where you can turn left and follow road 92 towards Dorotea or follow road E 12 towards Mo I Rana. If I make one relation towards Dorotea with ref=92 and one relation to Mo I Rana with ref=E 12 this makes sense, but not if both destinations are clamped in one relation. Also using the amenity=* and such is a great idea, but should, as I see it, only be used when a corresponding icon is used on the road sign. (E.g. hospitals, airports, parkings...) This also solves the problem with signs only showing an icon or a road ref but no destination. --Cohan 03:39, 10 December 2008 (UTC)

complex routing

Where complex routing is necessary to get to the destination, what about allowing the ways you need to go be members of the relation? Example, in my home town, a sign is put up in a crossing that to take a left you need to make 3 right turns, including bypassing a street that is oneway in the wrong direction. --Skippern 13:01, 8 December 2008 (UTC)

Maybe I misunderstand you, but shouldn't a routing software be able to figure that out for itself? --Cohan 03:06, 10 December 2008 (UTC)

The routing software will not be depending on signs, but if it is going to give you sign information to aid you there, than the sign must be correct, if you have a road side sign pointing the streets you have to drive to get there, than inheriting these streets into the sign will allow the routing software to recognize that. Besides, the no-left-turn restriction might give the routing software a different idea than the signs, and might send you on unsigned roads to the destination, if signs are given the right relations, than it might also be given priority in the routing software. --Skippern 04:07, 10 December 2008 (UTC)

Destination signs for only some vehicle types

We have signs here like: (similar signs are possible for pedestrians, cyclists or horses, or a combination of those), where the sign is just for a certain category of road users (and where cars would have serious troubles trying to follow them :-) ). How to fit that into this proposal? --Eimai 13:45, 8 December 2008 (UTC)

Relation:Restriction as member? --Skippern 03:27, 9 December 2008 (UTC)

Wouldn't it be easier with access tags (e.g. bicycle=yes) --Cohan 02:35, 10 December 2008 (UTC)

Probably yes, but if you are routing through a road with a restriction relation, why not use it in the sign as well, so whenever the restriction changes, so will the sign. --Skippern 03:06, 10 December 2008 (UTC)

Will it be any problems at all? If it points to a cycleway a routing software (set for car navigation) shouldn't want to make a turn there in the first place, and if it points to a road which later on becomes a cycleway that leads to the signed destination a car could still use it as navigational aid to other destinations on the road before the cycleway. Maybe some tag to make the routing software show a bike/horse/... icon would be nice though. --Cohan 03:51, 10 December 2008 (UTC)

The problem is that these signs aren't really put on locations which are always visible for cars, even though both roads may allow cars. These signs are also much smaller than the ones for cars. Basically, you don't want to get instructions to follow an arrow like above in a car. --Eimai 13:23, 10 December 2008 (UTC)

I see your point. Well, then neither my latest suggention to ignore it nor the restriction-relation is an option. That leaves the use of access tags in some form. We could either use the same as for roads (e.g. bicycle=designated, motorcar=no etc. Perhaps with slightly modified meaning of designated) or make one of our own like usable_by=bicycle. --Cohan 22:19, 10 December 2008 (UTC)

Why restrict routing software to cars? I know there are good routing units to be used with motorcycles, so why not allow this to be used by cycles, horse riders, or other that might want to? Besides, a restriction might also be set for heavy goods vehicles or other as well. My point is that the routing software should be configurable to what restrictions to follow, so that a heavy goods vehicle shouldn't be sent up a road designated for small cars, a car should never be sent down a cycleway, but a bike should be allowed down a road (unless there is a restriction against cycles). If we use the Relation:Restriction as a member of the sign relation, than the sign (and the routing software) will be updated when the restriction is changed. --Skippern 04:03, 10 December 2008 (UTC)

I can't see where I'm restricting myself to car navigation. Set the unit to pedestrian and it won't suggest that you turn right upon the motorway link, and hence it won't show that you should follow the sign pointing towards that link. Set it for HGV and the routing software will make a route that's valid for a HGV and since no unappropriate roads will be driven on, the unit will never show signs pointing to those road, thus making all kinds of restrictions applied to the signs redundant since they are already on the map. (Exception is a "no-left-turn for HGV"-restriction, which isn't really "on the map", but since the unit in the planning stage already abides to that there's no need to put that extra information with the signs.) --Cohan 04:23, 10 December 2008 (UTC)

btw, I really don't understand what all this has to do with the restriction relation? --Eimai 13:28, 10 December 2008 (UTC)

One for all or each one by themselves?

As I said on the proposal page, and has been lifted earlier on this discussion page, we have to figure out how to deal with several signs pointing in the same initial direction in an intersection. As I see there are two options. Please fill in pros and cons. --Cohan 04:23, 10 December 2008 (UTC)

• [A] One relation for each sign
  • + Makes it easy to use with ref=* and such
  • - Could lead to lots of relations
• [B] One relation for each initial direction in the intersection

• [C] one relation for a sign/guidepost by using separable tags in the relation

direction:1:a=name1 direction:1:b=namea2 distance:1:a=distance to name1 . . . direction:2:a=name1 direction:2:b=name2 distance:2:a=distance to name1

that will cover huge guideposts with many arrows. it seams better to put the information into the relation (or the guidepost?) because its more error-prone against deletion of nodes in the way. (e.g. as in edits from crossing into roundabout) real life example [1] the sign node has all information from the surveyor inherit. --Shony 22:19, 26 July 2010 (UTC)

• [D] one relation for all signs pointing to any single destination, as described at Relation:destinationsign. Or several relations if the relation would grow too big to handle comfortably. Alv 05:45, 27 July 2010 (UTC)

A note to makers of routing software

A good routing software would look ahead and see what destinations are shown further down the road and minimize the number of different destinations shown. We use the nice example-map above and pretend the red dots are cities instead of nodes. Lets say you're going from G to some obscure place between A and B. At F you have signs pointing to A, B, C and D and at B you have signs pointing to A and C. The routing software should then tell you already at F to drive towards A.

As long as you only look at "Destination Signs" -relations at the next n crossings along an already calculated route this sounds like a nice to have feature for the future (once there is signposting-data and then support for it in the driving instructions at all.). --MarcusWolschon 09:55, 2 March 2009 (UTC)

driving instructions prepared to use this relation

On the page Sample driving instructions‎ we now have translated driving instructions to make use of this relation later on. --MarcusWolschon 09:55, 2 March 2009 (UTC)

Suggestion to example on front page

Way or Node	Role	Recurrence?	Description
	intersection	one	The intersection where the sign is posted
	to	one	Destination or Direction
	via	optional	Needed when to is NOT adjescent to the sign
	from	optional	For junctions where some, but not all ways have sign pointing to destination.

The ideal is if use of relation on the via tag allows to inherit the ref from the relation, and if to is not a way or place, let it add the symbol from the inherited destination. This can allow you to render a museum symbol of a sign pointing to a museum without making a long list of symbols to specify in this relation. The same goes for use a relation of a cycleway in via that will render a cycle symbol on the sign. Any thoughts? --Skippern 05:38, 10 December 2008 (UTC)

Do we really want a museum/zoo/... icon to be shown in the navigation aid if it's not shown on the road sign? I wouldn't. Then I'd be on the lookout for a museum-icon sign along the road when in fact there are none. Hospitals have icons on road signs, (larger) parkings have icons, airports have icons, museums (at least in Sweden) does not.

Very good table! But I don't think the to node should be the destination for two reasons. 1. The destination could be more than 500 km away which make it quite tiresome to set up the relation. Not to mension that larger cities and capitals tend to have roadsigns pointing to them from quite a distance, and hence you could end up with literally thousands of relations having the node of the city as the to node, which makes editing other relations in the city area a pain. (Both JOSM and potlatch would load every relation for every sign pointing to the city.) 2. I might not be a bit interested in the signed destination, but still want to follow that to get where I'm going. My idea when I set up the proposal was to get something like this. I should follow the E 4 towards Malmö. Whether I'm going to Malmö is irrelevant. My destination might be Ystad, but there isn't a sign for Ystad in the intersection so I'll have to follow the sign towards Malmö for now. In the example "map" above, let's say you're going from A to D or A to E, but the only sign for turning left at B is towards G. I should then be told to follow the sign towards G even tough that's not my destination. I therefore belive that the to member of the relation should be a (the first) node or way after the intersection and not the destination the sign is referring to. --Cohan 21:21, 10 December 2008 (UTC)

As I said, this can allow for these symbols to be rendered, but that is for other software to decide, besides signs to amenities and smaller attractions tends to be within short distance only, when a larger place is the destination on the sign, use the name tag and some node close on the road or the road to follow as destination, I'll change that to destination/direction if you like that better. --Skippern 13:07, 11 December 2008 (UTC)

It depends on the country which icons there are. My opinion is that if the sign on the road has an icon, there's a reason why one would want to add that to this relation somehow, as too much information can't hurt. The signs for Belgium are here (all the S-numbered icons), and here for the sport icons. --Eimai 13:19, 11 December 2008 (UTC)

Exactly my point, by linking a hospital sign to the hospital itself, than the symbol can show up if it is of interest, besides, signs for St. Olavs Hospital are generally only in one part of Trondheim (main hospital in Trondheim) so I do not expect to see signs for it in Orkanger (a nearby town), but than Oslo are signed in Trondheim, and the distance is several hundred km, but than I would use the E6 relation as that is the road leading to Oslo, and that way get the E6 road-number logo on the sign. Nothing in this relation should give any automatic rendering, but allow for information that can be used in several different ways. If you want to overide icon rendering, why not use a noicon=true tag in the relation? I for one would rather let the relation have all information that might be useful than miss out information, and that way make a demand for more relations. --Skippern 13:30, 11 December 2008 (UTC)

Come to think of it, a roundabout can be an intersection, and signs are generally put at the exits, as well as a full description of the roads before arriving from the main roads. The intersection should also accept way as a member. --Skippern 13:33, 11 December 2008 (UTC)

That could still be managed by placing the relation intersection member on the very node in the roundabout from which the road to be followed exits. Allowing a way as intersection adds a great risk of errors and more or less requires that all intersections on that way are signed with the same destination. Unless the via member is required, which might be a good idea anyway since it greatly simplifies programming of the guiding software. To have all the features without introducing more risk maybe the to-member should be destination and optional, and the via-member direction and required? The implementation thus beeing as simple as that you follow a (prevously made) route, look for if you're passing a from and via of the same relation and if so show the sign specified by either the to-member or the name-tag. Maybe we also should have a icon-member since at the moment we sometimes want the icon from the via-member and sometimes from the to-member, which also helps when sometimes signs pointing to nearby cities are shown with road designation and sometimes without. --Cohan 17:04, 13 December 2008 (UTC)

But that might require the same object to be a member two times with different function, and as far as I know, that isn't supported. Each object can be member of only one role in relations. If you want to use E6 as the to or via in the relation, than you would need to find another part of E6 as the icon relation. It might work if you use the E6 way as one member and the E6 relation in another member. --Skippern 17:19, 13 December 2008 (UTC)

That's true. Aaaaarrgh! This turned out to be a bit more complicated than I first expected. :) --Cohan 11:37, 14 December 2008 (UTC)

It could be solved with an icon-tag. That would allow generic as well as country-specific looks of icons and that roadsigns with icons will have icons and roadsigns without will be without. However, it will be quite tedious, require an icon set and it's not really working with road numbers so I'm not sure this is the best solution. --Cohan 12:34, 14 December 2008 (UTC)

To solve this we might require an API written for this relation, something that enables us to extract icon information in a useful way and put it in the relation. --Skippern 12:38, 14 December 2008 (UTC)

Maybe we should start small and then expand it later on. If we omit support for icons for now, how is the relation suggestion then? What should be mandantory / optional of the from/via/to members? (The intersection member being mandatory.) --Cohan 21:33, 30 December 2008 (UTC)

Flow for practical use of the relations later on

I thought I line this up in a nice numbered list. It will hopefully help spotting problems.

1. Check for destination_sign-relations along the route (which is already made and we are about to follow).
2. Keep all relations where the route passes the intersection member and then the via member of the same relation. (discussed)
3. Remove all relations that have from member(s) but no from member is being passed through by the route.
4. If necessary (e.g. on devices with small screens) remove relations (in a smart way) so there is no more than one relation shown in each intersection.
5. Show to the user a sign (possibly with specified colours) with the name either from the to-member or from the destination-tag. If specified, also show icon from '???'

One of the better ways to reduce signs is to follow signs with the same destination for as long as possible. E.g. if I'm going to Timrå I should follow the sign "E 4 Sundsvall", but I could also follow the sign "Umeå" and then "Örnsköldsvik" and then "Sundsvall" and I would still be following the exact same route. It's just a little more convenient to follow the Sundsvall-sign from the beginning. --Cohan 12:08, 14 December 2008 (UTC)

Different signs for the same intersection

Today I found an intersection where the sign standing a few 100 meters ahead of the intersection stated 3 destinations if you turned right at the intersection. At the intersection there were also signs for 3 destinations if you followed the road leading to the right, but only one destination was the same as on the sign a few 100 meters earlier. How can we handle this? In this special case we could just add the only destination that appears both before and at the intersection. But perhaps we need a more general solution.

A possibility that's not breaking the current syntax is to have a relation for the intersection and another relation with the intersection node ahead of the real intersection. Does this mess things up? --Cohan 21:43, 30 December 2008 (UTC)

Why an intersection?

Why shouldn't we just do a "sign" node for the location of the sign? There would be 1 sign node, 1 direction (via/to) way, and 1+ from ways. There doesn't necessarily have to be an intersection. Think of signs on motorways for instance. This variant also solves the problem above: each sign would be a different relation.

That was sort of the solution I was thinking of, but I forgot to write out the change of intersection-node to sign-node. Thanks for clarifying. I'll put that in the proposal. --Cohan 00:57, 22 January 2009 (UTC)

* for "all directions"

Can someone explain the * for "all directions" part of the destination-tag? As I thought it when I wrote the original proposal the destination tag is the actual text on the sign, so putting a * for "all directions" makes no sense to me. --Cohan 14:58, 7 March 2009 (UTC)

I suppose it's for what we have here in Belgium as well: signs literally saying "All directions →". Meaning that if you want to get out of the place, you have to follow that arrow, whatever your destination is. Don't know if it's better to write "*" for that, or just what's on the sign. --Eimai 15:28, 7 March 2009 (UTC)

In Germany we also have signs "all directions"="Alle Richtungen". It is not the name of a place, so it cannot be used in the same sentence-structure for driving directions. Therefore there needs to be a way to determine if this sign is for "all directions" or for a specific place. The actual text seems to be fixed in all countries and can thus be translated. --MarcusWolschon 06:51, 9 March 2009 (UTC)

Oh, I see. You learn something new every day. (We don't have such signs in Sweden.) In that case a * should work fine. --Cohan 16:21, 17 March 2009 (UTC)

But if we're going to give special values for the "meta-destinations", we're going to need more of these. There are also signs here for example like "Doorgaand verkeer", meaning "traffic that's going through the place". Or "Andere richtingen" ("other directions"). If "all directions" gets a "*" symbol, signs like these have to get one as well, so I propose to just enter whatever is on the sign, without special symbols. --Eimai 18:04, 17 March 2009 (UTC)

You've got a point. And a thought on translations: If I'm driving in a country where I don't speak the native language I want to see what I should look for on the signs, and not what it means. So perhaps it's just best to enter what the sign says. --Cohan 19:18, 17 March 2009 (UTC)

Litteral text (with eventual translations)

I think it sould be possible to just note the litteral text of the sign with for exemple time / distance / generic destination (ALL, other, center, ...)

--EMerzh 09:33, 2 July 2009 (UTC)

Alternate labels

As proposed by ck3d during voting:

• key:destination should be key:label. The label and the destination can be different.
• A member as role:destination should point to the destination.
• I prefer type=sign instead of type=destination_sign. If a role:destination role is given, it's automatically a destination sign.

--Cohan 17:14, 18 July 2009 (UTC)

I'm not sure why the destination member should be that important (the suggestion seems to imply it should even be required), maybe ck3d can provide some reasons here - and some use-cases that need this information. The known use-cases (2D/3D rendering, "follow the sign labelled X" hints) don't need it. Currently, it only seems to make entering the signs harder, because the destination can be rather far away and might not be part of the currently edited bounding box.

If a destination member (only optional) is given, you have much more information. Renderer or router could also provide:

• a calculated distance (along street, direct horizontal or vertical) to a destination
• additional information related to a destination, like a translated or entire name of a destination (for example: name=München, name:en=Munich)

--ck3d 19:18, 18 July 2009 (UTC)

Well, if it is optional, I won't oppose that one. Everyone can add what they consider worth the effort, after all. Right now, I cannot imagine a situation where this would really help me. --Tordanik 20:53, 18 July 2009 (UTC)

Using a more general type value does only make sense if there are applications that can handle all objects with that type uniformly. So, for example, the highway=service + service=parking_aisle solution is preferable because for some applications, highway=service is enough information. Are there applications that will handle all traffic signs exactly the same? If no, type=destination_sign is preferable because it makes documentation easier (for example, we usually have one wiki page per tag/type) and makes it easier to spot errors such as missing members.

Look at the relation type=route. More and more route types has been defined. I think we should go the same way. After destination sign we get for example a traffic sign which relates only to a street, or a information board/sign which relates to a historic building.

We should define the tags type=sign and sign=destination and the destination member with a blank role, same scheme as for the route relations. --ck3d 19:18, 18 July 2009 (UTC)

Routes, however, all have more or less the same members: ways making up the route. Imo, this is why a common type makes sense. What are the members/tags that will be the same for all sign relations? The sign node, probably. Anything else? --Tordanik 20:53, 18 July 2009 (UTC)

From, to and intersection will also be different. --ck3d 08:49, 19 July 2009 (UTC)

I don't care much about destination vs. label, but please be aware that "label" has been used in some proposed relations as a role for rendering hints. To sum up my opinion, I'm far from convinced that these suggestions would improve the proposal. --Tordanik 17:57, 18 July 2009 (UTC)

I think it doesn't matter because in your example, this label has a different content. For me label is like name or ref, which are multi reusable. --ck3d 19:18, 18 July 2009 (UTC)

Just wanted to mention it. It would be nice to have some more people's opinions about that tag's name. --Tordanik 20:53, 18 July 2009 (UTC)

Either way is fine by me. While using destination as a node member pointing to the actual destinaiton is irrelevant as per my original proposal I don't oppose such (optional) usage if there are useful applications for it. Perhaps the use of "label" or "name" as the key better describes my intention of the relation (and feels more correct if the sign says "Exit" or other non-place guidance) - you follow a label, not necessarily a destination. However you might think of the implication using a destination node. Think "London" or other major city. If the London-node were to be the destination member of what I just can assume to be thousands of sign-relations (there ought to be good number of signs pointing London) there will be trouble with some editors. I find Potlatch hard to use for relation purposes when there are more than 20-30 relations in the current field of view. Imagine the bloated relation list of JOSM... --Cohan 10:20, 21 July 2009 (UTC)

Yes, it will be hard mapping it. But if no member destination is given, a router will not determine which destination is meant and therefore completly unuseable! It will be only a feature for a renderer. --ck3d 16:20, 21 July 2009 (UTC)

This is not intended for routing decicions. This is for ease the following of a already made route. At least that's how I thought of it when I wrote the original proposal. An example: the route I have somehow got says I should turn left at the next intersection. At that intersection there happens to be a sign pointing left stating "Xyztown". The navigator should then tell me to follow the sign to Xyztown. Regardless if that's my destination or not - but that sign is pointing in the right direction at that intersection and hence eases navigation. --Cohan 19:19, 21 July 2009 (UTC)

sign member

Do I understand correctly that the sign member is supposed to be placed on the way or intersection, even if the sign is next to it in reality (as in the photograph)? This might make some applications impossible. Information about the signs placement is required, for example, for 3D rendering software. --Tordanik 18:05, 18 July 2009 (UTC)

In the original proposal there was also an intersection member. Is it really needed with two different members? It is not like we are putting the sign on the map, but rather provides the information of the sign. I think that sign and intersection members can be combined, and therefor put on the way (the intersecting node) --Skippern 09:38, 19 July 2009 (UTC)

I do not agree with "it is not like we are putting the sign on the map" - why shouldn't an application be able to do this if it wants to? My suggestion would therefore be to use the intersection member as you describe, but still allow an optional node with sign role to mark the place where the sign actually is (i.e. usually not on the way). --Tordanik 10:58, 19 July 2009 (UTC)

My original idea was to get something like this - to get where you are going - wether it's Malmö, Ystad, Copenhagen, Rome, Cairo, London, the airport, your local supermarket, your daughter's scool or your house - you should for now follow the sign "E4 Malmö", because that's the sign that points you in the right direction at the next intersection. That the actual destination of the sign is Malmö is irrelevant - the only thing of interest is that following the sign makes you turn left, and left is what you should turn to reach your destination - whatever your actual destination is. I never thougt of this as something to be rendered on maps, but just shown in an information box in a navigator or in print in a turn-by-turn description. If this is to be rendered then perhaps there has to be some adjustments.

As of the sign and intersection-nodes (both are still present in the current voting proposal); the use of a sign node came since I was traveling on the highway and reached a sign "In 1000 m take the right exit to reach place A, B and C". 1000 m later I came to the exit with a sign "Take this right exit to reach place A, D and E". Hence a need for different information to be presented to the user depending on how far from the intersection you are - ie in addition to which intersection the information regards (the intersection node), you sometimes have to specify how far that information is valid (the sign node). For a navigational software this is easier if the sign node is on the road. --Cohan 09:12, 21 July 2009 (UTC)

You are right, for your intended purpose it's easier if the position information is projected onto the way. However, I'd also like to be able to render those and for that purpose the true position of the sign is required, as it cannot be reconstructed. Of course, it's entirely possible to use a new role for that so it's optionally possible to tag both. I only referred to the "sign" member because I first thought that "The point where the sign is" meant the physical place of the sign. And, actually, I would prefer using "sign" for the physical position and "position" or sth. similar for the abstract position - the words fit better this way than the other way round, imo. --Tordanik 10:28, 21 July 2009 (UTC)

Not only "follow signs to"

I've recently entered several signs (as type=destinationsign for now, just because the syntax is a bit different) but think that some things could be rewritten. The API 0.6 has ordered relations and allows ways to be members multiple times in one relation, which facilitates some things. IMO editing the relations is more awkward if the from and to members are just nodes.

Besides giving navigating software the ability to show "show signs leading to place X", these signs in themselves are interesting in the sense that they reveal something of the importance of the place. It's likely that even places quite far from the country capital have signs pointing to it while smaller cities appear in the signs only in the adjoining cities; likewise some suburbs are more "important" than others.

As I live in a bilingual country, where some cities have only one name and others have different names in the two languages, the signs to one destination vary from place to place, too. Some have one line, others have two lines.

Basically the sign relations could be more like the turn restrictions (as already discussed above, yet that was pre API 0.6).

members
role	type	description
destination	node	the destination itself
from	way	the way leading to an intersection
sign	node (optional)	location of the sign itself
via	node/way (zero to many)	the node at or ways over the intersection
to	way	the way leaving the intersection

One relation could have repeated members (except for the destination): after a to there could a next from -> via -> to sequence. If there's only one sign or direction, the order isn't important.

This way several signs in one intersection (for coming to that intersection from different directions) can be in the same relation; a sign member applies to all from ways before it in the relation, but after the previous sign member. The via and to members act the same; one to is the direction to use for all previous from and via members after the previous to member. It's then also possible to use the same relation for several intersections; the signs around the country do point to the same destination node. In a sense they're "scattered partial routes".

I haven't yet made up my mind on how to store the information that some of the signs have the label in two languages (two rows) and other's don't, even when the member destination has both name and name:sv. Maybe have two relations: one relation has only name=Helsinki and the other that includes signs with both names has also name:sv=Helsingfors. Then there's actually even third variant used inside the city border: Keskusta (for center). Alv 07:38, 20 July 2009 (UTC)

I generally agree with the role definitions from your table (except that the destination member should be "optional" and not necessarily a node).

However, I do not believe that expressing several signs with one relation by using the (very fragile) information encoded in member ordering is a good idea. The "one relation per sign" approach is easy to understand, even for someone who encounters a relation like this without having read the documentation. That person would not know that the order of members has any meaning. Imo, ordered members should only be used for concepts that have a natural ordering (like sequences of a route), as these can intuitively be understood.

Btw, name=* isn't a good tag for the label on the sign - it isn't the sign's name but the destination's name. --Tordanik 14:36, 20 July 2009 (UTC)

Most of the time it's even evident without the order which from member leads to which to member; looking at oneway tags and common nodes, preferably at the end of the way. Yes, sign and destination members could be optional (even via sometimes), just didn't add a column for that. So far I've entered the name tags (in the relations) just for easier editing - no one's using these yet. Alv 21:03, 20 July 2009 (UTC)

Pronunciation

For a proper navigation tool a pronunciation hint is needed. See Phonetics --Lulu-Ann 11:44, 20 July 2009 (UTC)

This can be amended to the proposal later, besides I do not think most mappers know how to write phonetics, and I know for sure that I pronounce more than half the place I map wrong, so even if I could write phonetics I would probably still get it wrong. --Skippern 09:26, 21 July 2009 (UTC)

sign color

I do not think it is correct to tag sign colors in the relation, even though I would like the signs appearing on the screen to have the correct colors and symbols. This can be solved by making a tag similar to the network=* tag used on route relations. It is one simple identifier that allows software to connect it with a rendering rule. --Skippern 09:29, 21 July 2009 (UTC)

That's a great idea! Simplifies data entry, keeps color choices consistent, but adds another step in rendering. However it shouldn't be too big problem to have a list made availible for renderers. --Cohan 19:32, 21 July 2009 (UTC)

Following a route or creating one

Maybe we should pin this down once and for all. As I intended this to be an aid when following an already made route, aiding in the creation of it is something different with some other requirements of the relation. When then opposing a follow-proposal because it lacks creation-parts is like saying "No, I don't think we should go to McDonalds, because I don't like Italian food."

So. Once and for all; should this relation be for aiding in following a route and/or aiding in creating one? --Cohan 09:27, 22 July 2009 (UTC)

following. That doesn't stop anyone from preferring those when creating a route, either. Alv 14:25, 11 March 2010 (UTC)

Language

Instead or additional to any pronunciation hint, the language of the destination should be tagged. Important next to borders or in bilingual areas. As in these cases often one city is given in more than one language, tagging ideas are welcome. Basstoelpel (talk) 12:47, 4 September 2015 (UTC)