I have the New Zealand 1:50,000 Topographic Database and I wanted to serve out several layers from that database using ArcGIS Server. The intention was that this service be used as a basemap for mapping projects as well as a test for and demonstration of the caching abilities of ArcGIS Server. Topographic data is an ideal candidate for a cached service as it is updated infrequently, yet is commonly used as a base map in applications, and at many scales.
The source data from Land Information New Zealand (INZ) was in Laserscan IFF format, and came in seven modules (hydro, relief, transport etc.) each with a number of logical layers, with a total layer count of around 140. The first step was to make this manageable through subtyping point, line and polygon feature classes for each module, reducing the feature class count greatly. Subtyping means creating within a feature class a number of feature subsets which share the same attributes. For example the structures feature class in this service has many subtypes including beacons, schools, windmills and so on.
In all, this service includes 29 different layers of data which reside in File Geodatabases totaling many gigabytes of data.
After all of the symbolization of the data layers I published the map document (.mxd file) as a map service in ArcGIS Server. Once the map service was published, I was able to create the cache.
I tried numerous types of caches with varying parameters. It turns out that using JPEG images is the best option for this basemap layer due to its support for large color variation in a manageable file size. The compression of the JPEG images was set at 90, with a resolution of 96 dpi and a tile size of 512 by 512 pixels. I also choose to use anti-aliasing which is a way to make lines and labels appear clearer after caching.
I cached the map at 6 scales to cover the 269,000 km2 of the New Zealand landmass:
- 1:5,800,000
- 1:1,200,000
- 1:300,000
- 1:100,000
- 1:50,000
- 1:20,000
The caching process running with 2 SOC instances ran for 96 hours before it completed with no errors. It created 311,869 files in 1,055 different folders taking up 5.26Gb of disk space.
I have used the service in ArcMap, ArcGIS Explorer and a Web Application with great success. The cache allows the cartographically complex map to run very fast in these applications.
View the cache in a sample application
Download a map document referencing this service
Contributed by Kurt Janssen of the ArcGIS Holistic Test team
5 Responses to Map caching case study: New Zealand topo maps
Leave a Reply
You must be logged in to post a comment.
That is interesting Steve. 5Gb is very resonable, especially after seeing the 55Gb size of your cache.
The shape of New Zealand and its very complex coastline means that there are many blank tiles or tiles with just a snippit of landmass on them. Many of these tiles are only a couple of kb. Its therefore somewhat missleading in the sense that many of the tiles take up minimal disk space hence reducing the overall size of the cache.
Tim- In this situation you could create a small buffer around the railroad and use the “Update specific areas using a feature class” option in the caching tools.
You’ll still get some empty tiles because the server draws a large area before cutting it into the 512 or 256 px tiles for your cache, but if you are caching the entire country at large scales, you can save a lot of space caching by feature class boundary this way.
The above is the 9.3 solution. At 9.2 you’ll have to cut your buffered railroads into smaller regions so that you don’t get the whole X,Y envelope (9.3 actually follows the feature boundary). Then feed it to this script to cache by feature class: http://arcscripts.esri.com/details.asp?dbid=15161
This tool can help you cut up your buffer or any other feature class into a few manageable square regions: http://resources.esri.com/geoprocessing/index.cfm?fa=codeGalleryDetails&scriptID=15896
I’d be interested in hearing peoples’ experiences with caching by feature class boundaries. In the near future I hope to write a post with some best practices for this.
J- Thanks for sharing this map. We’re very curious- how’d you come up with the 384 px tile size? Have you experienced any issues with the software related to using this size?
Allan. The data is available from resellers. They can be found on this website; http://www.linz.govt.nz/topography/topographic-data/vector-extracts/data-distributors/index.aspx
The other option is to if appropriate simply use the service we have published to create overview maps though the data is not the latest available.
Cheers
@Eamonn- The size of the cache will vary greatly depending on what image format you are using and how much color variation occurs in the tiles. Probably the closest guess you can get is to create a feature class of a representative portion of your map. If you’re caching a country, maybe pick a medium sized urban area with a chunk of surrounding countryside. Create a test cache of all scales using just this feature class and note the size.
Then use the Calculate Geometry tools to calculate the areas of both your test feature class and the feature class of your full cache. Once you have those values, you can use equivalent fractions to estimate how big your full cache will be. For example, if it takes 1 GB to cache 1000 square miles in the test cache, you can guess that it will take 100 GB to cache 100000 square miles in the full cache.
It’s only worth going to this trouble if you know your cache will be very large and will take days/weeks to create.
ArcGIS Server 9.3 SP1 has a caching progress bar, so another way to estimate would be to cache, say, 10% of your map and note the size, then extrapolate.