[Tagging] exit_to on motorway_junction

Martin Vonwald imagic.osm at gmail.com
Thu Nov 22 08:45:36 GMT 2012


>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 <osmned at 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.smale at 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 at openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/tagging
>> >
>>
>>
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>



More information about the Tagging mailing list