VCGI - Your source for Vermont GIS data, information, and events

A.1: The ESITE point features can have “0” address values for three reasons: 1) Zero address ESITE’s with the “Type” attribute equal to “EH” (Fire Hydrant), “ED” (Dry Hydrant), “EP” (Fire Pond), “SC” (Special Comment) or “VC” (Verification Comment) are typically not assigned an address; 2) A new ESITE feature location (i.e., newly constructed structure) added to the data layer is awaiting an address from the town; or 3) Zero address ESITE features within “grand fathered” towns, e.g., those towns adopted conventional street addressing prior to the Enhanced 9-1-1 initiative, their addressing scheme was approved by the Enhanced 9-1-1 Board, and participated in the GIS database development project that included site collection. However, Enhanced 9-1-1 Board is still awaiting feedback from those towns on assigning an address range to the road where the feature is located.

Q.2: When is E-911 data updated?

A.2: The Enhanced 9-1-1 Board receives updates on an ongoing basis from towns. Updates can also be triggered by changes or identification of errors in existing data. Originally, the Board compiled and provided a revised version of the data to VCGI every two months but more recently the update cycle is about twice a year. VCGI will process the data to make it easier for use in a GIS, and check for errors. If no problems are found, the data will then be made available on VCGI’s website and through its normal distribution channels.

Q.3: Why are there fewer data layers available now than before, and fewer data fields in some of those layers?

A.3: Some of the information in previous releases, such as zip codes and apartment numbers, was compiled to assist in notifying residents of their new locatable addresses. Now that this task is complete, such data is no longer kept current, and is therefore not distributed. Some layers were essentially copies of existing VCGI data layers, such as the SW (water) layers, CITIES, and ELEC (electric transmission lines).

Some differences are due to changes in the way the Enhanced 9-1-1 database is maintained. The 9-1-1 Board now updates its database directly using an ArcView-based application known as “E9GIS”, developed by microDATA GIS, Inc. of St. Johnsbury, the contractor which developed the GIS data for the Enhanced 9-1-1 system. Previously, updates were performed by microDATA using ArcInfo. As a result, feature types currently not available in ArcView shapefiles are no longer part of the public dataset. This includes such things as road name annotations (RDAnnnnn) and Road Access Zones (RDEnnnnn).

Q.4: Why were there historically no ESITE points (or road address ranges) for some towns?

A.4: Originally, some towns chose not to participate in the Enhanced 9-1-1 re-addressing and GPS building location program. Those towns still have access Enhanced 9-1-1. However, the Map Display at the Public Safety Answering Point (PSAP) only displays road information,. The E911\OTHER tabular dataset includes TOWNINFO.DBF, which has information about which towns chose this “grandfathered” option. There are 17 towns that originally had no site data available. However, the Enhanced 9-1-1 Board hired microDATA GIS, Inc., of St. Johnsbury to collect site data for these towns. Site data for these 17 towns was added to the Enhanced 9-1-1 Data set in 2004.

These towns were: Bellows Falls, Brattleboro, Burlington, Dover, Fairfax, Groton, Huntington, Ludlow, Lunenburg, Middletown Springs, Milton, St. Albans City, Stannard, Swanton, Vernon, Westford and Winooski.

Q.5: What is the difference between the E911\RDS roads data from the Enhanced 9-1-1 program and the RDSnn roads data from the Vermont Agency of Transportation (both available from VCGI)? Which one should I use?

A.5: For a full review refer to the "Vermont’s Road Centerline Data FAQ". The E911\RDS data layer contains fairly current address ranges for most Vermont towns. The RDSnn data layer contains the most up-to-date road class information. Both data sets may get separate updates to road names, alignment, or new roads, because they are maintained separately by their respective agencies. Data users will need to assess both data sets and decide which is better for a given purpose.

VCGI will continue to work with VAOT, the 9-1-1 Board, and Regional Planning Commissions to develop strategies for data update sharing, now that VAOT and the 9-1-1 board both have standardized data updating systems in place.

Q.6: Will it be possible to obtain Enhanced 9-1-1 data from past years to view changes over time?

A.6: VCGI is creating an “archive” 9-1-1 data set annually from the then-current data. Depending on size, these archive data sets may be available for download or by special request from VCGI.

Q.7: Are all Esites related to the Rds data layer via the RDNAME attribute?

A.7: Yes, with the following exception. There are RDNAME values in SITES.SHP and ROADS.SHP that did not match to the ROADNAMES.DBF (MCODE 540204 & 543312) due to sites on Cedar Island and Neshobee Island that have no roads, but have been assigned addresses.

Q.8: Do Esite addresses start at zero at the town line or continue from an adjacent town, e.g., road segment based?

A.8: It varies in every Town. Some Towns may use continuous addressing consistently, others may begin addressing all roads at Town lines with "0" and still others may use a combination of both methods. You can tell which roads are continuous by looking in the ROADNAME.DBF table in the "startmi" field. If there is a numeric value greater then "0" then that is the distance in miles that the roads starts from the Town line. Further complicating matters, roads that swerve back and forth across a Town line create gaps in the road addressing. This requires the E 9-1-1 Board to identify how long the arc segment gaps are and manage each arc segment that preceeds and succeeds each gap in order to account for the continuous addressing of the road. They are able to store up to four of these "Gap segments" and their distances for addressing purposes.

Q.9: Why are some descriptors in road names inconsistent, e.g., "PVT", "Private", "RT", "Route" etc..?

A.9: Values present in the NAME attribute of the ROADNAMES database represent road names submitted to the E9-1-1 Board by each individual town. These values should follow the "Vermont Enhanced 9-1-1 Board's Addressing Standards." If a submitted road name does not follow these standards then the board alerts the town to remedy the issue. These standards do not address the inconsistent use of certain descriptors, e.g., PVT, Private, Rt, Route etc.. as these decisions are ultimately up to the town. The Enhanced 9-1-1 Board staff priority is to ensure that the road name in the NAME attribute of the Roadnames.dbf matches the road name in the town's Master Street Address Guide, which is maintained by the Board's system provider (Verizon). If there are discrepancies between the two then E9-1-1 staff coordinate with the towns to resolve the variation. This ensures that the Public Safety Answering Point (PSAP) Map Display can locate the road and address when a 9-1-1 call is made.

Q.10: Why are there some RDNAME values with only four numbers while others have seven?

A.10: When microDATA mapped the grandfathered Towns they used four numbers as the rdname numbers in certain cases to avoid duplicating other road name numbers.

Q.11: Why are there no ESITE points (or road address ranges) for some towns prior to 2004?

A.11: The answer to this question is detailed and complex due to the robust nature of the data, the history of assigning addresses in Vermont and the evolution of technology used to represent it. The availability of ESITE and RDS address range information varies depending on a town's "status". Click here for an Adobe Acrobat formatted map of E 9-1-1 "status" by town for the state of Vermont (hyperlink image under construction). A town's "status" was determined between 1997-1998 when the Enhanced 9-1-1 board initiated a GIS assistance project to assist towns in meeting the objectives of the Enhanced 9-1-1 program. A town's decision at this time to participate or not, decided which "status" category they entered. As a result, there were four different "status" categories for town's prior to 2004 when all town's data was completed: "Address Range Only", "Grand Fathered", "Not Grand Fathered" and "Partially Grand Fathered".

Towns without pre-existing addressing information or others that declined to participate in the program were given a status of either "Not Grand Fathered" or "Address Range Only". ESITE and RDS address range information were created for all of these towns with the following exception: towns not fulfilling their responsibility to assign the actual addresses before submitting their data to the Board for approval, only have address range information as a result. These none grand-fathered towns have a "Address Range Only" status. If a town had a pre-existing addressing scheme for the entire town and chose to participate in the assistance program then they were classified as "Grand Fathered". There are four sub-categories for the "Grand Fathered" status described in detail below. If a town had a pre-existing addressing scheme for the village or town center portion of the town only and chose to participate in the assistance program, then they were classified as "Partially Grand-Fathered", e.g., Rutland Town.

For towns without ESITE data, the Board hired microDATA GIS, Inc., of St. Johnsbury to collect the site data. Site data for these towns was added to the Enhanced 9-1-1 Data over time.

Regardless of a town's status there can be valid zero address ESITE's. These can be defined as one of the following ESITE "Types": Fire Hydrant-EH, Dry Hydrant-ED, Fire Pond-EP, Special Comment-SC, and a Verification Comment-VC. All other zero Esite addresses are therefore "invalid" and are being remedied in an ongoing effort by the E 9-1-1 board, subject to Municipal cooperation. The term "invalid" doesn't necessarily have a negative connotation as assigned addresses to recently captured structures can take time and is not always dependant on the E 9-1-1 board, e.g., towns assign the actual address and remit to the board for inclusion in the data sets made available on the Vermont Geographic Information System (VGIS) maintained by VCGI. "Invalid" addresses are in two categories: 1) Building points added in the field without a value yet supplied by the Municipal contact; and 2) All other "0" addresses not assigned during Municipal review during initial data collection.

TOWN STATUS DESCRIPTIONS

· ADDRESS RANGE ONLY - These towns have address range data only and no Esites. Source of data: The range data is derived from the E911 road data.

· GRAND FATHERED: "Grand-fathered" towns are towns that had their addressing scheme approved by the Enhanced 9-1-1 Board and/or participated in the Board's GIS assistance project in 1997-1998. Addresses from these towns do not represent actual mileage. This is almost exclusively true for towns that were grandfathered because they already had some type of locatable address system that was based on an increment value, i.e., 5.28', 25' or 50' (varies by density of buildings). The address would first have to be multiplied by the increment value used in that town, i.e. a town using an increment value of 50' translates 400 Jones Brook Rd. to (400 x 50'/5280' per mile) or 3788 Jones Brook Rd. Another explanation for these type of addresses are that some towns either didn't want large "urban" numbered addresses. The four subdivisions of the "Grand Fathered" status are:

1. ALL SITES GRAND FATHERED - The town status is "grand-fathered". There are geographic site locations, addresses and E911 road data, FOR SOME BUT NOT ALL, areas within the town.

2. ALL SITES GRAND FATHERED W/ NO RANGE DATA - The town status is "grand-fathered". There are geographic site locations, FOR SOME BUT NOT ALL, areas within the town. There is no addresses or road data available.

3. ALL SITES GRAND FATHERED W/ NO RANGE DATA CUSTOM | INCTYPE - The town status is "grand-fathered". There are geographic site locations, FOR SOME BUT NOT ALL, areas within the town. There is no addresses or road data available and the increment value used to create address values is custom, i.e., unique to the town.

4. NO SITES GRAND FATHERED W/ NO RANGE DATA - The town status is "grand-fathered". There are NO geographic site locations or addresses available.

The "zero address values" in ESITES are related mostly to those towns that requested GIS assistance that did not indicate the grand-fathered address for that site. Exceptions would be new ESITE features added in the field where no address was readily available and for fire hydrants. "Zero address values" in grand-fathered towns will require follow-up with the municipalities to resolve. "Zero-length ranges" in RDS pertain to grand-fathered towns that have not provided the Enhanced 9-1-1 Board road segment range information.

· NOT GRAND FATHERED - The town status is " none grand-fathered". There are geographic site locations for all areas within the town, EXCEPT, those currently being edited or for sites that are actually fire hydrants. Both addresses and road data are available.

· PARTIALLY GRAND FATHERED - The town status is "partially grand-fathered". These towns generally have two categories within them: 1) The village or town center areas are completely "grand fathered" as they already have an address system that allows for some degree of locating sites; and 2) Rural areas served by the "rural route" postal category. The latter are not "grand fathered".

Q.12: Why are there ESITE points with RDNAME = 0?

A.12: Some of the pre-ArcSDE versions (pre January 2007 ) of ESITES data have records with RDNAME = 0. These are predominately EITES with TYPEs equal to P7 (Fire), P9 (Ambulance), P6 (Police) and PS (PSAP - Primary Service Area Provider). The issue is that many of these records had both addresses and road name values in the pre-ArcSDE versions of the data. So what happened? The insight from 911 revolves around updates made to their new (ArcSDE) based system. Whereas, these features used to reside in the ESA feature class of the previous shape file based system, they now reside in the ESITE data of the new system and are temporarily considered to be "orphaned ESITES with a relationship to the agency name that once defined them." the 9-1-1 board is currently in the process of editing these and once the transfer of information from the ESA features to the corresponding ESITES features is complete the ESA data layer will be retired in order to represent the data in a single feature class.

Q.13: How is the "Interim" data delivery format different from the earlier one?

A.13: The migration of Enhanced 9-1-1 data to ArcSDE in 2006 has impacted both the schema (attribute names/definitions) and content (record values) of the current output "interim" delivery format when compared to the original delivery structure (12/13/05 and prior). E 9-1-1 and MicroDATA are be working on a new formalized data delivery format. Until that time the "interim" format will apply. The first ArcSDE release was January 2007.

To minimize the effects of these changes on customized applications and day-to-day efforts that affect both developers and users alike, the following explanations and resources are available:

1) Details on the changes between the original and interim delivery formats are listed below in the “SUMMARY OF SCHEMA AND CONTENT CHANGES” section;

2) Three tables (provided by E 9-1-1) that address the content changes, i.e., updated record values, of the “Arcid”, “Rdname” and “Siteid” attributes that provide a "cross reference" between the "old" values (the 12/13/05 data delivery and prior) and the "updated" values (the 1/16/07 and future interim deliveries). See “CROSS REFERENCE TABLES” section below.

The most interim deliveries have slight differences in both the schema (attribute names/definitions) and content (record values) than the older deliveries that may affect custom applications and impact developers and users alike. These current changes are temporary and should not be used to guide developers in updating their applications, however permanent changes are likely. The schema changes between the interim and older data layers are minor, e.g., fields are still either numeric or character but may be of different widths but there are some content changes, e.g., “Arcid”, “Rdname” and “Siteid”. These changes are a result of data being exported from the updated SDE database while trying to maintain, as closely as possible, the structure of the old data deliveries. This was a "stop gap" measure to end the long delay in data deliveries.

Ultimately, both the schema and content of the older and interim deliveries will be superseded by ones established in an updated data exchange agreement between VCGI and 9-1-1 currently under development.

An example of the content changes is the SITEID field in the ESITES data layer. A user pointed out that his custom application no longer worked with data in the 1/26/07 release and upon further inspection, observed that the record values in the SITEID field appear to have changed. An explanation from 9-1-1 follows:

...the ESITE “Siteid” field values have in fact changed between the most recent and all previous deliveries. The reasoning is pretty straightforward in that is was an opportunity to clean up the band-aid upon band-aid scenario from the past - "We have reassigned ID's to every feature in the data set so there will be some translation changes that the users of the data will have to conform too. The conversion was a perfect opportunity to clean up the feature ID's in their entirety. There was a mish mash of different types of ID's in the past and I wanted to make them all numeric and sequential."

NOTE! Regarding the last statement "...all numeric and sequential" - the SITEID field in the Jan. 07 delivery was in fact of Character type because 9-1-1 was trying to mirror the specifications of earlier deliveries as previously noted. This is only one example of the differences that may come to light once the updated data exchange database is defined.

CROSS REFERENCE TABLES

While the content of these tables will not change in the finalized dataset, the schema will. Therefore, the schema of these tables only applies to the cross-reference between the "old" and "interim" data delivery formats, not the future ones. For both the "Rdname" and "Arcid", the names will change to "Geonameid" and "Streetid", respectively while remaining of character type, though with greater width. For "Siteid", the name will change to "Esiteid" and the definition will change from character to numeric permanently. Additional posts to VGIS-L will be provided once the new schema is available. These three tables have been added to the EmergencyE911_OTHER layer: 1) siteid _crossref .dbf; 2) rdnameid _crossref .dbf; and 3) arcid _crossref .dbf and VCGI highly recommends downloading the updated file. The tables address the updated values for the Siteid, Rdname and Arcid attributes, respectively.

Cross Reference Table	Historic Values	Updated Values	Update Notes	Data Affected

siteid _crossref .dbf	Old_Siteid	Siteid	All Siteid's recalculated to numeric, unique ID's . "Siteid" will be renamed "Esiteid"	ESITES, RDS
rdnameid _crossref .dbf	Old_Rdname	Rdname	Old and new attributes both numeric. "Rdname" will be renamed "Geonameid"	RDS, Roadnames.dbf, ESITES
arcid _crossref .dbf	Old_Arcid	Arcid	Old and new attributes both numeric. "Arcid" will be renamed "Streetid"	RDS, Roadnames.dbf

SUMMARY OF SCHEMA AND CONTENT CHANGES

Comparison of the previous (12/13/05 and older) and interim (1/16/07 and later) Enhanced 9-1-1 data deliveries.

==> File definition for dw.aat

OK: File matches template definition.

==> File definition for esa.pat item

CODE,8,9,F,0 used to be CODE,4,4,B,0 in esa.pat item

UPDTSRC,20,20,C,0 used to be UPDTSRC,3,3,C,0 in esa.pat item

UPDTDT,10,10,C,0 used to be UPDTDT,7,7,C,0 in esa.pat

==> File definition for esz.pat item

MCODE,8,9,F,0 used to be MCODE,4,3,B,0 in esz.pat item

UPDTSRC,20,20,C,0 used to be UPDTSRC,3,3,C,0 in esz.pat item

UPDTDT,10,10,C,0 used to be UPDTDT,7,7,C,0 in esz.pat

==> File definition for landmarks.pat OK: File matches template definition.

==> File definition for rds.aat Error:

Number of items (30) has changed (used to be 26).

==> File definition for sheets.pat item

MCODE,8,9,F,0 used to be MCODE,4,3,B,0 in sheets.pat

==> File definition for esite.pat

Number of items (17) has changed (used to be 16).

==> File definition for roadnames.dbf item

MCODE,8,9,F,0 used to be MCODE,4,3,B,0 in roadnames.dbf

==> File definition for esn.dbf item

MCODE,8,9,F,0 used to be MCODE,4,3,B,0 in esn.dbf

==> File definition for esadata.dbf item

UPDTSRC,20,20,C,0 used to be UPDTSRC,3,3,C,0 in esadata.dbf item

UPDTDT,10,10,C,0 used to be UPDTDT,7,7,C,0 in esadata.dbf

Q.14: Why are there differences between “Villname” or “Townname” field values in the VGIS BoundaryOther_BNDHASH layers and equivalent values in the ESITEs “Newcitst” field?

A.14: All of the differences in the “Newcitst” field are purely for 911 purposes. These are Town names that are in the ALI (Automatic Location Identifier) database and also in the ALI MSAG (Master Street Address Guide). E 9-1-1 created that field to accommodate both. The GIS data needed to reflect what is in the ALI identically so there is a field that incorporates the “Virtual Town” names and upon export pulls the spelling that is in synch with the ALI database. The “Newcitst” Town names also have there own unique ESZ’s Emergency Service Zones which is an area that is covered by a unique combination of Emergency Service Agencies, (LAW, Fire, and EMS). They are a combination of actual Town name spelling differences and village names. The following list may not be complete:

E911 Newcitst
"BNDHASH_towns Townname"
AVERY'S GORE
AVERYS GORE
BUEL'S GORE
BUELS GORE
ESSEX
ESSEX JUNCTION VILLAGE
ESSEX
ESSEX TOWN
NORTH BENNINGTON
BENNINGTON (village)
ORLEANS
BARTON (village)
ROCKINGHAM
BELLOWS FALLS VILLAGE
RUTLAND TOWN
RUTLAND
SAINT ALBANS CITY
ST. ALBANS CITY
SAINT ALBANS TOWN
ST. ALBANS TOWN
SAINT GEORGE
ST. GEORGE
SAINT JOHNSBURY
ST. JOHNSBURY
SAXTONS RIVER
ROCKINGHAM (village)
WARNER'S GRANT
WARNERS GRANT
WARREN'S GORE
WARREN GORE
WEST PAWLET
PAWLET

Q.15 How are ESITES physically located, e.g., by the front door, end of driveway, corner of building, center of building, etc. Are there a variety of methods employed?

A.15: The final goal of representing an ESITE is the centroid of the structure, however, there are two primary caveats: 1) Location accuracy reflects the technology available at time of location capture; and 2) The location of a new site is initially estimated at the intersection of the driveway and road or via orthophotos as a general navigation point for the field crews to acquire the final position. These records have a corresponding “GPSFLG” field value of “y”, i.e., location verification required. Older site records were generally located using manual GPS “offsets” that estimated a location based on the physical location of the GPS and manual bearing and range (distance to the feature) values. In the latter case accuracy degrades over distance.

Q. 16 Does a statewide “cross tab” table exist that correlates the old address format, i.e., RR #1, and their new 9-1-1 address?

A. 16: Not at the state level. These may exist on a town-by-town basis and each town would have to be contacted individually.

Q.17. How is TYPE determined, e.g., assessed in the field, via town grand list category?

A. 17: It is based on the town supplied value, but if the town did not (or has not yet) supplied the 9-1-1 with a value then by default TYPE = “R1”, i.e., single family home.

Q. 18 Can the MAPYEAR attribute values be used to track development patterns across the state, i.e., when structures were built or changed?

A. 18: The “1899...” and “1900...” values that make up a majority of the unique values are likely past “Y2K” related errors. Values of “20020211” and later reflect the date that a point was field verified by 9-1-1. For 2007 and later the date of actual construction (unknown) and the date is was field verified (MAPYEAR) are accurate to within a few months. In previous years the association is not as close and cannot be stated other than to say that once towns notified the board the site was field verified as quickly as resources allowed.

Q. 19 Is it possible to do statewide “Time Series” analysis using the historical 9-1-1 datasets?

A. 19: Not exactly! While its tempting to use the 9-1-1 datasets, especially the ESITES data, as a proxy for certain types of analysis like historic development patterns and updating Land Use/Land Cover data etc. there are a number of issues to consider first. Regardless, it is simply not possible to compare some of the earlier data releases with later ones due to voids in some of the older data, i.e., “grand-fathered” towns. The evolution of the Emergency 9-1-1 program, changes in technology and the nuances of Vermont’s town-based form of government all play a part in explaining why data from one “snapshot” isn’t always identical, in structure or content, to another. The following is a list of the primary evolutionary milestones that would affect any time series analysis. This is not necessarily a complete list and other issues may also be relevant:

Grand-fathered towns;
Procedural issues;
Conflation with the Automatic Location Identification (ALI) database; and
Migration to Spatial Database Engine (SDE).

Grandfathered towns: April 6, 2004 - This marks the first truly “statewide” release where all “Grand-fathered” towns are represented in the 9-1-1 datasets. Prior to this date, the towns may have only had data for the village area within the town, the town area outside the village or no data at all due to this issue. Conducting a time series analysis with data before and after the April 2004 on "Grand-fathered" towns would be erroneous. See FAQ “ Q. Q.1: Why do some ESITE points have a “0” address? “ for what constitutes a “grand-fathered” town ”.

Procedural Issues: (Ongoing) - Throughout the history of data collection and update efforts, changes are not always reflected in the subsequent data release and can sometimes show up all at once or metered out over time. One reason is that Towns, in addition to their myriad responsibilities, are also responsible for assigning road range values and ultimately the 9-1-1 addresses themselves. Depending on town resources and diligence these efforts can take time, impacting the timeliness of data integration with the statewide databases. One example of a delayed update was in 2004 where a concerted effort by MicroDATA to capture outstanding Esite features resulted in a sizeable increase of blank Esite address records as the addresses couldn't be assigned until the town provided road range data to the board. This can affect the accuracy of time series analysis when using historical data.

Conflation with ALI Database: September 23, 2005 - As of this release, the 9-1-1 data contains refined ESITE addresses and RDS range data etc. resulting from "bumping" the GIS database , i.e., ESITE addresses and RDS range data etc., up against the Automatic Location Identification (ALI) telephone address database. This effort identified 9-1-1 addresses that were originally assigned incorrectly when compared to the "true" spatially assigned address. These records were listed in Unmatched Address Reports (UARs), and forwarded to the respective towns for their remediation. As a result, the updates are not reflected in data releases until they are returned to the E 9-1-1 board and this can happen in large blocks or over time. In any case, this issue can affect comparative analysis involving derivative datasets that are generated by geocoding/address matching.

Migration to SDE: January 16, 2007 - With the migration of the 9-1-1 databases into the ESRI Spatial Database Engine software, the database schema changed to an “interim” data schema and key unique identifiers were reset. The schema has yet to be finalized as of the Sept. 2008 release. Issues relating to the interim format have been integrated into the 9-1-1 FAQ page under Q. 13 "How is the "Interim" data delivery format different from the earlier one?" Cross-reference tables that translate the new and old SITEID, RDNAMEID and ARCID values (siteid _crossref .dbf; rdnameid _crossref .dbf; and arcid _crossref .dbf) are packaged in the latest “EmergencyE911_OTHER” data layer. This issue can affect analysis based on these “key fields”.

Historic Values

Update Notes

Data Affected