[Tagging] noexit=yes on ways ?

Peter Wendorff wendorff at uni-paderborn.de
Thu Apr 10 19:29:38 UTC 2014

Am 10.04.2014 16:01, schrieb Pieren:
> On Thu, Apr 10, 2014 at 3:48 PM, John Packer <john.packer7 at gmail.com> wrote:
>> I also added the following phrase to the "Usage" section:
>>> In the past this tag was used on ways very often, but because tagging on
>>> ways has several disadvantages, you should rather tag noexit=yes on nodes.
> I cannot agree. What is the disavandtage on the way when the tag is
> only used by QA tools and only when the highway is ending nearby
> another highway ?
> Even when both highway ends are nearby another highway, the tag is
> clear. 
I agree that far - but not further:
> And if one of the ends is connected to another highway, then
> the tag is also clear (since we only look at ways ending nearby anothe
> highway). 
In this case it's only clear if it's currently correct, it's impossible
to detect an error now.
>What is unclear here ?

For routing and similar the tag isn't needed at all. Therefore there are
two possible usages:
1) In general to note that the way ends there and is not mapped
2) To clearly state the fact that two ways near to each other are not
connected at all, by tagging "this is the end node here, it does not

If anything is still correct there's no need in the tag at all - both is
purely cosmetics for QA tools.

But what if an error occurs?

Imagine a cul-de-sac on one end (!) of an osm way.

Option 1: no_exit is tagged on the dead end node, but somebody
accidentally connected it to the next street. It's easy to see that this
is an error, and it's easy to spot the cause as you know from the data
you see where the dead end should have been.

Option 2: no_exit is not tagged at all: you wouldn't spot the error.

Option 3: no_exit is tagged on the way, but somebody accidentally
connected the dead-end to the next street. You could see that there's
something wrong, but you have to look into the history to see where.

It's even more clear if you consider a two streets in a T-shape, mapped
as two ways where one has two dead ends. With the no_exit tagged at both
end nodes of the "upper" way it's clear that both are a cul-de-sac. In
contrast when it's tagged at the way, you don't know if there's a
connection missing on one end (nor on which end) or not.
If you consider the case of someone accidentally connecting one end
again, the data looks still correct, the error cannot be spotted from
the data any more.

Remark: Of course you could take the history into account and some if
not all of the benefits could be tackled by doing that, but history
research in OSM is still hard, and QA tools should run as fast as
possible producing as up to date and accurate results as possible. Most
QA tools out there does not take into account the history - and that's
why my conclusion is clearly towards no_exit on nodes and only nodes.


More information about the Tagging mailing list