|
Summary: Is there an agreed upon convention on tagging road links (such as freeway on-ramps)? The discussion of pros and cons of using ref=* on links follows. Detailed problem description I am not naturally inclined to tag road links (freeway on- and off-ramps specifically) with a ref=*, but some people in my area have done it copiously and meticulously. So an on-ramp from a road name El Toro Road to a freeway designated CA-73 would be tagged name=CA-73 South onramp See it here It looks good in Mapnik and works well in Potlatch if you have a mess of links in the case where several freeways meet (the above example is not one). However, some tile makers and routing apps (notably skobbler) use the value of ref to put a shield on roads. It works fine when ref=I-405 or even ref=CR S18, but it gets a bit ugly with the example above, when the app places the entire "from El Toro Road" in a shield floating in the middle of a map. It takes a while (even with OSM knowledge) to figure out where it's coming from. I can imagine how confusing it is to drivers. I know we're not here to serve skobbler users, and I will be bringing this up with skobbler developers to see if they can be more discriminate in displaying shields derived from ref tags. But at the same time, I did see some of the more experienced OSM editors advise to not use ref=* on links. Why is that? Is that because most of the users of OSM data will tend to misinterpret this info as a highway designation/shield? Wiki does not state one way or the other. Should I start clearing up this data in my area? That does not feel right. I would much rather all tile generators and all routing apps would read the OSM editors' minds and know when and when not to show this info as a shield. |
|
The refs used there on those ramps appear to be valid values for exit_to= tags (save where they're "from" someplace, those would need to be updated, and it would need to be on the junction node at the start of the link, not the link itself. See tag:motorway_junction for details. Also, I see most of the names are obviously wrong; name is the name only. Many of the names shown should be description=* instead. I don't see a problem with fixing the tags, though it does appear there is useful information available; I would try to preserve the existing, incorrectly tagged data by moving it to more widely accepted tags. If that doesn't satisfy whatever renderer they're using at that point, well, that's the renderer's problem. Paul, in the example above, can you explain which names are wrong and why? I read the "name is the name only" writeup on wiki. name="CA-73 and CA-133 North onramp"seems perfectly reasonable to me. As far as where to move the values form ref=* on motorway_links, you mention that it should be a tag like exit_to on a motorway_junction. But as you yourself point out these are not exits, these are "entrances". So what would be the tagging schema for a node on the surface road where an onramp originates? I don't think it's in the wiki.
(05 Mar '11, 09:12)
ponzu
1
That's not the actual name of the road, though. It's a description of a road that very likely has no name or the same name as the adjacent freeway. It's generally unnecessary to tag what it's an enterence to...
(05 Mar '11, 17:56)
Baloo Uriza
|
|
Using "ref=from El Toro Road" sounds very cludgy and (if it's not written anywhere as a reference number for the road) just wrong. It's not just Skobbler that uses both ref= and name=; my Garmin reads both out too, and I'm sure that others do as well. Presumably that's why people are doing it - so that the Satnav says "take the CA-73 South onramp from El Toro Road". If there's any doubt I'd map what's on the ground wherever possible, but I'd be a little reticent about cleaning up anything that someone else has spent a lot of time entering (even if it's wrong). I'd certainly try to engage them in some sort of dialog to try and figure out what what they're doing, and also present the arguments in favour of recording what's on the ground rather than what works well in one particular application. A very reasonable opinion that reflects mine. But it is still an opinion, isn't it? Opinions, someone will tell us shortly, belong in the forum. If there is a definitive answer, I am hoping to hear it soon.
(04 Mar '11, 20:11)
ponzu
Does "Fake Steve C" add answers here? Perhaps he should - they'd certainly be "definitive". Not necessarily "reasonable", though. Seriously though, it's very difficult to have definitive answers in a collaborative project. Everyone doing what they think is right is a good start, though.
(04 Mar '11, 21:16)
SomeoneElse ♦
|
|
Hi. I'm the guy doing the tagging in question. First, I appreciate the way this is being discussed - it's my ideal of "the OSM way". When I started tagging these, there was no agreed-upon method, so I tried to use existing tags in a way that was close to their purpose. It seemed particular useful for navigation to name the ramps as I did. I didn't want to lose the information I put in ref yet because I wasn't sure exactly how it would/could be derived in the future. The ref tag was documented as a free-form place to put any sort of non-name reference information. Since then, certain patterns in that field have been defined and recognized to be shown as shields, but I believe skobbler is doing the wrong thing in this case, because "from El Toro Road" doesn't look like any of those defined patterns. So, here's my current approach: Exit node - node where exit ramp originates at motorway: Exit ramp - motorway_link from motorway to street: Entrance ramp - motorway_link from street/motorway to motorway: I believe I recognized that the "name" tag would be most likely to be immediately used by nav and rendering, and so put what seemed correct for them there and stuck the rest of the description in ref. I'd not be averse to separating those back out of ref into their own tags if you can suggest them. I'm not convinced they are ready to be dropped completely, and I don't think there's compelling space/size argument to be made. Anyway, just out the door for the weekend - I'll be back to discuss/resolve next week. I don't think the current ref=* values should be dropped completely, but I think they should be moved to an innocuous tag, such as description=* or even note=* By the same token, I don't see a problem with your values for name=* for these onramps, the way Paul above does. I would not touch those. I just want to clear up the shields from the skobbler maps and who knows what other mapping/routing apps. I did write to skobbler to tell them they should either be smarter about contents of shields or drop shields from motorway_links altogether.
(05 Mar '11, 09:15)
ponzu
1
I'm just agreeing with the established, well-documented practice on the name tag: Name should be the name, putting a description in the name is just tagging wrong for a specific renderer...
(05 Mar '11, 16:15)
Baloo Uriza
I disagree that it is not the name of the road. If the public works department creates a work ticket for these ramps or connectors, it is very likely to name it almost exactly name+ref (well, at least the "from..." part of ref). The line between name and description is often blurred with frontage roads, service roads, etc. Because description is specifically defined as non-rendering, I lean toward using name because I think the information is useful to render, particularly for routers.
(11 Mar '11, 13:47)
AM909
|
|
Sorry for the delay. So, how about: For an offramp, or connector between trunks or higher: remove ref tag and add: for an onramp: remove ref tag and add: Assuming this is OK, how long should I wait for comment before doing this? Should I mention it on the tagging or talk-us list? I intend to download all the ramps I've tagged using XAPI, fix the tags with a perl script, inspect in JOSM, and upload the changes. Should take less than an hour and hopefully not result in any conflicts. Still not quite there. How about this: On the node where the motorway and motorway_link meet for the exit, "ref = 54" and "name = Mountain Avenue". On the exit ramp itself, no ref, no name (unless it's a case where a state highway uses that ramp to leave a motorway and go to another way, then the highway's name and ref would be appropriate. Not sure "[enterance|exit]_from" are widely used, and seeing them rendered or used by anything is unlikely as a result. (more in next comment).
(11 Mar '11, 18:29)
Baloo Uriza
Name should just be the name, ref should just be the reference. For your onramp example, I wouldn't use either tag (except in the same highway-takes-the-ramp example above). "description = I 210 East onramp from Foothill Boulevard North" would be more appropriate. There's nothing stopping you from using exit_from or entrance_from tags, but again, not sure what their use would be.
(11 Mar '11, 18:31)
Baloo Uriza
If the goal is to show how one gets to or from a particular motorway route to surface streets, this is probably better handled by adding the motorway_links as "link" members of the relation for the route on the motorway.
(11 Mar '11, 18:32)
Baloo Uriza
I hope we get a resolution soon. Alan, I would run this through the tagging list and see if there is consensus or at least enough encouragement to go with some version of your schema. That said, should you simply change all ref=* on motorway_links to description=* the way Paul seems to be suggesting, I will not object. It seems our main concern is preserving the data no matter how superfluous it appears to be at the moment, while cleaning up the rendered driving maps (e.g., skobbler, but probably others as well)
(16 Mar '11, 05:02)
ponzu
|
|
I do want to retain the information for reasons I've described earlier. On talk-us, Mike N is proposing that 4
It depends on the renderer. Don't incorrectly tag for any particular renderer.
(28 Mar '11, 16:45)
Baloo Uriza
|
|
In this case, which came first, the renderer or the database? Both MapNik and OsmaRender show the exit names, presumably intentionally. Shouldn't any change in that particular functionality be co-ordinated with the renderer developers, and discussed by more than 3 of us? 3
(28 Mar '11, 16:51)
Baloo Uriza
2
Yes, there is also more languages than English. Think about that OSM maps get rendered in many different languages. How would a software know that "offramp" is a description that should be translated, and Mountain Ave is a name that should not be translated?
(28 Mar '11, 23:23)
dieterdreist
|
No matter what answer gets accepted, I strongly recommend sending a polite request to the folks who are torquing the tags and pointing them to this question...
Absolutely will do that. The person who added the tags has personally surveyed (i.e., drove, recorder tracks and took photos), mapped and tagged thousands of miles of roads in the US Southwest. Without him, the OSM for Southern California, Nevada and Arizona would look very different.