InaSAFE 4.0 Impact Map and Report naming conventions

[Charlotte-Morgan]

Problem

InaSAFE 4.0 generates a folder for impact analyses (yay) but the files in the outputs folder do not have unique names. These files (map and reports) are the files most likely to be shared but they only have names based on templates

Expected Behaviour

File names for maps and reports should be more explicit in their file naming, preferably unique.

Proposed Solution

1. make the file names something like this for now

   on_map_A4.pdf on_report.pdf

2. In the future - aim to make them more like a realtime event file name

[timlinux]

Hi @Charlotte-Morgan can you clarify the meaning of the 'on' prefix in your examples above?

+1 To have names of datasets with meaningful names.

[Charlotte-Morgan]

Oh - that looks silly. I think it was supposed to say something like:

<hazard>on<exposure>_map_A4.pdf
 <hazard>on<exposure>_report.pdf

Happy for your team to work out what is possible now

[timlinux]

Ah maybe you put angle brackets in the names above. Editing your comment above to put the example in back ticks might fix it.

[Charlotte-Morgan]

:) done

[timlinux]

👍

[timlinux]

I guess one hitch with this while I am thinking about is is we will need to add another layer of logic in the metadata to keep track of what the output layers are and what their significance is. I wonder if it would not be better to give the output folder a meaningful name, the layer titles meaningful names but the actual on-disk file names adhering to a standard naming so that we can point to an analysis directory without knowing anything about it and find e.g. analysis_layer

[lucernae]

I'll put some more thought on this:

• We can put some description for each output/component in the report metadata, so it can be explained to user using help, perhaps.
• We can create another key in report metadata, so we can easily group which component is the final product (like most pdf output) and which is just intermediate product (like infographic donut chart svg). This allows us to fetch all final product without having to know what the names are.
• We can tag each component to a useful tag, perhaps? Like, we can tag all HTML component as html tag or pdf tag for pdf component. Or tag it based on concept, like is it infographic type of report, or map report, or just table. This allows us to again fetch component or product just using the concept without having to know the name of the component.

[timlinux]

Ok that sounds good thanks @lucernae

[samnawi]

on_map_A4.pdf on_report.pdf Happy for your team to work out what is possible now

Hi @Charlotte-Morgan I agree for this. But, to make it unique, I proposed to add date and time as an ID for the result.

<date><time>_<hazard>on<exposure>_map_A4.pdf
 <date><time>_<hazard>on<exposure>_report.pdf

[timlinux]

One confusion that may come from adding date/time to the file name is that we need to make it clear it is not the event time, but the analysis time.

[timlinux]

@lucernae any feedback on this? Maybe we can assign to @myarjunar

[lucernae]

One confusion that may come from adding date/time to the file name is that we need to make it clear it is not the event time, but the analysis time.

What's the feedback on this @samnawi ?

Was and is the layer title respectively?

[timlinux]

@lucernae I think just make a call on this and go with @samnawi 's last suggestion:

<date><time>_<hazard>on<exposure>_report.pdf

[lucernae]

I'm stuck on this. So the problem is, I need the impact function to be serializable so I can get impact_function's provenance and resolve the file name even if the user change layers. Perhaps we can move it to 4.1?

[timlinux]

@lucernae we are going to hand this over to @myarjunar to implement. Just rename the generated reports according to the naming convention above. For now the generated GIS datasets should keep their current names.

[lucernae]

I had some work in progress that I can handover. We need to make impact function serializable, that's the blocker.

[timlinux]

The PDF renaming is going to have a lot of side effects - I am holding this over to 4.3 as we won't be able to resolve it in time for 4.2

[timlinux]

From the desktop side I think this is easier to manage now because the PDF's are generated on the fly at print time. We need to figure out in realtime how to pass back something which says what the name of the generated PDF is so that the web UI can predictably find the output.