[Tagging] noexit=yes on ways ? (a typical OSM story)

André Pirard A.Pirard.Papou at gmail.com
Thu Apr 10 16:08:55 UTC 2014

On 2014-04-10 15:07, Florian Schäfer wrote :
> Yes, I agree.
> That recommendation was introduced yesterday by Pieren [1]. I strongly
> oppose that.
> The wiki is not for documenting Tagging-trends, but for documenting
> best practices. And I would say, that tagging noexit=yes on ways is
> not a best practice.
> In my opinion an acceptable comment in the Wiki about tagging
> noexit=yes on ways would be "In the past this tag was used on ways
> very often (~40%). But because this tagging has several disadvantages,
> you should rather tag noexit=yes on nodes.".
> Cheers
> Florian
> [1]:
> https://wiki.openstreetmap.org/w/index.php?title=Key%3Anoexit&diff=1015025&oldid=1014495

The wiki update seems to have been made on this ground:

On 2014-04-04 17:35, Pieren wrote :
> It seems that 40% of the "noexit=yes" tags are on ways and are
> understandable by their contributors but 100% of the persons writing
> on this thread do not understand what 40% of the contributors do ...
> So, instead of trying to change 40% of the contributors with wiki
> fiddling and josm obscure validations, you should try to open a bit
> your mind and accept that contributors can supply the same information
> in different ways (or nodes ;-). Stay open like "Open"StreetMap ;-)
> Pieren 

In other words, 40% tags (on ways) can't be wrong. But the problem is
that 99.+% of these correct tags are mistakes and shouldn't even exist
because they do not represent "ways ending near another way", which are
the targets of noexit=yes,  but normal dead ends needing no other tagging.

Saying that we do not understand what the contributors do is rather
peculiar without asking them what they meant with those tags. I made no
poll, they would probably not answer, but I listened carefully to those
who spoke up here and said why they used ways: "I had not consulted the
wiki [since a long time]", "I was recommended ways by a friend", "I
thought I was tagging the noexit traffic sign".  It seems to me that
many people snowball tags in vague similarity with what they see without
much study and that it is really catastrophic when it pertains to access
rules and routing.

Saying "or on the way Way
<http://wiki.openstreetmap.org/wiki/Elements#Way> itself" without saying
which way is bizarre and heading for more chaos.
What, in tagging a way, indicates on which end of it is the dead end? 
(I asked that already).
What does happen when the way is split or unsplit?
Will a normal contributor understand what he's dealing with if he sees
noexit on what he splits?.
In fact, is it "the way" or is it "the highway"? Just a segment or more
and up to where?
Or is it a whole neighborhood like in this rue Grétry
and will those with the ability to understand what the contributors do
conclude that noexit=yes in fact tagging the noexit and further remove
that no no remark from the wiki too?

The noexit specification was very weak from the start.

  * instead of something like no_topology_error which is the subject
    matter it used the word noexit which is a misleading, particular
    consequence of the first
  * instead of saying "on the node which is close to the other way" it
    said "on the end of the way" and, obviously, not everyone
    understands that the end of a way is a node and that a node
    indicates where a dead end is but not a way
  * instead of saying "... that an otherwise suspicious tag or road
    layout preventing passing further than the end of a road is
    perfectly intentional" it said "... that there no possibility to
    travel further" making believe that it is some sort of required
    traffic restriction to be used foa all dead ends

That was enough to create perfect, snowballing, collective chaos and
some obviously have fun to add up even more.

Welcome to Fuzziland.

I know who is right: our government who say that OSM is not
[necessarily, to remain civil] up to the quality they expect for data. I
fear that this does not favor obtaining data from them.
I was enthusiastic, but I now believe less and less in OSM.

Please let us ask Osmose to mark as an error any nooexit=yes that is
either not on a node or not close to another way.  We could report that
action to that government and others as an example that we at least try
to put our data right.

Now what about some more fun?  Flood tagging noexit=no in the middle of
every street?  That wouldn't make 40% but 100% and require a wiki update
by those able to understand contributors, wouldn't it? ;-)



> Am 10.04.2014 14:51, schrieb John Packer:
>> Just a quick comment:
>> If it's not useful to use it on ways, then I don't think we should
>> recommend it on nodes /or ways/ on the wiki page (as it is currently).
>> In fact, we should recommend against putting on ways.
>> 2014-04-09 16:16 GMT-03:00 André Pirard <A.Pirard.Papou at gmail.com
>> <mailto:A.Pirard.Papou at gmail.com>>:
>>     On 2014-04-09 10:47, Pieren wrote :
>>>     On Tue, Apr 8, 2014 at 6:38 PM, André Pirard
>>>     <A.Pirard.Papou at gmail.com <mailto:A.Pirard.Papou at gmail.com>> wrote:
>>>          1. noexit cannot be used on ways because that does not show
>>>             what end "cannot pass"
>>>     eeh, what "what end" ? Either the highway line is linked to
>>>     another highway at both ends, then "noexit" is a tagging
>>>     mistake. Or the highway line is not linked to another highway on
>>>     both ends and then the "noexit" can be helpful (confirming
>>>     tha'ts really an isolated highway and not some connection missing)
>>     ??? Let's explain in details. We let alone the Xmas trees.
>>     Assuming real noexit, the typical cases
>>     <http://overpass-turbo.eu/map.html?Q=%3C%21--%0AThis%20has%20been%20generated%20by%20the%20overpass-turbo%20wizard.%0AThe%20original%20search%20was%3A%0A%E2%80%9Cnoexit%3Dyes%E2%80%9D%0A--%3E%0A%3Cosm-script%20output%3D%22json%22%20timeout%3D%2225%22%3E%0A%20%20%20%20%3Cquery%20type%3D%22way%22%3E%0A%20%20%20%20%20%20%3Chas-kv%20k%3D%22noexit%22%20v%3D%22yes%22%2F%3E%0A%20%20%20%20%20%20%3Cbbox-query%20s%3D%2250.66839555058174%22%20w%3D%225.717890262603759%22%20n%3D%2250.67569820203223%22%20e%3D%225.731172561645508%22%2F%3E%0A%20%20%20%20%3C%2Fquery%3E%0A%20%20%3C%21--%20print%20results%20--%3E%0A%20%20%3Cprint%20mode%3D%22body%22%2F%3E%0A%20%20%3Crecurse%20type%3D%22down%22%2F%3E%0A%20%20%3Cprint%20mode%3D%22skeleton%22%20order%3D%22quadtile%22%2F%3E%0A%3C%2Fosm-script%3E>
>>     *look like* two normal junctions at each way end but one of them
>>     *is in fact *a dead end.
>>     Why would we tag noexit on the way and request the beholder to
>>     zoom in each end to determine which is dead if we can tag the
>>     information clearly on the end node?  What about T shaped ways
>>     where the top way contains 2 dead ends? "gotcha, there were 2"?
>>     Now, instead of a vertical bar,  what about a small (or larger)
>>     mesh like /rue Grétry/: are we going to tag as dead ends all the
>>     segments of the mesh up to the normal junction even if they're
>>     not directly related with a dead end?  And, BTW, are we speaking
>>     (in Subject:) of ways or of roads?  Must we apply noexit=yes to
>>     both ways of the same road when we split one?  How would the
>>     brave contributor splitting a way cope with that if he hasn't got
>>     the faintest notion of what noexit is (no blame on him!)?
>>     These are [probably a part of] the questions that raise and
>>     should be settled and that no one advocating noexit on ways
>>     mentioned.
>>     Frankly, noexit on nodes (as designed) is much more logical and
>>     simple (than on ways, of course).
>>     Cheers,
>>     André.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20140410/678b3e49/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20px-Osm_element_way.svg.png
Type: image/png
Size: 655 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20140410/678b3e49/attachment.png>

More information about the Tagging mailing list