HomeMy WebLinkAboutItem 14 - GIS Data Development MEMOTO: 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.
�,A:_
u
t
i
City of Grapevine, Texas
Information Technology &
AG R,E E ME"1` T F0 R GIS Department
F'R N S 0 N N.i, S 6 R11 I
CANOPY SP TIAL, LL
E)A U,AND A fl" ire )0)"i D) /) i
&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
iC'II M i.lf.JH',,,,9E& IP1R(.)D Ui C°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 RICE I!V^JI & Ih"IIIIJAP401 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 1 $ 130 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 Z $ 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
I
',, �� ,'�, , // ,,, „ r ;rrrrrrrrrrr„rrrrrrrrrrrrrrrrrrrrrrrrrr II
r
ro%
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 DATAK4ARK team 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) end location validation function /LVR.
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 as the legacy MSA(S and AL| tabular clatasets. Other required CIS datasets include: emergency
service boundaries, PSAP boundary and o provisioning boundary. Without this accurate G|S data,
tsansitioning 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 G|S 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.
������ U� �0���
"nxnx�n n� ��n �
DATAMARKS VEP is an end-to-end Next-Generation 9-1 1 (N(59-1 1) geographic information system (G|S)
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 (S|S and non-G|Stnained personnel to conduct 9-1-1
location data validation and quality control beyond internal datasets. DATAK4ARKVEP has the capability to
work collaboratively with clatasets from regional 9-1 1 location data partners - from constituent (5|S data
providers and addressing authorities to neighboring 9-1 1authorities.
The DATAMARKVEP SOftvv8 re-as-G-Service (SGuS) solution is @ cutting-edge, S8[un2, cloud-based system
that speeds and eases the collection, preparation and maintenance Of CIS data for all 9-1-1 systems.
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' No additional investment in hardware or software.
v' Dedicated support staff proficient in customer service and technical support DfVEP.
,/ User-friendly interface for the CIS novice to the CIS expert.
| NTE R NATmON A L
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� Check
- --' --'
`/ Unlimited access to comprehensive data QC and validation checks tu prepare data for N(S9-11.
/ |nteroperabihtVvvith existing public safety systems.
"' Platform agnostic design to support a variety of other applications including CAD, CAD
mapping, and /Y/L
DATAMARKVEP'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 (N(SCS)
and across the entire organizational data enterprise. DATAMARK VEP and the corresponding data model
use the current 0ENAN{S9-1 1 CIS Data Model asa template, but the application is flexible enough 10
incorporate our clients' custom fields and additional schema requirements.
�KU�����&�� ��� ����UU���
�.m.°..°."^.". "�. ."��.w�.�
The DATAMARKteann field mapped the data into the DATAMARK NENA-compliantschenna. The data is
validated using the unique set of DATAMARK validation checks. Table 1 (below) shows the clatasets and
records used in the analysis. Where data is not-compliant and is not ingestible into the DATAK4/\RKNENA
cmrnp|iant schema (e.g. a|phanurnerics in the house number field) it is possible that the total number of
records may not match the number of records ran in the analysis.
Table / Datasets provided to DATAMARK for G DRC and the number of records within each dataset utilized for
analysis.
NG9-1-1 DATA SET AVAILABLE #OF RECORDS #OF RECORDS
RAN
Road Centerlines Y 20'280 20,280
Address Points Y 117,861 113,404
K4SAG Y 6'115 6'115
AL| Y 158,078 158,078
P5AP Boundary N
Provisioning Boundary N
ESB- Lavv N
ES8- Five N
ESB- EMS N
ES8 Other N
Tables 2-6 provide 8 summary of 8n0nn8|i8S identified the provided data. These 8n0nn8ly tables reflect
the logic output from the OATAK4ARKVEP application.
Table 2 Road Centerline Anomalies
R[L Empty Geometry 8 8%
R[LAddress Range Overlap' 1,324 6.5%
R[L Inconsistent Address Range Pari1y^`^ 28'274 108.0Y6
R[LAddress Rang* Consistency 4,924 24.3%
R[LAddreso Ranges Incomplete 2 <196
| NTE R NATmON A L
D�AU /-\A/°������ [�i/ — O ��G9-1-1Dm� ReadUne� Check
— --' --'
ON
RCL Digitized Direction 1'010 5.0%
R[L Digitized Direction and Address Range Flip 2,250 11.1%
RCL Outside of Provisioning Boundary N/A N/A
R[L Outside ofPSAPBoundary N/A N/A
KCLisK4u|ti-part° 0 096
R[L Segment is Too Short" 948 4.7%
RCL Segments Intersecting" 86 <196
R[L Segment Self- nteoeciing~~ 3 <196
RCL Segment Under/Oveohooto° 10 <196
R[L Too Oose° 14 <196
RCL Has No Matching K4S4G 4'017 198Y6
R[L Has No Matching K4SAG Address Range 4,411 21.896
+Address range overlap flags all instances of range overlap given all other centerline attributes are the same. There may he
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-77GIS Data Model.
~~R{I topology check
Table 3 MI46Ano/nm/iec
VALIDATIONS #OF ANOMALIES %OF TOTAL
FEATURES
K4SAGwith Invalid Address Range 599 9.8%
K4SAG Has Zero Address Range 0 096
K4SAG Has No Matching RCL 1'759 28.8%
K4SAG Range Outside R[LRange 1'256 20.596
Table 4 Boundary Topology Anomalies
VALIDATIONS #OF ANOMALIES
Gaps and Overlaps inPSAPBoundary N/A
Gaps and Overlaps in Emergency Service Boundaries
N/A
(Lew, Fire, EMS)
Island Topology Errors N/A
Boundary isMultipart N/A
Boundary is Multipart and anIsland N/A
Table 5 Address Point Anomalies
VALIDATIONS I #OF ANOMALIES %OF TOTAL
FEATURES
AP Empty Geometry 8 0V6
| NTF RNATmON AL
D�AU /-\A/°������ [�i/ — O ��G9-1-1Dm� ReadUne� Check
— --' --'
AP Missing Attribution 0 O%
AP Duplicate Point 1,296 1]96
AP Not Reflected in R[L° 961 <1Y6
AP isonWrong Side ofR[L*° 3,382 3.096
APK4isordered Along R[L+ 12'542 11.1%
AP Maps to K4u|hp|e R[L° 5,241 4.696
AP Outside of Provisioning Boundary N/A N/A
AP Outside of PSAP Boundary N/A N/A
*Uses DATAMARKKEp/shhonologic
°°UcesDAl4MARK calculated 8{I parity field in the logic ifno parity attribute b present in data and DATAxARKVEPfshbone
logic.
Table 6/4L/Anomalies
VALIDATIONS #OF ANOMALIES %OF TOTAL
FEATURES
AL| Has Alpha House Number 192 0.1Y6
AL| Has Invalid House Number 2 <196
AL| Has No Matching AP 2 <196
AL| Has No Matching RCLRange 0 096
Potential Invalid AL| Address 158,076 10096
| NTERNATION AL
VALIDATION CHECK DESCRIPTIONS
ROAD CENTERLINE VALIDATION CHECKS
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.
IS 113 1291
101 ',........
100 114 116 130
Road Centerline Inconsistent Address Range Parity
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 the
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.
D TA A A R K 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.
Left IFROM Right FROM Right TO Parity Right
Address Address Address
----------- ---------- ------------------------------------------------------------------------------------------------Im-------------------------------------------------------
1111110110 1911Y7 11001, 11999 ulE 01
2000 2998 2001 2999 IE 0
3G00 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.
Left IFRO�M Right FROM �� Right'To Parity Right
Address Address Address
.........................................................................................I............................................................................ ..............................................................................................
11000 1997 1001 1999 E 01
2998 210019 2001 2999 IE 0
3000 39,98 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.
1,74111T.M. IM:
I N T E R N A T 1 0 N A L 6 1 P a g e
DATA DATAMARK® 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 flag as an anomaly.
1011111���' wo � 5 0 12
1 1
100 � � w
116 1,30
101 115 100 MI4SLIL Main Street
0 129 116 1.39 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 't'1,3
13'3' t 3133
1t
1,74111T. IINTERNATIONAL wlllw w
7 1 P a g e
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� 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 lsMulti-Part
Multi-part features are those features that are spatially disconnected but are represented by single
record in the attribute table. These features represent discontinuous features that have identical
attributes. The presence of multi-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 The image below conoptuolizzes the road centerline b multipart. 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.
zoz az, om 114 Mann Street
Road Centerline Segment lsToo Short
This validation check is looking for segments that are too short and may potentially be an anomaly. VEP
has @ threshold Df1Onn, if the segment is shorter than that it will 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 5 The image below conceptualizes this validation check. This check specifically looks for road centerlines that
are less than 70nneters. Therefore, this R[1us9.5nn will flag oson ononnoh/
9.5rn
| NTE R N A Tm0 N A L
D�AU /-\A/°������ [�i/ - @ ��G9-1-1Dm� ReadUne� 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 6 The 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 R[L segment mt the point of intersection and attributes modified.
-7 Z 2
1 '/
Road Centerline Segment Self-Intersecting
This validation check is looking for an R[L 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 7 The example below b o crude example ofself-/ntecsecdny. It's cunn/non that this type of error is done when
digitizing is not done utun appropriate scale and the level of detail tu mitigate these types of self-intersections are
not minimized.
Road Centerline SegUmentUmder/Oner9h$ots
This validation check specifically looks for 8n R[L 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 or overshoot 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 0 The image below iso crude example o/under and overshoots. These anomalies are frequently seen when
snap tolerances /n the editing environment are off which produce these types o/digitizing enno
| NTERNATION AL
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� Check
- --' --'
Road Centerline Segments Too Close
In this validation check,� if an RCL is greater than 5O96 contained within a Jrn buffer mfanother RCL, it is
flagged as an anomaly. Frequently this a byproduct ofinconsistencies 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 N(59-1 1 call routing, however itdoes
affect data quality and may impact optimal vehicle routing.
Figure 9 The image below ison example of how the validation checks works. (foR(Ib more than SO% within o2nv
buffer uroR{I /t will flag. Individual anomalies will identify if the R{Ib within either SO%, 6096, 70% or80%+ of
the buffered R[L.
Road Centerline Has No Matching MSAG
It's imperative to ensure that the RCL8nSvv8rS all the same questions as the K4SA(S, given that the MSA(5
is accurately routing [@||S in the E9 1 1 system. This validation check will flag KCL records (not looking at
ranges) that are not present within the K4SACS. Results frequently are a byproduct of mismatch between
ESN values, misspellings, or data consistency issue (e.g. suffix types are AVENUE v. AVE which results in
an anomaly given all other attributes are the same).
Figure /0 /n the conceptual graphic below, the R[l data cnn&x/nx o 7300 /399 S VALIDATION AVE with an £3N o/
508 However, the MSAG has u 700-7399 S VALIDATION AVE/n Highlands with on ESN o/408 Since the ESN values
IN T E R NATmONwL
10 1 Page
D�AU /-\A/°������ [�i/ -' O ��G9-1-1Dm� ReadUne� Check
- - --
are different, this will flog as an ono/nuk/ It's critical to ensure that the R[L du&u oncwom oil the some questions as
the MSAG.
STREET
SUFFIX
mm
z
Road Centerline Has No Matching K8SAG Address Range
It's imperative to ensure that the R[L answers all the same questions as the K4SAG. This validation
identifies R[Ls that have matching street attributes (such asthe predirectiona[ street name, street suffix,
etc.), except that the address range of those attributes are not contained within the IMSAG. Similar tnR(I
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 VALIDATION CHECKS
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 spatial
location, its ability to route in @ N(59 1 1 system is hindered.
Figure 77 Empty geometry is identifiable in the attribute table bvreviewing the shape length of the attributes. Where
u record is NULL orL\ it's identified cis having "empty geonoeby".
INTERNATIONAL
11 | Page
DATA DATAMARK® NG9-1-1 Data Readiness Check
Ipcl
dui ��, K,
1.
in,
s ,
iw9,zo. go. N e,,, 0,,� ..
IS,
a
STREET NAME STREET
1.01 MAIIN', STREET GEIVlICe1AVII L 4839.7336'8'
105 MAIN STREET GEIVI[UTAVILLE 0.00
Ill MAIN STREET GE11+11IhJIAVILLE
Address Point 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 Warne 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 a house number 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 a NG9-1-1 system.
Figure 12 If critical attributes are missing for a given AP record, it's impossible to the VEP logic to determine which
RCL the AP is connected too. The records shown here do have a spatial component, but they will not receive the
possibility of a fishbone until the critical attributes of house number and street name are populated.
1,74111T. l wlllw w
INTERNAT111ONAL 121Page
DATA DATAMARK® NG9-1-1 Data Readiness Check
�e c,
xe
1d
.10 -'0 1011- f
14
-10 &0
Address Point 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 a 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.
Figure 13 Where two or more address points have the same attributes, they are flagged as duplicate address points.
However, only one fishbone is drawn for these duplicate points. The fishbone is drawn to represent the average
vector of the duplicate address points
1C7
b�Q�
Z�e S11
101i
....
1
14
�04 9.,06 it
Str� �Sergi P �� Se" iy�n t
t
l wmw �w
I N T ERNATION AL 13 Page
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� Check
- --' --'
Address Point Not Reflected in Road Centerline
Address points in this 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 /4 There are several instances where onAP will not find o matching R[L 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 o/this address is NOT using Apple Drive.
~�«�'
�r
114
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 range 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 nD longer valid. Further, itis common [O find even and odd addresses on the 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
exceptions.
| NTE R N A Tm0 N A L
14 | Page
DATA DATAMARK® 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 flag as an anomaly.
The some goes for the AP of 715 Main Street.
_70
w5'
"11
s r0 "470 �
Address Point Out of Order Along Road Centerline
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.
Figure 16 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.
99
99
1010 L
f I '
�10 ���U
r 4r,,,y sr'� 41, sir ,
a ,
�� o sr'"'-'4�04 r
l wmw �w
I N T E R N A T10NAL 15 Page
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� Check
- --' --'
Address Point Maps{o 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 (S|S data (centerlines and address points). This validation identifies APs that
geocodetm more than one R[L 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 R[lon the left has onextent to775 whereas the R[Lonthe right begins with /73, this overlap
between the two enables to the AP to nnop to nnu/dp/e R[l.
^
Address Point orRoad Centerline Outside 8fPSAIPBoundary
The Public Safety Answering Point (PSAP) Boundary is a required (5|S 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 PSAP boundary
is not provided, all address points and road centerlines will flag as an anomaly since the PSAP boundary
is required layer inthe MG9-1 1 G|S Data Mode[
Address Point or Road Centerline Outside of Provisioning Boundary
The Provisioning Boundary is a required N(Sg 1 1 data layer that defines the geographic area ofG|S data
provisioning responsibility. These two validations determine the address points and road centerlines that
are beyond the provisioning boundary. haprovisioning boundary is not provided, all address points and
road centerlines will flag as an anomaly since the provisioning boundary isa required layer inthe NG9
1 1 G|S Data Model.
| NTE R NATmON A L
16 | Page
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� Check
- --' --'
MSAG COMPARISON CHECKS
It's critical to ensure that the RCLs answer all the same questions as the IVISAG for sound call routing
within a NG9-1 1 system. The tabular checks performed will provide a comparison of the K4SA{5 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-499 and 80O-1199 are rnissing).
Figure 0 The image below illustrates o discrepancy between the MSAG and the R[l data. Axdstands, the R[Idata
cannot answer all the same questions as the MSAG and may impact call routing within a NG9-7-7 system.
*� avAppv AVE zua 1399 w/sm/Amou +mo
500 7e8 5010 799 mnAppv AVE HIGHLANDS «mo
Cr.
12010 1298 1201 12e9 MArpv AVE HIGHLANDS 400
13010 1398 1301 13ee IMAppv AVE m/GwLAmos «mo
K8SAG with Invalid Address Range
This validation check flags k4S/\(S records with an alphanumeric address range. There is no reason for the
K4SA(5 low/high fields to contain a|phanurnerics. These anomalies will require follow up with the K4SAG
Coordinator.
K8SAG Has Zero Address Range
IVISAG records 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 K4SAG 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 RCLtO ensure proper call routing in 8 N{S9 1 1 system. This is @
critical check because the K4SAG is currently routing C@||S in @ E9 1 1 system and if the QCL cannot answer
all the same questions as the IVISAG, a call may improperly route when transitinning to N(S9-1 1. C)ften,
there is a mismatch in ESN, a spelling issue or a street type domain discrepancy in the IVISA(S versus what is
maintained in a centerline. This validation identifies unique street names that appear in the K4SAG but are
not found in the 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
K4SA(S low/highvalues extend beyond the ranges found within the RCLThis critical check ensures that
every attribute of the IVI5AG is wholly contained within the R[L so that in a NG9 1 1 system, all calls route
properly.
IN TERN AT ION wL
17 | Page
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� Check
- --' --'
ALI VALIDATION CHECKS
It's critical to ensure that the G|S data can answer all the same questions as the AL| 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 G|S 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
is all Highlands with an ESN of40O. Therefore, for this particular record, the G|Sdata can answer all the
same questions as the AL| and will ensure sound routing in a N{59-1 1 environment.
Figure /9 The graphic below highlights wheoethes/ng/enrroxƒhi h8ohtedboepmsnnted/nho1h1heR{IondtheAP
data. Therefore, the G/S data is answering all the questions that AL/can for this particular record.
���� S VALIDATION AVE
=
1��1
�
�
�
ALI Has No Address Number
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 ALI records that have no address number.
ALI Record with Alpha Characters
The house number field contains only integers and nOalpha charGct8rS.This iS because in8nNG9 1 1sySt8nn,
each address point represents 8 unique address. In the NENA NG9 1 1 G|S Data K8Od8| for address points,
suboddress information is stored in other appropriate attributes such as building, floor, unit, room, landmark,
and additional location information.
Potential Invalid ALI Address
Thisva|ido1ionf|aBsananoma|yif1hereCDrdf|agsinbmthAL/hDsnOnnDtchingAPandAL/hasnOcngtching
RCL rGnge. Reviewing these validation results will identify invalid address assignment, gaps in the current
address point and road centerline G|S data, and make sure that all valid civic locations from 1heAL| are
contained appropriately within the G|S data so that the G|S data will "answer" the same questions as the
AL| in NG9 1 1 system.
I T E R N A Tm0 NwL
18 | Page
D�AU /-\A/°������ [�i/ - O ��G9-1-1Dm� ReadUne� Check
- --' --'
ALI Has No Matching Address Point
The synchronization of the ALI and Address Point data requires a 1:1 match. Some examples mf why enAL|
record can't be matched to an address point are: missing address points, a street naming conflict, a
disconnected phone line (orphaned AL| record), oranAL| Telephone Nurnber [TN) assigned to a non-situs
address (ATM, etc.).Verification of an AL| address must occur before adding to the G|S data sinceAL| records
are not always 100% reliable.Any anomalies within the ALI data need reporting to the telephone companies.
ALU Has 0o Matching 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.
|fa civic location in the current AL| cannot geocodealong aroad centerline then a9-1 1 call may improperly
route in a NG9-1 1 environment.
BOUNDARY TOPOLOGY VALIDATION CHECKS
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 call. For example, an overlap in PS/\P
boundary would return more than one PS/\P location during call handling. It is critical that topology is
reviewed and PSAP boundaries are free from gaps and overlaps.
Gaps and Overlaps in Emergency Service Boundaries /Lam\ Fire, EMS)
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 a N(59 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 Lov4
Fire, and EMS feature classes.
Island Topology Errors
This validation check isflagging any boundary that iSsurrounded by greater space. This anomaly does not
necessarily mean that itisan error. The results here may hinder call routing in a NG9 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(591 1 call routing if not reviewed carefully and rectified
to a single-part feature.
Boundary is Multi-Part and an Island
This validation [heck 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 NATmONwL
19 1 Page