Recently I encountered my first network dataset. This is a special file created by, and meant to work with, the Network Analyst extension.

Route planning is the first thing that pops into my mind when I think about what a GIS does, yet I’d never even turned on that extension before. This is going to be a very basic introduction for people who might be in the same boat: interested in what Network Analyst can do, but don’t know where to start.

I am going to post it in three installments
1. Preparing your data to become a network dataset
2. Creating the network dataset
3. Doing network analysis

The first thing you will need is a streetline layer. The more information it has in it, the better. It should at least have road names, road types, and direction of travel (for one-way streets) designated, or its use will be very limited. You can use the ESRI StreetMap data if you have access to it, which is optimized for use with Network Analyst and even comes with a pre-made network dataset. If you’re going to do that you can skip ahead to installment #3. Otherwise, read on:

Preparing your data to become a network dataset
I downloaded a streetline shapefile from the City of Portland GIS Data Catalog.

The fundamental bit of information network analyst needs in order to work is a Cost Attribute. Cost is either the travel time or distance on each road segment. It is the thing the model is trying to minimize when calculating the best route. Distance is easy to add to any dataset. Create a field (type: double) if one is not there already, and then use the Calculate Geometry tool. Chose miles or kilometers, whichever you prefer, as your length unit. Note: your dataset needs to be in a projected coordinate system for this to work.

If you know, or have a basis upon which to estimate, the speed of travel on each road segment, you can also create a Cost Attribute based on time. This will make your results much more meaningful. My dataset designated road types, which allowed me to make an educated guess about speed limits. I added a Speed field and populated it with my miles per hour estimate. The Insurance Institute for Highway Safety has a table of maximum speed limits in each state. Oregon’s is 55 for urban interstates. So, I used 55 for highways and freeways, 45 for major/primary roads, 35 for secondary roads, 25 for minor/local roads and ramps, and 15 for driveways.

These speed and distance fields in the attribute table will be used to calculate a time attribute later in the process. Moving on:

The next fundamental attribute to have is Hierarchy. Network analyst uses it to create more realistic routing based on the fact that people prefer to travel on larger roads. It is an integer value that ranges from 1 (major) to 3 (minor) based on road class / road level. If your roads are already labeled as primary, secondary, and tertiary, you’re set; otherwise, you’ll have to make some classification decisions. You can add a new integer field to the attribute table for it (that’s what I did). Or, you can calculate it later, like I’ll explain how to do with the time attribute.

Next, you will need to flag one-way roads with their direction of travel. I struggled with this for quite awhile before stumbling upon a procedure that works correctly, so I recommend doing it just this way:

1. Create a new string field in the attribute Table called OneWay.
2. Change the symbol of your roads to a cartographic line with the arrow pointing right. This will allow you to see what direction the line was digitized in.
   
3. Bring up a Google map of your area, or something else that allows you to see the direction of travel.
4. Put an “F” in the OneWay column for any road that has been digitized along with the direction of travel.
5. Put a “T” in the OneWay column for any road that has been digitized against the direction of travel.
6. Use an “N” for any roads that don’t permit travel in any direction.
7. Use any other value for 2-way streets. (I used “X”).

(click on image to see full size)

When you create your network dataset later, Network Analyst will recognize this formatting and will know what to do with it.

Finally, examine the way your road lines were digitized, especially around overpasses and tunnels. If they have a unique segment between each intersection (that is, they break anywhere a person could theoretically turn), then you can use End Point connectivity—the default. If, however, your roads are long lines that don’t break when they cross, you will have to use Any Vertex connectivity. The type of connectivity you chose tells Network Analyst where to create Junctions. Junctions are a special point layer that will be generated along with your network dataset. They are created wherever a person could transfer from road to another.

Regardless of what connectivity you chose, you will need a way to designate overpasses and tunnels so that people will not be routed to turn onto roads that are inaccessible because they pass below or above them. This is done using z-levels. Create two new integer fields to hold your z-level information. Call one “F_ZLEV” and the other “T_ZLEV”. The field prefixes stand for “From” and “To,” respectively. First, designate all ground level roads as z-level 0 in both fields. Then designate overpasses as 1 and tunnels as -1 in both fields. (Hopefully, your attribute table will tell you where these are. Mine had a “Structure Type” field). Now, symbolize with a cartographic line again as I described in Step #2, so you can see the digitization direction. Change F_ZLEV to 0 at the beginning of raised or lowered segments where they meet level road. Change T_ZLEV to 0 at the end of raised or lowered segments where they meet level road. The idea is that a route will only go through a junction where the z-levels match.

(click on image to see full size)

You are almost ready to move on to the next step, but before you do, think about any other potential restrictions to travel. Do you have roads that are marked as “under construction,” toll roads or private roads? Make a note of how they are designated in the attribute table so you can flag them later.

Stay tuned for installment #2: Creating a network dataset

Natural Earth is a crisp basemap dataset available for the world at 1:10m, 1:50m, and 1:110m scales. I downloaded one of their most detailed layers, the 1:10m Admin 1 – States, Provinces shapefile for use as my example.

If you were asked to write a metadata record or some other type of report about this dataset, you would want your description to be as complete as possible. You might find it necessary to generate a long list of place or topic keywords. Often, the attribute table already includes this information. You just need a good way to extract it.

For instance, if I symbolize by category on the ENGTYPE_1 field of my natural earth layer, I get a long list of administrative area types. There’s way more than just states and provinces here! If only I could select this list and paste it somewhere else to have in a usable format. Unfortunately, it’s not that easy.

The solution I have come up with is not perfect. I keep thinking there must be a better way. If any of my readers know of one, I would love the feedback. For now, this method certainly beats having to type the entire list:

First, open attribute table and right click on the field you want to turn in to a keyword list. Then, select Summarize…

Chose one summary statistic field. It doesn’t matter which, but works a little better if you chose something that’s always going to be the same. I chose “CheckMe” because that’s basically a flag (yes or no) field. It doesn’t matter which summary statistic (minimum, maximum, first, last etc.) you pick either. You won’t be using any of this information–it’s just a way to get ArcMap to make a list for you that includes each category one time.

Hit the browse button in the Specify output table section. Then, change Save as type to Text File.

Open up your text file in Notepad and remove the first line (the field names). Then, do Edit — > Replace and replace all commas, quotation marks, numerals 1-9 and whatever text phrase was in your summary statistic field with nothing.

When you are done, you end up with this. If you want to add commas and move these all into one row, it’s pretty easy from here.

I have often been asked questions like “What is the total acreage of forest in our study area?” or, “Has the total forested area increased or decreased since we last mapped it two years ago?” The answer starts with being able to calculate polygon areas. After that it’s just addition and subtraction.

I used to have to use VBA scripting to calculate polygon areas. Now the task has been simplified with the Calculate Geometry tool introduced in ArcMap 9.2. However, there are some things you need to know to get good results with this tool.

There’s a lot of little parks around the San Francisco bay area in California that will serve as a good test case.

Let’s add the area of each park to the attribute table. The first step is to create a new field to hold the values. Chose field type “Double” (Double-precision floating-point number) which allows lots of decimal places. Then, right click on the field name and chose “Calculate Geometry…” from the context menu. You will then get to choose your units. In this case, decimal degrees are the only option because the layer is in a geographic coordinate system. Decimal degrees are pretty useless.

Fortunately, the tool allows you to use the coordinate system of the data frame, so you don’t have to worry about re-projecting. You just need to change the data frame into a projected coordinate system, one that uses a linear unit of measure, such as feet or meters. UTM (Universal Transverse Mercator) is widely used. This image from wikipedia shows the San Francisco bay area is in UTM zone 10N.

To change the projection of the data frame, select Data Frame Properties from the View menu. On the Coordinate System tab, pick from the Predefined – Projected Coordinate Systems folder.

Now, the Calculate Geometry tool gives you choices like square feet, square miles and acres. I picked acres, a good tiny park sized unit. I got results back with 6 decimal digits, which sure seems good.

But wait. We used a common projection which is great for most purposes, but not particularly for this one. UTM preserves shape and direction, which makes things look right on maps. However, it distorts area and distance. Exactly not what is needed here. The distortions may be small, but if you want to be as accurate as possible (and what GIS Analyst doesn’t?) it is better to use an equal-area projection. Albers projections preserve area while distorting shape and distance. If you root around in the list, you’ll notice there’s several Albers equal-area projections available for different regions, such as Albers North America and Albers USA Contiguous. It is best to pick the most local one you can find. In the State Systems folder, there’s a California (Teale) Albers. Perfect!

Changing the data frame to this, and recalculating the area in a second field, does yield different, better results.

If you need to get the total area of all the parks, don’t dig out your calculator. Just right click the field name to run the Statistics tool.