GIS, OPTIMIZER: Add biomasscd 4 to psites table

[lbross]

Biomasscd 4 is reserved for 'other merch'. To add this as a valid biomasscd the following issues should be addressed:

1. Need high-level understanding of how biomasscds are currently used in haul times calculations. How should this new code be treated relative to current logic?
2. Currently the xref from biomasscd to description is defined as an array (m_strBioCdDescArray) in the C# code. Consider moving this into a database table so that it's easier to add new codes in the future. However, if new codes will always require changes to the haul times calculations the extra effort to switch this to a database may not be worth the effort
3. Define changes to the Wood Processing sites screen. It would be most efficient to make these changes at the same time we make other requested changes to this screen (issue #333)

This issue originally surfaced when copying an Optimizer scenario, so make sure that still works when changes are complete.

[lbross]

From @jsfried: Our initial BioSum analyses focused on merch wood and dirty chips (suitable for a boiler). As the system has progressed over the years, demands have developed for more particular representations of products. For example, for the biochar study a few years ago, we needed bole wood and NOT branches or bark so Joshua Petitmermet ended up coding his own processor in Python. There is increasing interest in what kinds of products can come put of fuels management systems—having the potential to transport particular kinds of wood (post and pole, Log home materials, etc.) may be important for some kinds of analyses. Moreover, when thinking to add processing capacity, existing facilities of any kind have a compelling advantage for adding the processing of a different kind of wood product. That’s why we don’t want to leave the log home processors out, but we also don’t want to represent them as dimension lumber or plywood plants (i.e. traditional merch wood), hence the need for a code 4. In other regions of the country, if BioSum takes off, they will definitely need to track pulp logs (typically a species group and size class combo). Pulp logs are short and worth less than merch by far but more than dirty chips (dirty, because we are chipping branches and needles and leaves and bark and tops all into the same chip van for delivery to a boiler for bioenergy production, in most of the analyses we’ve done). Someday we’ll want a code 5 for pulpwood logs (which go to different facilities than merch, but as logs, not in a chip van the way the dirty chips travel). But not the immediate priority.

[lbross]

Ultimately we will need to rework the haul cost calculations in Optimizer to support biomasscd 4 and 5. Because the calculations are dependent on the biomasscd, it's not worth the effort to put these values in a database. We will need to change the haul cost calculations for any new biomasscd. As an interim step in v5.11.1, we will add biomasscd 4 to the m_strBioCdDescArray 2D array. We need a description for biomasscd 4. For example, biomasscd 1 is "Merchantable - Logs Only." We also need to update the haul cost calculations in Optimizer to ignore any psites where biomasscd not in (1,2,3). The analyst has the option of updating the project psites table and changing the 4's to 1,2, or 3.

[jsfried]

Description for code 4 could be "Nongeneric Wood Facility with Potential"

This allows the psites db to track wood processing facilities that exist but are NOT currently configured to broadly accept a range of species and size classes for converting into lumber and plywood (e.g., post and pole, cedar mills, log homes). This way, users can add these as potential future mill sites when looking to expand the wood processing network, and avoid the false assumption that (if near to where the wood is coming from) they might currently absorb all the wood generated by fuel treatments, for example-- something that might be possible with a large sawmill but certainly not for a log home log supplier.

[lbross]

In the current master travel times .db @druepdx changed all of the 4's to 1's so that BioSum could load them. These records have a note that they are actually 4’s so it will be easy to locate/update them to a 4 when BioSum can support that.