2. Improving Accuracy & Consistency in Location Validation
Brooks Shannon
Scott Ross
Brian Crumpler

3. The Mars Climate Orbiter (formerly the Mars Surveyor '98 Orbiter) was a 338-kilogram (745 lb) robotic space probe launched by NASA on December 11, 1998 to study the Martian climate, Martian atmosphere, and surface changes and to act as the communications relay in the Mars Surveyor '98 program for Mars Polar Lander. However, on September 23, 1999, communication with the spacecraft was lost as the spacecraft went into orbital insertion, due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf s) instead of the SI units of newton-seconds (N s) specified in the contract between NASA and Lockheed. The spacecraft encountered Mars on a trajectory that brought it too close to the planet, causing it to pass through the upper atmosphere and disintegrate.

4. Inconsistency in units caused a difference of altitude of 169 kilometers, spelling doom for the orbiter.
Inconsistency in location results, between different LVFs, can spell all sorts of other doom. Today, we’ll dive deeper and explore ways we can protect ourselves from problems and ensure consistent validation.

5. Today’s Discussion What is validation, and why it is important?
Why is it so important to have consistent validation results?
What can lead to inconsistent results?
Tuesday, October 11
Improving Accuracy and Consistency in Location Validation (D)
9:30 AM – 10:30 AM | George Bellows Ballroom A & B
Facilitators: Brooks Shannon, Scott Ross, and Brian Crumpler
Session Type: Hands-On
Know Before You Go: What an LVF is, and how it works at a high level (described in sections 4.4 and 5.3 of the latest draft version of the i3 document)
Outcome: Examples of technical and operational issues that could cause inconsistent validation results, as well as a list of future work to be considered
This session discusses technical and operational issues that could cause Location Validation Functions (LVFs) to produce inconsistent location validation results (some LVFs claiming a location is valid while others claiming it is not). Attendees will explore cases in which inconsistencies could occur and develop recommendations for mitigating those issues.

6. What is validation?
In NG9-1-1, location validation is “the validation of civic address-based location information against an authoritative GIS database containing only valid civic addresses obtained from Authorities.” (STA section )
Add from our INF doc

7. What things validate locations?
The Location Information Server (LIS)
Maybe the Call and Incident Handling functions at the PSAP
Maybe even GIS professionals
Add from our INF doc

8. What is a valid location?
A valid location is one that is dispatchable
Add from our INF doc

9. Why is validation important?
Invalid locations can:
Introduce inconsistency and induce confusion on the part of telecommunicators
Make it time-consuming or impossible to dispatch first responders
Cause call routing failures
Add from our INF doc

10. Why is consistency important?
LVFs, regardless of vendor or configuration, should return the same answers to validation requests
If they do not
It could cause a lot of unexpected GIS data work
It could impact software interoperability
It could cause inefficiency when validating records
Switching LVF vendors or operators could result in unexpected, large amounts of work to correct locations that suddenly become invalid
Software vendors producing LVF clients may find interoperability difficult to achieve
Service providers using more than one LVF may need to develop multiple, inefficient processes to account for variations in validation responses

11. An example of validation

12. Inconsistent validation
Inconsistency has a few flavors
“Baseline” inconsistency – simple valid or invalid
Inconsistent sets of what elements are valid, invalid, and unchecked
Inconsistency can be caused by
Technical differences - the way that LVFs are built
Operational differences – the way that LVFs are configured and managed

13. Technical causes of inconsistency
Baseline validity
Literal string comparisons versus fuzzy/forgiving matching
Different interpretations of valid for routing, valid for dispatch, and perfect match against GIS data
Valid/invalid/unchecked element lists
Use of a contextual hierarchy, or the lack thereof
Any others?
The way that LVF implementations vary – the way they are built and the way that they validate – can cause inconsistency

14. Example Inconsistency: Loose vs Literal Search

15. Example Inconsistency: Geocoding Offset

16. Operational causes of inconsistency
Examples
Differences in GIS data field mappings (for example, which field does A3 map to?)
Variations in geocoding offsets
Variation in dataset fallback strategies (SSAP to RCL to admin areas to…)
Any others?
The way that LVFs are managed – the way they are provisioned and configured – can cause inconsistency

17. The Location Validation Consistency Working Group needs your help!
Interested in helping?
The Location Validation Consistency Working Group needs your help!
We meet on Tuesdays at 3:00pm ET
us at