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.

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.

Note: the TOD field is so chaotic that I don't even know how to check it. 😭

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.

• Certain fields should only have integer values: due to ACTION_CODE, NEW_DIRECTIONS, NEW_TYPE1&2, NEW_AMPM1&2, and MODES being stored as TEXT fields in the table, there aren't technical restrictions on what can be written. However, logically, they must be able to be converted to a integer.
• 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 have values within a certain range: see table at the end of the section.
• Skeleton links must have either action 2 or 4 applied to them: conversely, regular links must have either action 1 or 3 applied to them.
• REP_ANODE + REP_BNODE should only be filled in for ACTION_CODE = 2.
• Links with ACTION_CODE = 2 and 3 must have all 0s: there cannot be unusable attribute values on replace links (ACTION_CODE = 2) or delete links (ACTION_CODE = 3).
• Links with ACTION_CODE = 2 must have valid replace node values: otherwise there is nothing to replace.
• Links with ACTION_CODE = 4 must have required attributes filled in: NEW_DIRECTIONS, NEW_TYPE1, NEW_AMPM1, NEW_THRULANES1, NEW_THRULANEWIDTH1, and NEW_MODES should always be filled in. NEW_TYPE1 will determine if NEW_POSTEDSPEED1 is needed.
• Links with NEW_DIRECTIONS = 1 or 2 should not have unusable '2' attributes: This is true no matter if the action is 1 or 4.
• Links with NEW_DIRECTIONS = 3 should have all required '2' attributes filled in: This is true no matter if the action is 1 or 4. NEW_TYPE2 will determine if NEW_POSTEDSPEED2 is needed.
• Links with potential to become duplicates cannot have ACTION_CODE == 2 applied to them: if a skeleton link is becoming a regular link, and it has a potential to become a duplicate, then ACTION_CODE == 4 must be used instead (so that NEW_DIRECTIONS can be checked.)
• Links with potential to become duplicates cannot have NEW_DIRECTIONS > 1: if both ANODE-BNODE and BNODE-ANODE exist in the base links, then they are not allowed to become bidirectional.
• Links with ACTION_CODE = 1 must deal with this very specific situation: if TYPE1 USED to be 7 and didn't have a POSTEDSPEED1, and there is a NEW_TYPE1, then there MUST be a NEW_POSTEDSPEED1. (this is also true of the '2' version).

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.
• Links with potential duplication issues should be reviewed by hand: While I have error checking in place, it might be best to review this by hand too.

Valid Attribute Table

Field	Range
ACTION_CODE	1, 2, 3, 4
NEW_DIRECTIONS	0, 1, 2, 3
NEW_TYPE1&2	0, 1, 2, 3, 4, 5, 6, 7, 8
NEW_AMPM1&2	0, 1, 2, 3, 4
NEW_POSTEDSPEED1&2	geq 0
NEW_THRULANES1&2	geq 0
NEW_THRULANESWIDTH1&2	geq 0
ADD_SIGIC	0, 1
ADD_CLTL	-1, 0, 1
ADD_RRGRADECROSS	-1, 0, 1
NEW_TOLLDOLLARS	geq 0
NEW_MODES	0, 1, 2, 3, 4, 5

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.