Impact on Buildings: we need a new data type

[Charlotte-Morgan]

problem

All impact functions on buildings assume that the data are classified and have a 'type; field. This is fine if buildings data have been downloaded through OSM and data type field is added regardless of whether the data have any attributes or system of classification. This means that users can not use their own building data on a building analysis.

proposed solution

add an "unclassified" key word option for building (and road) data types. This will allow users to quantify affected structures but not produce a detailed report.

By adding the 'bug' label - I hope this can be in (Bug fix release 3.2.1) BFR 321 :)

cc

@timlinux @MattJakabGA @vdeparday @assefay @iyan31

[Charlotte-Morgan]

on second thoughts - maybe this is a regression as the user docs describe classified and generic buildings

[timlinux]

Yeah we used to have a 'non osm' building IF I think - maybe it got killed in one of our cleanups. @ismailsunni can you see if you can get the existing OSM based IF to also support layer with no Type keyword please?

[ismailsunni]

Hi @timlinux We have this function, get_osm_building_usage. It will be used if the exposure layer doesn't have structure_class_field or set to None (or empty string). Is that what you mean?

But, I thought what @Charlotte-Morgan means if the user feels that the exposure layer doesn't have field that represent the type of building (or road), we should not try to classify (or group) the building (or the road) based on their type.

[Charlotte-Morgan]

I think users were able to have the generic option when assigning kw to building data - now they only have classified as an option

[ismailsunni]

Actually, the generic thing for exposure is not related to the breakdown by building type. We made it to show that it doesn't have unit. In the previous InaSAFE, some IFs did not show the breakdown by the building type because it's not coded yet. Some other IFs gave the breakdown, no matter what we set in the exposure field (even this exposure field was not existed or used yet). Because we didn't have the exposure field, we use a little hacky method to retrieve the building type based on attribute in OSM.

So, it's not a regression. We need a new capability for InaSAFE to support exposure layer that doesn't have exposure field.

[timlinux]

This should be taken care of by the work that @borysiasty @ismailsunni and @Gustry have been doing to support value_maps for exposure data. Here are some extra notes:

Things that are not classified in the metadata: We had a bit of a discussion on it here and there arn’t really any optimal ways to deal with it so my suggestion to Etienne is to do this:

• Add some text to the value mappings page in the wizard informing the user that any items that are not included in the classification tree will automatically be added to the ‘other’ group.
• @Gustry will add logic to the IF / post proccessor to add unknown classes to the other group automatically
• In future if you can think of a better behaviour we will do that as a tweak to the above system

See also

2721

2741

2743

[timlinux]

@Gustry please close this out when your work on value_map is done

[Gustry]

The value_map is done in InaSAFE 3.4