Validation Type
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
Fishbone Validations
AP Not Reflected in RCL | AP Maps to Multiple RCL | AP Misordered Along RCL
Caution: Address Points and Road Centerlines with a feature status of Retired or Proposed will not be included in validations or validation results. This can affect Fishbone Validation results if the Address Point and Road Centerline are not both Retired or Proposed.AP Not Reflected in RCL
Address points in this validation have no corresponding road centerline feature based on their street attributes and municipality. Frequently, this is a byproduct of street misspellings, inconsistent street directional values, inconsistent street types, or potentially missing streets. This is not always the case and is imperative to review the GIS data to ensure data completeness. It is important to have consistency between the centerline file and address point file before provisioning the data to an NG9-1-1 system. If the address point isn't reflected in a road centerline within a PSAP before provisioning data into an NG9-1-1 system, a call originating from that address point may not route to the correct PSAP.
Ways to resolve: Compare the Address Point in question to the Road Centerline it should match with and use the table below to review the fields used in the validation. Make sure the Address Point field values are identical matches to the corresponding Road Centerline field(s). Check for spelling or abbreviation differences Verify that for each field populated for the Address Point, the corresponding Road Centerline field(s) is also populated. Watch out for leading or trailing spaces! These can be hard to catch but will prevent fishbones from drawing if they are not in both the Address Point and Road Centerline fields.
AP Maps to Multiple RCL
Each unique address in a jurisdiction must be represented by only one possible location in the GIS data (centerlines and address points). Address Points in this validation geocode to more than one road centerline segment, frequently a byproduct of address range overlap (see Address Range Overlap). In an NG9-1-1 system, address points that map to multiple road centerlines have two potential locations that may or may not be in two separate PSAPs. As a result, this may delay call routing.
Ways to resolve: Check the range values of the corresponding Road Centerlines and make sure they do not overlap. This can cause the Address Point add_num to match both ranges and draw multiple fishbones. Review the matching Road Centerlines for any fields in the table below that could uniquely associate the Address Point to only one Centerline. The more fields that are populated, for both the Road Centerline and Address Point, the less likely an Address will map to multiple Centerlines.
AP Misordered Along RCL
Addresses typically follow a sequential order either moving higher or lower as one traverses a direction along a street. This validation flags address points that do not follow the expected numeric sequential order along the corresponding road centerline (utilizing From-To range values). Often these anomalies result from inconsistent civic address assignment and may require field verification to identify if they are exceptions. In the DATAMARK validations, address points that are out of order are highlighted by the crossing of fishbones. Identifying these anomalies is critical for first responders, particularly along long stretches of road where there could be miles between two addresses. If marked incorrectly, it could delay the timeliness of first responders.
Ways to resolve: Sometimes fishbones cross between Address Points when a Centerline has an extremely broad range. If the Centerline can be broken up in to segments with more narrow ranges, it can reduce this type of anomaly. Additionally, updating the Road Centerline range value to actual ranges instead of theoretical ranges can reduce unnecessary fishbone crossing. If the Address Point add_num is correct but out of order from the neighboring points, this may be an appropriate situation to mark the anomaly as an exception.
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
Address Point Validations
AP Missing Attribution | AP Duplicate Point | AP Not Contained Within Boundary
Address Point [Field] is Blank or NULL
AP Missing Attribution
Address points in this validation are checked for 0 or null values in the Address Number field and null or blank in the Street Name fields. Per NENA's NG9-1-1 GIS Data model, the address number field only includes integers, and the street name requires parsing into their root elements (Street Name Pre-Modifier, Street Name Pre-Directional, Street Name Pre-Type, Street Name Pre-Type Separator, Street Name, etc.). Address points without any house numbers are flagged because they are a major component in locating a unique civic address location. Address points with missing street names require verification to confirm that no street name is assigned to the feature they represent. An incomplete attribution of an address point may hinder the ability of a call to route in an NG9-1-1 system.
Ways to resolve: Check that the Address Point in question has appropriate values in the add_number and st_name fields.
AP Duplicate Point
In an NG9-1-1 system, each address point represents a unique address. In the NENA NG9-1-1 GIS Data Model for address points, there are additional fields that enable a GIS authority to uniquely identify an address point that may share a common primary address. These attributes include building, floor, unit, room, landmark, and additional location information. In an NG9-1-1 system, duplicate address points may hinder correct call routing because duplicate points may fall within two different PSAPs. It is critical to ensure that duplicate primary address points maintain adequate subaddress information and are associated with the correct PSAP to ensure adequate call routing.
Ways to resolve: If two or more Address Points have identical street field attribution, use the sub-address fields (unit, building, floor, room, seat) to differentiate them.
AP Not Contained Within Boundary
This validation check identifies address points that are not contained within various boundaries (PSAP, Provisioning, Law, Fire, EMS, Animal Control, Coast Guard, Forest Service, Poison Control, Emergency Service Boundary, Unincorporated Community Boundary, Incorporated Municipality Boundary, Counties, and State).
Ways to resolve: Make sure that the Address Point is contained within all boundaries in the data. If the Address Point appeared to be within all boundaries prior to uploading, verify that the Address Point and all boundary layers were in the same projection prior to uploading. If there is a difference in projections between layers prior to uploading, there could be a shift in their location after they are re-projected.
Address Point [Field] is Blank or NULL
These validations check for required data fields for civic locations in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Address Points that have no attribution for the listed fields.
Ways to resolve: Populate the corresponding fields with an appropriate value. For VAL80-01, make sure that either the add_number field or the landmkname field has attribution.
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
Road Centerline Validations
RCL Address Range Overlap | RCL Parity Inconsistency | RCL Range Inconsistency | RCL Range Incomplete
RCL Range and Parity Inconsistency | RCL Digitized Direction | RCL is Multipart | RCL is Too Short | RCL Intersecting
RCL Self-Intersecting | RCL Overshoot/Undershoot | RCL Switchback | RCL Too Close
RCL Does Not Break at Boundary, RCL Not Snapped to RCL on Boundary, and RCL Not Snapped to Boundary
RCL Not Contained Within Boundary | RCL [Field] is Blank or NULL
RCL Address Range Overlap
This validation checks for ranges that overlap with another segment sharing the same street attributes in the dataset. These overlaps can occur on the left, right, or both sides of the street segment. If overlap occurs, addresses may geocode to multiple road centerlines thereby impeding the ability of an address to route accurately to the PSAP (see Address Point Maps to Multiple RCL). Address range overlaps require correction so each position along a street centerline is unique.
Ways to resolve: If the Road Centerlines in question are part of continuous road, update the range values so they do not overlap. Start the range of a centerline with the next highest number value from the centerline range before it. If the Road Centerlines being flagged are not part of a continuous road, verify that all other fields used in this validation are filled out correctly. If any of these fields can be used to distinguish one Centerline from the other, it will resolve the anomaly.
RCL Parity Inconsistency
This validation check ensures that the range parity (i.e., is the left/right range even, odd, both, or zero) is a match to the parity attribute (i.e., E, O. B, Z). If there is a mismatch between the range parity and the attribute, this will be flagged as an anomaly. All records will be flagged as an anomaly if parity values are not maintained in the road centerline dataset. Since parity values are required within the NENA NG9-1-1 GIS Data Model, this validation check ensures that left and right parity fields are accurately maintained in the data.
Ways to Resolve: Verify that the Road Centerline in question has appropriate field values for the parity fields.
If the Road Centerline has values in the parity fields, check that the parity values are consistent with the feature's range values. Use the anomaly's validation description for guidance on where to correct the data.RCL Range Inconsistency
Ideally, the numerical range of a street segment has the From address range lower than the To range. This validation check flags street segments where a From range is higher than the To range. While these anomalies are not fatal errors to NG9-1-1 call routing, each record warrants review to ensure that the range reflects reality and then subsequently marked as exceptions.
Ways to Resolve: Ensure that Centerline's fromaddr fields have a lower value than its toaddr fields.
If the Road Centerline has high to low road ranges in the field, this may be an appropriate situation to mark the anomaly as an exception. RCL Range Incomplete
Address ranges are incomplete when not consistently populated with integers in the From/To fields. If one is populated with a positive integer and the other a zero, blank, or null, it will be flagged as an anomaly. It is acceptable to have no address range information (e.g., a From/To value of both zero or null). Incomplete ranges may delay call routing within an NG9-1-1 system.
Ways to resolve: Check the Road Centerline's fromaddr and toaddr range fields for blanks, zeros, or null values alongside a positive integer. Update the fields so they are both positive integers or both zero/null values. RCL Range and Parity Inconsistency
This validation checks for inconsistencies between the Road Centerline parity fields and the corresponding range field values. An anomaly will be flagged when the range values do not reflect the assigned parity value.
Ways to resolve: Review the Road Centerline in question and follow the guidance of the validation description to compare the parity field value to the range values. Update either the parity field or the range field values so that they have consistent attribution.
RCL Digitized Direction
Road centerlines and address points should flow in the same direction. In this validation check, the road directionality is checked to ensure that the flow of address numbers in the address point dataset ascends in the same direction as the road directionality. I.e., the lowest address number should be near the start point of a road centerline and the highest address number should be near the endpoint of a road centerline. If the flow of the two datasets does not match, the road will be flagged as an anomaly. While not critical to NG9-1-1 call routing, it may delay the timely delivery of a call to the PSAP. However, digitized direction and associated topology issues have a greater implication on vehicle routing.
Ways to resolve: Review the directionality of the Road Centerline in question and compare it to the corresponding address points along that road. If the lowest address point is at the end of the road, consider whether the direction of the segment needs to be flipped. Review the Road Centerline in question compared to the sequential Road Centerline segments. If the digitized direction of the consecutive segments does not flow in the same direction, this will flag an anomaly. Ensure all of the sequential segments flow in the same direction to resolve If the Road Centerline accurately reflects the field, this may be an appropriate situation to mark the anomaly as an exception.
RCL is Multipart
Multipart features are those features that are spatially disconnected but are represented by a single record in the attribute table. These features represent discontinuous features that have identical attributes. The presence of multipart features however is not in concordance with recognized addressing data best practices and requires review and splitting into individual, single part features if possible. The anomalies in this check are not fatal to NG9-1-1 call routing, however, it does affect data quality and may impact optimal vehicle routing.
Ways to Resolve: This kind of geometry issue needs to be repaired in the user's local environment. Please reach out to the local environment provider for the solutions offered for this type of geometry error.
RCL is Too Short
This validation check is looking for segments that are too short and may potentially be an anomaly. VEP has a threshold of 10m, if the segment is shorter than that it will be flagged as a potential anomaly. The anomalies in this check are not fatal to NG9-1-1 call routing, however, it does affect data quality and may impact optimal vehicle routing.
Ways to resolve: Road Centerline segments this small may have been created by mistake. If that is the case for the Road Centerline in question, delete it to resolve the anomaly.
If the Road Centerline accurately reflects what's in the field, determine if it makes sense to lengthen or merge the segment. If not, this could be an appropriate situation to mark the anomaly as an exception.RCL Intersecting
This validation check is looking for RCL segments that cross another segment or touch another RCL mid-segment. The anomalies in this check are not fatal to NG9-1-1 call routing, however, it does affect data quality and may impact optimal vehicle routing.
Ways to resolve: If the Road Centerline crosses another Road Centerline without breaking, break both Road Centerlines at the place of intersection and snap the segments together. If the Road Centerline overlaps another Road Centerline, edit the segments so that the end points are snapped together and no longer overlapping. If it is difficult to see where the Road Centerline crosses or overlaps another Road Centerline, try zooming in to a 1:1 ratio. If this anomaly flags but the Road Centerlines in question appear to be snapped together, it may help to pull the features apart, increase the snapping tolerance, then re-snap them together.
RCL Self-Intersecting
The anomalies in this check are not fatal to NG9-1-1 call routing, however, it does affect data quality and may impact optimal vehicle routing.
Ways to resolve: Verify that the Road Centerline in question is not intersecting itself. If there isn't an obvious self-intersection, try checking all of the vertices and make sure the segment isn't 'doubling back' on itself. Delete any unnecessary vertices.RCL Overshoot/Undershoot
RCL segment disjointed is looking for places where the RCL is not snapped to a vertex and either under or overshoots another RCL segment. This creates either a topological gap or an overlap. This validation check specifically looks for an RCL endpoint that does not intersect another RCL. This endpoint then cannot have any other RCL endpoint within 5m of it. If there is one within 5m, it is flagged as an anomaly. The anomalies in this check are not fatal to NG9-1-1 call routing, however, it does affect data quality and may impact optimal vehicle routing.
Ways to resolve: Snap the Road Centerline in question to the corresponding Road Centerline. If one Road Centerline is intersecting the other, make sure the intersected segment is broken at the snap point. If it is difficult to see the gap or overlap, try zooming into a 1:1 ratio. If this anomaly flags but the Road Centerlines in question appear to be snapped together, it may help to pull the features apart, increase the snapping tolerance, then re-snap them together.
RCL Switchback
Sometimes RCL segments may have switchbacks where vertices have a 180-degree turn and a segment folds back on itself. This can also happen when segments have sharp turns of less than 10 degrees. These switchbacks can be hard to detect but may cause digitization issues in the data. It's best practice to remove all instances of switchback to preserve data integrity.
Ways to Resolve: Delete any vertices that have double-backed on the Centerline segment being flagged so that there are no 180-degree, or less than 10-dgree angles between vertices.
RCL Too Close
Besides where RCLs intersect at start and endpoints, there is rarely a time when another RCL should be within 2m of another RCL. Frequently there's a city block that buffers these RCLs. In this validation check, if an RCL is greater than 50% contained within a 2m buffer of another RCL, it is flagged as an anomaly. These anomalies may not be an error but warrant validation to ensure sound data maintenance practices. The anomalies in this check are not fatal to NG9-1-1 call routing, however, it does affect data quality and may impact optimal vehicle routing.
Ways to resolve: Review the Road Centerlines in question and verify that they do not need to be snapped together. If the data is accurately reflecting what is in the field, this may be an appropriate situation to mark the anomaly as an exception.RCL Does Not Break at Boundary, RCL Not Snapped to RCL on Boundary, and RCL Not Snapped to Boundary
This series of validation checks identify road centerlines that do not break or snap to various boundaries (PSAP, Provisioning, Law, Fire, EMS, Animal Control, Coast Guard, Forest Service, Poison Control, Emergency Service Boundary, Unincorporated Community Boundary, Incorporated Municipality Boundary, Counties, and State). Additionally, corresponding "Snap Points" are produced in the MARKUP_POINT feature class to allow users to have a spatial point of reference to snap road centerlines when splitting centerlines along the boundaries.
Ways to resolve: If the Road Centerline crosses a Boundary without breaking, break the Road Centerline at the place of intersection and snap the segments together and to the boundary layer. Verify that the Road Centerline layer and the Boundary layers are in the same projection prior to uploading into VEP. Inconsistent projections can lead to data shifts after re-projection and will disconnect snapped features between layers. If it is difficult to see where there is a gap or overlap between the Road Centerline and the boundary, try zooming in to a 1:1 ratio. If this anomaly flags but the Road Centerline in question appears to be snapped to the boundary or other Road Centerline segment, it may help to pull the features apart, increase the snapping tolerance, then re-snap them together. The Proposed Snap Points in the Markup Points layer may be used as a guide to snap the Road Centerline to the Boundary layer. This validation may flag an anomaly for a Road Centerline that is near, but does not cross, a boundary. If the data accurately reflects what is in the field, this may be an appropriate situation to mark the anomaly as an exception.
RCL Not Contained Within Boundary
This validation check identifies road centerlines that are not contained within various boundaries (PSAP, Provisioning, Law, Fire, EMS, Animal Control, Coast Guard, Forest Service, Poison Control, Emergency Service Boundary, Unincorporated Community Boundary, Incorporated Municipality Boundary, Counties, and State).
Ways to resolve: Verify that the Road Centerline in question is within the boundary referenced in the validation description. If it is difficult to see where the Road Centerline crosses the boundary, try zooming in to a 1:1 ratio. If this anomaly flags but the Road Centerline in question appears to be snapped to the boundary, it may help to pull the features apart, increase the snapping tolerance, then re-snap them together.
RCL [Field] is Blank or NULL
These validations check for required data fields for Road Centerlines in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Road Centerlines that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
Boundary Validations
Boundary is Multipart | Boundary is Multipart and an Island | Gaps and Overlaps in PSAP Boundary
Gaps and Overlaps in Emergency Service Boundaries | Boundary is an Island
PSAP [Field] is Missing Attribution | Animal Control Boundary [Field] is Missing Attribution
Coast Guard [Field] is Missing Attribution | EMS Boundary [Field] is Missing Attribution
Fire Boundary [Field] is Missing Attribution | Forest Service Boundary [Field] is Missing Attribution
Law Boundary [Field] is Missing Attribution | Poison Control Boundary [Field] is Blank or NULL
Boundary is Multipart
This validation check flags any boundary (Law, Fire, EMS, PSAP, and Provisioning boundary) where there are multiple polygons for a single record within the attribute table. Multipart features may hinder NG9-1-1 call routing if not reviewed carefully and rectified to a single-part feature.
Ways to Resolve: This kind of geometry issue needs to be repaired in the user's local environment. Please reach out to the local environment provider for the solutions offered for this type of geometry error.
Boundary is Multipart and an Island
This validation check flags any boundary (Law, Fire, EMS, PSAP, and Provisioning boundary) where there are multiple polygons for a single record within the attribute table AND boundaries that are surrounded by a greater space. The records flagged here are not flagged individually between the island topology errors and the boundary is multipart validation checks.
Ways to Resolve: This kind of geometry issue needs to be repaired in the user's local environment. Please reach out to the local environment provider for the solutions offered for this type of geometry error.
Gaps and Overlaps in PSAP Boundary
These validations report gaps and overlaps between PSAP Boundaries. NG9-1-1 requires that PSAP Boundaries are regionally validated to ensure the proper routing of a 9-1-1 call. For example, an overlap in the PSAP boundary would return more than one PSAP location during call handling. It is critical that topology is reviewed and PSAP boundaries are free from gaps and overlaps.
Ways to resolve: Snap the PSAP boundary in question to the neighboring PSAP boundary to remove any gaps or overlaps. If it is difficult to gap or overlap, try zooming in to a 1:1 ratio. If this anomaly flags but the PSAP in question appears to be snapped to the neighboring PSAP Boundary, it may help to pull the features apart, increase the snapping tolerance, then re-snap them together.
Gaps and Overlaps in Emergency Service Boundaries
To ensure that Emergency Service Boundaries, including Law, Fire, and EMS, are usable for NG9-1-1, the topological relationship between features must be free of gaps and overlaps. Law, Fire, and EMS boundaries will be stored in separate layers in an NG9-1-1 system and features within each layer must not have gaps or overlaps with features coexisting in the same layer. This validation identifies gaps and overlaps in the Law, Fire, and EMS feature classes.
Ways to resolve: Snap the referenced Emergency Service Boundary in question to the neigboring Emergency Service Boundary to remove any gaps or overlaps. If it is difficult to gap or overlap, try zooming in to a 1:1 ratio. If this anomaly flags but the Emergency Service Boundary in question appears to be snapped to the neighboring Emergency Service Boundary, it may help to pull the features apart, increase the snapping tolerance, then re-snap them together.
Boundary is an Island
This validation check flags any boundary that is surrounded by greater space. This anomaly does not necessarily mean that it is an error. The results here may hinder call routing in an NG9-1-1 environment.
Ways to Resolve: This kind of geometry issue needs to be repaired in the user's local environment. Please reach out to the local environment provider for the solutions offered for this type of geometry error.
PSAP [Field] is Missing Attribution
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags PSAP Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Animal Control Boundary [Field] is Missing Attribution
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Animal Control Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Coast Guard [Field] is Missing Attribution
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Coast Guard Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
EMS Boundary [Field] is Missing Attribution
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags EMS Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Fire Boundary [Field] is Missing Attribution
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Fire Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Forest Service Boundary [Field] is Missing Attribution
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Forest Service Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Law Boundary [Field] is Missing Attribution
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Law Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Poison Control Boundary [Field] is Blank or NULL
These validations check for required data fields for Boundary data in the NG9-1-1 GIS Data Model and therefore require population. This validation flags Poison Control Boundaries that have no attribution for the listed fields.
Ways to resolve: Populate the referenced fields with an appropriate value.
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
MSAG Validations
MSAG Invalid Address | RCL Not Reflected in MSAG | MSAG Not Reflected in RCL
RCL Not Reflected in MSAG Range | MSAG Range Incomplete
MSAG Invalid Address
This validation check flags MSAG records with an alphanumeric address range. There is no reason for MSAG records to contain alphanumeric characters in these fields. These anomalies will require follow-up with the MSAG coordinator.
Ways to resolve: Remove alphanumeric values or special characters from the field(s) referenced in the validation description.
RCL Not Reflected in MSAG
It's imperative to ensure that the RCL answers all the same questions as the MSAG. This validation identifies unique street names that appear in the RCL that are not matched in the MSAG. Often, there is a mismatch or missing ESN, a spelling issue, or a street-type domain discrepancy in the centerline versus what is maintained in an MSAG. Further, a centerline file may contain alleys, trails, or other non-addressed or navigable roads that would not appear in an MSAG. Validating the anomalies will ensure that all currently routable calls in an E9-1-1 environment will also route in the NG9-1-1 system that relies on GIS Data. For GIS to MSAG data comparisons, the validations will compare the MSAG data to the Legacy street attributes fields in the GIS data. If the Legacy street attributes are not populated with data, the validations will compare the MSAG data to the NG9-1-1 street attribute fields in the GIS data.
Ways to resolve: Verify that the Road Centerline feature in question has a match to an MSAG record. Use the table below to compare the appropriate fields. If there is a field that is populated for the Road Centerline, but not the MSAG (or vice versa), this will cause a mismatch. Populate all fields in the Road Centerline feature that are also populated in the MSAG table. Verify that there are not differences in spelling or abbreviations between the Road Centerline field values and the corresponding MSAG fields. Watch out for leading or trailing spaces! These can be hard to catch but will result in a Not Reflected anomaly if they are not in both the Road Centerline and MSAG fields.
MSAG Not Reflected in RCL
It's imperative to ensure that all MSAG records are contained within the RCL to ensure proper call routing in an NG9-1-1 system. This is a critical check because the MSAG is currently routing calls in an E9-1-1 system and if the RCL cannot answer all the same questions as the MSAG, a call may improperly route when transitioning to NG9-1-1. Often, there is a mismatch in ESN, a spelling issue, or a street type domain discrepancy in the MSAG versus what is maintained in a centerline. This validation identifies unique street names that appear in the MSAG but are not in the road centerline table.
Ways to resolve: Verify that the MSAG record in question has a match to a Road Centerline feature. Use the table below to compare the appropriate fields. If there is a field that is populated for the MSAG, but not the Road Centerline (or vice versa), this will cause a mismatch. Populate all fields in the MSAG table that are also populated in the Road Centerline feature. Verify that there are not differences in spelling or abbreviations between the MSAG field values and the corresponding Road Centerline fields. Watch out for leading or trailing spaces! These can be hard to catch but will result in a Not Reflected anomaly if they are not in both the MSAG and Road Centerline fields.
RCL Not Reflected in MSAG Range
It's imperative to ensure that the RCL answers all the same questions as the MSAG. This validation identifies RCLs that have matching street attributes, except that the address range of those attributes is not contained within the MSAG. Similar to RCL has no matching MSAG record, a centerline file may contain alleys, trails, or other non-addressed or navigable roads that would not appear in an MSAG. However, this may indicate new development where the MSAG is not updated and may not route calls effectively in an E9-1-1 system. For GIS to MSAG data comparisons, the validations will compare the MSAG data to the Legacy street attributes fields in the GIS data. If the Legacy street attributes are not populated with data, the validations will compare the MSAG data to the NG9-1-1 street attribute fields in the GIS data.
Ways to resolve: Compare the Road Centerline range fields to the MSAG high and low field values. Update the range values or the high and low field values so that that have matching ranges.
MSAG Range Incomplete
MSAG records should always have a range (values in the Low and High fields) to identify addresses along a stretch of street. There is no reason to have null, blank, or "0" ranges in an MSAG. These anomalies will require follow-up with the MSAG coordinator.
Ways to resolve: Populate the field(s) referenced in the validation description with valid attribution.
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
ALI Validations
ALI Address Number Invalid | ALI Not Reflected in AP | ALI Not Reflected in RCL | ALI Address Incomplete
ALI Not Reflected in AP and RCL
ALI Address Number Invalid
The house number field contains only integers and no alpha characters. This is because, in an NG9-1-1 system, each address point represents a unique address. In the NENA NG9-1-1 GIS Data Model for address points, sub-address information is stored in other appropriate attributes such as building, floor, unit, room, landmark, and additional location information.
Ways to resolve: Verify that the ALI record in question has a valid house_number field value. Remove any alphanumerics or special characters.
ALI Not Reflected in AP
The synchronization of the ALI and Address Point data requires a 1:1 match. Some examples of why an ALI record can't be matched to an address point are missing address points, a street naming conflict, a disconnected phone line (orphaned ALI record), or an ALI TN assigned to a non-situs address (ATM, etc.). Verification of an ALI address must occur before adding to the GIS data since ALI records are not always 100% reliable. Any anomalies within the ALI data need to be reported to the telephone companies.
Ways to resolve: Verify that the ALI record in question has a match to an Address Point. Use the table below to compare the appropriate fields.
If there is a field that is populated for the ALI, but not the Address Point (or vice versa), this will cause a mismatch. Populate all fields in the ALI table that are also populated in the Address Point feature.
Verify that there are not differences in spelling or abbreviations between the ALI field values and the corresponding Address Point fields.
ALI Not Reflected in RCL
This validation check highlights discrepancies between the ALI and the road centerlines. It ensures that every ALI record has a coordinating centerline where the ALI house number falls within that road centerline range. If a civic location in the current ALI cannot geocode along a road centerline, then a 9-1-1 call may improperly route in an NG9-1-1 environment.
Ways to resolve: Verify that the ALI record in question has a match to a Road Centerline feature. Use the table below to compare the appropriate fields.
If there is a field that is populated for the ALI, but not the Road Centerline (or vice versa), this will cause a mismatch. Populate all fields in the ALI table that are also populated in the Road Centerline feature.
Verify that there are not differences in spelling or abbreviations between the ALI field values and the corresponding Road Centerline fields.
ALI Address Incomplete
House number is a required data field for civic locations in the NG9-1-1 GIS Data Model and therefore requires population. This validation flags ALI records that have no address number.
Ways to resolve: Populate the ALI record in question with a valid house_number field value.
ALI Not Reflected in AP and RCL
This validation flags an anomaly if the record flags in both ALI has no matching AP and ALI has no matching RCL range. Reviewing these validation results will identify gaps in the current address point and road centerline GIS data and make sure that all valid civic locations from the ALI are contained appropriately within the GIS data so that the GIS data will "answer" the same questions as the ALI in an NG9-1-1 system.
Ways to resolve: Verify that the ALI record in question has a match to both an Address Point and a Road Centerline. Use the table below to compare the appropriate fields.
If there is a field that is populated for the ALI, but not the Address Point and Road Centerline (or vice versa), this will cause a mismatch. Populate all fields in the ALI table that are also populated in the Address Point and Road Centerline features.
Verify that there are not differences in spelling or abbreviations between the ALI field values and the corresponding Address Point and Road Centerline fields.
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
Parcel Validations
Parcel ID and CAMA Mismatch | AP Not Contained Within Parcel | Parcel Overlaps, Gaps, Multipart, and Island
Note: Parcel Validations are a premium feature. Contact your Client Success Manager for more information.Parcel ID and CAMA Mismatch
This validation compares the CAMA table to the Parcel boundary layer. It searches for a matching ID between both sets of data. If there is no match, the feature will be flagged as an anomaly. Having matching Parcel boundary features and CAMA table records are requirements in some jurisdictions, but in all cases, it is important to maintain this information for accurate record keeping.
Ways to Resolve: Compare the Parcel feature in question to the CAMA table record it should match with and use the table below to review the fields used in the validation.
Make sure the Parcel feature field values are identical matches to the corresponding CAMA record.
Verify that for each field populated for the Parcel feature, the corresponding CAMA record is also populated.
Watch out for leading or trailing spaces! These can be hard to catch but will cause an anomaly to flag if they are present in either the Parcel feature or CAMA TableDescription
Fields Used in Validation Logic
| Parcel Fields | CAMA Fields |
|---|---|
| APN | PARCEL_NUMBER |
AP Not Contained Within Parcel
This validation check identifies address points that are not contained within a Parcel boundary. If an address point exists outside of the Parcel boundaries, it will be flagged as an anomaly. This validation helps the user identify misplaced Address Points that may be located outside of the County or within the road right of way. Poor Address Point placement may hinder call routing in an NG9-1-1 environment.
Ways to resolve: Make sure that the Address Point is contained within the Parcel boundary in the data. If the Address Point appeared to be within all Parcel features prior to uploading, verify that the Address Point and Parcel layers are in the same projection prior to uploading. If there is a difference in projections between layers prior to uploading, there could be a shift in their location after they are re-projected.
Description
Topology Check - No Fields Used
Parcel Overlaps, Gaps, Multipart, and Island
This validation checks for Parcel boundary overlaps, unexpected gaps, multipart features, and islands. To ensure that the Parcel boundary is a usable data source, the topological relationship between features must be free from all overlaps. It should also be free from any unexpected gaps. Road Right-Of-Ways (ROW) is an example of an expected gap in the Parcel layer. This validation will also flag any parcel that is surrounded by greater space and any parcels that contain multiple polygons for a single record. Some examples of these may not be an error, as a parcel may be surrounded or split by a road ROW. These would be examples of an exception. Maintaining an error-free parcel fabric will help ensure accurate address management.
Ways to resolve: Snap the Parcel boundary in question to the neighboring Parcel boundary to remove any gaps or overlaps.
If it is difficult to gap or overlap, try zooming in to a 1:1 ratio.
If this anomaly flags but the Parcel in question appears to be snapped to the neighboring Parcel Boundary, it may help to pull the features apart, increase the snapping tolerance, then re-snap them together. For multipart and island features, this kind of geometry issue needs to be repaired in the user's local environment. Please reach out to the local environment provider for the solutions offered for this type of geometry error.
Fishbone Validations | Address Point Validations | Road Centerline Validations | Boundary Validations
MSAG Validations | ALI Validations | Parcel Validations | Routing Validations
Routing Validations
RCL Wrong Way Inconsistency | RCL Speed Limit Inconsistency | RCL Road Class Inconsistency
Note: Routing Validations are a premium feature. Contact your Client Success Manager for more information.
RCL Wrong Way Inconsistency
This validation checks for one-way attribution that does not match any other Road Centerline segment that shares street field attribution and touches the segment in question. If the source Road Centerline Segment has a different one-way value than the next (or target) Road Centerline segment, than this anomaly will be raised. If one-way attribution is incorrect, it could cause the routing software to route incorrectly.
Ways to Resolve: Check that the Centerline in question has the same attribution for the one-way field as the next successive Centerline segment. If the fields do no match and that's not accurate with what's in the field, update the one-way field to the appropriate value to resolve. If the Centerline segment in question has matching attribution to the next successive segment, but the digitized direction is not flowing in the same way, an anomaly will flag. If that is the case, changing the digitized direction of the Centerline going the wrong way will resolve this. If the Centerline in question truly has a change in the field from one-way to both directions, and the data is accurate, this may be an appropriate situation to mark the anomaly as an exception.
Description
Fields Used in Validation Logic
| Road Centerline Fields |
|---|
| st_premod |
| st_predir |
| st_pretyp |
| st_presep |
| st_name |
| st_postyp |
| st_posdir |
| st_posmod |
| oneway |
| incmuni_l |
| incmuni_r |
RCL Speed Limit Inconsistency
This validation checks for speed limit attribution that does not match any other Road Centerline segment that shares street field attribution and touches the segment in question. If the source Road Centerline Segment has a different speed limit value than the next (or target) Road Centerline segment, than this anomaly will be raised. If speed limit attribution is incorrect, it could cause the routing software to route incorrectly.
Ways to Resolve: Check that the Road Centerline in question has the same attribution for the speed limit field as the next successive Road Centerline segment. If the fields do not match, update the speedlimit field to the appropriate value to resolve. If the Centerline in question truly has a speed limit change, and the data is accurate, this may be an appropriate situation to mark the anomaly as an exception.
Description
Fields Used in Validation Logic
| Road Centerline Fields |
|---|
| st_premod |
| st_predir |
| st_pretyp |
| st_presep |
| st_name |
| st_postyp |
| st_posdir |
| st_posmod |
| speedlimit |
| incmuni_l |
| incmuni_r |
RCL Road Class Inconsistency
This validation checks for road class attribution that does not match any other Road Centerline segment that shares street field attribution and touches the segment in question. If the source Road Centerline Segment has a different road class value than the next (or target) Road Centerline segment, than this anomaly will be raised. If road class attribution is incorrect, it could cause the routing software to route incorrectly.
Ways to Resolve: Check that the Centerline in question has the same attribution for the road class field as the next successive Centerline segment. If the fields do no match and that's not accurate with what's in the field, update the roadclass field to the appropriate value to resolve.
If the Centerline in question truly has a road class change in the field, and the data is accurate, this may be an appropriate situation to mark the anomaly as an exceptionDescription
Fields Used in Validation Logic
| Road Centerline Fields |
|---|
| st_premod |
| st_predir |
| st_pretyp |
| st_presep |
| st_name |
| st_postyp |
| st_posdir |
| st_posmod |
| roadclass |
| incmuni_l |
| incmuni_r |