[Talk-ca] Flood Mapping in BC

Wed Nov 17 21:52:51 UTC 2021

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
NateWessel.com <https://www.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.
>
>> On Nov 17, 2021, at 16:28, Nate Wessel <bike756 at gmail.com 
>> <mailto: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 
>>>> <mailto: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 
>>>>>> <mailto: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 <mailto: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
>>>> _______________________________________________
>>>> Talk-ca mailing list
>>>> Talk-ca at openstreetmap.org <mailto: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/c3d1ebe9/attachment-0001.htm>