[Tagging] noexit=yes on ways ?

Florian Schäfer florian at schaeferban.de
Thu Apr 10 13:07:11 UTC 2014

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.".



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é.
>     _______________________________________________
>     Tagging mailing list
>     Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20140410/bb1d897d/attachment.html>

More information about the Tagging mailing list