On Sep 30, 2020, at 2:31 AM, Sarah Hoffmann <lon...@denofr.de> 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
