Implementing NENA Schema

JenniferStone · ‎10-28-2014

We are involved in a statewide NENA project which will ultimately make all the 911 addressing info, minus the personal stuff, available online for maintenance (if you choose to use the online system), viewing, and analysis purposes. We have already had our data converted to the NENA standards and returned to us where it has happily sits collecting dust while we try to figure out how to get the NENA schema into the production/live database used by the 911 center.

In regards to or update I have been asked to accomplish the following and am hoping you might have some insight on:

Update the data to the new NENA standards (time consuming but not really a problem)
1. Has anyone found an efficient way to QA/QC their data per the NENA standards?
Update the schema of the existing dispatch database
1. Would it be best to give them the schema xml to import to a new live/production database?
2. Or have them change the schema in the existing database?
3. Or just import the NENA compliant database onto their server as a SDE/SQL database once I finish updating everything?
4. Is there anything I should be looking out for? Be wary of?
5. Would it be better to wait until the update/mgration to the new CAD system is done?
Load the data into the new schema (again, not a huge issue)

Any help/advice/tips would be greatly appreciated.

JonHall · ‎10-05-2018

Jennifer, did you eventually answer your questions?

-Jon

JenniferStone · ‎10-09-2018

Jon,

I believe so. Fortunately I am the GIS Analyst, GIS Programmer, GIS Coordinator, 911 Addressing Coordinator, MSAG Coordinator, etc... all as part of my new title, GIS Coordinator, so coordinating in that aspect was simple. We have one other GIS Analyst but his focus in Real Property, mine is 911 Addressing. I ended up working with what Joe Borgione suggested and came up with this...

Updated our schema and domains to match NENA, our schemas were already very similar but the domain values were different. Not to problematic because we were migrating into an SDE geodatabase from a file geodatabase at that time anyways so we didn't have to modify the structure of our existing database just our new, unpopulated one.
Added data to the new SDE geodatabase, mapping the old fields to my new fields, per NENA, with an append process.
Built an object model in model builder to migrate our 10.3.1 SDE geodatabase addressing data to a NENA compliant 9.3.1 file geodatabase to map the data backwards to a format excepted by our current 911 CAD system.
Built another object model, using a hollow and append process, to then migrate that data (now in 9.3.1 format) to the 9.3.1 SDE geodatabase used by Dispatch. I used custom expressions and tools to modify the new NENA standard domain codes back to those used by the 911 Dispatch software. This was necessary because the external MSAG had not yet been brought up to date to recognize the new street suffixes.
Worked with 911 Dispatch to create new locators for use in the CAD system.

After a bit of trial and error we finally got a system that works fairly smoothly, just in time for NENA to finalize the new, again different albeit I don't think it's too different, schema. I do concur with the technician who expressed her frustration with that but I also understand it's a learning curve and an ongoing process, so it is what it is. Now, they are upgrading our CAD system to 10.3 just as we are moving to 10.6 on the GIS end so I imagine I will be re-configuring those models again to do something similar. I will also have to look more in-depth at the NENA schema to see if anything needs to be modified on our end.

I should point out that through this entire process I was working on the review process for the spatially invalid points that were provided by the NYS SAM project. This took two long years because we are very limited in staff and high in workload (our office handles three "Departments").

Now I have just completed an MSAG Audit of all of our roads and submitted that information, with the new NENA road suffixes, to our external MSAG AMS coordinator so some of those models have been adjusted to eliminate the extra steps needed to make it work in our CAD database. This is an ongoing process so I anticipate more to come but we will cross that bridge when we can see it.

JonHall · ‎10-09-2018

Jennifer, thanks for the detailed reply! RE:"

the external MSAG had not yet been brought up to date to recognize the new

street suffixes.

Are you referring to the spelled-out pre and post directionals ("NORTH"

replacing "N") or street types ("ROAD" replacing "RD")? This is the biggest

issue in the NENA-STA-006.1 standard that I forsee impacting GIS data

professionals, causing backward compatibility issues (your #4). Does NENA

really envision MSAG coordinators making all those changes in the legacy

MSAG during lengthy NG911 transition periods? The NENA data structures

workgroup will be trying to answer that question and more, in an upcoming

info document. Your input and experiences are very valuable.

Thanks!

-Jon

JenniferStone · ‎10-09-2018

I’m talking about different suffix extensions, some examples include:

Ours NENA’s

AV AVE

CRSG XING

TERR TER

We don’t use ST except in certain cases ST on every street

TRNPK TPKE

That sort of thing. Although the NENA suffixes now exist in our geodatabase I still had to modify the object model to return the suffix to our original setting (i.e. : AV or CRSG) so that it worked with our MSAG/Dispatch crossover. Thankfully that has now been corrected in the MSAG, or at least they said it was, we are still not positive about the ST issue because Verizon has never used that in the past except in certain cases.

Directionals and most of the more common suffixes were not typically an issue, we were already using many of them.

Jennifer D. Stone

GIS Coordinator

Sullivan County Real Property Services

GIS & 911 Addressing

Sullivan County Real Property Tax Services

GIS and 911 Addressing Center

Sullivan County Government Center

100 North Street

Monticello, NY 12701

Phone: (845) 807-0224

Fax: (845) 807-0232

Email: jennifer.stone@co.sullivan.ny.us<mailto:jennifer.stone@co.sullivan.ny.us>

Disclaimer: The Office of Real Property assumes no responsibility for any errors or omissions in the information provided. Furthermore, the Office of Real Property makes no representation as to the accuracy of the information provided. The Office of Real Property specifically provides this information as is and expressly disclaims responsibility for damages or liability, whatsoever, that may arise from use of the information provided.

Confidentiality Notice: This e-mail message, including attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and attachments. Thank you.

JoeBorgione · ‎10-06-2018

Just my $00.02. The NENA standards aren't anything any other database schema has to offer. It's just a set of 'guidelines' Having spent just short of 15 years as the GIS guy in a large 911 call center, (on to greener pastures now) I've seen my share of 'standards'.

(#1) Update exisiting data to NENA standards: it's just a schema. While I haven't seen NENAs final draft ( final draft, isn't that like jumbo shrimp?) I'm sure it has attributes for City, Left Address From, Street Name, Pre-direction etc. Your existing data has the same sort of info, but you just call those fields something else, right?

Create an empty feature class based on the NENA standard, and load or append your data into it: you'll need to map the field names over is all.

QA QC: there are a million ways to do this: start with the most important attributes and make sure they at least have values: not null or not '' (blank). Then make sure all those values are the standard. ST not Street: E not east, etc, etc. I've done this with lists in python.

(#2) Pretty much covered in #1: start fresh. Your existing data is already working for you right? I used to say 'Yeah, my data gets QA'd QC'd everytime the phone rings'... Create the new database and import the exisiting data.

With respect to your CAD migration, without knowing what you currently use and what you are migrating to, that's a tough one. Are you talking about migrating your existing records data into the new CAD or just your GIS data? If the former, get your checkbook out, as I'm sure the new vendor would be happy to take your money. If the latter, work with the new vendor: you'll need to learn how the new CAD uses your data. Some CADs use published services (REST end) to access the data; others have you beat your GIS data into a completely different format to get the data into CAD.

These are only suggestions and from the 20,000 foot view. However, having lived through 3 cad migrations between two call centers, I can tell you, it can be done.

That should just about do it....

JonHall · ‎10-06-2018

Joe, you are correct, in general. Anyone who works extensively with GIS data for E911, like you and I, appreciate many details and nuances that are not apparent to 90% of GIS professionals who work primarily in other disciplines

I've developed numerous QA checks in PYTHON scripts and VB.NET ArcGIS AddIn tools for attribute issues that impact geocoding. West Safety has a "MAPSAG" product, and GeoComm has a "GIS Hub" cloud-based, hosted product, that have built-in the QA audits necessary for NG911. Others have made similar toolsets available at no charge, like the Kansas NG911 project. Use builtin ArcGIS Topology rules for centerlines that must not have dangles, must intersect, and carefully determine which "errors" are necessary acceptable "exceptions" to rules, and which require edits to correct.

Writing the code, using Model Builder, PYTHON, or VB.NET to extract, translate, and load existing GIS data into the NENA NG911 GIS schema is beyond the capabilities of the average GIS professional. An experienced GIS programmer could easily do it, and will discover the many shortcomings that may exist in the source data. You have done this type of work using PYTHON, but the average joe has not. Just "map the field names" is rarely one to one.

That is where the average GIS professional working in other disciplines needs some guidance. What do you do if your data does NOT have an equivalent attribute? Or your values domain doesnt translate to NENA values domain? Resolving these issues is labor intensive, the avg GIS tech doesnt have hundreds of hours available to drop everything and work on it, and its very expensive to pay a vendor to do it for you. There are some VERY good vendors, thank goodness, but eventually they will give you a TODO list that only the local GIS and 911 authorities can resolve.

My advice is to start chipping away at it now, before you are in the jam Jennifer found herself in 4 years ago.

The NENA schema is used to provision the backend GIS database for web servers that validate addresses (Location Information Server, Location Validation Function services) and replace E911 Selective Routers for the NG911 Emergency Call Routing Function (ECRF). These web servers need interoperability between ESINETs in 50 states and a dozen different vendors who code their proprietary versions of the ECRF/LVF. Different vendors may provision data from source files that arent NENA standards compliant, and might store data in their webserver that aren't NENA standards compliant, but must have the interoperability capability to export data to NENA standards when requested by other web services on the interstate 911 information highway, aka ESINET. This is very difficult to code, if the server database, (and provisioning source data) are in a schema that is significantly different than the NENA GIS standards.

And the NENA GIS standards are continuously evolving, so it is a moving target. I'm on a NENA standards workgroup, and last weeks conference call included a member comment that she didn't appreciate NENA changing the draft standard 3 times while she was working on a statewide provisioning plan. There is finally a stable, published standard, and the next v2 revision will carefully consider the impact on everyone using v1.

NENA plans to write an information doc of guidelines for NG911 GIS Transition, using lessons learned by early adopters (like Jennifer?). There has also been discussion of writing a short "NG911 GIS Data for Dummies" info document distilling the basic concepts in the data model standard doc, for folks like Joe who don't have time to read the full standard.

Thanks for your insights, Joe. If you renew your NENA membership, your perspective would be valuable on a standards development workgroups. If not, take comfort that many who have walked in your shoes are contributing to the standards.

Take away: if you aren't a fulltime time 911 GIS professional, but supporting NG911 GIS data maintenance will be a part of your job, start educating yourself on the subject. MSAG-GIS street name synchronization is one of the first steps. Google NENA 71-501, a 2009 info doc that will be refreshed next year. The process is a basic necessity, long before you consider any GIS data schema conversion. Its complicated, if the GIS analyst who provides mapping updates to a 911 center is not already familiar with the MSAG coordinator. Some local authority must determine if the GIS is wrong and needs edits to match the MSAG spelling, or the MSAG needs edits to match GIS. Dont forget to check street signs and USPS spellings, and request updates by USPS and/or the street sign authorities to get everything in sync.

JonHall · ‎10-06-2018

Aha! Sullivan County. Wish I'd seen your 2014 post, I had some personal involvement with Sullivan County 911 data in the eary 2000s. NYS is much further along in NG911 transition now. Best regards, Jennifer

JoeBorgione · ‎10-09-2018

Jenifer: if you haven't seen this yet, check it out: NENA NG911 street tool

I kringe when I see the letters M S A G; I thought NG911 was finally going to get us away from it, At the call center where I worked, we had an audit and they wanted me to compare my centerline and address point data to the MSAG; not the other way around. Here I was maintaining a modern spatial database that was constantly being updated, and I had to compare that to a spread sheet....