Jmapb writes:
> On 5/30/2019 4:22 PM, Abhijit Kshirsagar wrote:
>> Hello all,
>> I'm an old OSM user and have recently moved to the US.
>> What is the correct procedure to submit temporary (at least a few
>> weeks long) road closures on OSM?
>> Also, how long to changes typically take to make it to the
>> downloadable maps that the cellphone apps (such as OSMAnd) use?
>>
>> Thanks in advance,
>> Abhijit K
>> Minneapolis, MN
>>
> Howdy Abhijit, and welcome to the US, and to Talk-US!
>
> There was a related discussion on the tagging list earlier this month:
>
> https://lists.openstreetmap.org/pipermail/tagging/2019-May/045122.html
>
> The considerations here have a lot to do with the duration of the
> closure -- and this is closely related to the second question you asked,
> about frequency of updates for the programs that use OSM data. This
Agreed.
> frequency is entirely up to individual apps. For OSMAnd, I think it also
> depends on what version you're using.
Normal OSMAnd usage has maps generated at the end of every month,
available on about the 10th of the following month.
OSMAnd has a second mode "live", where you can get delta updates from
your last full map, at intervals up to hourly, and in particular on
demand. You can then see the time of update, and the time of last map
change. If I update, I typically see a last map change within about an
hour, maybe a bit longer, and usually when it's longer (at 6am, it might
be last evening) I suspect there were no edits overnight.
> But it's highly likely that a snapshot of the map made today will still
> be in use on some app or device months or even years from now. This is
> one reason most people avoid tagging roads closed if the closure is
> temporary.
It's true that this likelihood exists, but I would argue that users of
OSM data should have a plan to get users fresh data reasonably often
(longer than 6 months does not seem respsonsible). I do not think we
should design for systems that are not attempting to get reasonable
freshness.
I have observed over my 10 years in OSM that the typical update cycle
has shrunk, and in many cases when it gets to a month it doesn't shrink
much more, usually.
With OSM, there are no licensing reasons not to update; it's about
transfers of large files vs freshness. And then there's delta updates,
which osmand does.
> In the thread linked above, I proposed using the "conditional syntax" to
> make a temporary road closure if the dates are known. It's mentioned in
> the wiki, but not much seen in the wild. There's no way to add
> approximate dates though. And it's unclear if any software will actually
> parse these tags correctly.
Agreed. Around me, hard to predict.
> Other than that, it's really a judgement call as far as when to close a
> road. If you do and the road re-opens quickly, you risk some apps
> thinking it's closed for a long time to come. If the road will be closed
> for months, though, I'd say it's probably better to go ahead and close
> it. (Be sure to add a fixme to help remind people to open it again.)
>
> The truth is IMO we don't have a perfect way of dealing with this right
> now!
Indeed that we don't have a consensus perfect approach.
One should also consider the relative merits of
road is closed and router thinks it is open
road is open and router thinks it is closed
typically, an open road that is marked closed is not the only way, and
reasonable routes will be chosen. As opposed to a closed route that is
marked open, the user will be routed to it and hit a detour. So I
think "some apps (especially those that have too-long update cycles)
thinking it is closed for a long time" is not a big deal, because 1) it
doesn't hurt much and 2) those apps should shrink their update cycles.
Personally I have come to view 1 month as the longest reasonable update
time, and if a road will be closed for 30 days or more, and I get around
to it, I edit it in OSM. Overall I tend to optimize for those who are
making the effort to have fresh data, as I think that's where we are
heading, and it meets people who are trying halfway.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
