check_hwyproj_coding_table()

With this method, the integrity of the project table will be checked.

In the base project table, a field called "USE" was created by generate_base_hwy(). A "USE" value of 1 is the default and means that the row is valid. A "USE" value of 0 means that the row is invalid and the project row will not be applied.

If a row is determined to be invalid, it will be considered an error and its "USE" field will be set to 0. The "PROCESS_NOTES" field will also be populated with a small description of the error. Otherwise, if a row is determined to be valid but strange, it will be considered a warning. Its "USE" field will stay as 1, but the "PROCESS_NOTES" field will be populated with a small description of the warning.

In the output folder, a text file called "base_project_table_errors.txt" will be created that summarizes all the errors and warnings. Additionally, an excel file called "base_project_table_errors.xlsx" will be created of all the rows with errors or warnings.

The method checks the table in 3 stages. The first is the Primary Key check, which determines that each row in the table can be uniquely identified by its TIPID-ABB combination. The second is the Individual Row check, which determines that each row does not contain invalid values. The third is the Row Combination check, which checks for combinations of rows which are not allowed.

Special care is given to links with potential for duplication. If both ANODE-BNODE and BNODE-ANODE are present in the base link set, then neither of their direction flags should ever be set to 2 or 3.

Primary Key Check

• Duplicate TIPID + ABB combinations are not allowed: Each combination of TIPID + ABB must be unique, as a link is only allowed to be in single state after a project is applied. If there are duplicates, the USE field is set to 0 until the table is changed for it to be unique.

Individual Row Check

Any violation of these will result in the USE field being set to 0.

• Each TIPID must reference a project in the hwyproj table.
• Each ABB must reference an ABB in the hwynet/hwynet_arcs feature class.
• Rows must not violate domains: all attributes must conform to the domains described in Highway Data.
• Skeleton links must have ACTION_CODE = 4 applied to them: conversely, regular links must have either action 1 or 3 applied to them.
• Links with ACTION_CODE = 3 must have all 0s: there cannot be unusable attribute values on delete links (ACTION_CODE = 3).

Finally, a violation of these will result in warnings:

• Links with ACTION_CODE = 1 should not have all 0s: If all the attributes are 0, then it isn't doing anything. This is let off with a warning because it's harmless, but it should be reviewed at some point.

Row Combination Check

A violation of these will result in warnings:

• For any 1 skeleton link, if it's being both added and replaced it should be done carefully: If, say, a link has both ACTION_CODE = 2 and ACTION_CODE = 4 being applied to it, please make sure you're comfortable with the interpretation of this behavior described in hwy_forward_one_year().
• If a skeleton link is replacing a regular link, usually the regular link is deleted with it: In the vast majority of cases, if link A is replacing link B, then link A has 2 applied to it and link B has 3 applied to it. However, in some cases, link B does not have 3 applied to it. These cases are flagged in case you did, in fact, want to delete B.

Note: it is possible for a row to have both of these warnings. Unfortunately, there is only room for 1 warning in the "PROCESS_NOTES" field.

TODO: add a warning if there are multiple actions on 1 link in the same year.