OpenHistoricalMap / issues

File your issues here, regardless of repo until we get all our repos squared away; we don't want to miss anything.
Creative Commons Zero v1.0 Universal
18 stars 1 forks source link

Need a method for tagging and rendering regions of natural disaster (fire, earthquake, typhoon, tornado, etc.) damage #533

Open jeffreyameyer opened 1 year ago

jeffreyameyer commented 1 year ago

What's your idea for a cool feature that would help you use OHM better. It would be great to have some method for highlighting areas that have historically been damaged by fires or earthquakes both in space and time.

Spatial Tagging

I general, I'm thinking these tags should be applied to a relation of type=multipolygon in order to allow relatively complex boundaries.

I'm not sure if we need to differentiate between fire or earthquakes (or tornados or typhoons), as the end result should be the same: extensive destruction of the pre-disaster landcover (e.g., forest) or landuse (e.g. buildings).

I'm not sure if landuse=* should apply, as it's not clear who's "using" the land that way, other than Mother Nature.

I'm also not sure if landcover=* is appropriate, as it could be both forests, even after they've burned down.

I believe HOT has a protocol for tagging disasters that we may want to follow, but I'm not [yet] sure where this is documented.

damage:date=2023-02-06
damage:event=#TürkiyeEQ060223
damage:type=earthquake
destroyed:building=yes
earthquake:damage=yes
source=*

Temporal Tagging

Even though natural events are short-lived, their impacts last longer, so end_date should be set to allow for reasonable restoration of the disaster's damage.

A wide time window will also allow the event to have a visual impact on the maps for a longer period.

Rendering

We will need some suggested approach - maybe a border of some sort, perhaps a transparent fill/pattern of some sort, maybe a border tint.

Also... this should be rendered on top of all other area layers.

Current workarounds Nothing is stopping the tagging or mapping right now, but there's no clear way to get the area rendered without a workaround (e.g. landuse).

Additional info Here's a link to a sample footprint: https://www.openhistoricalmap.org/relation/2743803#map=14/37.7847/-122.3961&layers=O&date=1909-10-10&daterange=1850-02-18,2023-12-31

And a screencap - note that even though there's a landuse=retail tag on the shape, it is buried underneath other types of landuse/cover/etc.

Monosnap Relation: ‪1906 San Francisco Earthquake and Fire Footprint‬ (‪2743803‬) | OpenHistoricalMap 2023-05-03 12-26-12
jeffreyameyer commented 1 year ago

Here's another example: 1923 Berkeley Fire: https://www.openhistoricalmap.org/relation/2743804#map=16/37.8789/-122.2623&layers=O&date=1922-04-16&daterange=1878-04-04,2023-12-31

Monosnap Relation: ‪1923 Berkeley Fire Boundary‬ (‪2743804‬) | OpenHistoricalMap 2023-05-03 12-49-23

Of note: it looks like landuse=retail is gray in OHM as opposed to pink in OSM. May have to switch to vineyard! ;)

Kovoschiz commented 1 year ago
  1. Why not landuse=brownfield or landuse=construction if the area being cleaned up than rebuilt? This is more verifiable.
  2. How is the affected area determined for earthquakes? Large fires are more well-defined from what's burnt down. Typhoons and tornado are in between, as they have a moving track, but again have wide varying area of influence.
    For 2, I suggest to start with eg natural=epicentre plus the magnitude and depth for earthquake histories. The extent of impact may then be estimated. natural=meteor_crater already exists in OSM. If the land has ruptured, this is another more certain line or area to draw than some wide-ranging damage area. Tsunamis could have both the impacted =coastline collected in a new type=, and the furthest the waves reached added. This is also easier to determine than the earthquake itself.
tsinn commented 1 year ago

https://taginfo.openstreetmap.org/keys/damage%3Atype#values

In OSM, I'm seeing lots of building=damaged combined with typhoon:damage=yes for typhoons. image

As an example for earthquakes, there is quite a bit of landuse=brownfield, specifically for the 2015 Nepal Earthquake. This is combined with damage:event=nepal_earthquake_2015, but it could also be combined with a more generic damage:type=earthquake or earthquake:damage = yes. There are also many damaged buildings (building=damaged) as well as destroyed buildings (destroyed:building = yes). The brownfields tend to show clusters of buildings, like this: image

For fires, in Italy (for example), there are the following tags for somewhat larger areas: damage=destroyed and damage:type=fire. They are associating these tags with previous / future land use (landuse=orchard or natural=wood), but for a period of time in OHM, this could also be noted as landuse=brownfield. image

matkoniecz commented 1 year ago

Note that building=damaged is quite problematic as it hijacks building key and blocks proper tagging of building type.

1ec5 commented 1 year ago

For destruction caused by disasters, start_date:cause and end_date:cause both have over a thousand occurrences in OpenHistoricalMap. For damage caused by disasters without total destruction, HOT’s damaged:* scheme makes sense, but both approaches are geared towards individual features.

For a whole expansive area, landuse=brownfield/construction feels slightly off, since there’s nothing intentional about it. An OSM approach would be to dust its hands of the issue and require data consumers to figure out where the damage is clustered based on individually tagged features. A heatmap or cluster map would be more informative than a polygon that makes a binary decision about damage, especially with something like an earthquake where there are so many kinds of potential damage. The Mapbox Style Specification includes a heatmap layer type that could be useful for this purpose.

Kovoschiz commented 1 year ago

Certainly that's the best, but it requires having each building, and marking which are damaged. There isn't even each street block and landuse= yet. I don't know if historical materials have that precision if it's earlier. =construction and =brownfield doesn't have to be "intentional" by human activity. The cause can also be added separately. They still express what's being done there. Damage is only one stage. Life goes on afterwards. If a polygon is undesirable, a new type= to collect the affected place= or boundary= is still a good overview.

jeffreyameyer commented 1 year ago

While I hear the benefit of marking destruction at the individual item level, I'm not sure it fits with historically-important, large-area catastrophes where people might want a view of a where a multi-year impact to a city took place, regardless of proper life-cycle tagging of individual buildings.

I believe there are 2 primary factors at hand here:

  1. Significance
  2. Convenience (yep!)

For the significance - we have a multiyear physical impact on a large area that - in this case - was densely populated. And, so much so that it has a Wikipedia article devoted to it. This is one of the biggest events in San Francisco history and that event is tightly bound to a geographic footprint, which seems well-suited for our map.

For convenience - think of both mappers and viewers. Mappers may want to be able to add information relevant for story telling (I saw an elephant) without the burden of having to map everything (the grain of an elephant's hide) to tell the story. A viewer may want to see a region of impact visually without having to invoke / select a heatmap or additional layer. Also, a viewer may want to be able to search for the polygon (which we could certainly have them search for, but unless it's on a map, there's no way of quickly seeing if a different item they search for is in the disaster's footprint).

Also, for convenience - I don't think it's reasonable to ask viewers or data consumers to download a bunch of data (most likely buildings), know the tagging criteria, do some sort of buffer around the union of all shapes that meet the filter criteria, etc. My reaction here is that as to changeset tags for sources... no one is ever going to do that. And, I'm not sure that this would be that different from having people map forests by mapping trees.

Convenience shouldn't be a compelling factor in all cases, but we should think about where that convenience will lead to increased use, consumption, and sharing of data on our maps.

In reading @tsinn, @1ec5, and @Kovoschiz's comments above, maybe we just need a new area type of tag? I know that area=* may be less-favored these days (except for highway?), but what about area=disaster or area=damage, to fit in with the HOT model?

Kovoschiz commented 1 year ago

area= is used for the data type. But in this direction, a derived area for abstract presentation could be eg area=virtual , area=representative , area=bounding (bounding geometry), area=influence (in the Area of Influence meaning, not exactly the physical influence of an event), etc. (don't know what the GIS term is)