[Talk-ca] Flood Mapping in BC

Wed Nov 17 21:47:12 UTC 2021

My thoughts would run along the lines that unfortunately most end users do
not use the database directly.

It's one thing to add a new highway or path that no one else has but quite
another to map an existing blockage.

Osmand users will almost certainly be using map data that is not as up to
date as the main database.

I think the problem lies in how reliable the data is.  End users tend to
rate reliability above everything else.  Can I trust the data?  Adding in
the blockages means that old versions of the map will not be as reliable,
when the blockages are cleared the main map will show the cleared highway
but those lagging copies will not.

So it becomes a matter of trust.  As an end user can I trust what I'm
seeing from OpenStreetMap and if you add the blockages you cause a lot of
uncertainty to the end user.  Has this routing engine been updated?  Do I
need to purchase another download for OSMAnd or whatever software?

I'd tend to leave this one.  If they are mapped then it should be by a
local who can remap the area immediately the blockages are cleared.

Cheerio John

On Wed, Nov 17, 2021, 4:32 PM Nate Wessel <bike756 at gmail.com> wrote:

> That's a very pragmatic approach, and defensible for sure. But it also
> sounds to me like a case of "tagging for the renderer
> <https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer>", or for
> the router in this case.
>
> One can also make a good case that OSM should reflect reality on the
> ground
> <https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground>,
> which is the direction I lean in personally. Our data can be better and
> more up to date than some of the big map services can even handle. How neat
> is that?
>
> But this is probably one of those glass half-full/half-empty debates in a
> lot of ways. Both sides have good arguments.
>
> Cheers,
>
> Nate Wessel
> Cartographer, Planner, Transport Nerd
> NateWessel.com <https://www.natewessel.com>
> On 2021-11-17 3:51 p.m., Martin Chalifoux wrote:
>
> Reasonable, and don’t forget routing services do not use the OSM data
> LIVE, they use a copy. Even services such as OpenRouteServices do not
> rebuilt their routing tree every day. Their visual map may update, but the
> underlying routing engine, which takes a lot of computing to update, is not
> updated very often. So even if the person doing the edit is diligent to
> undo it when the construction is finished, these services will not update
> quickly. That is why I say you are adding inaccuracies later. When the road
> re-open, people will still be diverted from using it. That caused more
> problems than it solves. Given the nature of OSM I see it as pointless to
> add temporary edits like this. It really does no good at all.
>
> Cheers.
>
> On Nov 17, 2021, at 15:33, Nate Wessel <bike756 at gmail.com> wrote:
>
> I agree with regard to very short term closures e.g. for parades,
> marathons, but I imagine we're talking here about closures that could have
> impacts for weeks to months, and would have dramatic implications for
> routing especially. IMO it's on any service providers to update their data
> in a timely way, including data from OSM.
>
> My main criteria, personally, for including these sorts of changes in OSM
> is whether the person making the edit that closes a road (etc) because of
> damage, construction, is also planning to make a timely edit to reopen that
> road when the time comes. Better to leave it as is if there isn't anyone
> watching for the reopening. But if someone wants to watch the situation
> closely and make the map mirror reality, I say go for it.
>
> Cheers,
>
> Nate Wessel
> Cartographer, Planner, Transport Nerd
> NateWessel.com <https://www.natewessel.com/>
> On 2021-11-17 2:26 p.m., Martin Chalifoux via Talk-ca wrote:
>
> OSM is not designed to map elements that change in time such is traffic,
> construction. There is no way to set start and end dates to element for
> example. It is a database that gets *duplicated* in tons of services be
> it online services that render OSM data, or apps on smartphones, etc. These
> services take a snapshot and then may not update again for months, a year,
> who knows. When people put elements that expire quickly, such as
> maintenance construction (OSM construction tags exists but are designed for
> new roads being built, not repairs), then there temporary elements are
> expires and removed, they remain in all the other services. It makes the
> OSM data unreliable. You add a bit of short time accuracy but even more
> long time inaccuracy.  Anyhow I presonnaly advocate agains adding broken
> roads to the OSM database. Road closures are the responsibility of the
> rendering engines and they must get that info from other sources than the
> map database and then add it as a layer. OSM is the map layer, then
> traffic, closures, weather, etc. are better treated as completely
> independant layers.
>
> My take anyway, Martin.
>
>
>
> On Nov 17, 2021, at 13:55, Joel <joel at joelmcfaul.ca> wrote:
>
> Hi everyone,
>
> Numerous major highways have been washed out or blocked due to recent
> flooding in BC. Does this community have any thoughts about reflecting
> these changes in OSM? I assume most of these closures will be temporary,
> however are significant and may last for months.
>
> Thank you,
> Joel
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> _______________________________________________
> Talk-ca mailing listTalk-ca at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20211117/9e150489/attachment.htm>