[Talk-us-massachusetts] River Street Bridge CLOSED

Greg Troxel gdt at lexort.com
Sun May 22 12:36:29 UTC 2022


Bill Ricker <bill.n1vux at gmail.com> writes:

> An imaginary friend on OHM suggested re the basic closure tagging
>
>> i would just mark the bridge segment access=no until you got the desirea
>> clarification
>
> to which i replied
>
>>  that seems reasonable to ME, and I think that's what was done with the
>> Sarah Mildred Long Interstate Bridge (which is itself Interstate, but does
>> not carry an Interstate Highway), but Wiki.osm specifically requests we NOT
>> do that (nor Construction tags) for temporary closures ≤ 6 months,  so i've
>> given it a 6 month closure access:conditional and a NOTE to update when
>> schedule is announced/slips/etc
>>
>> https://www.openstreetmap.org/way/141395663
>> https://www.openstreetmap.org/note/3189485
>>
>> comments &/or armchair welcome!

I think the wiki text has not aged well and should not be followed in
this case.

Stepping back, there are various timescales at which the main OSM
database flows to users.  And, there is varying support for conditional
tagging.  I would guess, without any data, that this support is not very
good or widesspread.   The wikifiddling community is good at inventing
tags that the mainstream render/router world doesn't pay attention to :-(

Let's Look at the data flow from the main OSM database to users in terms
of a typical degree of being out of date.   This has two ways we can
express this:

  An update latency, for things that basically sync continuously.  The
  main render might be said to be "2 minute delay".

  A batch cycle and a delay, for things that get periodic sync.  for
  most fo these, the delay is smallish compared to the cycle.  OsmAnd
  has new maps once a month, with a delay of about 11 days.
  Specifically, they snapshot the db at 0Z of the 1st, and user's can
  download the new maps around on the 10th or 11th.

But we can blur this to a single value, ignoring the 10 days as shorter
than "a month", and call it "update interval".

This leads to

  If the closure is short relative to the update interval, don't change
  the map.

  If the closure is long relative to the update interval, just change
  the map and then change the map again when it's over.

  If the closure is of a known duration (a published end time which can
  be relied on to be accurate -- and I can hear you all laughing), and
  that duration is comparable to the update interval, and
  renderers/routers are known to interpret conditional tagging, then use
  conditional tagging, *AND* remove the conditional tagging when it is
  back open.

So let's look at how data is updated now:

  main render on openstreetmap.org: 2 minutes

  routing engines on osm.org: unclear and surely varies, but feels like
  about a day

  OsmAnd regular map download: 1 month

  OsmAnd live updates slow config: 1 week

  OsmAnd live updates normal config: 1 day

  OsmAnd live update extreme config: 1.5 hours

  Organic maps: I'm not sure but feels like several months

  People building maps for their Garmin with mkgmap: Their call, but
  could easily be 1 month if they care.

  OsmAnd data in renders from other providers as shown on various
  websites: I have no idea, but will assert that if it's longer than a
  month, they are behind the open-source world and I don't feel they
  need to be accomodated.

Personally, I use OsmAnd to navigate and I get live updates every
morning (for maps where I tend to be).  (I also provoke an extra live
update when I've edited the map to add detail to a place I'm about to go
to, both to use the new data and to spot things that need adding, but
that's me-as-editor not me-as-user.)

All of that leads me to:

  significant usage has about a 1 day latency from db edit to actual use

  the mainstream usage probably is order of a month

  some usage is slower

So I would set the knob of "is this closure short compared to update
timescales" to a value somewhat less than a month.

I would say that a road still marked closed on a map after it has
re-opened is a smaller problem than a road marked open that is closed,
in terms of impact on navigating.

So I personally lean mostly to:

  If a road is closed, and the duration of closure is expected to be
  around a month or greater (always true if there is no published
  reopening date), just change the map to show that the road is unusable
  (access=no if blocked, highway=construction if work is in progress).
  
  If a road is closed for 2 weeks, don't update the map.

but I also tend to want to optimize for those who are making the effort
to get fast updates.  Obviously we don't want to tag current traffic,
and we don't want to adjust tagging for "fire department has closed
I-495N for Life Flight to land but probably within 2h it will be back
open".  But when a road is closed by jersey barriers and signs instead
of a police car with flashing lights, to me that crosses into a level of
permanence that has longer time scale than the update time of many map
users.

All that said, the wiki text made sense in 2010.  It just should have
been written as "median timescale of updates flowing to users" instead
of 6 months.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us-massachusetts/attachments/20220522/b42dac0d/attachment.sig>


More information about the Talk-us-massachusetts mailing list