Jump to content

 
Photo

ArcGIS Server rendering

- - - - -

  • Please log in to reply
5 replies to this topic

#1
Nick Springer

Nick Springer

    CartoTalk Founder Emeritus

  • Moderator
  • PipPipPipPipPipPip
  • 939 posts
  • Gender:Male
  • Location:Crosswicks, NJ
  • Interests:Cartographic Design, Print Maps, Graphic Design, Web Development, Ultimate Frisbee
  • United States

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):

Attached File  california_mxd.png   58.8KB   111 downloads Attached File  california_web.png   81.73KB   102 downloads

Attached File  san_francisco_mxd.png   76.81KB   102 downloads Attached File  san_francisco_web.png   76KB   95 downloads

Nick Springer

Director of Design and Web Applications: ALK Technologies Inc.
Owner: Springer Cartographics LLC


#2
paul

paul

    Key Contributor

  • Validated Member
  • PipPipPip
  • 75 posts
  • Location:Logan, UT
  • Interests:Running, telemark skiing, GIS
  • United States

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.

#3
Nick Springer

Nick Springer

    CartoTalk Founder Emeritus

  • Moderator
  • PipPipPipPipPipPip
  • 939 posts
  • Gender:Male
  • Location:Crosswicks, NJ
  • Interests:Cartographic Design, Print Maps, Graphic Design, Web Development, Ultimate Frisbee
  • United States

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.

Nick Springer

Director of Design and Web Applications: ALK Technologies Inc.
Owner: Springer Cartographics LLC


#4
paul

paul

    Key Contributor

  • Validated Member
  • PipPipPip
  • 75 posts
  • Location:Logan, UT
  • Interests:Running, telemark skiing, GIS
  • United States

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.

#5
Nick Springer

Nick Springer

    CartoTalk Founder Emeritus

  • Moderator
  • PipPipPipPipPipPip
  • 939 posts
  • Gender:Male
  • Location:Crosswicks, NJ
  • Interests:Cartographic Design, Print Maps, Graphic Design, Web Development, Ultimate Frisbee
  • United States

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

Director of Design and Web Applications: ALK Technologies Inc.
Owner: Springer Cartographics LLC


#6
Nick Springer

Nick Springer

    CartoTalk Founder Emeritus

  • Moderator
  • PipPipPipPipPipPip
  • 939 posts
  • Gender:Male
  • Location:Crosswicks, NJ
  • Interests:Cartographic Design, Print Maps, Graphic Design, Web Development, Ultimate Frisbee
  • United States

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.

Nick Springer

Director of Design and Web Applications: ALK Technologies Inc.
Owner: Springer Cartographics LLC





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

-->