[Talk-ca] Flood Mapping in BC

Wed Nov 17 22:46:11 UTC 2021

I would be in favour of mapping some of the closures, but not all of them. For example, Highway 1 here on Vancouver Island is currently partially closed, but I expect the damage to be fixed within the next week or two at most (or at least fixed to the point of the highway being usable in both directions). That's certainly too short to make OSM changes. On the other hand, Highway 5 could be closed for many months. Based on some of the images I'm seeing, it could be many, many months for some parts of it. That may be worth mapping. 

I think we should wait until the waters recede and authorities have a better idea of timelines, and then we can decide whether any closures will be long enough to be worth mapping. Given more time, we'll also get a better sense of where exactly the damage has occurred and what might need to be edited. I know the bridge at Juliet is out and I think there's a washout near Othello, but I'm not completely certain where some of the other damaged portions of Highway 5 are. 

Andrew 

From: "talk-ca" <talk-ca at openstreetmap.org> 
To: "talk-ca" <talk-ca at openstreetmap.org> 
Sent: Wednesday, November 17, 2021 2:24:24 PM 
Subject: Re: [Talk-ca] Flood Mapping in BC 

Dans le cas de chantiers majeurs, la question du verre à moitié plein, oui quelle décision appliquer. 

J'entends aux infos que le gouvernement de Colombie-Britannique veut réagir rapidement et assurer que des voies temporaires soient accessibles.Il serait possible de montrer l'évolution de l'accès routier à condition que la communauté locale (qui peut observr de visu et suivre les infos locales) assure le suivi. A voir si quelqu'un se propose. Il faudrait par exemple mettre a jour constamment les relations les plus importantes dont l'autoroute vers la vallée du Fraser et assurer que les relations indiquent toujours un chemin continu (non interrompu par des travaux). Les différents outils tels OSMAnd pourraient avoir un certain retard à publier mais par contre toujours offrir un trajet continu. 

À titre d'exemple, dans la région de Montréal deux projets routiers majeurs on été suivis au cours des dernières années par les contriubuteurs de la région. Ces deux projets étaient quelque peu différents parce que dans ce cas il s'agissait de représenter le déplacement des anciennes vers les voies temporaires puis les nouvelles voies permanentes. Les nouveaux segments étaient ajoutés, les anciens indiqués comme désuets et les relations routières étaient constamment mises à jour pour réfléter les nouveau segments à utiliser. 

Pierre 

Le mercredi 17 novembre 2021, 16 h 55 min 59 s UTC−5, Nate Wessel <bike756 at gmail.com> a écrit : 

So, the main critique in the phrase "tagging for the router/renderer" as I understand it is that it implies that one is modifying their reasonable interpretation/understanding of reality to accommodate a particular, limited technology or application. In this case, those routers really should be able to update quickly when the data changes, but maybe some of them don't and that is what it is, but it's definitely not the ideal scenario given that data often changes. 

Tons of things in the OSM database change all the time. I just mapped out dozens of new weed dispensaries in Toronto because I think that's an interesting trend. But if even half of them are still open in two years I'll be pretty surprised. 

In the end, everything changes, even the mountains. Ashes to ashes and dust to dust, etc. The only real question is how fast is too fast. I'd say something that exists for a month may well be worth mapping. Other people may draw that line somewhere else. Keep in mind that OSM, because it maintains history, is also an historical database. Most of us don't use it for that, but I think the applications there are very very interesting, especially as OSM transitions from adding new data (by and large) to maintaining and updating. 

Definitely not zero value. 

Nate Wessel 
Cartographer, Planner, Transport Nerd 
[ https://www.natewessel.com/ |  NateWessel.com  ] 
On 2021-11-17 4:37 p.m., Martin Chalifoux wrote: 

Let me ask then, if you are not tagging construction work for the router, what are you doing it for ? It makes no sense doing it. Somebody must show how it can be usefu to anybodyl. I repeat myself, but the core map database is not the place to put time-changing data like that. It belongs elsewhere. 

Google Maps and Apple Maps are years ahead in this area. But they also have a huge infrastructure supporting it, including live traffic data fed back from all the phones going on the road. They have lots of employees taking info from transport authorities and feeding it to their apps. They don’t do it by hand with a handful of people. If OSM want to get into that ball game, it needs a proper plan. Tagging roads and messing with the core map database is not a plan. I see it has having zero value. Partners using the OSM dataset I am sure see it the same way. 

Cheers. 

BQ_BEGIN

On Nov 17, 2021, at 16:28, Nate Wessel < [ mailto:bike756 at gmail.com | bike756 at gmail.com ] > wrote: 

BQ_END

That's a very pragmatic approach, and defensible for sure. But it also sounds to me like a case of [ https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer | "tagging for the renderer ] ", or for the router in this case. 

One can also make a good case that OSM should reflect [ https://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground | reality 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 
[ https://www.natewessel.com/ |  NateWessel.com  ] 
On 2021-11-17 3:51 p.m., Martin Chalifoux wrote: 

BQ_BEGIN

BQ_END

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. 

BQ_BEGIN

On Nov 17, 2021, at 15:33, Nate Wessel < [ mailto:bike756 at gmail.com | bike756 at gmail.com ] > wrote: 

BQ_END

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 
[ https://www.natewessel.com/ | 
                                      NateWessel.com  ] 
On 2021-11-17 2:26 p.m., Martin Chalifoux via Talk-ca wrote: 

BQ_BEGIN

BQ_END

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. 

BQ_BEGIN

On Nov 17, 2021, at 13:55, Joel < [ mailto:joel at joelmcfaul.ca | 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 
[ mailto:Talk-ca at openstreetmap.org | Talk-ca at openstreetmap.org ] 
[ https://lists.openstreetmap.org/listinfo/talk-ca | https://lists.openstreetmap.org/listinfo/talk-ca ] 

BQ_END

_______________________________________________
Talk-ca mailing list [ mailto:Talk-ca at openstreetmap.org | Talk-ca at openstreetmap.org ] [ https://lists.openstreetmap.org/listinfo/talk-ca | https://lists.openstreetmap.org/listinfo/talk-ca ] 
_______________________________________________ 
Talk-ca mailing list 
[ mailto:Talk-ca at openstreetmap.org | Talk-ca at openstreetmap.org ] 
[ https://lists.openstreetmap.org/listinfo/talk-ca | https://lists.openstreetmap.org/listinfo/talk-ca ] 

_______________________________________________ 
Talk-ca mailing list 
[ mailto:Talk-ca at openstreetmap.org | Talk-ca at openstreetmap.org ] 
[ https://lists.openstreetmap.org/listinfo/talk-ca | 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/5d6a2016/attachment-0001.htm>