Home

The go-consequences repository is intended to provide computational solutions for consequences calculations used to support natural resources analysis. The project is intended to be scalable to a national scale leveraging cloud computing.

There are three main components to the library:

• consequences.Receptor
• hazards.Hazard
• consequences.Result

This library allows a flexible combination of consequence receptors with hazards to create a result.

consequences.Receptor

A consequences receptor is an interface that fulfills the method Compute with an injected hazard and produces a consequences result. There are currently three implementations of consequences receptors, StructureDeterministic, StructureStochastic, and Crop. Any object that implements the Receptor interface can be used with the other interfaces in the library. Each consequences receptor also implements the locatable interface to be able to retrieve the geography.location for the receptor. This facilitates retrieving hazards from a HazardProvider during the compute workflow.

hazards.Hazard

A hazard is an interface that describes damage driving parameters of a hazard. For instance, in flooding at structures the damage driving parameter is typically depth. A DepthHazard has been implemented to describe that specific hazard. Hazards must implement a method called Parameter which produces a HazardType. A HazardType is a byte flag describing all of the parameters that the hazard implements. This allows an easy set of queiries on the hazard to determine if it is capable of creating a consequence result at a consequence receptor.

consequences.Result

A consequence result is a struct that has a list of string that represent the names of the outputs provided by a compute on a consequences receptor for a given event. The struct also contains the results as a list of empty interface. This allows for a data table like structure that provides a fairly flexible implementation of outputs for a consequences receptor compute.

There are three other important elements in the library that facilitate the interaction of the above components.

• consequences.StreamProvider
• consequences.ResultsWriter
• hazards.HazardProvider

consequences.StreamProvider

A stream provider is an interface that provides a way to iterate over a consequences.StreamProcessor func by consequence.Receptor. The StreamProvider provides a way to iterate over consequence.Receptors ByFips code or ByBBox. This allows for a query by standard FIPS code (state, county, census tract, census block, etc.) or by a rectangular query. For each receptor provided by the StreamProvider, the StreamProcessor func is called to execute. This allows the injection of the computational process on the atomic element of a consequences.Receptor.

consequences.ResultsWriter

A consequences.ResultsWriter is an interface that implements the basic interface similar to IO.WriteCloser. The difference is that instead of a byte array, the write method accepts a consequences.Result. This allows for fairly high flexibility in how the results are written.

hazards.HazardProvider

A HazardProvier provides a hazard for a geographic location (x,y) and produces a hazards.Hazard or an error. The HazardProvider allows for flexibility in the type of hazard produced at a location. A single HazardProvider could provide hazards of varying type (fluvial and pluvial or riverine and coastal) or it can produce a constant type e.g. DepthEvent only.

consequences.Compute

The consequences compute brings the StreamProvider, ResultsWriter, and HazardProvider together to create a simulation. The stream provider iterates over the inventory and provides the location for each receptor to the hazard provider to retrieve a hazard. The receptor and the hazard are combined with the receptor's compute method to create a consequences.Result that is then written with the Results writer. These elements can be combined independent of the consequences.Compute methods like StreamAbstract, if the use case requires more customization.

Example Code

Thanks to Patrick Kane for bringing this pseudo code example together:

//define hazard
myEventHazard, _ := hazardprovider.Init(“GeoTiff filepath”)
//define structure inventory
shpStuctureProvider, _ := structureprovider.InitSHP("Path to point shapefile that meets schema specifications")
//define result writer
myEventResults, _ := resultswriters.InitGpkResultsWriter("output file path", "event_results")
//run the compute
compute.StreamAbstract(myEventHazard, shpStructureProvider, myEventResults)

Obviously, ignoring the errors is bad form, but it simplifies the example to illustrate the structure of a valid event based compute.