[Tagging] [Talk-us] Large fire perimeter tagging?

[Sarah Hoffmann]

On Wed, Sep 30, 2020 at 01:55:35AM -0700, stevea wrote:
> On Sep 30, 2020, at 12:01 AM, Andrew Harvey <andrew.harvey4 at gmail.com> 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).

This is a classic case where you should set up a separate
database to save the polygons and overlay them with OSM data.

For one thing, the description sounds like it is not really
suitable for OSM. It describes a past even ("the perimeter
firefighters used weeks ago") which is likely not ground
surveyable because I doubt that the firefighters have put
red tape all along the perimeters. The description is really
fuzzy. It just defines that the area is "of interest for
something". We have traditionally rejected this kind of
mapping, see e.g. recent discussions on no-go zones in
cities. The problem with them is that you don't find two
mappers really agreeing what they mean to represent. That
is bad in two ways: a) data consumers shy away from using them
because they cannot rely on that they mean what they think they
mean and b) the features tend to rot in the database because
most mapper don't dare to touch data they don't understand.

The other thing is that this kind of data is really easy to
merge with OSM data. You don't need to merge attributes into
specific OSM objects. You just want to state "anything inside
my polygon needs attention". Perfect for overlays. So there
really is no need at all to burden the OSM database with it.

Just to emphasize again: I'm not saying that the data is useless.
I just think it is better put elsewhere.

Sarah