On Sep 30, 2020, at 12:01 AM, Andrew Harvey <[email protected]> wrote: > So it seems then that what you're mapping here isn't so much the active fire > front, it's the burnt area given you want it to stick around after the flames > are out.
Neither of these two, really. Certainly not the active fire front: the fire is out (for about a week now, but it burned for about six weeks). Nor “the burnt area” exactly, but rather a polygon which represents the EXTENT of where firefighters kept the fire limited by building a perimeter around it. Some (I’d guess much or even most) of it IS burned, no doubt, but exactly where is not fully yet known — but burned areas certainly ARE inside of this polygon. This is useful because it shows not only where OSM mappers (like me) will need to update landcover (and in some limited cases, landUSE, too) as we update map data, but where map data consumers such as hikers in the area (like me) will want to know “there may be closed roads, dangerous areas and severely limited viewscapes, wildlife (both flora and fauna) et cetera to enjoy were I to recreate here.” These are but two valuable reasons for this fire=perimeter remaining in the map, until the polygon's usefulness essentially becomes exhausted (there are no longer reasons for these data to remain). > During Australia's fires last season, I did contemplate mapping active fire > fronts, given I could see with my own eyes where the flames were up to and I > could have done a more accurate job for a small area than what the government > authority was publishing at the time. However due to the fast changing nature > of it and temporary nature of the active front, I don't think it's worth > mapping. I agree with you those data are of a “more ephemeral” nature and so are much less useful to include in the map. > For burnt areas and recovery progress, sure this is not temporary (could be a > few months to years for evidence on the ground) and it's not fast changing, > once an area is burnt it stays burnt. So yeah you could map it, but from my > experience in Australia this again wouldn't be worth it (not saying that you > shouldn't map it, the way isn't really harmful and I'm not local, so not > telling you what to do). The main reason here is that the burn isn't uniform, > patches are noticeably burnt to a higher degree than others and some patches > might be unaffected, and it can be hard to survey this. It's also hard to > know when to remove it from OSM, because after all OSM doesn't contain > historical features which aren't found on the ground anymore, so at some > point OpenHistoricalMap becomes more appropriate. I saw someone say “six to seven years” (as what might pass for “recovery” to a large degree) to have “taken root” and after living most of my life here, that sounds about right. This length of time is similar for human structures (houses, barns…) as well as (the beginning of) the natural world to have begun to bounce back. (Here, insurance, permits, construction, re-population can and do take years). However, do know that this area's redwood trees can be a thousand years old (rare, but we have those). Summer 2008 I hiked a couple hours drive south of here (Big Sur, Ventana Wilderness…) after a major fire and even when trails re-opened only nine or ten weeks after the burn and most of it looked like a moonscape, I saw the literal “green shoots” beginning to sprout, starting the growth cycle anew. (I have pictures!). After six, eight, ten years, it begins to look “more like it once did,” but no sooner. > Satellites do a pretty good job of finding out which areas burned and to what > degree, so I'm happy mostly to just rely on rasters from satellite instead of > hand traced and vectors in OSM. The latter define the bounds of the former, as the former become available. And not just for tracing / better mapping with newer imagery (as above), but for “map data consumers” (hikers…) alike (as above). SteveA _______________________________________________ Tagging mailing list [email protected] https://lists.openstreetmap.org/listinfo/tagging
