<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Joost,</p>
<p>Thanks for your comment.</p>
<p>For the trail_visibility: According to me, here the tag is fully
relevant, the path is indeed sometime not visible, depending on
the conditions, and users are mainly walkers, VTT and horses. That
matches quite well the definition of trail_visibility:horrible as
I understand it, and I could not find an alternative tag that
matches better.<br>
=> Even if the tag in itself is not the solution (not
self-sufficient), I consider the tag relevant and I don't catch
why it would be tag trolling.<br>
</p>
<p>Indeed the lifecycle prefixes are more relevant, and solve a big
part of the issue. But I'm still not fully convinced, due to the
timing.</p>
<p>Beyond the fact maps can technically be updated at anytime, I
consider that a "validity period" matching both the OSM spirit and
the respect of users (as well as device makers) should be
something like [1..3] years for items likes tracks/paths/etc.
(Target, not absolute truth!)<br>
=> The disused: and razed: prefixes are clearly made for
mid/long-term or one-time situations, not for periodic+cyclic
short terms [1..3 months].<br>
=> OSM is "real/current state", old data (>2-3 yars) are to
be deleted to respect the philosophy.</p>
<p>The second point indeed also implies that the real use for
disused/razed is limited, since beyond 1-3 years the items would
simply be deleted. Good point.<br>
</p>
<p>So, the lifecycle prefixes solution could indeed be better, also
because it can stand this way until someone updates the bypass
too.<br>
But, according to me, this solution is only usable IF there is a
visible and short bypass close around (which is the case of my
examples, ok). If not, then it appears there is no more trace, and
users will just be annoyed.</p>
<p>Also, old GPS devices and devices not designed to support those
prefixes will just hide the disused track, which disappears only
periodically but could exist the day the user passes.<br>
According to me this is negative drawback: As a user I really
would prefer to have the choice, and select the one I take
according to the real situation the day I pass there. (No matters
if the culture was removed the day before, we cant' monitor all
these places on a daily basis.)</p>
<p><br>
PS: I just tested the disused: prefix to see if it is rendered in
some way on the default web layer... It is absolutely not visible,
except in edit mode. And I really feel I lost the information I
expected to find on the map, as a biker. I ride mostly to discover
new paths, and I would have missed this one.<br>
<a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/way/716828273">https://www.openstreetmap.org/way/716828273</a><br>
</p>
<p>NOTE: In Wallonia, the legislation clearly tells that if some
culture invades the path, we have to pass on it. Only if it is not
possible, we may take any bypass... (Farmers are aware of this.)<br>
This is why it's very important that users still pass on the
official trace, the bypass may be forbidden at any time. And if
the official trace is no more visible, then the path is lost since
no more user will make the trace anymore. Ok that's not the
problem of OSM strictly speaking but, well, it's intimately
related anyway. No path, no map! :-)<br>
</p>
<p>Regards,<br>
François</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/26/19 9:21 AM, joost schouppe
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAO2_g7LTWHNwO6Sj-f-48X4tTCy8g3Q5ASAmKoy6BVsrxxKR8Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>I do not recommend trail visibility in a case like this. I
think it is meant for real, usable trails, that just happen to
be hard to see on the ground. To use it in this case, is
almost troll tagging. Basically you are saying: there is a
path here, but it isn't actually a path. less advanced
data-users (i.e. almost any app) will not show it any
differently.</div>
<div><br>
</div>
<div>This is why I would recommend the lifecycle tags. If the
official path is still there, but it is just razed by the
agricultural works, you can use razed:highway. If remnants of
the path are still there, you could use disused:highway. If
the situation persists for a longer time, it might be best to
delete it all. But as you said above: strictly "mapping what's
there" means you should delete and remap a lot of paths a few
times every year. This is what creates clutter and makes the
data less readable to me!</div>
<div>The use of lifecycle tags implies that a data user has to
know about this stuff, and hence it is a concious choice, not
an accident, to show them to the data user. Osmand for example
does this. Which I really like, because I like exploring the
woods. It would be relatively easy to make a "switch" for
Osmand rendering to show or not show "lifecycle related"
stuff. If you're not interested in ruined buildings, future
bridges or disappeared paths, you can swithc them all off :)<br>
</div>
<div><br>
</div>
<div>If used reasonably (as in "oh this is weird situation, how
should I map it", not "I have an old atlas, let's map ALL of
the disappeared paths"), then I don't see how it "clutters"
the map. And even where it does, people don't seem to mind
much anyway. Check out: <br>
</div>
<div><a
href="https://www.mapcontrib.xyz/t/6d1770-Trage_wegen_als_Note"
moz-do-not-send="true">https://www.mapcontrib.xyz/t/6d1770-Trage_wegen_als_Note</a></div>
<div>It shows a bunch of ways with no properties except a
note="some buurtweg here". I shared it a few times here, and
nobody bothered to delete or fix them...<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op wo 21 aug. 2019 om 13:57
schreef Francois Gerin <<a
href="mailto:francois.gerin@gmail.com"
moz-do-not-send="true">francois.gerin@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Thanks for the comments, it confirms that it was relevant
to share on this.</p>
<p>It's already time to share a little more on my own
conclusions then.</p>
<p>@Marc Marc:<br>
Thanks for using option 3. The global/general idea to map
only the reality is good and important, but what appears a
contradiction here is not, IMHO. (See here below.)<br>
PS: You're right for the highway path/footway. I fully
agree, and this what I do in my area. But in the area of
the example, another habit is in place... So I respected
it. This is another issue, which is a consequence of the
French translation of the web editor menus, according to
me.<br>
Thanks for the comment on the description tag, good point,
I'll add it to the other case.<br>
</p>
<p>@Marc Gemis:<br>
I fully agree with the general rule "map the existing" and
was applying it in these cases too until recently. In
fact, this is the reason of my mail... I extend on this
here below.<br>
Thanks for the disused tag, I missed it. It will be useful
in some other cases, but here it cannot apply. (See here
below.)<br>
I'm contributing also to balnam, which is an organization
that monitors those paths and footways, which is
absolutely not the same purpose as OSM, and both are very
useful, each one in its area. Also, the official
administration in charge of this monitoring is so slow
(years!) than the life cycles with OSM would result in a
complete mess.<br>
Also there are several administrations for several
purposes, and quite inefficient in many ways, even if some
have real good intents.<br>
</p>
<p>@Tim Couwelier:<br>
Indeed the user's perspective is critical, and this is
part of the various items I integrated in my own analysis
of this issue. Thanks for the confirmation, it also goes
in the direction I expected. But this is more related to
the rendering than the data itself.</p>
<p><br>
</p>
<p>So, since we "agree", a little more from my own
conclusions...</p>
<p>- Yes, I fully consent to the "map the current reality"
approach. And in fact, this is what I was doing before I
had to reconsider my way of thinking and finally change my
mind. This rule must be kept as the main lead. However,
like all rules, especially the "global" and "generic"
ones, there are exceptions... And here it is one that,
IMHO, requires a specific attention, so as to document it
for the (probably many) contributers who face this.</p>
<p>- An important aspect, that is missed by the general rule
and fully part of the exception, is the timing: The path
*appears and disappears very periodically*, according to
the cultures on the field... If someone removes the path
from the map, I'll add it again soon after, when the path
is back. This would lead to big frustrations and/or
litigations, as well as a lot of noise in the database...
Resulting in a situation that is negative for everybody.
(While having all the data in the DB and rendering
properly would lead to a positive situation fro
everybody.)<br>
</p>
<p>- The comment from Tim about the users is particularly
important, but it is more a question of rendering than
data in the DB. (That was what I pointed to in my original
message, "Side issue" note.)<br>
A flag, being trail_visibility or another, makes it
possible for cheap, and it satisfies the software
development rule "issues must be solved at their root
cause".<br>
</p>
<p>- We prefer not to add yet another tag just for this. The
disused tag does not match either, it would change every
few months. The trail_visibility much better matches
matches the case, even if not perfect... Think of a street
closed periodically, here and then, for the time a
building (1-4 years) is made in a city. It would be
strange to see a tag "trail_*" for a street in a city.<br>
=> This is just to mention that the notion is wider,
I'm not asking for a solution for this case, the solution
of the trail_visibility is just fine for me. But if
something new has to be made, probably it should be made
generic enough to also cover more generic cases. Maybe
just adapt the trail_visibility to make it more generic.<br>
</p>
<p><br>
</p>
<p>That's it for now on my side. And I guess sufficient to
bring the point to everyone...<br>
While waiting for a possible other option/consensus, I'll
continue to proceed with solution 3, which is not
contradicting the important "map the real state" rule,
according to me. It does not contradict because the
official way still exists in reality, even if it is
sometime hidden for a few weeks/months a year, in a
cyclical way.<br>
</p>
<p>Thanks for your participation and comments. If some have
meetings/discussion sessions, I think it would be a good
topic...<br>
</p>
<p>Regards,<br>
François<br>
</p>
<p><br>
</p>
<div class="gmail-m_-6360713122056091339moz-cite-prefix">On
8/21/19 11:42 AM, Tim Couwelier wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>I'm with 'second marc' on this one - I chose to map
ground truth.<br>
<br>
</div>
<div>In part because that's generally 'how things should
be mapped', in part because otherwise we receive
criticism from avid users, who are highly annoyed to
get stuck / at dead ends because they saw a path on
their map and it's nowhere to be found.<br>
<br>
</div>
<div>While I fully support efforts to keep such paths
functional / accessible / known to the public, mapping
them when they aren't to be found in the field does
not seem like the way go.<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Op wo 21 aug. 2019 om
10:46 schreef Marc Gemis <<a
href="mailto:marc.gemis@gmail.com" target="_blank"
moz-do-not-send="true">marc.gemis@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Seems my opinion is
different from the other Marc.<br>
<br>
AFAIK, the OSM consensus is to map what is on the
ground, in this case<br>
only the by-pass. You could keep the "official" path,
with some tag<br>
disused:highway or so, but IMHO, that is just clutter
that makes it<br>
harder for others to edit. When your local council
does not bother to<br>
re-instantiate the official path, it will soon loose
that status, not?<br>
<br>
As far as the removal of the "official" path is
concerned, it probably<br>
depends on what "official" means. If it is e.g. in the
Atlas der<br>
Buurtwegen and was not officially removed by the
council, you should<br>
contact your council and describe the problem. I did
that once and the<br>
day after, the track was open to the public again.<br>
<br>
On Tue, Aug 20, 2019 at 8:59 PM Francois Gerin <<a
href="mailto:francois.gerin@gmail.com"
target="_blank" moz-do-not-send="true">francois.gerin@gmail.com</a>>
wrote:<br>
><br>
> Hi,<br>
><br>
> Here is a probably subjective issue, that has
certainly already been<br>
> discussed, but I cant' find a search engine for
the mailing archives.<br>
><br>
> Problem:<br>
> It's very frequent, in Belgium and certainly in
many places, that a<br>
> private or farmer steals a footway because he
dislikes people pass there<br>
> or just to extend his field for free.<br>
> The **official** path is then often no more
visible and, sometime, there<br>
> may have an **unofficial** by-pass in the area.<br>
> The official trace MUST be kept because, well...
it is official. :-)<br>
> And also because the by-pass MAY disappear at any
time.<br>
><br>
> Envisioned solutions:<br>
> 1. Keep official path only. =bad because it does
not reflect the<br>
> reality (which may stand for many years!)<br>
> 2. Delete the official one, draw the by-pass.
=rejected, because the<br>
> official must be kept, or we may loose both<br>
> 3. Keep both, but flag the hidden one with
trail_visibility tag. =best<br>
> option found up to now, which seems accepted
widely+officially<br>
><br>
> Questions:<br>
> A. Is there any OSM consensus for a solution, at
the global/worldwide<br>
> community level?<br>
> B. If not, is there any Belgian community
consensus?<br>
> C. If not, is there any widely accepted option?<br>
> D. If not, is there any better solution than
option 3?<br>
><br>
> (Side issue: the current rendering on OSM does
not express that this<br>
> path is poorly visible. But at least the flag is
there for other<br>
> rendering tools/layouts.)<br>
><br>
> Two examples I had to do:<br>
> <a
href="https://www.openstreetmap.org/way/700172645"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://www.openstreetmap.org/way/700172645</a><br>
> <a
href="https://www.openstreetmap.org/way/629096505"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://www.openstreetmap.org/way/629096505</a><br>
><br>
> Thank you in advance for any
pointer/doc/wiki/consensus! :-)<br>
><br>
> Regards,<br>
> François<br>
> (aka fgerin on OSM)<br>
> (aka fge1 on balnam)<br>
><br>
><br>
> _______________________________________________<br>
> Talk-be mailing list<br>
> <a href="mailto:Talk-be@openstreetmap.org"
target="_blank" moz-do-not-send="true">Talk-be@openstreetmap.org</a><br>
> <a
href="https://lists.openstreetmap.org/listinfo/talk-be"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
<br>
_______________________________________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org"
target="_blank" moz-do-not-send="true">Talk-be@openstreetmap.org</a><br>
<a
href="https://lists.openstreetmap.org/listinfo/talk-be"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
</blockquote>
</div>
<br>
<fieldset
class="gmail-m_-6360713122056091339mimeAttachmentHeader"></fieldset>
<pre class="gmail-m_-6360713122056091339moz-quote-pre">_______________________________________________
Talk-be mailing list
<a class="gmail-m_-6360713122056091339moz-txt-link-abbreviated" href="mailto:Talk-be@openstreetmap.org" target="_blank" moz-do-not-send="true">Talk-be@openstreetmap.org</a>
<a class="gmail-m_-6360713122056091339moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org" target="_blank"
moz-do-not-send="true">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
</blockquote>
</div>
<br clear="all">
<br>
-- <br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">Joost Schouppe</div>
<div dir="ltr"><a
href="http://www.openstreetmap.org/user/joost%20schouppe/"
target="_blank" moz-do-not-send="true">OpenStreetMap</a> | <a
href="https://twitter.com/joostjakob"
target="_blank" moz-do-not-send="true">Twitter</a> | <a
href="https://www.linkedin.com/pub/joost-schouppe/48/939/603"
target="_blank" moz-do-not-send="true">LinkedIn</a> | <a
href="http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/"
target="_blank" moz-do-not-send="true">Meetup</a></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Talk-be mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-be">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</blockquote>
</body>
</html>