Mapping Center

The ESRI Map Book has become an annual must-have collectors item for ESRI International User Conference attendees and GIS users alike. The twenty-third volume of the ESRI Map Book showcases the innovative and inspiring accomplishments of GIS users around the world. The true excitement of this book lies in the discovery of which maps have made it from the 2007 ESRI International User Conference Map Gallery into publication. More than 100 full-color maps are featured from distinct industry categories such as cartography, environmental management, government, natural resources, planning and engineering, tourism, transportation, and utilities. Each map is presented with an insightful description of how it was produced or used. The maps were hand selected by Jack Dangermond, the book edited by Michael Law, and designed by Doug Huibregtse.

Click on any of the following images to see example page spreads in PDF format.

Map Book Vol. 23 is available for purchase at the Spatial Outlet bookstore in the San Diego Convention Center from August 4-7. It will be available for purchase online at http://store.esri.com/esri/ after the ESRI International User Conference ends.

One of the most frequently recurring topics on Mapping Center is what to do with stacks or clusters of point features on maps. In August 2007, I wrote a blog posting on how to use Maplex to display coincident points, and this worked for some scenarios, but not all.

New with 9.3 is a tool called Disperse Markers; it's in the Cartography toolbox, in the Symbolization Refinement toolset.  The only caveat to using this tool is that your data need to be stored in a geodatabase because the tool works on representation symbology. This will be easier for many map makers, and it will work for more scenarios than the Maplex solution did.

Here is the basic procedure:

1. Symbolize your point features.
2. Convert the symbology to representations.
3. Run the Disperse Markers tool with your point representation layer as the input.

Here is an example of my results (using the same voter data I used in the Maplex example in which each voter is represented by a point whose color is based on political party affiliation):

Before: The points are stacked on top of each other, and there is no way know how many voters live at the same location.	After: The points are dispersed and it is easy to see all the voters, even those in apartment buildings versus single family dwellings.

Some things to note:

• Even though the dispersed marker symbols are representations, i.e., the original point feature coordinate were not changed, they can be given a feature weight for labeling -- notice how the Pine Ave. and Ash St. labels got adjusted.
• I had about 35,000 points in my dataset; it took about one hour and forty-five minutes to process. I used the Expanded option.
• Some of the same caveats that applied to the Maplex method apply here -- for instance, there is no way to restrict the direction of dispersal, so some points may have been dispersed across streets in my example.
• The advantage of this method over the Maplex method is that all the points are shown, whereas Maplex may have determined that a point was too far away (based on my settings, which were hard to fine tune) so it got processed it as an unplaced label and was not shown.

Not all of the new functionality for mapping and cartography was shown in the mapping section of the What's New in 9.3 PDF that's available on the new Resource Center. New with both the 3D and Spatial Analyst Extensions in ArcGIS 9.3 is the Contour with Barriers tool, which generates contours from a raster surface and allows you to limit the creation of the contours to either side of a barrier. This tool has several improvements over the the existing contour tool:

• Smaller output -- in my tests, the output from the Contour with Barriers tool was about half the size of what the existing contour tool produced. That means faster drawing and labeling.
• Option for specifying index contour interval -- with this option adds a field called Type and calculates values of 1 for intermediate contours and 2 for index contours. To run the tool you would specify, for example, a contour interval of 20 feet and an index contour interval of 100 feet. The old way of doing this was to add a new field and calculate it yourself using the VBScript Mod() function.
• A new parameter for a barriers feature class -- this actually applies to a lot more than cartography, but for mapping, imagine being able to use as a barrier a line feature class representing shorelines, the edge of a glacier, or the toe of a landslide. The result be contours broken at these barriers, allowing you to decide how or whether to display those contours.

Another important use of the barriers feature class is to clip contours at the study area edges when you need to create contours over a large region. With the existing contour tool, a single contour line can noodle across very large portion of the output dataset's extent without being broken. For a large region, there can be many of these contours and they can be extremely long, especially if the area has a lot of relief and the contours are very convoluted. This effectively defeats the dataset's spatial index, making drawing, selection, labeling, geoprocessing, etc., very slow. Using something like U.S. Public Land Survey System lines or quad sheet boundaries (installed with ArcGIS at c:\program files\ArcGIS\reference systems\usgs24q.shp) as barriers, the resulting dataset will perform much better.

There are a couple of drawbacks to the contour with barriers tool:

• It runs in about twice the time it takes the existing contour tool to run, but that is more than mitigated by the time saved in not having to do additional geoprocessing to accomplish tasks required for cartography anyway (that is, clipping contours at barriers and attributing index contours).
• As noted in the help, this tool does not deal with large elevation raster datasets as input and small contour intervals in the output. The next to last section of the usage tips in the online help gives you strategies to work around this limitation until it is fixed. That said, I was able to produce 50 foot interval contours from USGS 30 meter NED DEM data for the State of Washington using 1:250,000 scale quadrangle sheet boundaries in only 8 hours, thought I had to write a script to do the tiling.

At this point, I can say that the Contour with Barriers tool is usually going to be a better option from the perspective of taking the time up front to run the tool and saving time later in geoprocessing and performance.

We got a good question on Ask a Cartographer this morning. The gist of the question was how to go about symbolizing street centerlines so they could be drawn using line symbol widths that reflected, at scale, the actual width of the road (as shown in the image to the left). This is a good cartographic solution because varying the line width adds hierarchy to the roads -otherwise it would be hard for you map reader to know which are wider or more heavily used.

Over the past few years, I think I've investigated most of the possible solutions to this problem, from simply symbolizing already available street centerlines to more complicated and time consuming solutions that involve the creation of polygons from line features (such as curbs) simply to symbolize the streets. Basically, street centerlines are great until you zoom in far enough that you either see the imperfections in geometry or it's obvious that the streets should be shown with much wider line symbols. The trick is to find that happy medium between the abstracted/cartographic look of hierarchically symbolized street centerlines and the engineered look that comes with exactingly digitized curb lines.

For instance, is something like the look of a map from Google what you want? Or, would you rather have something that shows the roads based on their real life width? I started out on this slippery slope pretty much the same as the person who asked the question. The main problem is that in most cases for GIS data that represent street centerlines, features are not coded by street width, i.e., there's no attribute with the width, and the road class field doesn't begin to account for the real life variety in road widths. So here's how you can traverse the slippery slope, starting with the easiest solution:

1. I was making trails maps and I really wanted to make it easy for people walking on the roads between trails in Redlands to be able to locate trailheads relative to the characteristics of the roads. But, I did not want to digitize curbs--too much work! I wasn't happy with the road class field as the basis for line width. Too many relevant details weren't handled. So I spent some time refining the road classifications--adding additional categories, like trails, fire roads, and alleys, that I could use to try and assign various line widths to.

2. That was better, but I really wanted cul-de-sacs to look like cul-de-sacs. To try and solve this problem, I added another class to my line classification for roads that ended in cul-de-sacs. As, I showed in an  earlier blog entry on symbolizing roads with cased line symbols. I used a representation rule to add the cul-de-sac point symbol to the end of the line road symbol. That wasn't bad until I zoomed in a bit more and looked at my solution relative to some 1m pixel imagery and learned that many cul-de-sacs aren't symmetrical and for that matter many roads aren't either.

TIP:  As I as enriching my road class field, I also realized the quality of my street centerlines, which was fine for 1:24,000 mapping, was a bit coarse for 1:4,000.  So, I spent a good bit of time using the Reshape Feature edit task to refine the geometry of my street center lines, in particular to introduce true curves with the Endpoint Arc tool. I did this with my imagery in the background to help define the curves and verify my results.

3. What finally did the trick for me was to buffer my centerlines and then only when something exceptional, like where a cul-de-sac or parking area was located, did I do any manual editing. Here are some tips for doing that refined editing:

1. Turn off the map's reference scale. Too often I needed to be zoomed way in, like 1:800, and if you keep the reference scale on, the line widths become too wide.
2. When you do have to zoom way in, always zoom to the same scale--that way you'll get used to the proportions of elements you're editing – that is, you begin to get a sense of the scale, which won’t happen if it keeps changing.
3. I used the Endpoint Arc tool to create my cul-de-sacs--several areas of Redlands have a lot of variety in the shape, size, and symmetry of cul-de-sacs so this let me deal with those variations. It also worked when things were regularly shaped.
4. For 'standard', symmetrical cul-de-sacs, I found that I once I made one feature, I could use the Cut Polygon edit task to sever the cul-de-sac off the end of the street, Copy it, and then use the Merge command on the Editor menu to re-attach the severed cul-de-sac. Then whenever I needed a standard cul-de-sac, I could just Paste, Move, Rotate (if needed), and Merge to attach a cul-de-sac to another street's end.
5. I found myself wishing, more than once, that I could use the Lasso Direct Select and then the Move Parallel tools from the Representation toolbar to select a few vertexes and move them. To get around that, I found I could select the street centerline and use the Buffer command on the editor menu to create a polygon.  Then I used the Cut Polygon task to remove the unneeded parts, and then move the part I needed into place, and use the Merge command on the Editor menu to merge that polygon with my street polygon. It's almost as fast as editing representations, and certainly faster than manually editing each vertex.

So hopefully this helps you, no matter where you choose to place yourself on this slippery slope of cartographic street editing.

I've spent the last few months immersing myself in ArcGIS 9.3, particularly ArcGIS Server and ArcGlobe in order to create some map and globe services and see how they work in ArcGIS clients, Google Earth, and Virtual Earth. These services need to look good and draw fast. One factor that can dramatically influence drawing performance is whether projection-on-the-fly is being used.  Projection-on-the-fly will slow your map down, anywhere from 30% to 1000% slower (depending on the coordinate systems involved).

I decided I wanted to optimize drawing performance for each of my map services by having my data in the same projection as the final map (not surprising since that's the same advise I'd give anyone making a paper map).  What I discovered was that for Virtual Earth and Google Maps, I needed my maps and data to use the WGS_1984_Web_Mercator projected coordinate system (new in 9.3); and for ArcGIS clients and Google Earth, I needed to use WGS_84. There is additional information about this in the online help in 9.3 in a new topic called How to build online base maps.

I had planned from the beginning to cache these maps because I knew this would mean that the cached map service would let people see the best cartography I could create in ArcMap without having to wait for ArcMap to draw it. What I didn't plan on was that drawing speed in ArcMap directly impacts the time it takes to cache these maps. I had chosen to make map services that either covered a large area at a number of smaller scales (continental U.S.) or a smaller region in great detail (Lower Colorado River Basin at 1:4,500). This meant I was either using large datasets (5 million or more features in a feature class), which are often not as efficient to query using definition queries and labeling SQL queries, or I had a lot of features drawing at a given map scale -- both of these cases can slow down the drawing speed. Avoiding projection-on-the-fly turned out to be one of the most significant time savers for producing the map caches.

Here are a few things I learned as I projected my data and created these map services.

1. Much of my data used coordinate systems based on NAD83.  It's easy enough to use the Project tool to change the coordinate system to WGS 84. However, learning which was the correct transformation method tripped me up:  for the North America use NAD_1983_To_WGS_1984_1; and for the continental U.S. use NAD_1983_To_WGS_1984_5 (there are eight to choose from).  TIP:  Use the project tool, and once it's run, copy the Transformation method string from the geoprocessing results window and paste it into a notepad session.  This will make it easier to use the Batch Project Tool which does not automate the pre-selection of the transformation methods--doing it this way, you'll be able to just paste the method into that tool.
   
2. Some of my source data was in NAD27, which needed to be projected to NAD83 first, and then to WGS84 as a transformation was required for each of these steps.
3. To project data to WGS_84_Web_Mercator, I had to first project my data to WGS84 because an additional transformation is necessary to project data from WGS84 to Web Mercator.
4. Make sure all of your data have spatial indexes because spatial indexes ensure optimum drawing speed. Spatial indexes are not always automatically created, so check your feature class properties on the Indexes tab to see if it has one.

There will also be times when projecting your data isn't practical, and relying on projection-on-the-fly is the only way to go. In my case, this applied to the imagery and elevation GRIDs I was using -- these were either datasets or map services for the U.S. and the data sets were so large that the projection operation could take many hours, even more than a day! In these cases, I would strongly recommend the data you are mapping be stored in WGS84. The reason is that these data can be projected on-the-fly with a minimum loss of accuracy.  Storing your data in a coordinate system based on NAD83, or worse NAD27, means you could very likely see "datum shifts" in the display when using the WGS_84_Web_Mercator coordinate system. An additional incentive to store your map data in WGS84 is that our development teams are also working on further optimizing the projection-on-the-fly routines from WGS84 to Cube (used by ArcGlobe).

Finally, I also saw that WGS84 based services performed very well on all web clients (not as fast as Web Mercator services on Virtual Earth -- I didn't have a license for Google Maps, but I have been assured the same is true here). So, based on my recent experiences, if you know that map and globe services are among the products you are expected to produce with your GIS data, I would strongly recommend storing your data first in WGS84, and then if needed extract data for product databases in the specific coordinate system required by each product.

Whether you’re labeling soils, buildings, geologic units, lakes, or parks; you’ll eventually be faced with the problem of the text for the label being larger than the polygon you’re labeling. In most cases we recommend offsetting the labels from the small polygons and using leader lines to positively associate the label with its feature. The general idea is to split up the labeling of a layer into at least two label classes, one for the normal case, and one for the small features.

The first task is determining features are small. I usually start by labeling my map as though usual and then carefully inspect the map. For instance the map on the right [click any of the maps to see a larger image] doesn’t appear, at first glance, to be poorly labeled. However, a second glance will show that some of the small polygons did not get labeled. This map on the right was labeled with Maplex, in best mode, and the labels that are placed are well placed, adding to the deception that all is not so bad. To reliably sort out whether your map is being labeled well, use the View Unplaced Labels under options on the Labeling toolbar. Select a new color if need be.

This second map on the right shows a bit more alarming picture. There were at least eight labels that were not placed. It is worth noting that in this second view Maplex actually makes the map look a bit worse than it might otherwise be. The reason for this is that the unplaced labels are drawn/dumped on the map in their default position with no attempt to minimize conflicts with other features or labels.

How the map was fixed:

1. First I used the Label Manager to add an additional label class and set its SQL Query to be: [Shape_Area] > 500000. I came up with the number 500,000 by using the Identify tool and clicking on what looked like a polygon that would typically be too small to contain its label. Then I just rounded up a little bit. I also renamed my Default label class to be Medium Units (see the illustration below.
2. For the text symbol of my Small Units label class I added a leader line:

1. Click on the Symbol button
2. In the Symbol Selector dialog box click the Properties button.
3. In the symbol Editor click on and show the Advanced Text tab.
4. Note that I also set up a white drop shadow here (0.8 X offset, and -0.4 Y offset)
5. Check the Text background option, and then click its Properties button.
6. Change the Type to Simple Line Callout.
7. Change the Leader Tolerance to 8.0
8. Check the option to automatically snap the leader to the text.
9. For the leader line symbol, I made a two layer symbol, the bottom layer was solid white line that was 1.2 points wide. The top line was a dark gray line that was 0.6 points wide. This allowed my leader line to uniquely match with the text symbol, making it easier to associate the leader and its text.
10. Click OK until you get back to the Label Manager and then click Apply.

3. Next, Maplex placement properties needed to be set.

1. Click the Position button and then choose Offset Horizontal.
2. Change the offset to 12 points.
3. Click the Properties button and show the Fitting Strategy tab, where I used the Overrun feature option and set it to 12 points and check to use the Asymmetric Overrun option.
4. For those of you already using ArcGIS 9.3, click and show the Label Position tab, where you can now click a button called External Zones where you can refine the priorities for which direction the label will be offset.

4. Click OK or Apply to see how your map was labeled. Below is how mine turned out:

The only unplaced labels (to prove I didn’t fake this by creating annotation) were at the lower corners of my data view and occurred because those polygons were clipped just beyond the edge of the data frame (something Maplex does to help ensure optimal performance).

One last tip on this subject is for when you may need some additional logic in selecting which features should get leader lines. In some cases I’ve found it useful to base my leader line labels on the number of characters in the text that will be used for a label. I used to add an integer field to my data and calculate it to be ‘len([name]). It turns out there is an SQL Operator called Char_Length, which can be used to save the time an effort of creating a field. Here is an example SQL Query statement from a label class in another map I recently made:

CHAR_LENGTH("LabelStr") > 11 AND "CS_ID" in (720008, 720009)

In this case the data were stored in a File Geodatabase.

Last, if you’ve got any tips you use to better label features on your maps by using leader lines please share them as comments on this post.

ArcGIS 9.3 has hit the streets, meaning some of you should have it in hand this week, and most of you will have it in the coming weeks. After you get it installed definitely read the What's new in ArcGIS 9.3 PDF [13Mb] (it also installed with ArcGIS 9.3 at C:\Program Files\ArcGIS\Documentation\Whats_New_In_ArcGIS_93.PDF). Use the text search (CTRL-F) to find content, like "Maplex" or "Representations", or whatever term best describes the enhancement you've been hoping for.

Also new with ArcGIS 9.3 are the ESRI Resource Centers.  For those of you already familiar with Mapping Center, think of the ESRI Resource Centers as a broader context, with similar kinds (and more) of information available for all areas of ArcGIS. 

The idea is one-stop shopping.  One thing that is pretty cool on the ArcGIS Desktop Resource Center is the Content tab. You can add this content your maps.  The idea is that many of you (and over the next year many more of you) will never have to store certain base layers of data yourselves--you'll be able to use these services for that data when you need it.

Mapping Center's content is designed to be useful right now, i.e., for those of you using the currently available version of the software.  That won't change; by next week we'll be talking about ArcGIS 9.3 as if it was the only version in existence. We won't be systematically retrofitting any of our existing content (there's just too much), though we may, as we find it obvious, make spot updates.  If you think any particular bit of content would be much better off with a 9.3 perspective let us know and we'll get it on our "to do" list. 

Last,for Mapping Center it's business as usual.  Last week we bid farewell to one of our team members, Peter Kasianchuk, who headed back north to Canada after accepting a position at the Alberta Ministry of Energy.  We'll miss him; especially as we get ready for the Users Conference.
 

Not long ago we found a workflow that demonstrated how convenient it would be to be able to copy a representation class. The situation arose as we were creating a map service for a map that had been designed for print. The problem was that many of the symbols were too small and detailed to be seen clearly on screen. Our symbols were already cartographic representations, so we didn't want to edit them (to make them larger) because we still needed them to produce our print map. We also didn't want to have to create and manage an extra copy of our data just to manage one additional attribute (the one added for representations).

After a bit of head scratching, documentation searching, and interface exploration, our persistence paid off. We had at one point right clicked on our layer and noticed that the choice to convert our symbology to representation was still active. What's more, when we used this choice, it worked! It made a copy of our representations for the print map. That saved us hours of work, by having to edit only one property (size) of only some of the symbols our layer used.

One additional thing we learned in the process was that not only did our point layers need to be updated, but our fill layers that used representation markers also needed to be updated.

Put yourself in the shoes of one of my interns, who was asked to use representations to replicate a 1:100,000 scale geologic map.  In less than two weeks she got it done, and did so well that the next thing I asked her to do was to test ArcGIS Server and make a map service with her map. Those intricate little point symbols on geologic maps that are rotated by their strike angles and labeled with their dip angles were just too small to be seen clearly on screen.  We needed to make them bigger. 

I thought, great, we'll use overrides (using a field in the data to drive the size of the symbols, just like we already were doing to rotate the symbols by their strike angle).  Then it turned out we had to not only add a field (type = double) to our data, but also edit each representation rule (we had more than 100) to use our new field.  

Hindsight being 20/20, I would have had the person who set the rules up in the first place do their job a bit differently. Meaning I now think it a good practice to assume that some override fields should be pre-staged in the data model. This is definitely a good idea if there is a chance that you want to serve your paper map as a map service using ArcGIS server.  Once these fields exist and are used by your representation rules, you only need to copy the feature class and then calculate those fields to change the sizes (or other properties of your symbols) in one step.  

Once we had adjusted our representation rules it was quite easy to very rapidly experiment with several marker sizes until we got the best look for the map service. 

 

We got one of those perennial 'tough nut' questions on Ask a Cartographer today. The question has to do with using annotation versus on the fly labeling with Maplex and what are often called overflow labels, which I have also heard called "key lists". While we are able to recommend tips and tools for specific circumstances or implementations, the person asking was more interested in what is the best strategy and why. So here's their question:

"We produce a 1"=1000' City map book from our GIS, similar to the Thomas Bros. street guides. The street names are annotation which has been carefully placed to best fit and while we've looked at Maplex we feel that our annotation is currently the best solution.

An issue has recently been raised at to how to best handle the names which do not fit on the streets. What we've done up until now is to place a sequential number on the street(s) and then have a table placed nearby with the number and the street name. Each individual tables usually starts with the number "1" and sequences up.

This works fairly well in the map book format, where the page boundaries are predictable and the tables are placed with this in mind. However, it doesn't work so well with custom map projects, where the streets may be separated from the tables by the map boundary.

One proposal to make the maps easier to read has been that all the overflow street name should have an unique sequence number, city wide. This would make it easier to determine which table goes with which streets, but on the other hand I think we have around 750 street names in the tables, so the numbers would be large. This then becomes a larger issue when you want to add a new street to an existing table - do you have a number in the table which isn't in sequence, or do you re-sequence all the tables citywide.

Thomas Bros. has their overflow tables always starting with "1", but they have a symbol and letter ("A" in a triangle for example) which is placed by the tables and also by the streets to indicate which text block goes with which group of streets.

We see pluses and minuses with all three methods for labeling the overflows. We were wondering what others are doing and if there are other options out there that we haven't thought of, and also if there is a "best practice" that we should be following.

Thanks in advance for any ideas or suggestions."

Please respond in the comments with your ideas and suggestions.   

Last month I was lucky enough to be invited to the USGS's Digital Mapping Techniques (DMT) conference. Unless you do geologic mapping this conference is likely not on your radar, but suffice to say it worth the effort to get to Moscow, Idaho on many counts.  One is that I met Andrew Wunderlich, who gave a great and detailed presentation on how he has been migrating a base of Adobe Illustrator files to ArcGIS.  This question has appeared on Ask a Cartographer a number of times, where we've given a rather general answer.  Andrew got into the details, I know more than a few of your are faced with this task, so here is a link to the Powerpoint from Andrew's presentation.  Andrew is also working on some additional notes and we will let you know via the comments on this posting when those are available.

The vertical change in the elevation of the land surface, when determined over a given horizontal distance-along a road or stream, for instance-is known as its slope (Figure 1). There are three primary ways to quantitatively express the slope between two points. In each, the lower the slope value, the flatter the terrain, and the higher the slope value, the steeper the terrain. The slope values may be expressed as a ratio, as a percentage or as an angle.

Figure 1 - Slope is computed from the elevation difference (rise) between two points A and B on a topographic map and the horizontal distance (run) between the two points.

Slope Ratio
The simplest way to express slope is to describe the slope as the slope ratio between the elevation difference (rise), and the ground distance (run) between the two points (Figure 2). Mathematically, this is written as y/x. In Figure 1, a rise of 85 feet over a run of 630 feet gives a slope ratio of 85/630, which is 0.13. Slope ratios can also be negative-a fall of 30 feet over a run of 150 feet gives a slope ratio of -30/150, which is -0.20. Notice that the vertical and horizontal distances must always be in the same units of measurement.

Figure 2 - The slope of a surface between two points can be expressed as a ratio (A), as a percentage (B), or as an angle (C), where tan^-1 is read as "angle whose tangent is..."

Slope Percentage
You can also express the ratio as a slope percentage (also called percent rise) (Figure 3). To do so, simply multiply the slope ratio by 100. In the example above, the slope ratio 0.13 is also 0.13 * 100, or 13%. Slope percentages range from 0 to near infinity. A flat surface is 0 percent, and as the surface becomes more vertical, the slope percent becomes increasingly larger. In Figure 2, you can see that when the angle is 45 degrees, as in triangle B, the rise is equal to the run, and the slope percent is 100 percent. As the slope angle approaches vertical (90 degrees), as in triangle C, the slope percent approaches infinity.

Figure 3 - These triangles help demonstrate the comparison of the values for expressing slope as a ratio, as a percentage and in degrees.

Slope Angle
A third way to express slope is in degrees that relate to the slope angle (Figure 3). Slope angle values range in degrees from 0 to 90. This way of specifying slope is based on the fact that the slope ratio (y/x) is the trigonometric tangent of the slope angle. Consequently, the slope angle is the inverse tangent (tan^-1) of the slope ratio (the angle whose tangent is the slope ratio). A slope angle of 45° is a 100% slope, since this is the angle whose tangent and slope ratio is 1.0.

I have recently "invented" a method for simplifying polygon map layers, which seems to give reasonable results. Probably many others have invented it before me, but I would like to present it in order to receive comments and advice on setting the appropriate parameters.

My task was to produce a national soil map suitable at 1:1,000,000 scale on the basis of a 1:200,000 map. The best method would probably be to have a geologist or soil scientist make a complete re-production for the new scale - but we needed a less expensive method. The challenge was to find a technique that would not totally erase soil types represented as many small polygons covering more than half of the area in some regions. A traditional Generalize or Eliminate would have this result.

The basic idea is to convert the polygon-layer to raster (ArcInfo license required), apply a majority neighborhood focal statistics to this raster, and then convert back to polygons. The degree of simplification is dependent on the cell size chosen for rasterization and the size of the neighborhood area. One advantage with this method is that the outline of the major polygons is retained in the simplified version.

A few more steps are needed to get proper results:

1. If the polygon layer does not cover the whole analysis area - a typical example could be that the surrounding sea is not represented as a polygon - then you must initially make this "outside polygon" a part of the layer. If not, your polygons will grow into the sea.
2. The majority statistics computation may sometimes result in two or more values with the exactly same number of cells in the neighborhood. In the cases the cell will get the nodata-value. I get rid of the nodata-values by using a Con-expression that uses value from the original raster in these cells.
3. This step - and probably other things - may produce some very small polygons, that don't belong on a simplified map. I use Eliminate (in the version from ET Geowizards) to get rid of these. The area-limit in this elimination may be considered as a third parameter for the simplification degree (besides cell size and neighborhood size)

The whole process is packaged as a Python script that receives the simplification parameters as arguments.

If the original field used for symbolizing is non-numeric, the original content will be lost in the raster processing and replaced with a numeric value. But since the mapping between the numeric value and the original content is preserved in the VAT-table of the raster resulting from the initial polygon to raster process, it can be easily fetched back via a join on this table.

I have tried to experiment with different values for raster cell size and neighborhood size to get the optimal result for a given map scale. I think, however, that rules must exist for choosing the proper values. Can anyone give me a hint on this, or a link to publications on the subject?

Not too long ago we received a question on Ask a Cartographer about symbolizing polygons with a scalloped edge (like the old ArcInfo hardwire line symbol). Hoping to do better (scallop lines were a nice idea, but they didn't always turn out as good as I would have liked, so I rarely used them), I started experimenting with the options in representation symbology. I'm happy to report that there is a better solution.

I had some vegetation polygons from a project my team had worked on a few years ago so I copied those polygons into a new file geodatabase, added them to my map, and immediately converted their symbology to representations with out changing the  original randomly applied symbols.  By the way, I'm find that I use those steps more often now that I'm becoming more familiar with the representation symbology user interface, rather than trying to symbolize my data using the old symbols, and then fine-tuning the resulting representation symbols. 

I ended up removing the original stroke layer and adding a new maker layer.  To do that I selected the stroke layer tab and used the remove layer button (to the left of the paint brush button), then clicked the Add Marker Layer button (first button on th left below the properties tabs).

Then I used the button that looks like sideways triangle to change the marker placement option to Variable size.

Tip:  The two smallest buttons ("+" and sideways triangle) on this user interface are easily the most useful buttons in terms of setting representation symbol properties and effects.

I changed the marker symbol to a solid circle; I needed to change it's color to the green I wanted to use for my tree polygon. (First, I clicked on the marker, then in the Representation Marker Selector, I clicked the Properties button, then clicked on the circle to select it, and then changed the color by clicking on it at the right.)

Next, I applied the result to see how it drew on my map.  The markers were too large, and the default Step size of 1 was too small. So I set the Marker size to 4 and experimented, finding that a step size of 3 worked the best.  I also found that my polygons appeared a little too large, and the cure for that was to use the Offset property (at the bottom of the Variable Size property list), and I set it to -3, which effectively inset my markers on my polygon.  Here is I was able to do:

I started wth my original map which used a transparent fill with random markers didn't look so good when I zoomed in (the above image is a 50% reduction), and I could see the polygon vertexes as they formed facets along my polygon edges. The original map's scale was 1:5,000 and the above map was at 1:1,500 in my ArcMap session.

By using the representation symbols described above I was able to get this sort of effect.  But it seemed a little flat to me--maybe I was biased by the texture in my original symbol.

So, I made a copy of my data, and using the Editor I offset the features in the copy.  (Started Editing, selected all the features in the copy of my trees data, and moved them a little to the right and down).  After I created representations for my offset features, I gave them the same symbology as described above, except I changed the color to 70% gray and set the layer transparency to 75%.

The examples given here were only examples--I have only visited Boise during the fall and winter, when there were no leaves on the trees, so I'm not sure how faithfully I've rendered this relative to how it looks on a nice June day.  But, adjusting the symbol size and the offset will allow this effect to better fit reality.

Making maps with data that were never intended for mapping has it's challenges. One of them is trying to use the names from GNIS (Geographic Names Information System) (U.S. Board on Geographic Names).  Even when someone has gone to the effort of assigning these names to GIS features, the way the names are formatted can create problems.  In the case of the GNIS, the names were formatted for an old-style (i.e., pre-modern search engine) alphabetical index that you could visually scan like a gazetteer in an atlas.  The result is that there are entries like "Great Salt Lake, The" or "Grande, Rio" which need reformatting in order to look correct on a map. 

As a general rule if a name in the GNIS, or data compiled with GNIS names, has a comma, then it needs to be edited.  Rather than manually edit each of those names, I felt it would be handy to have something to automate that work. So I wrote a field calculator statement that you can download to do the job.  It gets the portion of the name after the comma and moves it to the front of the string, and removes the comma.

Be careful, first select by attribute all the features that have a comma in the name; minimally it will save time:

"GNIS_Name" LIKE '%,%'    (this is using the correct syntax for file geodatabase format)

Once the features are selected, verify that you have no unexpected commas.  Then while that selection is still applied, calculate the field by loading the FlipAroundComma.cal file that is inside the ZIP file in the hyperlink above.

The result will help your maps look more professional.