Ask A Cartographer

map cache and road labels

June 03 2008 | 1 comment
Categories: ArcGIS Methods, Labeling, Maplex, Publishing

i am building map cache for use in ArcServer map services. i understand that these are much faster than using the standard .mxd. I also understand that i can use multiple .mxd files to create map services that can be combined in ArcServer webclient. I have a couple issue with the cache that i need help with. i am wondering if there are some standards that ESRI uses in there mapservices that might help as well.
first issue: the 'smoothness' of the line work seems to be controled by the DPI. the standard is 96 but this results in a 'choppy' effect. if i raise the DPI then the size of the cache goes up. it also is clear that all mapservices that are used in combination need to have the same DPI or they appear to be at different scales. I have tryed using the anti-aliasing option but it seems to make little to no difference. what advice do you have?
second issue: when i make a cache of my roads layer the labels are being cached as well. if i overlay this layer with my sewer pipes mapservice the street names get obscured. if i use the non-cached mapservice the labels appear on-top. is the only solution to this to create a seperate layer in the arcmap TOC that is street labels and build a cache of just it? i have attached a simple screen shot that illustrates both these issues.
thanks for your time.

Mapping Center Answer:

First, with regards to line smoothness. There are a couple of things beyond DPI that affect this, though I would first advise the DPI may only serve to confound the issue in the end as DPI must ultimately relate to the resolution of the web client screens. Instead, there is the option to smooth the edges of lines and text (the programmer put "Antialiasing" in parentheses, though strictly speaking we are not using antialiasing so much as something like it). Since you said you tried the smoothing, my only question is what image format? I find that it works best with JPEG, whereas, I would advise not using it with PNG.

Another aspect of this is how we relate the map cache scales to scales in the client software packages that view the cached maps. The main issue here is that for clients, like Google Maps that force you to use their scales (using that calibrated zoom tool), you only ever get the cached tiles at the screen resolution, so they always look good. However, for clients like ArcMap or ArcExplorer the issue is that these clients can zoom to any scale and will sample or extrapolate your cached tile to that scale. In 9.3 we improved the logic for this quite a bit, and we also developed a JavaScript REST-based client that works like Google Maps in terms of how you zoom.

We also use some tricks to deal with this problem.

Use a cased line or drop shadow with the text.
When labeling line features, particularly if the text symbol or line symbol are cased, make sure the offset from the feature is increased from 1.0 points to least 2.0 or even 2.5 points.
Legibility is also a factor here, so the text should be at least 9.0 points if you are using curved text.
Given your image, one thing that would help your roads layers is to use Maplex, and particularly to use the Street placement option will will turn on the word spacing option, which will allow the individual words in your street names to be placed and spaced to allow other data to show between the words. I would also abbreviate the street types (Street to St, Boulevard to Bl, etc.) right now your text for street names, which isn't the main point of the map is dominating the map. Label weights are the next step--definitely set a value of 100 for your sewer lines. That will force some of those labels to other locations.


comments to date posted by Charlie Frye on Jun 3 2008 2:03PM
Sorry--we had a glitch with this topic, so we reconstructed the comments to date here:

First thanks so much for your quick and useful reply.

Please define ‘cased text’ is that the same as masking? I am doing that already.

I will play with the maplex option and see if that helps. I am not sure this really address the issue of the labels being part of the map cache.

I have been using the default .png format so that I can use transparency as there are many mapservices being displayed as caches.

I am viewing these services through a browser not arcmap or arcexplorer.

Can you explain a bit more about the java-rest api and how it is like google maps zoom.?


I wasn't trying to avoid the topic of caching strategies as hope that it could be alleviated with symbology.

So, first, cased text wasn't what I wrote, which was cased line symbols or text with drop-shadows. The drop-shadow is less obtrusive than halos or masking polygons. The Mapping Center Blog entry: Can you read me now? deals with the symbology issues; the main thing that would help your display is to have the text take up less space on the map.

As for caching strategies, it sounds like you're leaning towards allow users to turn layers on and off. First, I would suggest thinking about that carefully--but not from the point of view of how much work it will be for you to built the caches. Instead, this is a usability issue--you were on the right track in expressing concern for having to have an additional layer just for street labels. A good rule of thumb for map services is to have the fewest number of layers possible. One layer being best, with two or three being the most. Seven or eight or more layers will just overwhelm the typical consumer of mapping services. So, making the service simple and it's usage obvious is the first thing to do--you really don't want to have to teach people to use your map service or application.

But if that still leaves you needing a solution that means you map needs to be disaggregated into layers, that when viewed in the map service client, need to play well together, so to speak, then here is what I would recommend:

Produce annotation for any layers that require a high level of refinement with regard to text placement. That means any other layers with labels going into your cache will have their labels placed relative to that annotation. Basically I'm saying you have to pre-make your most complex map product and then disassemble it when you cache it. If you have two layers with labels, at least one layer must be converted to annotation; if you have three layers with labels, then at least two will have to be converted to annotation, and so on.

At that point, you have the basis to create a set of map caches that when stacked together will show a composite, if busy, picture of your data. If you instead wanted to have a wide variety of layers available, and always looking good then you've got a problem because you cannot pre-can that map and you must rely on your users to do the cartography. Two solutions there: 1) Use feature services and expect the users to be using ArcMap, ArcExplorer, or ArcReader. or 2) pre-compute a small number of map services that each focus on a different aspect of the overall topic.

Last, I almost always regret mentioning stuff that's not quite available, like the Java Script API client that's coming in 9.3. I don't have a reliable service to point you to in order to show it off. Nor can I precisely comment on the availability of 9.3, other than it's imminent, as in coming this summer prior to the Users Conference.

If you would like to post a comment, please login.

Contact Us | Legal | Privacy |