Thanks for the comments, it confirms that it was relevant to share on this.
It's already time to share a little more on my own conclusions then.
@Marc Marc:
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.)
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.
Thanks for the comment on the description tag, good point, I'll add it
to the other case.
@Marc Gemis:
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.
Thanks for the disused tag, I missed it. It will be useful in some other
cases, but here it cannot apply. (See here below.)
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.
Also there are several administrations for several purposes, and quite
inefficient in many ways, even if some have real good intents.
@Tim Couwelier:
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.
So, since we "agree", a little more from my own conclusions...
- 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.
- 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.)
- 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.)
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".
- 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.
=> 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.
That's it for now on my side. And I guess sufficient to bring the point
to everyone...
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.
Thanks for your participation and comments. If some have
meetings/discussion sessions, I think it would be a good topic...
Regards,
François
On 8/21/19 11:42 AM, Tim Couwelier wrote:
I'm with 'second marc' on this one - I chose to map ground truth.
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.
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.
Op wo 21 aug. 2019 om 10:46 schreef Marc Gemis <[email protected]
<mailto:[email protected]>>:
Seems my opinion is different from the other Marc.
AFAIK, the OSM consensus is to map what is on the ground, in this case
only the by-pass. You could keep the "official" path, with some tag
disused:highway or so, but IMHO, that is just clutter that makes it
harder for others to edit. When your local council does not bother to
re-instantiate the official path, it will soon loose that status, not?
As far as the removal of the "official" path is concerned, it probably
depends on what "official" means. If it is e.g. in the Atlas der
Buurtwegen and was not officially removed by the council, you should
contact your council and describe the problem. I did that once and the
day after, the track was open to the public again.
On Tue, Aug 20, 2019 at 8:59 PM Francois Gerin
<[email protected] <mailto:[email protected]>> wrote:
>
> Hi,
>
> Here is a probably subjective issue, that has certainly already been
> discussed, but I cant' find a search engine for the mailing
archives.
>
> Problem:
> It's very frequent, in Belgium and certainly in many places, that a
> private or farmer steals a footway because he dislikes people
pass there
> or just to extend his field for free.
> The **official** path is then often no more visible and,
sometime, there
> may have an **unofficial** by-pass in the area.
> The official trace MUST be kept because, well... it is official. :-)
> And also because the by-pass MAY disappear at any time.
>
> Envisioned solutions:
> 1. Keep official path only. =bad because it does not reflect the
> reality (which may stand for many years!)
> 2. Delete the official one, draw the by-pass. =rejected, because the
> official must be kept, or we may loose both
> 3. Keep both, but flag the hidden one with trail_visibility tag.
=best
> option found up to now, which seems accepted widely+officially
>
> Questions:
> A. Is there any OSM consensus for a solution, at the
global/worldwide
> community level?
> B. If not, is there any Belgian community consensus?
> C. If not, is there any widely accepted option?
> D. If not, is there any better solution than option 3?
>
> (Side issue: the current rendering on OSM does not express that this
> path is poorly visible. But at least the flag is there for other
> rendering tools/layouts.)
>
> Two examples I had to do:
> https://www.openstreetmap.org/way/700172645
> https://www.openstreetmap.org/way/629096505
>
> Thank you in advance for any pointer/doc/wiki/consensus! :-)
>
> Regards,
> François
> (aka fgerin on OSM)
> (aka fge1 on balnam)
>
>
> _______________________________________________
> Talk-be mailing list
> [email protected] <mailto:[email protected]>
> https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-be
