Image compression for Ortho map cache

I took a minute today to analyze how much JPEG compression is appropriate for cached map services (ArcGIS Server) that are displaying an aerial photo. With JPEG compression you can set the quality between 1 and 100. 100 is more quality but less compression. Wikipedia actually has a great example of this. All of this stuff also applies to creating a map cache for imagery. So I set up a little test to see what the difference is between JPEG 90 and JPEG 55. I used 2008 orthophotography imagery for Hamilton county Indiana. I cached the map using the Bing Maps / Google Maps tiling scheme. Then I added a scale (1:575) on the bottom to build the cache down to the resolution of the 6 inch imagery. I figure this is what most people would do to get their full raster resolution in the map cache. The cache took a little over 9 hours to create for both services (2x3.59 Ghz CPU's). The first big difference was the size:

• JPEG 90: 32.8 GB
• JPEG 55: 15.1 GB

So JPEG 55 is about half the size of JPEG 90. That means that it will download about twice as fast in a web browser. Of course this is only part of the overall performance of the application but still it is pretty significant. Now what about the quality?

JPEG 90 at small scale




JPEG 55 at small scale




JPEG 90 at medium scale




JPEG 55 at medium scale




JPEG 90 at large scale




JPEG 55 at large scale




For my money the decision is pretty easy. JPEG 55 is half the size and very close on quality. You should certainly test this out when building your own cache though. Also, this is assuming there is no vector data in the map. When you have vectors in your map you need to go with JPEG 90 to keep the lines crisp. Or a better option would be to seperate the vectors into their own service and draw them on top of the ortho. This way you could use PNG 8 for the vector and JPEG 55 for the raster and get the best of both worlds. You can see that google maps is even doing this with their image service.

ArcGIS Server and map service projection on the fly

With ArcGIS 9.3.1 and the "Analyze Map" tool on the Map Service Publishing toolbar folks are realizing that projection on the fly can have a huge impact on map service performance. This leads people to think that maybe they need to project all of their data to WGS 84 or WGS 84 Web Mercator to get the best performance in their map services. This blog discusses projection on the fly as it pertains to performance for MXD or MSD based map services.

As a general rule I don’t think you need to projecting everything to WGS84 (or whatever coordinate system you are mashing up with). Map services do perform best when there is no projection on the fly happening in the MXD / MSD. But there are two places that projection on the fly can happen: within the MXD/MSD and within the map service. When you do projection on the fly within the MXD/MSD you are doing this projection on every layer in the map on every map service request. This is a lot of work and this can have a big impact on performance. When you do projection on the fly in the map service you are projecting the resulting map. This projection happens once for the entire map per request and is therefore much faster than the MXD/MSD projection on the fly.

When you have a dynamic map service who's map is using UTM (or some other local CS), it will automatically project on the fly to other map services in your application. So if you are using a WGS 84 base map from ArcGIS Online, your dynamic UTM service will overlay just fine.

Performance tip: with dynamic services, set the projection of your map to the same projection as your data.

This map service projection on the fly, does not work with cached map services. So for those map services that you are going to cache (all base maps and some of your operational layers), you need to change the projection of the map to the projection of the other services you are going to mash up with (e.g. WGS 84 or WGS 84 web mercator). In this case you would pay the price for projecting on the fly within the MXD/MSD. This would slow down your cache creation but you would get the great performance of a cached map service on each map service request. If you are building a very large cached map service, you should probably consider extracting your data to a file geodatabase just for the cache creation. A local (to the GIS server) file geodatabase is going to give you your best performance for cache creation. When you create this copy of the data for cache creation, you can project it to the coordinate system of your map service (e.g. WGS 84). The best tool for doing this is the Extract Data Wizard. Check out “Copying a geodatabase using the Extract Data Wizard in ArcMap” here: http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Methods_for_copying_geodatabases

Here is info on extracting data to a different coordinate system.

http://support.esri.com/index.cfm?fa=knowledgebase.techArticles.articleShow&d=34129

The Extract Data wizard is a great tool for this because it can create a copy of your map document that uses the extracted data.

In summary, store your data in the coordinate system that makes the most sense for your data maintenance, management, and analysis. Your map services can use this data to make fast maps in any coordinate system. One final curve ball is that ArcGIS Online will be moving to WGS 84 Web Mercator later in 2009 (see the ArcGIS Online blog for more information ).