HomeMy WebLinkAboutItem 14 - GIS Data DevelopmentMEMOTO: HONORABLE MAYOR AND MEMBERS OF THE CITY COUNCIL
FROM: BRUNO RUMBELOW, CITY MANAGER
MEETING DATE: MARCH 17, 2020
SUBJECT: PROFESSIONAL SERVICES FOR GIS DATA DEVELOPMENT AND
ADDRESS FIELD VERIFICATION
RECOMMENDATION: Consider approval of the purchase of professional services for GIS data
development and address field verification for new computer aided
dispatch (CAD/RMS) software system replacement.
FUNDING SOURCE: Funds are available in 117-44540-209-004 (Professional Services) &200-
44540-533-001 (Professional Services) for an amount not to exceed
$20,400.
BACKGROUND: The Police and IT Departments will be replacing the Computer Aided
Dispatch (CAD/RMS) system which is required to fully integrate with the
City's Geographic Information System (GIS).Once selected, the
CAD/RMS must utilize Next Generation 9-1-1 (NG911) addressing data.
Currently, the City's GIS addressing data does not meet the requirements
of NG911. This request is to seek professional services to develop the
required GIS data and field verify road enterlines and Site/Structure
Address Points (SSAP) datasets.
Road centerlines represent the estimated centerline of a real-world
roadway, and contains information on street names, address ranges,
jurisdictional boundaries, and other attributes. Road centerlines are an
integral part of any public safety GIS and CAD/RMS due to its critical use
for location information, vehicle routing, and mapping.
Site/Structure Address Points (SSAP) represent the location of a site, a
structure, or the location of access to a site or structure. They may also
represent landmarks. This SSAP data also considers high -occupancy
structures such as hotels, apartments, and shopping centers by denoting
each suite, room number, or unit number. Address points enable the ability
to locate sites that otherwise may not accurately be determined by only
using the road centerline data.
Chief Technology Officer and Police Chief recommend approval.
['r
AG RICE EM Ilk " Ali' T F OR
F RO ISI 111 SSVIII O NA 11 SIII R IV IIS ;u, r IUB m
E)A U, ANDa r�r"i KA) D) \/))
o,
City of Grapevine, Texas
Information Technology &
GIS Department
CANOPY SPATIAL, LLC
& S iJ V� i A A i`: Y
The staff of Canopy Spatial have been assisting municipal, county, state, federal, and private organizations
for almost fifteen years in duration and over 40 years collectively. Our team primarily supports these entities
with Data Collection — Aggregation - Integration, Database Development, Asset Management, Application
Development, Training, and Needs Assessment - Implementation Planning. This experience allows us to
assist local governments to streamline daily workflows and achieve optimal data management using
Geographic Information System (GIS) and related technologies.
Maintaining 9-1-1 systems and Next Generation 911 (NG9-1-1) implementation is something that our team is
experienced in and passionate about. This is a critical upgrade for communities that we are proud to
support. Often, funding and competencies are lacking, which have forced our team to develop and adopt
data collection, aggregation, and integration techniques or methods that are proving to be cost effective
solutions. Currently, we are providing professional services to over 14 counties in MS on NG9-1-1
implementation projects and in negotiation with multiple other counties in the southeast.
Canopy Spatial is providing this proposal in an effort to enter into an agreement with the City of Grapevine,
Texas, to provide GIS support services and products. Appropriate non -disclosure agreements will need to be
entered into so that data integrity and confidentiality can be met and fulfilled. This proposal is intended to
provide an opportunity for Canopy Spatial to deliver cost effective solutions, such as services and products,
to the City of Grapevine, Texas.
Il"P'R(1�4: Idil T& SCORE
Canopy staff will work directly with the GIS Manager as the primary point of contact on this project to confirm
schedules and deadlines for all field data collection and database development. We have designed two options
for achieving project and organizational goals.
Option A is our recommended and preferred approach. Canopy Spatial will work directly with the City of
Grapevine Staff and utilize City Vehicles. Option B does not integrate the City of Grapevine staff or vehicles and
will be completed by Canopy Spatial staff and vehicles.
Option A is recommended for the following reasons:
• City staff that utilize the data on a regular basis such as: Fire, Police, Dispatchers, GIS, 911
Coordinator, Planning, etc... gain a strong understanding of the data collection process.
• City staff are more familiar with any upcoming or recent addressing changes, developments,
projects, and other regular activities that may impact the data collection or quality.
• End-users gain a strong comprehension for the importance of data quality.
• Data collectors will be safeguarded by riding in vehicles with City Logo.
• A knowledge transfer of new developments and existing datasets will be communicated during
field verification, this allows for the most accurate and comprehensive information.
• City Staff are often the most important field resource, even those that never enter the field.
• Existing knowledge and familiarization of local roadways and developments saves valuable time
during field data collection.
• Limits expenses for transportation and additional personnel during field collection.
City of Grapevine, TX - Information Technology & GIS Page 1 of 4
The tasks and scope of work outlined below will be the roadmap for achieving project goals:
i. Needs Assessment:
• Review Existing Data and Database Schemas:
o Point Addresses
o Street Centerlines
o Fire Response Areas
o Law Enforcement Response Areas
o EMS Response Areas
o MSAG
o ALI
o Zip Codes
o Adjacent Municipal Fire, Law and EMS Response Areas
2. Database Design and Field Data Collection Application Development:
• Convert the existing dataset schemas into the new schema provided by the City of
Grapevine
• Complete topology checks on all datasets according to NENA GIS Data Model Standard
(NENA-STA-0o6.1-2oi8)
• Create the Field Data Application
3. Field Data Collection
• Daily pre -plan for field data collection
• Daily post process of data to ensure all roads and addresses have been physically verified
• Provide Daily Progress Reports by GPS Tracks.
• Utilize an R2 Trimble Survey Grade GPS Device.
4. Post Processing of Field Data Collection
• Post Process all Point Address Data
• Post Process all Street Centerline Data
• Create Correct Address Street Centerline Ranges according to NENA GIS Data Model
Standard (NENA-STA-oo6.1-2oi8)
• Populate all database attribute information
5. Data Review and QA/QC Report (Provided by Datamark*)
• NG9-i-i Data Readiness Check (DRC) (Attachment A: Sample DRC)
• After reviewing the report Canopy Spatial Staff will work with the City of Grapevine to
correct any anomalies or potential errors in the database.
*In addition to being an Esri Silver Partner, Canopy Spatial has developed strategic relationships with
technical experts and software providers that help support cost effective solutions that deliver high quality
data and applications.
City of Grapevine, TX - Information Technology & GIS Page 2 of 4
PI M i . lf.JH',,,, 9E & IP 1R (.) D il.l1C 1C S
In terms of the schedule and timeline, the following categories will be useful to establish milestones and
benchmarks for organizing tasks, duties, services, and products so that the identified scope of work can be
appropriately allocated.
DATE PROCESS
1. TBD ......................... Needs Assessment Completed
2. TBD ......................... Database Design and Field Data Collection Application Developed
3. TBD ......................... Begin Field Data Collection
4. TBD ......................... Post Process of Field Data Collection
5. TBD ......................... Data Review and QA/QC Report (Provided by Datamark)
P RICA I!V^I( i'+I)-"IIIIJAP40! If S
Depending on the option chosen by the City of Grapevine, Canopy will utilize resources that meet the needs
for supporting the project.
Compensation rates, invoicing preferences and schedule, and required documents or licensing will be
established or provided prior to any services or developing any products. Canopy utilizes a time tracking or
record system to maintain accountability, plan effort allocation, and track actual effort application. All
invoices will be issued with the understanding that the terms are "net 45" or "due upon receipt".
Both options are Not To Exceed using Time & Expense reporting: Option A - $17,900, Option B - $20,400
The estimated fees to complete Tasks 1 — 5 are based off of our standard Rate Table (Figure 1):
Figure i
POSITION
RATE
QUALIFICATIONS / REQUIREMENTS
This rate is based on personnel that has more than 13 years' experience managing GIS and
Project Manager z
$ 150
Related Technologies projects with an additional experience managing a variety of other
projects in real estate, construction, and urban planning.
Project Manager
$ X30
This rate is based on personnel that has 8+ years' experience managing GIS and Related
Technologies projects.
Solutions Engineer z
$ 140
This rate is based on personnel with io+ years' experience in specialized solutions that require
enterprise level or advanced GIS and Technology experience.
Solutions Engineer 1
$ 120
This rate is based on personnel with 7+ years' experience in specialized solutions that require
enterprise level / intermediate GIS and Technology experience.
GIS Specialist 2
$ 120
This rate is based on personnel that have lo+ years' experience working with local
overnments, engineering firms, and planners to implement GIS solutions.
GIS Specialist 1
$ 105
This rate is based on personnel that have 7+ years' experience working with local
governments, engineering firms, and planners to implement GIS solutions.
GIS Analyst z
$ go
This rate is based on personnel with 4+ years' experience and special expertise for the type of
work being completed.
GIS Analyst t
$ 75
This rate is based on personnel with z+ years' experience working as a GIS professional.
GIS Technician z
$ 6o
This rate is based on personnel with more than 1 year experience in GIS and familiarity with
the type of work being completed.
GIS Technician 1
$ 45
This rate is based on personnel with entry level experience as a GIS professional, work will be
reviewed by a person with more experience.
City of Grapevine, TX — Information Technology & GIS Page 3 of 4
A, TJA C � WflEN7'A..,,, (SAW"l �E DFQC)
City of Grapevine, TX - Information Technology & GIS Page 4 of 4
D�AU/-\A /°����� �[�i/ -O��G9-1-1Dm�ReadUne�Check
- --'--'
��������K��&�
^vm�uumu�mm
The DATAK4ARK8 team, Michael Baker International's public safety experts, obtained data for the
purpose of executing e NG9-1-1 data readiness check. The DATAK4ARKteann analyzed the data to
determine inconsistencies and anomalies that may impact the internal Public Safety Answering Point
(PSAP) systems (Computer -Aided Dispatch ([AD), CA[} mapping, AVL (Automatic Vehicle Location), etc]
and the Next Generation 9-1-1 (NG9-1 -1) core services that leverage GIS data; the emergency call routing
function (ECRF) and location validation function (LVF).
CIS data serves as the foundation of dependable and reliable NG9-1 1 system and is therefore elevated
to a mission critical level. A N(S9-1-1 system relies on highly precise (S|S location data to route the 9-1-7
call to the correct PSAP. The address points and the road centerlines are part of the required layers in the
NG9-1-1 CIS Data Model [NENA-STA-006]-2018]. It is essential that these two layers answer the same
questions asthe legacy MSA(Sand AL|tabular clatasets.Other required CIS datasets include: emergency
service boundaries, PSAP boundary and o provisioning boundary. Without this accurate GIS data,
transitioning from the current E9-1-1 system to an NG9-1-1 system may face a hampered schedule and
budget constraints.
This report utilizes DATAK4ARK.s unique set of validation checks to determine a baseline "readiness" of
the GIS data for NG9-1 1 system. These validation checks flag anomalies that may hamper the ability
fora call to route correctly within a NG9-1 1 system. Anomalies do not indicate a true error; an error is
determined as such after a detailed review of the data. Some of the features flagged are likely legitimate
exceptions and are not actual errors in the data. It is imperative to review all anomalies identified before
provisioning data into any N(S9-1 1 system.
WHAT IS VEP?
DATAMARKS VEP is an end-to-end Next -Generation 9-1 -1 (NG9-1 -1) geographic information system (GIS)
data aggregation, preparation, analysis, and maintenance solution that is designed to meet the needs of the
end-user. It provides a user-friendly interface for both GIS and non -GIS trained personnel to conduct 9-1 -1
location data validation and quality control beyond internal clatasets. DATAMARK VEP has the capability to
work collaboratively with datasets from regional 9-1 -1 location data partners - from constituent GIS data
providers and addressing authorities to neighboring 9-1 -1 authorities.
The DATAMARK VEP SOftvv8re-as -G-Service CSGuS\ solution is @ cutting-edge, secure, cloud -based system
that speeds and eases the collection, preparation and maintenance Of CIS data for all 9-1-1 sVsterns.
DATAMARK's technical experts located throughout the United States are well versed in NG9 1 1
requirements and public safety data workflows and stand ready to assist agencies with their N(S9 1 1 CIS
needs. The platform ensures:
v' Noadditional investment inhardware Orsoftware.
`/ Dedicated support staff proficient in customer service and technical support of VEP.
`/ User-friendly interface for the CIS novice tothe CIS expert.
|NTE R NAT mON A L
1|page
D�AU/-\A /°����� �[�i/ -O��G9-1-1Dm�ReadUne�Check
- --'--'
`/ Unlimited access tocomprehensive data QC and validation checks tuprepare data for N(S9-11.
/ Interoperability with existing public safety systems.
"' Platform agnostic design to support a variety of other applications including CAD, CAD
mapping, and AVL.
DATAMARK VEP's holistic integration of data from multiple data sources, combined with its data -forward
maintenance plan, ensures the updated information is consumable in the NG9-1 -1 Core Services (NGCS)
ind across the entire orioanizational data enter.%rise, DATAMARK VEP and the corres.%ondinA data model
use the current NENA NG9-1 -1 CIS Data Model as a template, but the application is flexible enough to
incorporate our clients' custom fields and additional schema requirements.
��0�N��������������
�.m.°..°."^.". "�. ."��.w�n�
The DATAMARKteann field mapped the data into the DATAMARK NENA-compliantschenna. The data is
validated using the unique set of DATAMARKva|idahon checks. Table 1 (below) shows the clatasets and
records used in the analysis. Where data is not -compliant and is not ingestible into the DATAMARK NENA-
compliant schema (e.g. alphanumerics in the house number field) it is possible that the total number of
records may not match the number ofrecords ran inthe analysis.
Table / Datasets provided toDATAMARK for oDRC and the number of records within each dataset utilized for
Road Centerlines
Y
20,280
20,280
Address Points
Y
117,861
113,404
MSAG
Y
6,115
6,115
AL|
Y
158,078
158,078
P5APQoundary
N
Provisioning Boundary
N
ESB-Lavv
N
ESB - Five
N
ESB -EMS
N
ESB Other
N
Tables 2-6provide 8summary 0fanomalies identified the provided data. These anomaly tables reflect
the logic output from the OATAK4ARKVEP application.
Table 2Road Centerline Anomalies
RCL Empty Geometry
8
8%
RCL Address Range Overlap'
1,324
6.5%
RCL Inconsistent Address Range Pahtv~^
28'274
108.0Y6
RCL Address Range Consistency
4,924
24.3%
RCL Address Ranges Incomplete
2
<196
|NTE R NAT mON A L
2|page
1 AaNMAI "
RCL Digitized Direction
RCL Digitized Direction and Address Range Flip
RCL Outside of Provisioning Boundary
RCL Outside of PSAP Boundary
RCL is Multi -part"
RCL Segment is Too Short"
RCL Segments Intersecting"
RCL Segment Self- IntersectiIng
'+
RCL Segment Under/Overshoots"
RCL Too Close"
RCL Has No Matching MSAG
RCL Has No Matching MSAG Address Range
DATAMARKO NG9-1-1 Data Readiness Check
1,010
5.0%
2,250
11.1%
N/A
N/A
N/A
N/A
0
0%
948
4.7%
86
<1%
3
<1%
10
<1%
14
<1%
4,017
19.8%
4,411
21.8%
'Address range overlap flags all instances of range overlap given all other centerline attributes are the same. There may be
instances of one to many relationships and therefore, the total number of anomalies may not represent the total number of
unique features.
***Uses data parity attributes. If there are no parity attributes maintained, all records will flag as an anomaly because parity is
required within the NG9-1-1 GIS Data Model.
++ RCL topology check
Table 3 MSAG Anomalies
MSAG with Invalid Address Range 599
MSAG Has Zero Address Range 0
MSAG Has No Matching RCL 1,759
MSAG Range Outside RCL Range 1,256
Table 4 Boundary Topology Anomalies
Gaps and Overlaps in PSAP Boundary
Gaps and Overlaps in Emergency Service Boundaries
(Law, Fire, EMS)
Island Topology Errors
Boundary is Multipart
Boundary is Multipart and an Island
Table 5 Address Point Anomalies
AP Empty Geometry 0
I IN T ERNAT 110NAL
N/A
N/A
N/A
N/A
N/A
9.8%
0%
28.8%
20.5%
0%
3 1 P a g e
1 111 111
11� WAIN MAIRU AQ "alk ik
DATAMARKO NG9-1 -1 Data Readiness Check
AP Missing Attribution
0
O%
APDuplicate Point
1,296
1]96
APNot Reflected inRCL*
961
<1Y6
AP isonWrong Side ofR[L*°
3,382
3.096
APK4isorderedAlong RCL*
12'542
11.1%
AP Maps to K4u|hp|e RCL*
5,241
4.696
APOutside ofProvisioning Boundary
N/A
N/A
AP Outside of PSAP Boundary
N/A
N/A
*Uses DATAMARKVEP fishbone logic
°°UcesDAl4MARKcalculated RCL parity field inthe logic ifnoparity attribute bpresent indata and DA7AxARKVEP fishbone
Table 6/4L/Anomalies
AUHas Alpha House Number
AL| Has Invalid House Number
AL| Has No Matching AP
AL|Has NoMatching RCL Range
Potential Invalid ALI Address
|INTERNATm0NAL
192
2
0
158,076
VALIDATION CHECK DESCRIPTIONS
I
.U1.114101 11111 I'll I l"011 W1.11,1111 11M
Road Centerline Empty Geometry
RCL with null geometry do not have shape or form. Despite having a record in the road centerline data,
there is no associated geometry. If an address or road centerline does not have a spatial location, its
ability to route in a NG9-1 -1 system is hindered.
Road Centerline Address Range Overlap
This validation check looks for range overlap where streets share the same attributes. 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 for 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.
Figure I The image below captures where two RCLs overlap with their ranges. This overlap between the two
RCLs enables the ability of APs to map to multiple RCL.
101 ', . ....... I --------------
100
Road Centerline Inconsistent Address Range Parity
114
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, 0, B, Z)If there is a mismatch between the range parity and
attribute, this will flag as an anomaly. All records will flag as an anomaly if parity values are not maintained
in the road centerline clataset. 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.
Table 7 In the table below, the inconsistent parity is seen in the left range values where there is an even
value in the FROM and an odd value in the TO. The calculated parity here is "B" for both even and odd.
1 111 111
11� WAIN MANOU AQ "alk N
DATAMARKO NG9-1 -1 Data Readiness Check
However, the Parity Left value is E for even. The comparison between these two is inconsistent and
therefore flagged as an anomaly.
1,111110110 1911Y7 11001, 11999 ulE 0
2000 2.998 2001 2999 IE 0
3GOO 3998 3001 3998 E 0
Road Centerline Address Range Consistency
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.
Table 8 In the table below, the red highlighted value is higher in the FROM field than the TO field therefore flags as
an anomaly.
11000 1997 1001 1999 E 01
2998 21001D 2001 2999 IE 0
3000 3998 3,001 3998 E 01
Road Centerline Address Ranges 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 flag as an anomaly. It is
acceptable to have no address range information (e.g. a From/To value of all zero or null). Incomplete
ranges may delay call routing within a NG9-1 -1 system.
I IN T ERNAT 110NAL 6 1 P a g e
DATA A A R K DATAMARKO NG9-1 -1 Data Readiness Check
Figure 2 As seen in the figure below, if an address range (whether the TO or the FROM) have a 0, blank, or
NULL value, it will flog as an anomaly.
101
11111��� ........................................................ ......... . ... . ... .. .....
wow
1,00
11
101 115 100 NISLIL Main Street
0 129 116 130 Main Street
Road Centerline Digitized Direction
Ideally, centerline management has consistent directionality of each centerline segment given the same
attributes whereby an end node snaps to the start node of the consecutive segment. However, due to
poor data management or addressing, the directionality is frequently compromised. In this validation
check, if road centerline segments have spatial interaction (do they touch in any way) given the same
attributes and do not snap the end node to the start node, then it is flagged as an anomaly. While not
critical to NG9-1 -1 call routing, the digitized direction and associated topology issues may have a greater
implication on the vehicle routing of field response units to an emergency.
Figure 3 The image below highlights where two RCL end nodes come together at the same point given the
same street attributes.
115 'L'13
100 13 3130
A 16
IN T E R NAT I ON A L 7 1 P a g e
DATA A ARi/ DATAMARKO NG9-1-1Data Readiness Check
Road Centerline Digitized Direction and Address Range Flip
Utilizing best addressing practices and sound data management, a road centerline is digitized in the same
direction as the associated address ranges (e.g. thefnon/to fie|dd. This validation check flags records
that are flagged as an anomaly in both AP Out of Order Along RCL and RCL Address Range Inconsistency.
The anomalies in this check are not fatal to N(S9-1 1 call routing, however it does affect data quality and
has implications on vehicle routing.
Road Centerline is Multi -Part
Multi -part features are those features that are spatially disconnected butane represented by single
record inthe attribute table. These features represent discontinuous features that have identical
attributes. The presence ofmulti-part features however is not in concordance with recognized
addressing data best practices and require 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 itdoes affect data
quality and may impact optimal vehicle routing.
Figure 4The image below conceptualizzes the road centerline bmultipart. In this example, the two-line segments
drawn are represented by one record within the attribute table, they are "multi -part" and not a contiguous line.
101 115 100 114 Ma�n Street
Road Centerline Segment is Too Short
This validation check is looking for segments that are too short and may potentially be an anomaly. VEP
has @ threshold Df1Orn, ifthe segment is shorter than that itwill flag GS@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.
Figure The image below conceptualizes this validation check. This check specifically looks for road centerlines that
are less than 70 meters. Therefore, this RCL as 9.5m will flag as an anomaly.
9.5rn
|NTE R NAT mON A L
8|page
1 111 111
11� WAIN MAIM AM "alk dk
DATAMARK@ NG9-11 -1 Data Readiness Check
Road Centerline Segments 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 N{S9-1-1 call routing, however it does affect
data quality and may impact optimal vehicle routing.
Figure 6The image below is an example of RCL segment intersections. In the first example, two different segments
cross each other. In the second example, one segment bifurcates another segment. Correct topology would split the
vertical RCL segment at the point of intersection and attributes modified.
Road Centerline Segment Self -Intersecting
This validation check is looking for an RCL segment that intersects itself. This frequently is a byproduct
of an editing error, The anomalies in this check are not fatal to N(S9-1 1 call routing, however it does
affect data quality and may impact optimal vehicle routing.
Figure 7The example below bocrude example of self -in It's common that this type of error is done when
digitizing isnot done utun appropriatescale and the level ofdetail tumitigate thesetypesofself-/n&coecdonsore
not minimized.
Road Centerline SegmentUmd
This validation check specifically looks for 8n RCL endpoint that does not intersect another RCL and does
not have any other RCL endpoint within 5m of it. If there is one within 5m, it is flagged as an anomaly.
This under orovershoot creates a topological gap or overlap between the RCLs. The anomalies in this
check are not fatal to 0{S9-1 1 call routing, however it does affect data quality and may impact optimal
vehicle routing.
Figure 0The image below isocrude example o/under and overshoots. These anomalies are frequentlyseen when
snap tolerances in the editing environment are off which produce these types of digitizing errors.
|INTERNATm0NAL
9|page
DTA A A R K DATAMARKO NG9-1 -1 Data Readiness Check
2
Road Centerline Segments Too Close
In this validation check, if an RCL is greater than SO% contained within a 2m buffer of another RCL, it is
flagged as an anomaly. Frequently this a byproduct of inconsistencies and errors within an editing
environment. 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.
Figure 9 The image below is an example of how the validation checks works. If a RCL is more than 50% within a 2m
buffer or a RCL it will flag. Individual anomalies will identify if the RCL is within either 50%, 609,6, 70% or 80%+ of
the buffered RCL.
Road Centerline Has No Matching MSAG
It's imperative to ensure that the RCL answers all the same questions as the MSAG, given that the MSAG
is accurately routing calls in the E9-1-1 system. This validation check will flag RCL records (not looking at
ranges) that are not present within the MSAG. Results frequently are a byproduct of a mismatch between
ESN values, misspellings, or a data consistency issue (e.g. suffix types are AVENUE v. AVE which results in
an anomaly given all other attributes are the same).
Figure 70 In the conceptual graphic below, the RCL data contains a 1300-1399 S VALIDATION AVE with an ESN of
500. However, the MSAG has a 700-7399 S VALIDATION AVE in Highlands with an ESN of 400. Since the ESN values
IN T E R NAT I ON A L 101 Page
DATA A ARi/ DATAMARKO NG9-1-1Data Readiness Check
are different, this will flog as an anomaly. It's critical to ensure that the RCL du&u oncwom oil the some qu*sdnoc as
the MSAG.
WARRIOR CREEK RD 123,90 12999 MILDRED COUNTY 1100
INC—MUNI = HIGH[ANIDS ESN = 500
Road Centerline Has NoMatching K8SAG Address Range
It's imperative to ensure that the R[L answers all the same questions as the K4SAG. This validation
identifies RCLs that have matching street attributes (such as the predinectiona[ street name, street suffix,
etc.), except that the address range of those attributes are not contained within the IMSAG. Similar tnRCL
has no matching MSAG record, a centerline file may contain alleys, trails, or other non -addressed or
navigable roads which would not appear in a IVISAG. However, this may indicate new development where
the K8SA(S is not updated and may not route calls effectively in@n E9-1 1 system.
Address Point Empty Geometry
Address points with null geometry do not have shape or form. Despite having a record in the address
point data, there is no associated geometry. If an address Or road centerline dD8S not have a Spad@|
location, its ability to route in a NG9-1 -1 system is hindered.
Figure 77Empty geometry is identifiable inthe attribute table bvreviewing the shape length ofthe attributes. Where
a record is NULL or 0, it's identified cis having "empty geometry".
IN TERN AT ION A L
11|Page
1 111 111
11� WAIN MAIM AQ "Olk dk
101
DATAMARKO NG9-1 -1 Data Readiness Check
1011,
�101 _Z06
MAIN STREET GEMIMAVI
MAIN STREET c�EmMwuLLE
MAIN STREET GEMIMAVILLE
Address Point Missing Attribution
Address points in this validation are checked for O 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 Stn88t n@nn8 requires pursing into their root elements (Street Name Pre -
Modifier, Street N@nn8 Pr8-0re[tiDn@[ Street Name Pre -Type, Street Name Pre -Type Separator, Street
Name, etclAddress points without ahouse number are flagged because they are amajor 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 [@|| to route in @ NG9-1 1 system.
Figure 72 Ifcritical attributes are missing for ogiven APrecord, it's impossible to the VEP logic to determine which
RCL the APisconnected too. The records shown here dohave uspatial component, but they will not receive the
possibility of a fishbone until the critical attributes of house number and street name are populated.
I T ERNATmONwL
12|Page
1 111 111
11� WAIN MANOU AQ "Olk dk
DATAMARKO NG9-1 -1 Data Readiness Check
HE
Address Point Duplicate Point
In an NG9-1-1 system, each address point represents a unique address. In the NENA NG9-1-1 ISIS Data
Model for address points, there are additional fields that enable a (S|S 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 e 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 PSAPtoensure adequate call routing.
Figure 73 Where two ormore address points have the same attributes, they are flagged as duplicate address points.
However, only one fishbone isdrawn for these duplicate points. The fishbone isdrawn torepresent the average
vector of the duplicate address points
|INTERNATmONAL
13|Page
1 111 111
11� WAIM MANOU AM "alk M
Address Point Not Reflected in Road Centerline
DATAMARKO NG9-1 -1 Data Readiness Check
Address points inthis validation have no corresponding road centerline feature based on its street
attributes, municipality and zip code (if populated). Frequently, this is a byproduct of street misspellings,
inconsistent street directional values, inconsistent street types, or potentially missing streets. It is important
to have consistency between the centerline file and address point file before provisioning the data to an
N(S9-1 1 system.
Figure /4There are several instances where onAPwill not find omatching RCL, eliminating the ability ofnfishbone
analysis. The image below shows an AP with an incorrect street name. Intuitively, we may assume that this APneeds
changing to "Main Street" and not "Apple Street". However, it still warrants validation before changing to ensure that
the owner ofthis address isNOT using Apple Drive.
� _9 \
�� ` �
�� 01 47
u�" 'w�, o�^� '�ot &� 06 -` �
i I �5
Address Point omWrong Side of Road Centerline
This validation checks that for each assigned address, the address is to the side of the centerline with the
same parity and range. Address points flagged in this validation fall on the opposite side of the street in
accordance with address mange parity in the centerline. It is not uncommon to find that these anomalies
are grouped where there is a parity error present in the centerline and, when corrected, the address point
errors are nDlonger valid. Further, itiscommon [Ofind even and odd addresses onthe same side ofthe
street in some historic areas. While they don't pose as fatal errors tothe NG9-1 1 ra|| routing systems, it
is helpful to check all address point errors and mark valid anomalies that have been field -verified as
|INTERNATm0NAL
14|Page
1 111 111
11� WAIN MAIM AQ "alk i1k
DATAMARKO NG9-1 -1 Data Readiness Check
Figure 15 AP on wrong side of RCL utilizes the fishbone logic. In the example below, the AP 174 Main Street
connected to the right side of the road but is spatially located on the left. Therefore, this AP will flog as an anomaly.
The some goes for the AP of 115 Main Street.
C51
115 .......... .. ..... .. . . ...... .. ....
_70
"114
se"04 4,1se
",
se/Z 'e4,
, 0,6
Address Point Out of Order Along Road Centerline
It T-,,# I " -*I-WTre7-dS—*. I, '. Lr#,7f I I I UIX!)
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. Ir
the DATAMARK validations, address points that are out of order are highlighted by the crossing of fishbones
Figure 76 AP out of order highlights the major benefit of fishbones in visualizing addressing issues. The image below
highlights where two fishbones cross. When this occurs, it's critical to determine if this is reflecting reality, and if so,
either readdress or mark as an exception.
I IN T ERNAT 110NAL
1_0
. ..... ...... -9 ""W
199
2,010
'dyjn
4,7
se,'-, 4 0'
151 Page
DATA A A R K DATAMARKO NG9-1 -1 Data Readiness Check
Address Point Maps to Multiple Road Centerlines
It is important in a NG9-1 -1 system that each unique address in a jurisdiction is represented by only one
possible location in the GIS data (centerlines and address points). This validation identifies APs that
geocode to more than one RCL segment; frequently a byproduct of address range overlap (see Address
Range Overlap).
Figure 77 The figure below illustrates when an address point maps to multiple RCL which is primarily a result of the
range overlap. The RCL on the left has an extent to 115 whereas the RCL on the right begins with 113, this overlap
between the two enables to the AP to map to multiple RCL.
101
3,
1010 114 116 130
.............................
Address Point or Road Centerline Outside of PSAP Boundary
The Public Safety Answering Point (PSAP) Boundary is a required GIS data layer that defines the
geographic area used to route emergency calls for NG9-1 -1. The validation checks that for each address
point there exists exactly one PSAP feature that spatially contains the address point. If a PSAP boundary
is not provided, all address points and road centerlines will flag as an anomaly since the PSAP boundary
is a required layer in the NG9-1 -1 GIS Data Model.
Address Point or Road Centerline Outside of Provisioning Boundary
The Provisioning Boundary is a required NG9-1 -1 data layer that defines the geographic area of GIS data
provisioning responsibility. These two validations determine the address points and road centerlines that
are beyond the provisioning boundary. If a provisioning boundary is not provided, all address points and
road centerlines will flag as an anomaly since the provisioning boundary is a required layer in the NG9-
1-1 GIS Data Model.
INT E R NAT I ON A L 161 Page
DATA A ARi/ DATAMARKO NG9-1-1Data Readiness Check
It's critical to ensure that the R[Lsanswer all the same questions asthe K4SAG for sound call routing
within a NG9-1 1 system. The tabular checks performed will provide a comparison of the K4SAG and
the RCL data for lack ofconsistency. Anomalies will require investigation for validity. As seen in Figure
18, the IVISAG has a large range for Mappy Ave, however, only a fraction of that range is presented in
the RCL data (the ranges between 10O-499and 80O-1199are rnissing).
Figure 0The image below illustrates odiscrepancy between the MSAG and the RCL data. Axdstands, the RCL data
cannot answer all the same questions as the MSAG and may impact call routing within a NG9- 7-7 system.
!MAPPY AVE 100; 1399 HIGHLANDS 400
ESN
U 500 798 5010 799 !MAPPY AVE HIGHLANDS 4Q
TO
12010 1298 1201 1299 MAPPY AVE HIGHLANDS 400
1300 1398 1301 1399 !MAPPY AVE HIGHLANDS 40C
K8SAGwith Invalid Address Range
This validation check flags k4SAG records with an alphanumeric address range. There is no reason for the
IVISAG low/high fields to contain alphanumerics. These anomalies will require follow up with the IVISAG
K8SAG Has Zero Address Range
IVISAG na[ORjs should @|vv@y5 have range (values in the Low and High fields) to identify addresses along @
stretch of street. There is no reason to have null, blank or "0" ranges in an IVISAG. These anomalies will require
follow up with the IVISAG Coordinator.
MSAG Has No Matching Road Centerline
If the current K4SAG is maintained and accurate within a E9-1-1 system, it's imperative to ensure that all
IVISAG records are contained within the RCL to ensure proper call routing in 8 N{S9-1 1 system. This is @
critical check because the K4SAGiScurrently routing calls in@E9-1-1 system and ifthe RCL cannot answer
all the same questions as the IVISAG, a call may improperly route when transitioning to NG9-1-1. Often,
there is a mismatch in ESN, a spelling issue ora street type domain discrepancy in the IVISAG versus what is
maintained in a centerline. This validation identifies unique street names that appear in the K4SAG but are
not found inthe road centerline table.
K8SAG Range Outside Road Centerline Range
This validation Check identifies all K4SAG records that share the same street attributes except that the
K4SAG lovv/highvalues extend beyond the ranges found within the RCL. This critical check ensures that
every attribute of the IVISAG is wholly contained within the RCL so that in a NG9-1 -1 system, all calls route
IN T E R NAT mONwL
17|Page
DATA A ARi/ DATAMARKO NG9-1-1Data Readiness Check
It's critical to ensure that the GIS data can answer all the same questions as the ALI to ensure sound call
routing within a NG9-1 1 system. The tabular checks performed here will ensure the quality of the AL|
and ensure all records are represented within the GIS data. Asseen in Figure 19, the high|ightedAL|
record of 1345 S Validation Ave is found in both the AP and the RCL data, furthermore the community
isall Highlands with anESN of40O. Therefore, for this particular record, the GIS data can answer all the
same questions as the ALI and will ensure sound routing in a NG9-1 -1 environment.
Figure 79 The graphic below highlights where the single record highlighted brepresented in both the RCL and the AP
data. Therefore, the GIS data isanswering all the questions that AL/can for this particular record.
S VALIDATION AVE
House number is a required data field for civic locations in the N(59-1-1 6|S Data Model and therefore
requires population. This validation flags AL|records that have nOaddress number.
ALI Record with Alpha Characters
The house number field contains only integers and no alpha -characters. This is because in an NG9-1 -1 system,
each address point represents 8 unique address. In the NENA NG9-1-1 GIS Data K8Od8| for address points,
subaddress information is stored in other appropriate attributes such as building, floor, unit, room, landmark,
and additional location information.
Potential Invalid A0AddyGss
This validation flags ananomaly ifthe record flags inboth AL/has nD matching APand AL/has nO matching
RCL rGnge. Reviewing these validation results will identify invalid address assignment, gaps in the current
address point and road centerline GIS data, and make sure that all valid civic locations from 1heAL| are
contained appropriately within the GIS data so that the GIS data will "answer" the same questions as the
AL| in NG9-1 1 system.
IN T E R NAT mONwL
18|Page
1300
�
1.301
�
�
1238675309 500
12355,510142 4100
ALI Has No Address Number
S VALIDATION AVE
House number is a required data field for civic locations in the N(59-1-1 6|S Data Model and therefore
requires population. This validation flags AL|records that have nOaddress number.
ALI Record with Alpha Characters
The house number field contains only integers and no alpha -characters. This is because in an NG9-1 -1 system,
each address point represents 8 unique address. In the NENA NG9-1-1 GIS Data K8Od8| for address points,
subaddress information is stored in other appropriate attributes such as building, floor, unit, room, landmark,
and additional location information.
Potential Invalid A0AddyGss
This validation flags ananomaly ifthe record flags inboth AL/has nD matching APand AL/has nO matching
RCL rGnge. Reviewing these validation results will identify invalid address assignment, gaps in the current
address point and road centerline GIS data, and make sure that all valid civic locations from 1heAL| are
contained appropriately within the GIS data so that the GIS data will "answer" the same questions as the
AL| in NG9-1 1 system.
IN T E R NAT mONwL
18|Page
DATA A ARi/ DATAMARKO NG9-1-1Data Readiness Check
ALI Has No Matching Address Point
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 Telephone Number JN) 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 reporting to the telephone companies.
ALUHas 0oMatching Road Centerline Range
This validation check highlights discrepancies between the ALI and the road centerlines. It ensures that every
AL| record has a coordinating centerline where theAL| house number falls within that road centerline range.
|facivic location inthe current AL|cannot geocodealong aroad centerline then a9-1 1call may improperly
Gaps and Overlaps inPSAP Boundary
This validation reports 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 oa|[ For example, an overlap in PSAP
boundary would return more than one PS/\P location during call handling. It is critical that topology is
reviewed and PSAPboundaries are free from gaps and overlaps.
Gaps and Overlaps inEmergency Service Boundaries /Aom\Fire, EMS)
Toensure that Emergency Service Boundaries, including Law, Fine, 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 a N(59-1 1 system and features within each layer must not have gaps or
overlaps with features coexisting inthe same layer. This validation identifies gaps and overlaps in the Lov4
Fire, and EMS feature classes.
Island Topology Errors
This validation check is flagging any boundary that iSsurrounded bvgreater space. This anomaly does not
necessarily mean that itisanerror. The results here may hinder call routing inaNG9-1-1 environment.
Boundary isMulti-Part
This validation check is flagging any boundary where there are multiple polygons for a single record within
the attribute table. Multi -part features may hinder N(59-1 1 call routing ifnot reviewed carefully and rectified
to a single -part feature.
Boundary [sMulti-Part and an Island
This validation check is flagging any boundary where there are multiple polygons for a single record within
the attribute table AND boundaries that are surrounded by greater space. The records flagged here are
not flagged individually between the island topology errors and the boundary is multipart validation checks.
IN T E R NAT mONwL
19|Page