Volcano impact on buildings - report by type error #2090

Closed
Charlotte-Morgan opened this Issue Jul 7, 2015 · 8 comments

Comments

Projects
None yet
4 participants
@Charlotte-Morgan

problem

The volcano point impact on buildings generates a report of affected buildings that also has some extra unrelated information.
It appears that during the impact analysis the attributes for the volcano buffer are joined to the building attribute table. The volcano data also has a type field and this is being propogated into the analysis results so that the buildings which were 'residential' in the OSM downloaded data are all "stratovolcano" in the building impact analysis results.
image

proposed solution

ensure the original building type field is retained throughout the analysis and that this field is the one used to generate impact reports

@timlinux

This comment has been minimized.

Show comment
Hide comment
@timlinux

timlinux Jul 13, 2015

Contributor

So the solution here seems to be (in short term) to change the buffering logic to not write 'type' as column name for generated volcano buffers and to ensure the volcano point IF uses the updated name.

Contributor

timlinux commented Jul 13, 2015

So the solution here seems to be (in short term) to change the buffering logic to not write 'type' as column name for generated volcano buffers and to ensure the volcano point IF uses the updated name.

@timlinux timlinux added this to the Version 3.2 milestone Jul 13, 2015

@timlinux timlinux referenced this issue Jul 13, 2015

Closed

We need to fix various issues with volcanos #2125

5 of 6 tasks complete
@cchristelis

This comment has been minimized.

Show comment
Hide comment
@cchristelis

cchristelis Jul 15, 2015

Contributor

The volcano name attribute is actually expected to be "NAME" if the user renames it to "TYPE" and sets it to "TYPE" in the impact function, then this problem is created. I propose inspecting the volcano name attribute and if that name already exists, then to edit the attribute name to end in an underscore "_".

In this case, the use case will be doing the following: The volcano point layer has a column called "TYPE", which contains the name. The user selects this as the attribute to contain the volcano name. Since the attribute already exists in the buildings layer, this is changed to "TYPE_" and the attribute is no longer masked.

Contributor

cchristelis commented Jul 15, 2015

The volcano name attribute is actually expected to be "NAME" if the user renames it to "TYPE" and sets it to "TYPE" in the impact function, then this problem is created. I propose inspecting the volcano name attribute and if that name already exists, then to edit the attribute name to end in an underscore "_".

In this case, the use case will be doing the following: The volcano point layer has a column called "TYPE", which contains the name. The user selects this as the attribute to contain the volcano name. Since the attribute already exists in the buildings layer, this is changed to "TYPE_" and the attribute is no longer masked.

@timlinux

This comment has been minimized.

Show comment
Hide comment
@timlinux

timlinux Jul 15, 2015

Contributor

Thanks @cchristelis Just make sure not to change / alter the source file, only intermediate working files.

Contributor

timlinux commented Jul 15, 2015

Thanks @cchristelis Just make sure not to change / alter the source file, only intermediate working files.

@Charlotte-Morgan

This comment has been minimized.

Show comment
Hide comment
@Charlotte-Morgan

Charlotte-Morgan Jul 15, 2015

I'm not sure that is what i experienced.
In the data i had, the volcano Type field has a value (Stratovolcano) - this is not the name but this value overwrote the affected building types in the impact on buildings analysis.

Maybe your comment above relates to the other ticket where the name of the considered volcano is not read by the IF?

I'm not sure that is what i experienced.
In the data i had, the volcano Type field has a value (Stratovolcano) - this is not the name but this value overwrote the affected building types in the impact on buildings analysis.

Maybe your comment above relates to the other ticket where the name of the considered volcano is not read by the IF?

@Charlotte-Morgan

This comment has been minimized.

Show comment
Hide comment
@Charlotte-Morgan

Charlotte-Morgan Jul 15, 2015

i changed my source file by removing the type field and renaming it voltype and the IF ran fine and results were as expected - except for teh other ticket about the name not being read

i changed my source file by removing the type field and renaming it voltype and the IF ran fine and results were as expected - except for teh other ticket about the name not being read

@cchristelis

This comment has been minimized.

Show comment
Hide comment
@cchristelis

cchristelis Jul 15, 2015

Contributor

Hi @Charlotte-Morgan,

What is happening here is a consequence of using the assign_hazard_values_to_exposure_data. What this method does, is it takes the exposure and adds hazard attributes to the exposure creating an impact layer. The impact layer has the following attribute:

Exposure Attribute 1 Exposure Attribute 2 ... Exposure Attribute N Hazard Attribute 1 Hazard Attribute 2 ... Hazard Attribute M

If any of these are equal the hazard attribute overwrites the exposure attribute. In our case the the TYPE field was overwritten. Since this is the standard building type descriptor name in our OSM building layers, the buildings where grouped by the hazard type they fall into, not the buildings' actual types.

This affects both Volcano Buildings IFs (Point and Polygon) as well as Classified Polygon on Buildings IF.

To avoid this problem we need to rename the conflicting name to something non-conflicting. If you think that the hazard attributes are no longer interesting after the analysis is done, then we can drop them after we have run the analysis.

Contributor

cchristelis commented Jul 15, 2015

Hi @Charlotte-Morgan,

What is happening here is a consequence of using the assign_hazard_values_to_exposure_data. What this method does, is it takes the exposure and adds hazard attributes to the exposure creating an impact layer. The impact layer has the following attribute:

Exposure Attribute 1 Exposure Attribute 2 ... Exposure Attribute N Hazard Attribute 1 Hazard Attribute 2 ... Hazard Attribute M

If any of these are equal the hazard attribute overwrites the exposure attribute. In our case the the TYPE field was overwritten. Since this is the standard building type descriptor name in our OSM building layers, the buildings where grouped by the hazard type they fall into, not the buildings' actual types.

This affects both Volcano Buildings IFs (Point and Polygon) as well as Classified Polygon on Buildings IF.

To avoid this problem we need to rename the conflicting name to something non-conflicting. If you think that the hazard attributes are no longer interesting after the analysis is done, then we can drop them after we have run the analysis.

cchristelis added a commit to cchristelis/inasafe that referenced this issue Jul 16, 2015

@ismailsunni

This comment has been minimized.

Show comment
Hide comment
Member

ismailsunni commented Jul 24, 2015

Can we close this? @cchristelis @Charlotte-Morgan

@cchristelis

This comment has been minimized.

Show comment
Hide comment
@cchristelis

cchristelis Jul 24, 2015

Contributor

yes we can!

Contributor

cchristelis commented Jul 24, 2015

yes we can!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment