5 replies to this topic

[Nick Springer]

Pardon me if I don't se the right terminology for things, as I don't use Arc very much.

I have been working on a dynamic mapping project for the web. I have been carefully crafting my design in Arc map at different scale levels, etc. I had the MXD file looking very good on the screen, but when the client put it in the ArcGIS Server web interface, the map looked TERRIBLE! Line weights were all out of whack. Labels and point symbols were funky.

Are we doing something wrong going from the MXD to the web? Is there someway in ArcMap to see it as it will be rendered online?

Here are some comparison images (MXD on the left, web on the right):

 california_mxd.png   58.8K   111 downloads  california_web.png   81.73K   102 downloads

 san_francisco_mxd.png   76.81K   102 downloads  san_francisco_web.png   76K   95 downloads

[paul]

Nick - while it's pretty easy to get a map service up and running using AGS, it's a bit harder to get everything looking good and readable for web viewing. A few general tips that I've picked up during my own efforts:

1. Keep symbology as simple as possible. Try to avoid line casings, complex polygon/point symbols, and other cartographic luxuries. There is a Style called something like "ESRI Optimized" that you should try to use for your mxds that are going into web applications. I've learned to think of web maps as showing only the bare essentials and nothing else.

2. Use scale thresholding in tandem with tile caching. Your tile caches should correspond with your .mxd scale thresholds for best viewing. This will ensure that your labeling and symbology looks right at all the scale levels specified, and also gives your server a performance boost by pre-caching the tiles.

3. For base maps, you can use some of ESRI's map services. This way, you don't have to worry about cartography, scaling, and rendering for these base layers, and can just focus on the focus or custom content of your map.

[Nick Springer]

Paul,

Thanks for the reply. Unfortunately none of this will really work for me

1. Keep symbology as simple as possible. Try to avoid line casings, complex polygon/point symbols, and other cartographic luxuries. There is a Style called something like "ESRI Optimized" that you should try to use for your mxds that are going into web applications. I've learned to think of web maps as showing only the bare essentials and nothing else.

That's a pretty huge limitation of ArcGIS Server if you can't really do any nice cartographic style. The client wants a unique design and need specific base map layers so I can't use the "Optimized" style. If they wanted that they wouldn't have needed to hire a cartographer

2. Use scale thresholding in tandem with tile caching. Your tile caches should correspond with your .mxd scale thresholds for best viewing. This will ensure that your labeling and symbology looks right at all the scale levels specified, and also gives your server a performance boost by pre-caching the tiles.

The map has dynamic data, so caching is not really an option. I have plenty of scale levels already in the MXD, the issue is the line weights and font sizes.

3. For base maps, you can use some of ESRI's map services. This way, you don't have to worry about cartography, scaling, and rendering for these base layers, and can just focus on the focus or custom content of your map.

The built in base maps do not serve the purposes of the map content unfortunately.

[paul]

Nick - are there any layers that are NOT dynamic? If so, you could put these base layers in a different mxd, create a separate map service, and perform tile caching. You could then have the dynamic layers as a separate map service. Doing this probably won't solve all your problems, but may solve half of them.

Also, when you have a cached map service within a web application, the I'm pretty sure web application becomes constrained to those tile scales, even if there is an uncached map service too. This means that if your cached map service has 8 different cache scales (for example), then your final web application can only be zoomed to those 8 pre-set scales. I think a lot of your display problems may be occurring when the user zooms to "in-between" scales, where symbology and labeling is not optimized. With caching, and a finite amount of viewing scales, the scale-thresholding in ArcMap becomes a lot more predictable and testable.

For example, if you cached a base map (non-dynamic data) at 1:12,000, 1:24,000, 1:100,000, 1:500,000, 1:1,000,000, 1:10,000,000, then you can pretty much count on the web maps looking the same as the mxd at those scales. In addition, you could set up the same scale thresholding for the non-cached (dynamic) service. When you overlay the dynamic service on the cached service, they should mesh seamlessly, and the available zoom levels of the entire web application should match the levels you set up with the cached service.

Sorry for the rambling. Some of this is a little underwhelming, but I do think the key is to constrain your scales to improve (and predict) run-time rendering.

[Nick Springer]

To me it really just looks like the server is making line weights, symbols, and font sizes larger - everything else is intact. It seem to me there must be some parameter or setting we can adjust to synch these up between the MXD and the Server.

[Nick Springer]

OK, we have figured it out partly. When using a basic web interface for ArcGIS Server, it seems to be making a request for a 72 dpi image, and since ArcMap seems to assume 96 dpi, it is throwing off line weights and font-sizes. The good news is that the final app is going to be in Adobe Flex and that allows you to specifiy the dpi, and when we make a 96 dpi request everything looks fine.