Mapping Center

After seeing my poster that described using dot maps to show soils at the AAG conference in Boston a few weeks ago, Charlie Frye suggested that I write this entry to describe my maps and the technique used to create them.  This seemed especially appropriate given the recent entries in this blog about dot maps.

The data source for the soil dot maps is the U.S. General Soil Map, previously known as STATSGO, which is available from the Natural Resources Conservation Service (http://soils.usda.gov/survey/geography/statsgo/).  The STATSGO database is a soil association map.  It was developed to depict the distribution of soil properties at small scales, and originally compiled at a scale of 1:250,000.  In a soil association map, generalization from larger scales (in this case, the county-level SSURGO data) is accomplished by grouping into a single mapping unit soil types that normally occur together on the landscape.  The digital STATSGO database retains links to the individual soil types and their properties by including information about the percentage (by area) of each component soil type represented in a mapping unit.  Most mapping units in the STATSGO database include between 10 and 20 different individual soil types.

The advantage of using the dot map over a choropleth mapping technique for this database is that it gives the map reader a sense of the variability of the soil types in each polygon. With a choropleth technique, usually the dominant condition that exists in the polygon is used to determine the pattern chosen for the entire polygon. For example, if a particular polygon were composed of 35% Alfisols, 30% Mollisols, 20% Inceptisols, and 15% Entisols, then the polygon would be assigned the symbol for Alfisols, even though the Alfisols represent less than half of the area in the polygon. With the dot map technique, there would be dots for all four soil orders randomly distributed inside the polygon: if the polygon’s area was 100 hectares, and each dot represented one hectare, there would be 35 Alfisol dots, 30 Mollisol dots, 20 Inceptisol dots, and 15 Entisol dots.

The tabular database included with STATSGO includes data about the individual component soils concerning many different soil properties. Some of the properties in the database pertain to the entire soil profile, and some to individual soil horizons. The distribution of any of these soil properties could potentially be mapped; for this map, I have chosen to use the soil order classification according to the Soil Taxonomy system.

To make the dot map, within each mapping unit I summed the areal percentage represented by each soil order, and joined the resulting table to the attribute table of the spatial data. At this point the attribute table contained a field for each soil order showing the percentage of each polygon represented by that order. Next, I calculated the area of each polygon in hectares, then multiplied the polygon area by the percent in each order. I now knew the number of hectares of each order contained in each polygon. This is the number that is used in creating the dot map.

I then made a dot density map in ArcMap. Multiple fields can be included in the dot density map; for the soil orders map I included the fields for all ten soil orders that exist in the conterminous United States. Each order was assigned a different dot color. Because the polygons were small relative to the size the of the map (there are more than 77,000 polygons in the conterminous United States), and in order to reduce the amount of clutter on the map, I chose not to draw the polygon boundaries on the map.

I also created smaller maps for each soil order which used a similar method to depict a single order at a time.  Here are links to PDFs for each of these:

• Alfisols [3.5Mb]
  
• Andisols [0.4Mb]
  
• Aridisols [2.1Mb]
  
• Entisols [2.7Mb]
  
• Histosols [0.4Mb]
  
• Inceptisol [2.3Mb]
  
• Mollisols [5.2Mb]
  
• Spodosols [0.8Mb]
  
• Ultisols [2.3Mb]
  
• Vertisols [0.6Mb]
  

Including these individual maps alongside the main data frame on the poster let the reader bounce back and forth between the main map and the individual soil type maps to better understand the nature of each soils type's distribution in the U.S.  Unfortunately, the main data frame was too large to link to here. 

We recently made some changes to the color ramp styles on Mapping Center under the ArcGIS Resources tab. You will now find a single ZIP file that contains a variety of color ramps. Our purpose in reorganizing the color ramps was to make it easier to find and use the color ramps.   The way we did that was to organize all the color ramps of a particular theme into a separate style file.  Then we gave each of the style file a name that better describes the purpose of the color ramps.

The .zip file contains color ramps for the following:

• Desert environments
• Hypsometry (elevation) developed using Imhof’s guidelines in Cartographic Relief Presentation
• Special cartographic effects (like the park boundary used on the Crater Lake National Park map)
• Special events (fire, global warming)
• Water bodies
• Water dynamics (water currents – direction and velocity)

               Desert                               Effects                                  Events

            Hypsometry                        Water Bodies                    Water Dynamics

Have fun with these and let us know how they work for you!

Hypsometric tinting (also called layer tinting, elevation tinting, elevation coloring or hypsometric coloring) is used to enhance elevation zones so map readers can better see differences in relief.  You can think of it as "coloring between the lines" where the lines are contours (lines of equal elevation) or isobaths (lines of equal depth below the surface of a body of water).  Hypsometric tints are often laid transparently over a hillshaded surface.

The colors selected for the tints are assumed to relate to the ground cover typically found at various elevations in the area being mapped. The highest elevation zone might be white, for snow-capped peaks, the next brown for treeless areas above the tree line, then light green for sparse vegetation on the upper slopes and a darker green for the verdant valleys.  Choosing your tints wisely requires that you know the area you are mapping

There are two ways that to go about layer tinting a hillshaded surface in ArcGIS - in one approach, you set the colors for each elevation interval (that is, you use classified values).  In the other, you use a gradually varying color ramp. There are advantages and disadvantages to each approach.

Layer Tinting Using Classified Values

Using classified values for layer tinting means that you assign specific colors to specific elevation intervals. With this method, the space between contour lines is given a distinct gray tone or color resulting in a map that has a stepped appearance, like a layer cake, as in the example below.

The primary advantage of this approach is that you have full control over the colors used on the map and the elevation ranges they are shown with. In the example above, it would be very difficult to get a gradually varying color ramp to have a specific color assigned to the zero value, which on this map  relates to the difference between land and water. The best way to do this is to have a separate water layer; this was laid over the land layer in the map above. Notice that both the land and the water layers are layer tinted using classed values

Disadvantages of this approach are that you need to create each of the intervals and assign each of the colors. You will likely end up with a  more graduated-looking colorization of the elevation since there are a set number of intervals that you can or will want to use. In the example above, there are 17 elevation intervals used to create the map, so 17 ranges had to be set and 17 colors had to be assigned.

Layer Tinting Using a Color Ramp

In the second approach, a color ramp that has gradually varying colors is used to represent the full range of elevation values.  In ArcMap's user interface, this option is called "Stretched".

An advantage is that the colors progress through the elevation ranges smoothly so there is no stepped appearance to the tinting. A disadvantage is that you have less control over which colors are assigned to which elevations (although you can try to modify this using the histogram).

A challenge with either method is to use a color ramp that has the range of colors appropriate for the area being mapped. You may have to modify the color ramp to get the colors you need. An easy way to do this is to start with the color ramps already in ArcMap modify them.

If you're making a map that is either a large format print map or a map that will be served via ArcGIS Server, squeezing every bit of wasted time out of drawing performance is critical.  Don't get tired of sitting there drinking extra cups of coffee watching the word "Drawing", all your layer names, and that little blue globe. If you're finding it stressful to explain when updates will be coming, or the timing for caching the map you are serving, or your map services generate complaints about poor performance, then try the two tips in this entry.

There are lots of obvious tips to improve drawing performance in the ArcGIS Help system, but I've got two tips that are not there and do make a big difference: first, once your map is set up, create attribute indexes; second, simplify the data that is being labeled (that means you'll be labeling a different layer than what you use to draw the symbolized geometry on your map).

Tip 1: Attribute Indexes

If you use an attribute to symbolize your data, e.g., the field you've specified for unique values, or the population field on census block group polygons, adding an index to the feature class for that field will boost your drawing performance.  The same goes for your label fields.  There is a topic in the online help called Creating attribute indexes that explains how to create attribute indexes and explains which options to use based on the nature of the information contained in the field you are indexing. 

Tip 2:  Simplified data for labeling

For line and polygon data, labeling performance is affected by the quantity of information that is fed into the labeling engine.  Whether you're using the Standard or Maplex labeling engine doesn't matter.  The label engine will work if you're sending it millions of vertices, but you'll experience a performance penalty for having to read and ingest so much data.  The main idea is to use either the Simplify Line or Simplify Polygon tool to reduce the number of vertices, without fundamentally changing the shape of your geometry at your map's scale. 

If you can see the vertices in your data as you draw, don't worry about doing this, but if you can zoom in on your data and continue to see more detail as you zoom, then definitely consider simplifying your data for your labels.

These tools have two methods, Point Remove (Douglas-Peucker algorithm) and Bend Simplify.  Point remove is generally better for data like roads, contours, and boundaries because it will not introduce new points.  Bend Simplify works better for rivers, streams, and natural features like soils and vegetation.  Remember the purpose is not to fundamentally change the shape of the feature--after all the label needs to associate well with the unsimplified version of the feature that is symbolized on your map.

To the right is  the table of contents from a map I've been working on recently that uses this tip.  My layer names contain the substring "Lab" in the cases where I am just labeling simplified features.  The map works at multiple scales and each scale is also noted in the layer's name. 

Last, we have been adding tips like these to the online help for ArcGIS 9.3--where those of you who are beta sites can find them now.

Last week we received an interesting question on Ask a Cartographer about how to create tapered stream or river line symbols. Tapered symbols are actually a bit more complicated than what is shown to the left; those lines are proportionally scaled symbols that are based on an attribute value. Notice that each stream is a single line width.  Tapered symbols would actually change widths along the length of a given feature, giving a very smooth effect. Tapering is more useful for depicting flows that range widely in value or magnitude, whereas proportional symbols are usually an excellent solution for symbolizing rivers and streams. 

Another aspect of tapering that is usually not appropriate for displaying rivers and streams is that the tapering is usually applied uniformly along the length of the line, suggesting, for instance, that the midpoint of the line is exactly half as wide as the widest portion.  Such an approach doesn't work well for river networks, for instance where the Ohio and Missouri Rivers each join with the Mississippi adds a large quantity of water that should be represented immediately rather than uniformly managed along the length of the Mississippi River.

To illustrate this point we’ve posted a dataset on Mapping Center’s resource page that contains hydro flowlines for the continental U.S. These flowlines were derived from the NHDPlus dataset created by Horizon Systems for the USGS and EPA. One of the valuable aspects of this dataset is that the hydro flowlines have attributes, including two for mean annual flow. In this particular example, I classified the flow attribute that was based on upstream drainage area into 25 flow classes. Then I dissolved the result on name and flow class. That is essentially what I used to create the image above which shows a portion of the Ohio River, the Wabash (on the upper left), and Kentucky (on the lower right) rivers.

The symbols are set up with proportional symbols with the smallest symbol at 0.1 (flowclass = 1) and the largest size (flowclass = 25) is automatically determined.

In order label these features, flow class can be used to set up labeling classes to label the rivers with text sizes that reflects the importance of the river. To do this I used the flow class attribute, but created fewer label classes.  I included a second feature class with "_lab" on the end of its name. That feature class has a field with three classes (small = 0, medium = 1, and large = 2).  This data is also simplified to a much greater extent, making it efficient to label.

Here is an example of how this symbology and labeling appear:

In the first dot density mapping blog, we discussed the workflow for creating dot density maps using ArcMap.  In that discussion we emphasized the need for using exclusion or inclusion layers.  Here is an example of how we set up the inclusion and exclusion choices for mapping population density in San Bernardino County, the county with the largest land area in the conterminous United States. Because of its size and the fact that population is not evenly distributed throughout the county (rather, it is concentrated in the southwest corner, around where Redlands is located), this county exemplifies the limitations of dot density mapping without inclusions/exclusions when mapping population density at the county, the state or even the country level.

We first created a dot density map for San Bernardino County without any exclusions or inclusions using the county itself as the enumeration unit that the dot density was applied to.  This is what it looked like:

Clearly, this does not represent the population density pattern very realistically.  One "fix" is to use smaller enumeration areas, so we first tried census tracts:

And then we tried block groups:

This was a big improvement over our first two maps, so we decided to do the exclusions and inclusions using these smaller enumeration areas.  The next thing we did was to determine areas of exclusion.  These included: 

• Parks
• Local
• State
• National
• Airports
• Landmarks
• Schools
• Hospitals
• Cemeteries
• Golf Courses
• Shopping Centers
• Stadiums

To create a single layer with these excluded areas we followed these steps:

1. Extract areas of exclusion from datasets to fit your study area or map extent and create new layers for them.  For example, we used Landmark data clipped to San Bernardino County (available from ESRI Data & Maps StreeMap).
2. We then created new a new empty layer that we could use to append all the areas of exclusion.
3. We batched appended all of the areas of exclusion. (see the list of categories that wee excluded above.) Keep in mind that all areas of exclusion or inclusion must be polygons.
4. The final step was to visually inspect the final exclusion layer and compared it to other reference information and our data to ensure we did not miss other areas that should have been included in the exclusion layer.

To set the area of exclusion (that is, the masking) for areal feature dot density representation, here are the steps to follow:

1. Right click the layer with the population density for San Bernardino block groups.
2. Click Properties.
3. Select the Symbology tab.
4. In the box on the right, under Show, click Quantities.
5. Select Dot Density.
6. Set the unit value and dot size.
7. To the right of the Background settings, click Properties.
8. Check the Use Masking box.
9. Select your final exclusion layer as the Control Layer.
10. Click the "Exclude dots from these areas" option.
11. Click OK.

 When we included the exclusion layer, we got this result:
 

There is one additional step that we wanted to add to this analysis which was to INCLUDE certain areas. We theorized that people would live closer to roads rather than far away from them.  To do this, we needed to use two layers - the urban areas and the roads layers (from ESRI Data & Maps StreeMap).  Here are the steps we followed to include areas near roads in the dot density analysis:

First we buffered the roads to a threshold that we determined made sense for our analysis. These are the steps we followed:

1. Select roads within the urban areas (we noted when we did this that dense road networks create problems when buffering).
2. Switch the selection (to learn how scroll to the bottom of the linked help topic).
3. Export the selection to a new feature class and then add it again to create a new rural roads layer.
4. Dissolve the roads based on a universal field (that is, all features having the same value for an attribute).
5. Buffer the roads based on:
1. Knowledge and visual analysis of the geographic area (we determined that 5 miles made sense for our study area)
2. Use the Dissolve type All.
6. Select urban areas that the roads where removed from (these areas were used as proxy road buffer for the urban areas in order to avoid the problem of the buffers of dense road networks.)
7. Buffer to same user defined threshold as roads (5 miles) and use Dissolve Type All.
8. Merge the areas of inclusion (that is, the road buffers and the urban area buffers) using Dissolve. In order to do this, we:
1. Add a field that the Dissolve tool will use to dissolve the features on.
2. Calculate all values in the new field to equal one ( = 1)
3. Use Dissolve Type All based on added field with identical values.
9. Set the area of inclusion using the same steps as setting the area of exclusion (described above) but select the “Place dots only in these area” rather than “Exclude dots from these areas” option.

Here is the result we got using this inclusion layer:

The final step is obviously to combine the exclusion and inclusion layers so we have one final layer to use in dot density mapping that represents the areas we know people NOT to be as well as we theorize more people TO be.  To do this we followed these steps:

1. Add both the final exclusion and inclusion layers to the map.
2. Use the Erase tool to remove any exclusion areas from the inclusion layer:
1. Set inclusion as input feature,
2. Set exclusion as erase feature, and
3. Set the output location.
3. Click Run.
4. Follow the steps from above to apply this as a mask for areas of inclusion.

This was our final result - a vast improvement over the map we started with for San Bernardino county!

by Alex Quintero and Daniel Smith, students at the University of Redlands.

Several weeks ago, after a colloquium given by Dr. Aileen Buckley on the devolution of cartographic theory, we approached her about research opportunities that she mentioned. She was glad to accept our help and put us in contact with Dr. A. Jon Kimerling from the Oregon State University. The research he was undertaking during his sabbatical in Redlands, CA dealt with a particular mapping method in the cartographer's bag of tricks - dot density mapping. After discussing the research issues with Dr. Kimerling, we were tasked with developing a series of maps to supplement his research (see his presentation: "Dotting the Dot Map, Revisited" and to document the workflow for creating dot density maps with ArcMap. This seemed to be easy enough and in fact was quite easy given ArcGIS provides the tools necessary for completing this task.

Here are the basic steps needed to create a dot density map.

The first thing that is necessary is areal data. For population dot density maps, census data are a good bet.

Identify of the attribute that contains values for each areal unit that you want to map.

Once you have identified the data and attribute to be mapped you need to define the dot size and dot unit value. There are a few ways to do this. You can refer to the Mackay nomograph (slide 6 of "Dotting the Dot Map, Revisited") that has been used for years or refer to Dr. Kimerling's work using probability theory to define an optimal dot density from which the dot unit value can be determined (appears later in the same presentation).

Now comes the ArcMap part. Right-click on your areal unit data in the table of contents and select Properties. Select Symbology tab and on the left hand side of the dialog box select Quantities (see below). The drop down box shows several options, among them Dot Density. Select this option. You will see the display change, and it will give you options for identifying the attribute(s) to be mapped, dot value and dot size. Set these parameters to what you would like and visually inspect the dot density preview. Pay special attention to the "Max" (maximum) preview box. Try to adjust your values, so that in the Max preview the dots begin to coalesce. Click OK and ArcMap will draw the appropriate number of dots according to the dot unit value in a random pattern, giving you a dot density map.

This dot density mapping is great, right? In many cases where features are distributed evenly across your areal units this simple procedure will work well, but what if we want a more realistic depiction of where dots should be placed? ArcMap has the functionality to handle this more complex situation in the form of applying masking to the layer and eliminating unsuitable areas for dot placement. The process for applying a mask is as simple as creating the dot density map, as explained above, but there are additional considerations. The first is defining exclusion or inclusion areas.

• For exclusions you are defining areas that are known to not contain the attribute you are representing with the dot density map. This is an exercise in assessment and knowledge of geography and of your study area, as well as a conceptual exercise of combining layers using various ArcGIS tools. Some examples of possible areas of exclusion from the work we have done creating dot density maps of population are state, local, and national parks, water bodies and airports.
• The concept of inclusion areas is exactly the opposite – areas that are known to contain the attribute you are representing with the dot density map. Examples from our work include road buffers and urban areas (minus airports and parks).

That being said, let’s get to the “how to” for setting the exclusion or inclusion layers. Note that the software will allow you to set one exclusion layer and that that layer must have polygon geometry. So you need to get all the exclusions and inclusion into one layer that you will use to make the map. For our work, we used a series of appends and dissolves, but using these depends on your data and what you are trying to do.

Once you have created your final exclusion or inclusion layer, make sure that it is above your data layer that contains the attribute being mapped using the dot density method (this will save you from banging your head against the wall for thirty minutes like we did trying to figure out why the results didn’t change). Set your exclusion layer to no fill and use no outline color if you wish not show these areas (in dot density mapping we are solely interested in showing the dots with some minor base reference layers such as state or county outlines).

Navigate to the Layer Properties Symbology tab of the layer being used for dot density mapping. Click the Properties button next to the background drawing options (I know that the Exclusion button is tempting but this is used to exclude specific instances or in other words records of your feature being mapped).

Check the Use Masking check box. Select your exclusion or inclusion layer as the Control Layer. As noted above, you can only use one layer to include or exclude dots so be sure to have all your exclusions and inclusions in one final layer. Depending on how you set that up, you will either Exclude dots from these areas (for a final exclusion layer) or Place dots only in these areas (for a final inclusion layer).

Select Fixed Placement if you do not want your dots to move around every time you zoom in or refresh your map display. Click OK in the Dot Density Symbol Properties dialog box and again in the Layer Properties dialog box. You have just created a dot density map using areas of exclusion or inclusion.

This and the next posting were written and submitted by Alex Quintero and Daniel Smith, students at the University of Redlands. 

Question: What is the difference between filling a polygon with randomly placed dots and creating a dot density map for the polygon?

Filling a polygon with a certain number of randomly placed dots is a form of choropleth mapping where random dots are the area symbol for a quantity that is assumed to be of uniform density throughout the polygon. The choropleth map seen below of San Bernardino county population density uses random dots in this manner.

Dot density maps, on the other hand, show the geographic density distribution of a phenomenon by placing dots representing a certain quantity of the phenomenon where they are most likely to occur. The dot density map seen below of San Bernardino county population density is made by first allocating the county population by much smaller census block groups, then excluding areas within block groups where people are unlikely to reside, such as parks and military exercise areas. The dot map eliminates the obvious geographic inaccuracies apparent in the choropleth map where the county appears to have the same population density in desert and mountain areas as at the eastern edge of the Los Angeles metropolitan area where most people reside.

Good dot density mapping is a little more complicated to achieve because it requires the use of related ancillary data and an understanding of the geography of the area. However, they are more accurate. With ArcGIS software, it is possible to achieve well-designed dot density maps, as will be explained in forthcoming blog entries by the students who made the maps you see here.

I've often had the situation where I wanted to use a raster data source as a single-color map background layer, but the cell size or other data processing output resulted in a 'blocky' or 'pixelated' appearance to the data at the map scale I need.  A simple raster-to-vector data conversion served only to recreate the boxes or 'saw-tooth' or 'stair-step' lines from the original raster. The ArcScan extension has tools that reduce or remove this problem, and create an output vector data layer with smooth polygon boundaries or more naturally sinuous lines. 

To the left is a USGS DRG mosaic of the Crater Lake National Park area in Oregon.  The original data came to me as a large MrSID file which contained data from at least a dozen original DRGs (an excerpt from the Park HQ area is shown at left).  I was able to locate most of the vector data for topographic features, roads, hydrology, etc. from National Park Service and USGS websites.  A challenge was finding vegetation or ground cover information I could use for the green "forested" shade on the map, but eventually I found vegetation surface cover data from the National Park Service - Pacific Northwest Region Database (http://nrdata.nps.gov/crla/crladata) stored as an ArcInfo raster in export format as "clnp_species.e00".  A few data processing steps ensued, and I reclassified the data to create a new output raster with just two values: 'covered' and 'uncovered'.  The result for the area of interest is shown below; the screen shot was captured displayed at 1:24,000 scale with my ArcMap application window at full size (i.e. I'm not zoomed in excessively):

 
Compare this to the map excerpt at the top of this article - the jagged appearance of the 25 meter cell size is too obvious at the scale I want to use.

What I wanted to do was keep the general depiction of ground cover, but avoid the rough appearance of this data, so I turned to the ArcScan extension Vectorization Settings to convert the vegetation species raster into a polygon feature class with smooth boundaries. To do this yourself, follow these basic steps:

1) Create new, empty polygon and line feature classes to hold the output geometry, and add them to your map. 

2) Add the ArcScan toolbar and start an edit session. The first setting I changed for this was in the Vectorization Options dialog, where I changed the Vectorization Method from Centerline to Outline.

3) Next, open the Vectorization Settings.  Obviously you'll need to experiment with these settings to suit your own data and mapping purposes, but I offer what I used as a place for you to start. Shown below are the default Vectorization Settings (the units of measure are pixels):


The setting with the most effect was Hole Size, I experimented with Gap Closure Tolerance, but this setting didn't have much effect on the output of this data.  The small squares shown in the original raster above are 25-meters, and therefore were translated into small, round polygons on output.  These couldn't be removed by either of these settings, as these one-cell features were neither 'gap' nor 'hole'.  So the main issue I was able to control was the number of small, cell-sized holes which remained in the main 'covered' areas.  A Hole Size setting of 3 proved satisfactory.

One handy feature in the Vectorization Settings drop-down is the ability to toggle on/off 'Show Preview' so that you can see what your changes look like prior to committing them to a new feature class.

5) Generate new features.

6) Admire your work.

Shown below are the results of my raster-to-vector conversion, which when added to my map ended up looking close to the original DRG.

Text and imagery have had an uneasy relationship since the day they met.  Satellite imagery and aerial photographs are the ultimate variable background, which makes any text drawn on them hard to read.

There are plenty of options in ArcMap for displaying text, ranging from changing the style, size, and color of text to adding effects like drop-shadows and halos. Some of these options will work better than others for individual cases, and combinations of these options can work quite well in many cases. The image below contains quite a few possibilities, some are intended to illustrate viable solutions, while others are just there to show failed strategies. 

These examples are mostly graphic text elements added using the Draw toolbar. Besides changing the size and style of the text, a drop shadow effect is used on the text in the second column.  The drop shadow was set up with a 0.4 point shift in the X direction, and a -0.4 point shift in the Y direction. Those shift directions match the direction of drop shadows in Windows and match most people's expectations for drop shadow direction.  The text in upper portion of the third column have a halo size of 0.6 points.  To learn how to set up these effects see the ArcGIS help topic about Creating text symbols.

The four groups at the lower right are annotation features, and the highlighting shows different kinds of masks created by the Feature outline mask tool, which can use annotation as input data.  The Feature outline mask tool is only available with an ArcInfo License.  I set the masks to have between 50% and 75% transparency; this depended on how large the overrun the mask represented; if it was larger, I used a higher percentage of transparency.

If you want to try any of these symbols, I exported my map's style (Tools menu -> Styles -> Export Map Styles) and you can download it. 

The above examples are simple, i.e., horizontal text, rather than text at an angle or text on a curved baseline.  Here is how diagonal text (30 degree angle) appears.

So far I've just shown what you can do to the text, you can also subtly change how the image is displayed.  For instance by setting the properties for contrast to -20, and brightness to 20, the imagery can be 'pushed' to the background without compromising the detail of the imagery.

The contrast and brightness settings are available in two locations: the first is on the display tab of the layer properties dialog, and the second is on the Effects toolbar.  By the way, this is also a good trick to know if you're printing imagery on relatively inexpensive paper and don't want to over-saturate the paper with ink.

The idea is that you should evaluate what will work best for your purposes and use that approach.  No single strategy will work best in all cases. If I'm pressed for a quick answer, I usually say use a yellow or white drop shadow on black text.  The reason is that it's fast to set up and it will make more text appear legible, while obscuring the least amount of imagery.  A potentially better solution is to use annotation, but that requires more time to create, and to create the masks.  Also, drawing the transparent masks adds a little to drawing time.

Last week we received a good question on Ask a Cartographer: is there a way to create parcel hooks with ArcGIS 9.2? After first discovering what parcel hooks were and finding an example of a typical case (shown at left), the answer seemed like a ‘no-brainer'. Sure, just use the line decoration option on a marker line representation. However, after acquiring some parcel data that included parcel hooks (thanks to Greene County, NC) and seeing the circumstances where parcel hooks (they're also called land hooks or parcel ties) are placed on maps, I learned there are are several scenarios that need to be handled.

First, the basic form of the symbol is a hook, rather than a tie, which is what the symbol in upper left image initially lead me to understand. To the right is an example what the hook would look like as a representation marker symbol.  We created a few of these markers and some representation rule line symbols and saved them in a style called RepParcelHooks.

We provided two options, one where there were parcel lines included in the representation rule, and another without lines, which  will just draw the marker line in the representation rule, i.e., only the hooks. The latter option will permit display of parcel hooks in a different layer (that still refers to your parcel lines data) along with other parcel line layers that may, already be annotated or have dimensions.

Notice that the hook symbol is inserted at the X in the Marker Editor; this allows the hook to be rotated around that point.

In terms of your data, the only requirement is that you are using a geodatabase, which allows you to use representations, and that you have an attribute that describes whether a parcel hook is located on a line, and if so, which side of the line. Even if you don't have that attribute, it is pretty easy to use the Editor with these representation rules to add hooks for your parcel lines.

As I mentioned above, I found several scenarios that required different representation symbology options. A few are fairly simple to follow, so I'll describe them first:

Single hook centered on a parcel line:  The images below show two scenarios for this situation: one where the hooks are on different lines and the other with the hooks on the same parcel line. The representation rule (below to the right) is set for the second case, i.e., there are two marker lines.  The only difference for the first case is that one of the marker line layers is not present. 

Single hook at the end of a parcel line:  Since parcel line features may be broken based on how their dimensions are described, ia hook may need to be shown at the beginning of a parcel line.  In this case the Decorations marker placement option for a representation marker line will work well.

Single hook on opposing parcel lines that are offset:

The issue here is how to get the hooks to align so they are exactly opposed. For example, the features shown to the right will not align if the hooks are centered on the parcel lines. To do that, an override for these features' representations is needed.

In order to fully understand how to override a feature's representation it will be helpful to know how I set up my layer's symbology. Before I created representations I added a field to my data that I could set to seven possible values.  These were based on whether there was a parcel hook, which side of the line the hook appeared (or both sides), and whether the hook's location would need to be customized. That way, when I created representations I could assign the first three classes to use the "On line" placement method for the markers in order to center the hooks, and use the "Decoration" placement method for the last three classes.  The key to using the decoration method for this last scenario is being able to set, or override, the Begin Position parameter of the representation symbology.

 
To create an representation override for a given feature it is first necessary to start editing and select one of the features. When you open the Feature Property Editor (which also opens the Attributes window), you will see an additional tab for each representation class defined for your layer's feature class. If the feature isn't already using the correct representation rule (based on the decoration geometric effect in this case), you need to change it.   You type a new value in the Begin Position parameter (as shown to the right).  You may need to experiment a bit to get the marker to be shown in the right place.  The value for Begin (or End) Position parameter is in points, and is based on distance on your display.

Tips:

• The <tab> key will not work to commit your edited Begin Position value, so just click in another of the parameter's boxes, which will force the new value to be committed and the display to refresh to show the new position of the hook marker.
• The values you type here are based on your map's Reference Scale.  This gets to one rule of thumb for working with representations, which is to set your reference scale first, then create representations.

By using the begin position parameter, you can customize the location of any parcel hook.  Depending on how your parcel lines are created, you can even add multiple hooks to a single parcel line by creating a rule with additional marker lines.

While this wasn't the simple, 'no-brainer' I thought it would be when I started looking at this mapping technique last week, it did turn out to be much easier than creating parcel hooks as separate features.  For instance, the Angle to line option worked in most cases, though in few cases where that caused the hook to intersect with other parcel lines, I found I could override the marker's angle to adjust the hook so it would display properly.
 

Early last month Chris Sergent forwarded me an email via Mapping Center's submit a blog entry feature.  Chris, who is a developer, was looking to connect with other ESRI developers. The spirit of Chris's email struck me as something we could all do with a little more of, so we put Chris's post up on the ESRI Developer Summit blog.

Last week I spent a day in Palm Springs at the Developer Summit, and was pleasantly surprised by the sheer number of people in attendance.  Combined with the attitude exhibited Chris's post, I didn't have much trouble recognizing this is a pretty important phenomenon and opportunity for all of us to share our knowledge and experience.  I think Chris's most important point is that user groups are key to making steady progress in the day-to-day work of implementing GIS, which includes all varieties of mapping projects and software applications - and cartographic products. 

While in Palm Springs I heard - more than a few times - a bit of buzz that raised my eyebrows, it went something like: "For me, as a developer, this is the most useful conference, and I don't think I need to attend the Users Conference any longer".  While there are many reasons someone might say as much (i.e. limited travel budgets), my feeling is that I would much rather continue to see the developers in San Diego. It's there that they get to meet and mingle with the folks who get their daily work done with the GIS applications that the developer community creates. It's also in line with one of the reasons ESRI puts on the Users Conference in the first place: for all our staff to get in touch with and to be informed by our clients.

For all the map makers and cartographers reading this, my point to you is that you should get to know the developers in your organization. In many cases these are the folks who are and will be paving the way to enterprise and server-based GIS systems. These are the people who have to implement (1) how you get data to map, and (2) in most cases, how you will publish your maps online.

While you might not hit the proverbial jackpot and meet a "closet cartographer" in your development group, you should at least find a way to convey your mission and priorities, so they to some extent become a shared mission and priorities.

We've added new site-wide search functionality to Mapping Center.  As our content and audience continue to grow, we will continue our efforts to make it easy to quickly find the information you need. 

The Mapping Center site has three search engines: one for Ask A Cartographer, one for the Blog, and the new Site Search.  Externally, you can also use Google Search to find our content.  As guidance for you to use the search engines effectively to get the results you expect, note the following:

• The Blog tab search will find only Blog content
• The Ask A Cartographer search will find content only within the Ask a Cartographer archives
• The Site Search will find all Mapping Center content except for the Blog
• Google finds all - though it may take up to a week for Google to index recently added content, especially on the blog.

Which are the 30 or 500 most important of Minnesota’s famous 10,000 lakes?  Next, think about that question from the point of view of making a zoom-able map of the U.S. and how many lakes need to be shown as you zoom in.  That question boils down to how to decide which polygons to show.  Not all polygons are created equally, some are roughly round, some are banana shaped (like ox-bow lakes) some have lots of prongs (like a reservoir formed by U.S. Army Corps of Engineers dam), some are long and twisty like a pretzel. 

The USGS’s guidance for selecting polygons from their 1:24,000 scale maps to be included on the 1:100,000 scale maps was based on the width of the smallest axis of a polygon. That worked well back in the days when folks used their eyes and hands to make maps.  For the modern cartographer databases, keyboards, and mice effectively blunt the senses and the mapmaking process.  

A little over a year ago I took the essence of that USGS guidance and decided to see how far I could push it. The result is a Python script tool (Minimum Bounding Rectangle Polygon Analyzer) that analyzes polygons and a method for selecting polygons based on that analysis. 

The analysis depends on creating the smallest minimum bounding rectangle (MBR) around a polygon and analyzing the rectangle and the polygon’s relation to it. This provides three measures that prove very useful in selecting polygons for smaller scales

• Area of the polygon, which is essentially a starting point, after all there is no point in analyzing polygons that are way too small in the first place.
• Percentage of the area of the MBR that the polygon occupies.  This indicates how substantial the polygon is.  The MBR Polygon Analyzer script adds a field called MBR_Area to your polygon data to store this information.
• Ratio of the length to width of the MBR.  This indicates whether the polygon is generally long.  For instance a 20:1 ratio indicates a long polygon, while a 2:1 ratio indicates a round-ish polygon.  The MBR Polygon Analyzer script adds a field called RatioL2W to store this information.

There seem to be four basic types of polygon shapes that need to be worried about (these can be subdivided, but I found after working with seven, and then five, that I was just repeating essentially the same work by having more classes).  Here are examples of query where clauses for each type of shape:

1. Roundish:  RatioL2W less than 1:5 AND  MBR_Area greater than 40%
2. Oblong:  RatioL2W between 1:5 and 1:12.5 AND MBR_Area greater than 30%
3. Long: RatioL2W greater than  1:6) AND MBR_Area between 6% and  30%
4. Pronged: RatioL2W between 1:2  and 1:20 AND MBR_Area" greater than 5%

These queries logically leave some gaps, but when combined with a minimum threshold for feature area, manage to select all the expected features in testing thus far. For instance, here is a definition query I used not long ago to select lakes from a NHD Medium resolution water bodies dataset to be included on a 1:250,000 online map:

("AREASQKM" > 1 AND ( "RatioL2W" < 5 AND "MBR_Area" > 40)) OR (( "AREASQKM" > 2)  AND ("RatioL2W" >= 5 AND "RatioL2W" < 12.5) AND "MBR_Area" > 30) OR (( "AREASQKM" > 3)  AND ("RatioL2W" < 6) AND ("MBR_Area" > 6 AND "MBR_Area" < 30) ) OR (("AREASQKM" > 2) AND ("RatioL2W" >= 6 AND "RatioL2W" < 20) AND ("MBR_Area" > 5))

While most of the design and testing of this method has been focused on hydrographic data, some testing has been done on soils, geology, forestry, buildings, and landcover data.  All show promising results.

Selecting the data for a smaller scale map is only the first step.  The polygon’s geometry may need to be simplified.  Depending on your cartographic preference, you may want to aggregate, displace, or exaggerate some of these polygons.  In fact, just to generate a little discussion, given the following example what would you do to the smaller ponds in this picture and why? Are there other things you would have done differently?  Please add your responses to the comments.

Keeping track of scale ranges at which a layer will be visible when a map has a few scale ranges and dozens of other layers can quickly become mind-boggling. This entry describes a strategy for using ArcMap's Table Of Contents (TOC) to create these maps and effectively manage all those layers and scales.

As you create a map that will cover several scale ranges, the recommended work flow is to create a group layer for each scale range.  Another way to think of this is that a multi-scale map is just an ordered sequence of maps of different scales.  At this point, I've found that in trying to verbally (or in writing) describe this to folks that a picture is extremely helpful; so I've included an example of the TOC of a hydrography map I made recently.

As I was making this map, I used group layers to organize layers by scale. Within each group layer my layers were essentially the same, i.e., there was a layer for Gages in my first five group layers. However, the symbols and labeling rules were revised for each scale.

I also used layer definition queries to select subsets of features for a given layer at each scale.  The idea is to show fewer and larger or more important features at smaller scales. For example, in the Cities layer I used the land area of the city polygons as the basis for selecting which cities were shown at each scale. Thus, in the 1:75,000 group layer I showed all the cities; in the 1:150,000 group layer I showed the cities that were larger than 0.001 decimal degrees, and for smaller scales I used larger areas. For each group layer, I zoomed to the minimum and the maximum scale and checked several areas, and if necessary I refined my definition query so it included only the cities that made sense for those scales without being too sparse or too crowded and cluttered.

The main benefit of using group layers this way is that the group layer scale range is applied to all layers in the group layer. This makes it easy to adjust the scale ranges just once for all the layers in the group. 

Another benefit is that once I had the symbology, labeling, and definition queries set for one layer at a given scale, I could copy it into another scale's group layer by dragging and dropping that layer, and then just adjust the properties rather than define them from scratch. 

TIP: Note how I've named my layers with short unique names.  This makes using the Label Manager much easier.

Sometimes you will have the same kind of data, but from a more detailed data source.  In this case, it may be possible to use the Import button on the symbology tab of the layer properties dialog.  This will import the symbols you have set up on the smaller scale layer, making efficient work of that task. 

Once you have the map working properly, i.e., only the features that are supposed to be displayed at each scale range are being displayed, you will likely need to publish the map.  Unfortunately the easiest way to make the map is not the easiest way to use the map.  The users of your map will want control visibility by simple, easy to understand layer names like  Cities, Rivers, Boundaries, etc.  To do that you can use group layers, but now the contents of each group layer will be a single theme of information and the layers will be set to use the appropriate scale range. Here is an example of how the map above was transformed:

In this case, the Basins layer is controlled by the viewer at the group layer level to turn it on or off, and this will work no matter what scale the map is currently shown.

The process of transforming the map is a bit repetitive as you will need to edit each layer. As a precaution, I first save my map with a different name. The nature of repetitive work being what it is; you, just like me, may get interrupted or side-tracked and it’s hard to come back to this task with a clear idea of where you were and what the next step should be.

The trick I use is to minimize such difficulty is to first go through each layer in a given map’s scale (from the table of contents above) and set all the layers to have the same scale range as their group layer does. It’s easier to do this at this point while you can still see the group layer’s scale range, which, believe me, is handy if you’re working late on a Friday. Then I turn off the scale ranges at the group layer level and pan and zoom around the map. Everything should still be working the same way. If everything is working well, save the MXD as a different name—that way you won't lose any changes.

Next create new group layers, named after each theme of information (based on the layers in your map). Drag and drop layers from the old scale-based group layers to the appropriate new theme-based group layers.

TIP: Use Ctrl-Click and Drag: this will not copy the layers, but instead just move them between the group layers; that way you’ll know you're done when the old group layers are empty. Delete the old group layers and save the MXD.

Last, test your work by panning and zooming around to make sure the newest map still functions like original.