A frequent discussion topic between Latitude Geographics team members and our customers is the Esri release plans for ArcGIS for Server 10.1, and Esri’s plans to deprecate ArcIMS (details at the Esri blog).
On October 12, we will be providing a free webinar to provide guidance on migrating from ArcIMS to ArcGIS for Server. We will also demonstrate an approach that can help accelerate this migration by gaining efficiencies in the design, development and maintenance of web-based mapping applications.
Often, making small changes to map symbology and the properties of layers can significantly reduce a map's drawing time. Here are some tips for map optimization:
Confirm all data are in the same projection. On-the-fly projecting can make your map take twice as long to load.
Data should be representative of viewing scale: generalized data (e.g. county boundaries, lakes, highways) can show at full extent, detailed data (e.g. parcels, local streets, imagery) should show only when zoomed in.
Use simplified data at smaller scales. For example, a detailed coastline may draw slowly at full extent. If it is simplified to have fewer vertices and line segments, it will draw much faster with little difference in appearance at full extent. The more detailed data can be used at closer zoom.
Set minimum scales (maximum zoom level) for all layers, and set MXD project full extent.
Minimize use and extent of labels.
Minimize use of offsets and masking.
Avoid serif fonts, as the "twiddly bits" take longer to draw.
Avoid using joined data. Instead, export the data to a new feature class that contains the joined data. If you must use joined data, check out the performance tips for using joined data in the ArcGIS Desktop Help.
Use queries where possible to remove features that are not required on your map.
Point, line, polygon draw order is generally preferred – note that transparent polygons may be best displayed as topmost layer.
Use the “ESRI optimized” symbol set for lines and polygon fills:
There are hundreds of map projections out there and knowing which one to choose for your map can sometimes be a challenge. When choosing a projection, you should consider what your data are showing, which qualities you need to preserve (shape/area/direction/distance), and who your audience is. If you are mapping population density, for example, your map is showing the number of people over a certain area, so you would want to choose an "equivalent", aka "equal area" projection to best preserve area. If your audience is not geography savvy, then a conformal projection that preserves shape may be your best choice because it will make your map "look right". If the area that you are mapping is relatively small (e.g. one U.S. State as opposed to all of North America), you will probably find that there is a projection designed specifically for your area (e.g. a State Plane projection). Your data may also dictate which projection to use - if the majority of your data is already in a suitable projection, then it will be most efficient to stick with that. If you really aren't sure which projection to choose, search the web for maps of your area - you will often find that most of them are in a certain projection.
Jade previously blogged about a MXD to AXL converter script, which is a great tool that I use all the time. We also recently discovered the ”GDK ArcTools” script which enables you to convert the other way – AXL to MXD. While it isn’t perfect, it saves a lot of time by setting all of your data paths, layer names, max and min scales, and successfully converting simple symbology, such as solid fill polygons, and basic points and lines. Value map rendering, grouped layers, raster marker symbols, and labels usually need to be redone or tweaked, but if you are dealing with a lot of data it can be a great start.
In my last post I mentioned a way to get distinct values for a featureclass out of ArcIMS. This involved bending the rules 'creatively', but it got the job done which was the ultimate intent. Recently I was discussing with some colleagues another frustrating issue with ArcIMS; namely, that of stacking an ArcIMS image on top of (or below) a WMS image. Since ArcIMS has no native WMS client capabilities, we're always forced to stack the images in the browser. This can have some unfortunate side effects - partially transparent polygons become opaque, and antialiasing goes straight out the window. Observe:
This is the standard Geocortex IMF demonstration site, with the USGS Shaded Relief WMS dropped behind. Notice the absence of image behind the jurisdiction layer, the poor antialiasing of the roads over the shaded relief, and the barely legible "Gaston" label.
Now, we can't make ArcIMS become a WMS client, but we *can* work around these issues if absolutely necessary. What happens from the IMF perspective when we generate this image is that it requests the WMS image from USGS, and at the same time requests the ArcIMS image. It then drapes one over the other in the user's browser. If we changed the workflow a bit, we can do the following:
Request the WMS image
Save the WMS image somewhere the ArcIMS server can get it
Add an acetate layer to the ArcIMS map with a single polygon. This polygon will cover the same area as the current map extent, which will also be the same area covered by the WMS image.
Use a RASTERFILLSYMBOL to paint the polygon, and use the WMS image as the source.
Using this trick, our image now will look like this:
Ahhhh, much better!
Note that I did take the liberty of changing the symbology slightly for the jurisdictions layer to work well with the WMS, but you get the idea :)
After working with ArcIMS for 7 years, I've learned to accept some limitations. Sometimes though, requirements dictate that we "bend the rules" a bit. One recent challenge was to determine the distinct values for a field in an ArcIMS layer. Since ArcIMS queries have no "distinct" clause, we had to get creative. Here are the two options we came up with:
Query for a bunch of records (say, 50). Get the unique field values from those 50, and query again, this time filtering out records that are NOT the ones we've just found. Repeat until you get no new records from ArcIMS or until you have more records than you can handle, whichever comes first.
Formulate a special WHERE expression, in the form OWNER.SCHEMA.TABLE.OBJECTID IN (SELECT MAX(OBJECTID) FROM TABLE GROUP BY UNIQUE_FIELD). A real-life example that can be used on our Geocortex IMF Demonstration Site (try the query builder on the Geocode Streets layer) is: SDE_CHAR_VMB.SDE_CHAR_VMB.CNTY_STREETS_V.OBJECTID IN (SELECT MAX(OBJECTID) FROM CNTY_STREETS_V GROUP BY SUBDIVISIO)
The first option is the only possibility for shapefile-based data sources, and for SDE data sources with non-unique OBJECTIDs. I'm partial to the second one though because it takes only one query, it's very fast (even for finding the 200 unique values in layers with hundreds of thousands of features), and it showed me that subqueries in WHERE expressions to ArcIMS are possible.
I'm curious to see what other clever things can be done with ArcIMS using sub-queries...