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

[Andrew Harvey]

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.

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.

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.

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.

On Wed, 30 Sep 2020 at 16:30, stevea  wrote:

> It appears somewhat-established (in this thread) that data consumers both
> DO and WILL find a datum of a polygon tagged fire=perimeter to be useful.
> This might be for "remap HERE when newer imagery becomes available"
> purposes (to a mapper in the area like me), to "might want to avoid hiking
> in this area as some roads / trails may remain or be closed, and it can be
> quite dangerous with "stump-slump" causing trail failures / slippages..."
> purposes (to a hiker in the area like me).  Not to mention other reasons /
> purposes cited here.
>
> I'll say it once again:  such a fire=perimeter IS a real-world "thing,"
> represented in OSM by a lightweight datum that I find to be "worth it" to
> be in the map.  It serves both better-near-future-mapping purposes as well
> as end-user / map consumer purposes.  I find that "balance" (storage cost
> in the database, whether such a datum should or shouldn't be "in the map at
> all," its usefulness to diverse OSM audiences for various, useful
> purposes...) to have value, even significance (though I'm local, so I'll
> grant I'm biased).  It seems others find similar value, too and agree that
> "sharing" such data, as OSM does, is both valid and valuable (to some) data
> to map.
>
> After all, we don't want to "hold back people from using (such data) in
> creative, productive, or unexpected ways," do we?
>
> Thanks for great feedback here,
> SteveA
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - electricity:source

[Jez Nicholson]

For questions on ground-truth, the proposal page
https://wiki.openstreetmap.org/wiki/Proposed_features/electricity:source
cites examples such as the e-bike charging station with its own solar
panels supplying the electricity
https://wiki.openstreetmap.org/wiki/File:Solar-Stromtankstelle_in_Allentsteig.jpg

Admittedly, a charging station could be supplied by electricity from a
green energy company that only uses renewable energy. In which case, there
may well be signage on the station.

Lukas, did you consider charging_station:source ? to be similar to other
power tags (power:generator + generator:source=solar, power:plant =
plant:source=solar)?

On Tue, Sep 29, 2020 at 9:30 PM Lukas Richert  wrote:

> Hi Colin,
>
> I agree that while a few suppliers source all of their electricity from
> renewable sources, most simply add a surcharge which is used to fund the
> growth of renewable energy infrastructure and price the electricity as if
> it were coming from solely renewable energy sources. I'm working on an
> article for Wikipedia that will explain green pricing tariffs in detail as
> this seems to be lacking in English.
>
> Arguing if the definiton of 'green electricity' is actually 'green' is not
> the point, this is already a term that is explicitly advertised at the
> charging stations or camp sites (see images in proposal) and also something
> that consumers look for as they want to fund renewable energies in the hope
> that all grid energy will be completely 'renewable' in future. While this
> obviously won't be for at least 15-50 years depending on who you ask, I
> think it is a worthwhile attribute to map as some people are conscious of
> what types of electricity generation they wish to support.
>
> Best, Lukas
>
>
> On 29/09/2020 16:56, Colin Smale wrote:
>
> Hi Lukas,
>
> You do realise that all electricity is the same, irrespective of how it is
> generated? The "greenness" or otherwise is not determined by the
> connection, but by the subscription/contract that the consumer has with
> their supplier.
>
> UNLESS they have a standalone generating capability, like PV or wind
> turbine that is not connected to the grid.
>
> On 2020-09-29 16:00, Lukas Richert wrote:
>
> Hi,
>
> I'd like to propose a new tag that defines the source of publicly
> available electricity: electricity:source
> 
>
> This could be used as an additional information tag on amenities that
> provide electricity for public consumption, such as bike/car charging
> stations or camp sites. Many charging stations have nearby solar or use
> green pricing tariffs. I've also seen camp sites and harbours advertise
> this.
>
> This topic came up as a group wanted to plan a bike tour using e-bikes but
> only with renewable energy. I noticed that there appears to be no easy way
> to filter for the source of the electricity provided.
>
> Potential discussion: It's not quite clear to me whether power_supply or
> electricity is preferred for this type of application. It might also be
> interesting for consumers to see which buildings are powered by green
> electricity if this is something a store or similar advertises. So it may
> be worth expanding the proposal to electricity used by the public even if
> not directly available (e.g. lighting in a store).
>
> Best regards,
> Lukas
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 30. Sep 2020, at 08:30, stevea  wrote:
> 
> I'll say it once again:  such a fire=perimeter IS a real-world "thing," 
> represented in OSM by a lightweight datum that I find to be "worth it" to be 
> in the map.


+1
it is also clearly verifiable on the ground and will remain so for some time.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[stevea]

On Sep 30, 2020, at 12:01 AM, Andrew Harvey  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [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  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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[stevea]

On Sep 30, 2020, at 2:31 AM, Sarah Hoffmann  wrote:
> This is a classic case where you should set up a separate
> database to save the polygons and overlay them with OSM data.

Thank you for your thoughtful reply, Sarah.  However… (and it’s not polygons 
plural, I only entered into the map this singular case, though with this 
discussion and other firefighters chiming in that these can be useful data in 
OSM, they could be talked about as a particular class of object)…

> 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")

That’s not quite what I said, I said “the extent of where firefighters kept the 
fire limited by building a perimeter around it.”

> which is likely not ground
> surveyable because I doubt that the firefighters have put
> red tape all along the perimeters.

I’m not positive that this is true for the entire perimeter, but 
bulldozer-cleared areas, hand-dug trenches many meters wide (to prevent a fire 
“jumping” from one side of the perimeter to the other) and usage of cutlines 
(for power cables / towers) and roadways to establish part of a perimeter are 
all strategies I believe firefighters use to “build” such a fire perimeter.  
This is much more clearly delineated in the real world than might be a bit of 
red tape on a tree.

> The description is really
> fuzzy. It just defines that the area is "of interest for
> something".

It is of interest for two specific purposes (perhaps better outlined here than 
in the recently-added note=* tag, though I only get 255 characters there):  to 
say “better mapping of existing land cover tags is very likely necessary HERE” 
and to say “if you intend to hike in this area, know that due to (recent) fire, 
closed roads and dangerous conditions, very much diminished in their ability to 
provide a suitable recreational landscape, are likely found HERE."

> 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.

I recall that “no-go” discussion and I agree that it was / is hard to define, 
which does yield “two mappers won’t likely agree on what this means."  Yet 
here, I see the focus sharpening on what is meant by this polygon, as well as 
others who say “yes, as a HOT mapper, a firefighter, someone for whom structure 
re-building going on in an area in a construction-intensive way, delineating 
this in the map is useful.”  In a sense, this discussion is a (more dilute?) 
form of a wiki proposal for fire=perimeter.  Except it is not, as we only 
discuss a single polygon, yet others say “I can see how THESE (not simply 
“this”) can be useful data.  As we agree on what fire=perimeter means, the 
ambiguity reason (a) vanishes.  And (b), as already discussed, such data don’t 
(or shouldn’t) “rot,” since as mentioned before, they fall away from the map 
when their usefulness vanishes.

> 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.

I think “burden” for a lightly-tagged polygon is hyperbole (exaggeration), but 
I do see the point that a sophisticated user who is curating data in, around or 
associated with such a polygon might find an overlay strategy to be ideal.  But 
doing so leaves out all other OSM users (many, besides the single user noted 
above) and all other “useful” reasons for the data being shared in the database 
(which might become many, but are now discussed as “at least two:  to better 
re-map and to warn users “there was a fire here, use care”). Perhaps we have 
identified an edge between where “data are better curated outside of OSM” and 
“data that seriously benefit by being shared and hence Inside of OSM.”  Who 
decides?  How?

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

I respect and welcome intelligent discussion on which data belong “in or out” 
of OSM, and why (or why not).  Perhaps this topic is (or is becoming) partly or 
mostly exactly that.

SteveA
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - electricity:source

[Lukas Richert]

Yes, I've seen exactly such signage on a number of charging stations in 
my area. I did consider the generator:source-type tagging as well, and 
pretty much took the possible values from there (plus adding the general 
'renewable' tag), however this is something that many different types of 
amenities advertise, like camp_sites, farms, harbours, etc. Therefore, 
my question is if it would be reasonable to also use as a tag for, e.g. 
buildings that are available to the public and use lighting from 
renewable sources.


Furthermore, there doesn't yet seem to be a great standard for mapping 
when electricity is available to the public - at least, I couldn't find 
appropriate tags via the camp_site wikipages. Closest seems to be 
power_supply  
(still in draft mode, but used some), however this seems to be meant 
more for individual sockets and it wouldn't fit well with tagging 
buildings that are simply powered by a specific type of energy. Also, 
the tag 'electricity' is being used to map if buildings are on- or 
off-grid (see also geographical distribution of the tags), so 
electricity:source might fit a bit better than power_supply:source, 
however both tags are not actually approved yet.


Perhaps we should try to combine the electricity draft and the 
electricity:source draft to finally be able to map publically 
used/available electricity? This seems to be, overall, a feature sorely 
lacking in OSM even though most people use it every day. I think it 
would be important to clarify which terminology is officially in use.


[Perhaps make electricity have the possible values grid or generator, 
and then use the tags generator:source and grid:source to further 
specify? This might be a problem for electricity=yes -> 
yes:source=renewable doesn't make sense, but it might not be possible 
for the mapper to verify if there is clear signage of '100% renwable 
energy' but the source is not clear ]



On 30/09/2020 09:24, Jez Nicholson wrote:
For questions on ground-truth, the proposal page 
https://wiki.openstreetmap.org/wiki/Proposed_features/electricity:source 
 
cites examples such as the e-bike charging station with its own solar 
panels supplying the electricity 
https://wiki.openstreetmap.org/wiki/File:Solar-Stromtankstelle_in_Allentsteig.jpg 
 



Admittedly, a charging station could be supplied by electricity from a 
green energy company that only uses renewable energy. In which case, 
there may well be signage on the station.


Lukas, did you consider charging_station:source ? to be similar to 
other power tags (power:generator + generator:source=solar, 
power:plant = plant:source=solar)?


On Tue, Sep 29, 2020 at 9:30 PM Lukas Richert > wrote:


Hi Colin,

I agree that while a few suppliers source all of their electricity
from renewable sources, most simply add a surcharge which is used
to fund the growth of renewable energy infrastructure and price
the electricity as if it were coming from solely renewable energy
sources. I'm working on an article for Wikipedia that will explain
green pricing tariffs in detail as this seems to be lacking in
English.

Arguing if the definiton of 'green electricity' is actually
'green' is not the point, this is already a term that is
explicitly advertised at the charging stations or camp sites (see
images in proposal) and also something that consumers look for as
they want to fund renewable energies in the hope that all grid
energy will be completely 'renewable' in future. While this
obviously won't be for at least 15-50 years depending on who you
ask, I think it is a worthwhile attribute to map as some people
are conscious of what types of electricity generation they wish to
support.

Best, Lukas


On 29/09/2020 16:56, Colin Smale wrote:


Hi Lukas,

You do realise that all electricity is the same, irrespective of
how it is generated? The "greenness" or otherwise is not
determined by the connection, but by the subscription/contract
that the consumer has with their supplier.

UNLESS they have a standalone generating capability, like PV or
wind turbine that is not connected to the grid.

On 2020-09-29 16:00, Lukas Richert wrote:


Hi,

I'd like to propose a new tag that defines the source of
publicly available electricity: electricity:source



This could be used as an additional information tag on amenities
that provide electricity for public consumption, such as
bike/car charging stations or camp sites. Many charging stations
have nearby solar or use green pricing tariffs. I've also seen
camp sites and harbours adver

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

[Paul Allen]

On Wed, 30 Sep 2020 at 08:09, Andrew Harvey 
wrote:

>
> 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.
>

It may not be sensible to map active fire fronts in OSM itself but something
like umap seems well-suited for that purpose.  It doesn't "contaminate" the
OSM database and is relatively easy to clean up when the fire has been
dealt with.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - electricity:source

[Janko Mihelić]

I don't like the tag key, because I would assume it's saying where its
electricity is coming from, the grid or a generator on premises. This is a
very intangible thing we are putting in a tag. A business is promising it's
going to have a certain kind of contract with its electricity supplier.
Maybe, electricity:supplier:renewable=yes?
electricity:contract:renewable=yes?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Allen]

On Wed, 30 Sep 2020 at 09:58, stevea  wrote:

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.


It was I who said that.  I don't have your personal experience, but in a
"seven degrees of Kevin Bacon" kind of way I have come to know a
group of people on Facebook who avidly hike in the affected areas.  When
discussing the fires and their possible aftermath they compare them to past
fires and mention six to seven years for past recoveries.

BTW, ordinary polygons won't do for this.  You'll need a multipolygon
to exclude the Mount Wilson observatory and some campgrounds that
were saved from the fires burning all around them. :)

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andrew Harvey]

On Wed, 30 Sep 2020 at 18:58, stevea  wrote:

> This is useful because it shows not only where OSM mappers (like me) will
> need to update landcover
>

At least after the Australian fires, we still left natural=wood areas which
burned tagged that way, and in my view this is correct since they are still
are wooded areas even after the fire even with crown fires and with many
trees not surviving.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[stevea]

On Sep 30, 2020, at 5:27 AM, Paul Allen  wrote:
> BTW, ordinary polygons won't do for this.  You'll need a multipolygon
> to exclude the Mount Wilson observatory and some campgrounds that
> were saved from the fires burning all around them. :)

Perhaps I have not been clear or remain misunderstood:  the polygon is not an 
exact delineation of "this (and exactly this) has all burned."  It is the 
perimeter of the fire, inside of which the fire was "fought" or allowed to 
burn, outside of which, "not."  If there are areas (like Mt. Wilson Observatory 
and campgrounds) inside of a perimeter that were "saved," the polygon should 
not explicitly exclude these areas with role "inner" as part of a multipolygon 
relation — that isn't the semantic of the perimeter.  Many areas inside the 
perimeter DID burn and will need their existing land cover (natural=wood, 
natural=scrub...) tags removed, some areas (trees, houses which were saved...) 
did NOT burn.  It would not be correct to re-map the fire=perimeter as a 
multipolygon with not-burned areas with role "inner."  As newer imagery becomes 
available, it is correct to leave not-burned areas alone, adjusting them up to 
the edge of where they DID burn, and in areas which did burn, removing / 
adjusting-to-smaller-areas land cover tags as they exist now.  This area was 
almost exclusively heavily wooded in the real world and OSM well maps fairly 
precisely where these "woods" were.  Only now, much of them burned.  Where, 
exactly?  "Somewhere inside of" the polygon denoted fire=perimeter.  OSM 
contributors await newer imagery, we will better (re-) map landcover and other 
data that are inside of the polygon when they become available.

At the completion of this process, the usefulness of the polygon diminishes to 
zero (perhaps there remain closed roads and dangerous areas, these can be 
mapped "differently," although "no-go" area tagging remains unclear) and the 
polygon can be removed, having exhausted its usefulness.

Some might complain that such an "improve existing map data HERE" polygon 
overlaps with small projects like a localized import or a Mapping Party to 
improve a particular city or county, saying a Tasking Manager or similar tool 
can and should be used to manage this.  But while "a particular city or county" 
have well-defined, largely in-the-map boundaries, an area devastated by major 
fire has no such boundary.  Unless and until a polygon tagged fire=perimeter is 
entered, to describe an "area of interest for improvement of existing map data" 
(rather than "this is all burned").  A Tasking Manager could be used for this, 
but it needs such a polygon to identify the area of interest.

SteveA
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Kevin Kenny]

On Wed, Sep 30, 2020 at 6:22 AM stevea  wrote:
> I’m not positive that this is true for the entire perimeter, but 
> bulldozer-cleared areas, hand-dug trenches many meters wide (to prevent a 
> fire “jumping” from one side of the perimeter to the other) and usage of 
> cutlines (for power cables / towers) and roadways to establish part of a 
> perimeter are all strategies I believe firefighters use to “build” such a 
> fire perimeter.  This is much more clearly delineated in the real world than 
> might be a bit of red tape on a tree.

Definitely, and more permanent as well.  My brother's place has a line
that was bulldozed down to bare rock in a firefighting operation in
1950. There's still a strip of bare rock there, because it takes
decades for enough duff and debris to accumulate to rebuild the soil.
(Moreover, the slope is steep, so the spring snowmelt tends to flush
away what has accumulated.) We still use the fire line to walk to the
back of the property. Nature is gradually rebuilding, but the
landcover there is still mostly ferns, mosses and lycopodia, although
there are a lot more perennial forbs and we're starting to see alders
reappear.

> I think “burden” for a lightly-tagged polygon is hyperbole (exaggeration), 
> but I do see the point that a sophisticated user who is curating data in, 
> around or associated with such a polygon might find an overlay strategy to be 
> ideal.  But doing so leaves out all other OSM users (many, besides the single 
> user noted above) and all other “useful” reasons for the data being shared in 
> the database (which might become many, but are now discussed as “at least 
> two:  to better re-map and to warn users “there was a fire here, use care”). 
> Perhaps we have identified an edge between where “data are better curated 
> outside of OSM” and “data that seriously benefit by being shared and hence 
> Inside of OSM.”  Who decides?  How?

I tend to have little patience with claims that features that are
visible in the field ought not to be mapped because they will "burden
the map".  Generally speaking, that means simply that those features
are not of interest to the claimant. I welcome correct mapping of any
observable feature, even ones that I'm highly unlikely to map or care
about. I don't think any of us has the right to dictate that another
mapper ought not to be interested in a given feature.

On Wed, Sep 30, 2020 at 8:29 AM Paul Allen  wrote:
> On Wed, 30 Sep 2020 at 09:58, stevea  wrote:
>> 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.
>
> It was I who said that.  I don't have your personal experience, but in a
> "seven degrees of Kevin Bacon" kind of way I have come to know a
> group of people on Facebook who avidly hike in the affected areas.  When
> discussing the fires and their possible aftermath they compare them to past
> fires and mention six to seven years for past recoveries.

If you consider replacing a stand of mature hemlocks with an alder
thicket to be 'recovery'.  (Substitute the successional stages of your
local ecosystem. Mostly where I hike, it's the mixed-deciduous forest
of eastern North America, transistioning to Canadian taiga at the
higher elevations, with alpine tundra on a few high peaks.)

-- 
73 de ke9tv/2, Kevin

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging