Serialize Loss Curves to the OQ DB

[Lars Butler]

Currently, loss curves are only serialized to to XML (and SVG too, I think). We should be able to support a user option for serializing to the DB or to XML.

[Gabriele Favalessa (favalex)]

After a loss curve calculation we need to store, for each asset, the following
information:

  1) an asset identifier (string)
  2) the asset site (point)
  3) the loss (array of floats)
  4) the PoE (array of floats)
  5) some information on the parameters openquake used to compute this curve
     One such parameter is the vulnerabitily function. Another one, not
     implemented yet but possible, is the end branch label of the logic tree.

Point 5 raises some questions:

  - is it really used? Some of our sample xml do indeed contain multiple
    curves for the same asset, distinguished by a different endBranchLabel
    attribute.

  - in the case it is used by the current risk engine, is endBranchLabel an
    appropriate name for it?

  - after a calculation how many distinct endBranchLabels (I keep using the
    existing name for convenience) are we expected to see? Just the order of
    magnitude.

  - after a calculation will all the asset have the same number of curves
    associated with them, with the same endBranchLabels (the curves themselves
    will need not to be the same, of course).

[Vitor Silva (vitor-silva)]

Hi Grabriele,

I also just checked the current schema for the loss/loss ratio curves and I agree with point 1 to 4, but I think we should store these results in the same way we stored the results of a loss map from a probabilistic event-based analysis. This is mainly due to the fact that again, we might have multiple results for the same location and therefore, the usage of a LCNode (loss curve node or whatever you want to call it) would be recommended. Moreover, it would show consistency between the different data models.
Just to clarify things, here's what I propose:

Common to the loss curve map:
  * Loss curve map ID : a simple identifier (short string).
  * Endbranchlabel : so once the logic tree is extended to the risk side, one can also track down the configuration that was used in the calculations (e.g: Vulnerability model, consideration of uncertainty, building inventory, spatial resolution, amongst others) (short string)
  * Loss category: to specify what are the losses that are being shown (short string)
  * Unit: to give further information about the losses (e.g: currency, population count) (short string)
  * Time span: Interval of time considered in the calculations (e.g: 1, 30, 50 years) (float)

Since many assets might exist at the same location, it is necessary to allow the capability of storing many curves per site. Which means, a loss curve map can have many sites (nodes), and each site can have many assets. For each asset, ID reference is stored (from the exposure model file) and two lists: one with the losses/loss ratios (floats and in the case of the loss ratios, it varies from 0 to 1) and another one with the respective probability of exceedances (floats).

This is pretty much the same data model of the loss map with the exception that we do not store a probability of exceedance common to all the values of the map and instead of a loss value per asset, we have two lists now. This data model is consistency with other hazard/risk models and the UHS will probably have a similar schema (many sets of lists per site).

Please also check the example file I sent.
Cheers
Vitor