A Guide to Managing and Maintaining the Street Centerline File for Johnson County

Why Read This?

The purpose of this report is to document the creation, maintenance, and attributes of the street centerline file. Methods and processes for maintenance will be explained in order to keep the file accurate and up-to-date. The countywide street centerline file was developed in the fall of 1994 with the coordination of MED-ACT and AIMS. Its uses are many. Anything from school district boundaries, to vehicle routings, to address matching applications are benefiting by this countywide file. The maintenance of this file is critical to its continued value.

The most important thing to take away from this document is:

If you find any discrepancies or errors while using the street centerline file or in viewing maps or presentations that contain the street centerline file please contact AIMS or email .

Who Should Read This and How Will It Help You?

This information is for use by the AIMS, its partners and others who have a need for communicating or using information related to streets and addresses in Johnson County. The street centerline file has uses ranging from emergency dispatch, and real time vehicle routing and tracking, to public information systems and many others. The benefits of a standardized, countywide street centerline file are numerous.

The following have been identified as possible users of the street centerline file. Anyone working in one of the occupations below should be familiar with this report. Their familiarity and participation will assist in making this the most accurate file possible.

• Planning
• Engineering
• MED-ACT
• Police
• Fire
• ECC
• Emergency Mgmt.
• Pavement Management
• Map Sales
• Internal Mapping Analysis
• Routing Snow Plows, Delivery vehicles, Maintenance Crews, Bus Routing
• Schools
• Election Commission
• Dispatch Services i.e. utility companies
• Permitting Applications i.e. utility companies
• Address Assignment
• Public Kiosk and/or Internet/Intranet Applications

How Was the File Created?

The street centerline file project was started in 1994. Analytical Survey Inc. (ASI) from the planimetric coverages provided the file's original creation. Subsequently, heads-up digitizing and plat centerline arcs were copied into the street network file to fill in areas built after the planimetrics were flown.

Topology errors were corrected, street names were added and classification codes for street type were added. Since that time the arcs in the file have been maintained by the AIMS staff receiving information about changes from many sources. Primarily changes have been provided from an individual in Med-Act who distributes hand drawn changes to the maps and copies them to their vehicle drivers. Most recently steps were implemented to provide Med-Act drivers with AIMS maps showing the streets and parcel boundaries to emphasize areas of new development.

Address ranges were the next step to enhancing this file. A county-wide parcel point coverage was used with the Arc/Info NEAR command to identify arc segments closest to each parcel centroid. The parcel centroid road NAME was then compared with the centerline road NAME and DIRECTION AND TYPE were compared. A score was assigned to each arc and any score not matching the specified range had to be manually checked and corrected. An Arc/Info routine provided by Black and Veatch was used to assign the initial address ranges to each arc. These address ranges were then "massaged" to meet specific criteria. Address matching was performed using the 911 intersection data for further quality control. Overlapping ranges, missing or incorrect road names, missing address ranges, and verification against the countywide address point dataset are added as part of the ongoing QC process.

Accuracy

The street centerline file has an estimated spatial accuracy of + or - 5 feet on 98% of the arcs. The other 2% are road modifications like widenings or relocations that aren't well documented. The tolerance on these are estimated at + or - 10 feet. This information is based on our partners’ experience using the file and information that Blue Valley School District provided where they had actually done some field checks, for bus routing purposes and found the file to be very accurate. It is the goal of the AIMS project to maintain this accuracy and to work towards 100% accuracy.

The attribute data accuracy is dependent on the attribute item. Currently address ranges are estimated to be 80% accurate, speed limits are only 70% accurate. Road_name, oneway, minutes, f_elev and t_elev are estimated to be 80% accurate. These percentages will increase over time as more people access the file for their applications and report inaccuracies, errors or omissions.

File Maintenance Methods and Processes

This section will focus on giving general descriptions to the overall street file maintenance as well as some specific information regarding who to contact, and why certain things are done.

Communicating updates

"StreetInfo" is a generic email, courier stop, and post office address that is managed through AIMS. Information can be sent to "StreetInfo" via:

• Email:
• Inter-County courier: Name - StreetInfo Department - DTI-AIMS
• U.S. mail address:
  Johnson County AIMS
  111 S Cherry St, Ste 3100
  Olathe, KS 66061
  Attn: StreetInfo

Streets from Plats

The County Clerk’s office digitally re-creates the plats by using coordinate geometry for incorporation into the AIMS datasets. The centerlines of these plats are then added to the centerline file by heads up digitizing what looks like the centerline in any of the Right of Ways. Attributes for these centerlines are then added based on what the plat says, and some review processes.

The arcs heads up digitized because the original method of construction, coordinate geometry of the parcels, does not fit with the topology in the published street centerline file. In a plat every road can be many arcs that make up a section of street. In the published street centerline file, there are fewer individual arcs that make up a road. For additional information on the process of adding arcs to the street centerline file please contact .

Streets in new plats are being entered into the file as soon as the property is entered, however they are coded as unbuilt until they are confirmed as built. Public Works uses a database that tracks new plats being filed, the city in which the plat will be built, and the road names in the plat.

December 1 every year a letter is generated by Public Works for the respective cities, asking them to confirm if the roads listed in the letter had been built or not. This letter will ask that the cities respond to "StreetInfo" mail stop and ask for confirmation that the plat was finished and that all the streets within the plat have been built. If the city responds that it is built then an inspection is done of the street centerline file to be sure it was added. Any changes in the plat from the time it was filed should be reported back, especially road name changes. On top of this AIMS works with a contact in the Med-Act office to visually confirm whether streets have been built or not, and to confirm the names with any street signs that may be present also.

"StreetInfo" will copy Public Works with the responses and see that the roads are included in the street centerline file with the appropriate attributes. This information will be incorporated into the street file by mid-January. This is to allow Public Works adequate time to produce their County Engineer's Road Map by the end of January.

Realignments and Road Improvements

Currently, Overland Park submits letters to MED-ACT and others with street update information. These documents include address changes, road name changes, etc.. The information is extremely valuable and other cities maybe doing something similar. Our goal is to have all the cities provide the County with the same type of information. This information should be sent to "StreetInfo". At this point copies will be made and provided to MED-ACT and others within the County who have an interest. This information is then used to update the street centerline file.

The current process of obtaining street data from MED-ACT will be continued. Presently, crews have pages of a map book assigned to them to check at least twice a year for accuracy. This equates to approximately a page a week from each crew. The pages with corrections are then turned in to the mapping staff in MED-ACT who gives copies to AIMS. A method will be put into place to assure us that the checks are being done on a regular basis. Right now there is no follow up. Each crew understands the importance of knowing the status of their service area. Therefore, it is assumed that each crew is acting responsibly, reporting any changes to the mapping staff and to actually check their service area at least twice a year.

Road Closings

MedAct is informed of all road closings in Johnson County. They will copy StreetInfo with this information in order to update the street centerline file.

Attributes

This information will be as accurate as you and the other users want to make it. Submitting changes and corrections to StreetInfo is the county’s primary source for getting updated information. This is an ongoing process and we solicit everyone’s help in identifying incorrect or missing data. The other source of getting updated information is through the Address Point Dataset. The county has scripts that run nightly to basically verify that all of the address points in the county fall within the address range on a street segment, and that they are named exactly the same.

Annotation

Annotation in the street centerline file is important because it is the method for effective communication of street names in map display. Adding annotation to the street centerline file is limited to a couple of individuals who have had a great deal of experience in determining effective/efficient placement of road names on the arcs. Past experiments with allowing multiple editors resulted in inconsistent editing which at times had big impacts on the cartographic and topologic characteristics of the street centerline file. There are many aspects to adding annotation that have to be considered for example annotation needs to be added in a manner consistent with the direction of the arc.

The level to which the annotation is added affects the display and usefulness of the annotation. The level of the annotation in most cases corresponds with the classification assigned to the road such as 10/local, 20/collector, 30/thoroughfare, and 40/highway. Additional annotation is added to arcs at a level of 11, 21, 31, or 41 to accommodate Med-Act's need for maps that display every arcs street name. A couple of other Annotation Levels are being updated for Med-Act’s needs, 12-Address Ranges, and 13-Notes. Unlike some general use maps that only need a majority of the roads annotated for cartographic display, Emergency Services cannot afford to miss a street because it was not displayed on the map to make it look appealing.

Street Centerline File Publishing

The updated street centerline file is copied to the published directory every Friday evening by the AIMS staff. It can be published more frequently if the need arises. This schedule corresponds with the updates to the property attribute files and is sufficient for the centerline file’s current uses. The file is published as part of AIMS weekly scheduled data publishing processes. The Centerline file is currently being edited as SDE Geodatabase Feature Classes with some custom tools in the current version of ArcMap. The goal is to have the file updated daily when real time access and/or tracking is necessary.

What Happens in the ArcMap Code?

Whenever a centerline segment is added, updated, or modified, the code runs through some different modules that calculate specific attribute fields. When a new segment is added, the code assigns it a UNIQ identifier based on the date and time it was entered. The UNIQ also uses a two digit random number to ensure that it is not duplicated. Altough this can produce duplicate UNIQ’s, the chances of two people entering a segment at the same second and getting the same random number is reasonably small. Also the Modified, Date Added, Minutes, Miles, Left and Right City, State, Zip, and County fields are automatically calculated/updated. The ROAD_NAME field is automatically re-concatenated when any of the parts are changed.

Database Design

The following are the items that make up the info table for Centerline_LN:

The following section defines the possible values that can be found in each of the items of the Centerline_LN file:

SUB_CLASS: This is a method for classifying the roads into certain categories. An attempt was made to design the classification scheme in order to meet the needs of the majority of our partners. This breakdown is the result:

ST_STATUS: The current purpose of this item is to identify streets that have been Build or Unpaved versus Unbuilt roads. 95% of the arcs in the centerline file are coded as built. The Classification Unbuilt is used mainly for display purposes to allow users to see that there is a planned road that will be there, but it is not drivable as of yet.

PREV_UNIQ: The unique number previously assigned to an arc before it was modified

UNIQ: A unique number that is assigned sequentially to the arcs. This number is provided for analysis purposes and to link the arcs to external databases for uses such as pavement management.

ROAD_NAME: This item includes the entire road name for an arc such as: W 132^nd St or N Lakeshore Dr E.

PRE_DIR: This item is populated with the first direction of the entire street name. In the examples above under ROAD_NAME the PRE_DIR is W and N. The possible values are N, S, E, and W

STR_NAME: This is the name of the street only. In the examples above this item is populated with 132^nd and Lakeshore

STR_TYPE: This identifies the type of street. In the examples above this would be St and Dr. The possible values are AVE, BLVD, CIR, CT, DR, HWY, LN, PKWY, PL, RD, RDWY, ST, TER, and WAY.

SUF_DIR: This field is not used often, but in the example of N Lakeshore Dr E the E is the SUF_DIR. The possible values are N, S, E, and W.

L_ADD_FROM: The address assigned to the left side of the beginning of an arc. This field is used for address matching and matches the naming convention in Arcview. See Illustration 1 for an example.

L_ADD_TO: The address assigned to the left side of the end of an arc. This field is used for address matching and matches the naming convention in Arcview. See Illustration 1 for an example.

R_ADD_FROM: The address assigned to the right side of the beginning of an arc. This field is used for address matching and matches the naming convention in Arcview. See Illustration 1 for an example.

R_ADD_TO: The address assigned to the right side of the end of an arc. This field is used for address matching and matches the naming convention in Arcview. See Illustration 1 for an example.

Illustration 1 - Left and right address range examples for from nodes and to nodes.

ONEWAY: Streets that are one way in nature. (For example: highway ramps).

Values:
FT - Direction goes from the FROM-NODE to the TO-NODE.
TF - Direction goes from the TO-NODE to the FROM-NODE.
N - The segment is closed to either direction.
2 - The segment can be traversed in either direction.

SPEED: A number that represents the speed limit of a street. If it is a new segment this is a best guess based on each segment’s classification, these may be updated if needed by submitting the change to StreetInfo. All new street segments have a speed assigned to them using the following schema:

It is our goal that posted speed limits will be assigned to arcs in the future, but this is the type of information we would need to have sent to us by you. Any method you have for identifying posted speed limits would be useful to us. Please send this information to StreetInfo.

MINUTES: The time it should take to traverse the segment based on LENGTH and SPEED. The time is stored as decimal minutes; thus, 30 seconds is represented as 0.50.

F_ELEV and T_ELEV: A value of 0 or 1 is assigned to the node at either end of an arc. This coding helps to identify segments that pass over other segments (i.e. overpasses) in networking applications. This tells the Network Analyst application that it can't get off of an arc with a node value of 0 and move to an arc that has a node value of 1. The following diagram illustrates how values would be assigned for an overpass:

Illustration 2 - F_ELEV and T_ELEV node assignments.

ST_CLASS: This is a redefined item for Arc/Info users. It is derived from SUB_CLASS.

L_CITY and R_CITY: Arcs are not broken at city boundaries, unless requested. However, city names are added to each arc. Whichever city spatially contains the center point of the arc with an offset of two feet Left and Right will be assigned to the arc. If the arc is primarily in the unincorporated area of the County (not in a city), then the value of County is assigned to the arc. The following are the possible values to be assigned to each arc:

• Bonner Springs
• County
• DeSoto
• Edgerton
• Fairway
• Gardner
• Lake Quivira
• Leawood
• Lenexa
• Merriam
• Mission
• Mission Hills
• Mission Woods
• Olathe
• Overland Park
• Prairie Village
• Roeland Park
• Shawnee
• Spring Hill
• Westwood
• Westwood Hills

L_ZIP R_ZIP: Zip code attributes are assigned to the arcs in a manner similar to city name. The following are valid values:

MODIFIED: This item was added after the street file was originally created. It is used for historical tracking, change analysis and for recovery purposes. All arcs existing at the time the item was added were given the value of 11-2-97. Whenever a segment is modified or updated this date is populated with the current system date.

Any Questions?

Should you have additional questions concerning the Street Centerline file please contact AIMS or email .