>From the taginfo map I wouldn't expect that we could find a global solution. I therefore would document both solutions (destination is already documented, preferable someone from the US has to properly document exit_to) and state in the articles about motorway_junction and exit_to that exit_to is mainly used in the US and some other countries that want to stick with exit_to.
This of course is not really a solution as data consumers have to implement two tagging approaches - and I doubt that every one will do this. But well - any better suggestions? Martin 2012/11/21 Johan C <osm...@gmail.com>: > Overlooking the discussion so far, I think exit_to cannot be deprecated. > However, there's strong feelings to support both destination and exit_to. In > my opinion, the following things can be done: > > 1. keep things the way they are now (where exit_to is the preffered choice, > because the text on the motorway_junction page states that it should be > used). The disadvantages of exit_to are not solved: > a. no description of exit_to > b. no solution of the exit_to_left yet to support both branches > c. not clear why other items of a exit ramp are not used in the > motorway_junction tag (like lanes, maxspeed) > d. no support for advanced lanes tagging > to summarize: no support for a lane assistant > > 2. deprecate destination > disadvantage the same as above, so no support for a lane assistant > > 3. deprecate exit_to > several U.S. OSM'ers do want to keep on using exit_to > > Possible solution in this discussion. The non-U.S. OSM'ers in this > discussion seem to favour destination. The U.S. OSM'ers seem to favour > exit_to. Lets split it in the text of motorway_junction tag. I do have a > text suggestion for that. Please send your thoughts on this. You can see I > also try to adress the realtion discussion, which I think can be handy, but > I don't see the value for motorway exit tagging. Destination can do the > trick there, and a relation is more complex = less KISS > > Destination > The tags destination=* , destination:ref=* (according to information on road > signs) and lanes=* should be used on the ways directly after the exit. The > tag destination:lanes=* can be used on complex motorway_junctions. These > tags are needed to support a lane assistant in navigation devices. > > In the United States exit_to=* on the motorway_junction node should be used > to detail the destinations where the junction exits to. The tag > Relation:destination_sign can be used in non-motorway situations. > > > This part of the exit_to will in my text suggestion be moved to the exit_to > Wiki page: > > —for example, if signage states a road leads to Anytown on the A1000… > exit_to=Anytown A1000; if multiple destinations are shown on signage, tag > them with semicolons: for example, exit_to=Anytown A1000; Elsewhere A1001; > Anyvillage; note that Anyvillage doesn't have a ref number. > > > 2012/11/21 Colin Smale <colin.sm...@xs4all.nl> >> >> Using only exit_to there is no way to handle junction topologies other >> than a straightforward highway exit, where there is one "big" through road >> and one "small" road leaving. What about wrong-side exits? Or where the >> highway splits into two (or more) roads of equal importance? >> >> Destination tagging is used a lot in the Netherlands, placed on the first >> segment of each way *after* the node where they split. My Garmin warns me >> ahead of time which side to keep to, so there doesn't seem to be a need to >> start the tagging at the first sign (which may be 1km or more before the >> actual junction). I have not yet found a case where adding destination=* >> around a junction felt like the wrong thing to do. >> >> IMHO destination=* on the ways is the right balance between the >> rudimentary exit_to on the node and using a relation which will have >> problems with support/adoption by both mappers and toolmakers. >> >> Colin >> >> > I don't see any reason to deprecate exit_to, it seems to be the simplest >> > method of mapping a destination sign on a motorway junction or similar >> > exit. I use exit_to fairly frequently and it has been a documented tag >> > for a while (although on the motorway junction page rather than it's own >> > page) and is also used in JOSM presets. >> > >> > I feel it is a less ambiguous tag than destination (as a tag on a way) >> > as it shows the specific point where a destination is signed, unlike >> > destination tagged on a way. If you use destination as a tag on a way >> > then I think you'd need to be sure that at every point along that way >> > the destination(s) given is the same throughout and if not or you didn't >> > know you'd need to split the way. The Taginfo stats also seem to show >> > that exit_to is the most popular of the three different ways of mapping >> > destinations: a destination relation, exit_to on a junction node, or >> > destination as a tag on a way. >> > >> > A destination relation is also a clear way of mapping a destination as >> > the intersection and both the 'from' and 'to' ways are part of the >> > relation, and is particularly useful in mapping situations where exit_to >> > wouldn't work (like at a crossroads) so I do also use this method. It is >> > however more complex (and so is unlikely to be a method that a new >> > mapper would be able to use) particularly where there are multiple >> > destinations given on a sign which requires a relation for each >> > destination. >> > >> > Cheers, >> > Paul Williams >> > (Paul The Archivist) >> > >> > _______________________________________________ >> > Tagging mailing list >> > Tagging@openstreetmap.org >> > http://lists.openstreetmap.org/listinfo/tagging >> > >> >> >> >> _______________________________________________ >> Tagging mailing list >> Tagging@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/tagging > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > http://lists.openstreetmap.org/listinfo/tagging > _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
