It's All about Streets
Tips and tricks for obtaining, building, and maintaining time-based network streets
By Mike Price, Entrada/San Juan, Inc.

This article as a PDF .

Editor's note: Mike Price has been a regular contributor of articles on creating models with GIS since this magazine's inaugural year. Over the last two years, he has authored a series on modeling street network data for public safety applications using the ArcGIS Network Analyst extension. In this article, he shares the data requirements for this type of modeling and tips he has discovered over the years for enhancing and managing those datasets.

It's often said, "Time is of the essence." This is certainly true when it comes to modeling networks for public safety response.

I now believe that finding/creating and supporting an accurate, reliable street network is the single most important part of building and using any public safety model. Unfortunately, locating or creating a network-ready street set that is current, is complete, and contains the necessary attribution is not easy.

Here are some tips and tricks that I use to find, enhance, and maintain a quality network street dataset. If you are new to modeling networks with ArcGIS Network Analyst or would like a refresher course on time-based response modeling, visit the Learn How to Model Networks page.

When I model networks, I may use one of four different street data sources: simple Census TIGER streets, StreetMap in the Esri Data & Maps DVD set that comes with ArcGIS, commercial network products, and customized datasets that are often built by a local jurisdiction or its GIS partner. Here is a brief summary of these data types.

Census TIGER Streets

TIGER streets, part of Census 2000 TIGER/Line Data, is a free source for streets. County TIGER streets may be downloaded from Esri's Free Data Web page (www.esri.com/freedata). The Census 2000 TIGER streets are outdated, and I'm waiting for the Census 2010 update. TIGER spatial geometries are approximate and they do not directly contain time impedance. The Census Feature Class Code (CFCC) may be joined to the streets to obtain typical speeds. For an early tutorial on using Census TIGER streets, see "Taming TIGER Data."

Esri Streets

For years, Esri has provided StreetMap in Esri Data & Maps, which ships with ArcGIS. To see these streets, locate the StreetMap DVD on a current Esri Data & Maps DVD set. These streets do include speed limits but compare this information with local signage. You may want to clip your favorite areas and save them as shapefiles or file geodatabases. Esri also sells StreetMap Premium (www.esri.com/data/streetmap), which provides streets that readily support geocoding and routing. Point-to-point routing is also available through the ArcGIS Online routing service.

Commercial Streets

Tele Atlas/TomTom and NAVTEQ are the two major commercial network street providers in North America. Commercial streets are available by subscription and include periodic updates. Vendors of street data also encourage users to provide current content.

Tele Atlas/TomTom provides digital maps and dynamic content that power essential navigation and location-based services. The company provides several products, including its MultiNet geocoding and routing dataset. MultiNet streets incorporate a full suite of capabilities, allowing users to locate the people and services they need quickly; reach their destinations via safe, reliable, and customizable routes; and use the clearest, most visually compelling maps available. Check out the MultiNet streets at www.teleatlas.com/OurProducts/MapData/Multinet/index.htm.

NAVTEQ provides high-quality street data to partner developers that incorporate it into many applications. Visit NAVTEQ Map online at www.navteq.com or contact NAVTEQ and find a partner vendor that can provide data for local needs.

Custom Street Datasets

Local agencies often create their own street centerline and travel lane data using a variety of sources including orthophoto digitizing, GPS data collection, and engineering drawings. These datasets are typically customized to meet local needs. They may be good for either geocoding or networking, but not both. Since they are supported locally, work with these providers to extend the capabilities of these datasets. To see several local datasets, check out the article, "Do It Yourself—Building a network dataset from local agency data" and "Managing Volunteer Firefighter Response—Using the OD cost matrix to model personnel availability".

Enhancing Street Data for Networks

Here comes the really important stuff! When you are sourcing (or have already obtained) a street dataset, what important network issues should you address? In a recent ArcUser article, "Do It Yourself—Building a network dataset from local agency data" (referenced above), I introduced several important issues you should consider when preparing a dataset for network modeling. Here are key issues that can be tackled by spatial and attribute editing.

Impedance—Distance

To properly calculate travel time, you need accurate distances. In a well-defined and documented model, distance-based impedance is easy to calculate. If your streets are registered in a standard projected coordinate system, you can readily calculate and verify distances between intersections in the native coordinates. If you are careful, you can calculate distance in a geographic data frame or across the metric/imperial measurement divide.

I use a field named Length_Mi to store travel distance. Since this is not a reserved field name, you must specify this field and its units when you build a network. I do not use the field name Length, as I often store length in multiple units of measurements (both metric and imperial) and certainly do not want to confuse these systems. As you edit your network dataset, recalculate segment lengths frequently, especially before you rebuild a network.

Impedance—Speed

A reliable time-based impedance (or speed) field is essential. Many agencies start with posted or ordinance speeds and factor them up or down, depending on policy, persistent travel constraints (such as slope and turn radius), and variable travel factors (weather, traffic, and disruptions, to name a few). Measured travel times allow a user to fine-tune speed-based impedance. Once directionality and connectivity issues are resolved, the segment length in miles and travel time in minutes can be calculated. If you use a field named Minutes, Network Analyst will recognize it immediately. Remember to recalculate segment length, then travel times on all street segments (or at least the ones edited) each time you finalize an edit session and before you rebuild your network. Be sure to edit or remove all zero-time segments in the dataset before you rebuild.

Crossing Relationships

Overpasses and intentionally nonconnecting crossings are two of the most difficult and important issues to address. Commercial streets use an integer code or Z elevation/Z level to manage crossing geometries. The Z elevation fields (from and to) specify whether traffic may turn at an endpoint intersection. To turn or traverse through an intersection, the endpoint of the traveled segment must match the start point of the new segment. Most simple networks will use only Z values of 0 and 1. However, a Los Angeles County commercial dataset that I recently modeled included Z elevation values up to 4. If you add new streets to a dataset that uses Z elevations, be sure to correctly populate this field.

A simpler way to manage crossing relationships, especially streets not also used for geocoding, is to build nonintersecting crossing geometries and apply endpoint connectivity. These streets are much easier to edit and visually inspect, and they perform much better if you are using lidar terrain to define slope impedance.

Connectivity

Connectivity defines how an individual element in a network relates to its neighbors. Simple connectivity options include endpoint and any vertex. I strongly recommend that you use endpoint connections. See Crossing Relationships, in the previous section, for more information.

Simple single-layer networks must have exact endpoint connections to function properly. I find that nonconnecting segments are the most common issue that will cause a network to fail. Use visual inspection, polyline topology, editing, and/or old-fashioned trial and error to define, repair, and maintain connectivity.

If you use a multimodal network that includes several feature classes, connectivity between participants is defined with special rules. Remember that you must place all participating feature classes in a single feature dataset to build multimodal models.

Directionality

Travel direction is critical when modeling one-way travel on divided highways, boulevards, one-way streets, and even individual travel lanes.

When streets are digitized, the digitizing direction creates an underlying street direction. To manage travel along or against this direction, a two-character text field named One_Way provides an effective way to flag travel direction relative to digitizing. Simple FT (from-to) and TF (to-from) codes define the course along and against the digitized direction. To check directionality against digitized direction, place small arrows at the terminating end of the street segment. Code a selected segment FT if travel is along the elements direction; use TF if travel opposes. In an edit session, also watch for the segment's red endpoint; it also represents the terminating end.

If your street network will not support address geocoding, you may also flip the street direction to reflect actual travel. Again, check out "Do It Yourself—Building a network dataset from local agency data" to learn this workflow. If you do use streets for geocoding, you may still reverse its direction, but you must reassign the left/right to/from values to respect the new orientation. This difficult task requires attention to detail, and I do not recommend it for beginners.

When you build a network dataset, Network Analyst will recognize the One_Way field and create the appropriate rules. When using the network, you will have the option to globally turn the One Way property on or off.

Turns and Turn Relationships

In a time-based network, turns and intersection slowdowns are very important. Global turns may be quickly applied throughout a network. As you build your network, use actual field times to calibrate them throughout your jurisdiction. You will probably find that travel times under constant low volume will vary slightly throughout your area. Experiment with global turns to achieve a best average. Field testing is described in "Convincing the Chief—Proving that time-based networks really work," an article that appeared in the Spring 2009 issue of ArcUser and that is also available from the Network Modeling, Learn How to Model Networks Web page. These Hands On articles build skills.

If you want to model individual turn penalties for many or all intersections, you can create individual rules for all intersections. This is a complex procedure that I do not recommend for people who are new to working with networks.

• Don't Give Up
  Stay with it. As you refine your network, you will be amazed with the possibilities. Building a reliable time-based network is not an easy task, and tuning and maintaining it are even tougher. Do not be discouraged. There are probably many potential partners in and around your jurisdiction that might want to help. In addition to finding some help in creating and maintaining your network data, here are some strategies for making the job easier.
• Start Small
  Build a small network in an area that you know well. Experiment and tune it to match field tests. Carefully watch how the network behaves as you build small service areas and test routes. If impedance, connectivity, geometry, and travel direction misbehave, practice fixing and rebuilding them. Test, and test, and test!
• Think Big
  Ultimately, your network will probably support the response efforts of many jurisdictions. Talk to your neighboring jurisdictions and develop partnerships. Collectively decide to obtain/create and maintain just one network dataset.
• Keep Both Eyes Wide Open
  Continually monitor your network's behavior. Repair problems individually or in small groups. Rebuild and retest problem areas. Do not be discouraged if fixing one problem just reveals another.
• Document Your Work
  Develop a method to track edits and network builds, especially when adding new segments and modifying attributes. When you build the network for the first time, before you click the Finish button, save your parameter summary to a text file with a date stamp. If you ever have to present and defend your work, you will be glad you did. I have presented network models to the legal community, and this information is priceless.
• Back Up and Try Again
  Occasionally, a network dataset becomes quirky or even corrupt. Do not hesitate to delete the problem set and rebuild using the same parameters. If you use a standard naming convention, you might be able to reuse the same dataset in an existing ArcMap document. Be very careful with this, though. You might have to remove the repaired dataset from an existing ArcMap document and rebuild all the solvers. I have had mixed success with replaced datasets and consider the jury to still be out on this strategy.