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:
Any help/advice/tips would be greatly appreciated.
Jennifer, did you eventually answer your questions?
-Jon
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...
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.
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
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
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.
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.
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.
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
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....
I know, right? Thank goodness for table joins…
Jennifer D. Stone
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.