ArcGIS Server: Making the map everyone needs
ArcGIS Server: Making the map everyone needs
Thinking about ArcGIS Server like a GIS office in a box is a good trick to help understand the inner workings of the software and relate it to workflows and processes many GIS practitioners are familiar with. Let us consider for a moment, the situation where our organization has the need for a map that shows all the important landmarks in the area…. the map with the parks, waterbodies, points of interest and streets on it. Most of the time this map is used to just help someone figure out where more important things are located. Like where is a project occurring, or where certain assets are located, or where is my house? However, the thing about this map that makes it different is that everyone wants to see it and if things change a little it’s not going to affect its overall usefulness. In ArcGIS speak, this is a basemap.
Because of these special properties, our GIS office prepares for printing a whole bunch of these maps in such a way that it won’t affect the normal operations of the office and plans for a process of updating the map as needed over time. While this map is advertised through the office’s normal channel, it’s serviced completely differently than “normal”.
To create a service in ArcGIS Server in such a way that we achieve high throughput… lots of responses to requests… and not affect the rest of the server’s processes, we draw the service at the time it’s asked for by clients from a set of cached tiles. These tiles typically are created before anyone asks for them, are created at multiple levels of detail, and are captured in a format most conducive to the data we are trying to show in it. In our ArcGIS Server office-in-a-box, there are special GIS analysts whose sole job is to make these maps. These are the instances of the CachingTools service in the system folder of ArcGIS Server. This service is not advertised to the rest of the organization, as only the manager of our office tells this service when to work. Also, this analyst typically works at nights and weekends when no one else is around, so they get all the resources of the office to themselves.
Once the analysts have invested the time to make a full set of seamless non-overlapping sections of the map at different scales (because remember this is just a metaphor and our GIS services are used in interactive maps with zoom in/out capabilities) or tiles, the tiles get sorted and organized. Where these tiles are stored is defined by the office manager. Depending on the size of the organization, the number of cached services, and the performance of the supporting infrastructure - all the cached services could share a single location or at the other extreme each cached service could have its own storage location defined for it. In our office you could think of this as one set of cabinets where the maps are stored or in separate rooms that people must go to get the map they specifically want. These different approaches are taken for efficient storage and retrieval purposes, balanced against cost and more disk space.
No matter the approach chosen for tile storage and management; the default structure of the storage is consistent. All the tiles for a service are stored together in a single folder. However, this folder is many levels deep. There is a well-documented structure that ArcGIS Server uses to organize these tiles based on the scale, or level of detail (LOD), at which they were generated, and the general location where they are in the extent of the service. When making the tiles ArcGIS Server will partition the full extent for a LOD into large areas called supertiles to manage the label generation. This supertile is then rendered into many smaller tiles that are aggregated together for storage in a binary file called a bundle file.
When a customer needs to see the basemap, ArcGIS analyzes the extent and scale of the request to view the map and fetches the needed tiles to fill the display including a ring of tiles surrounding that extent. When the client asks for these tiles the receptionist, the tile handler process, goes and gets the tiles for the client. Having received the tiles, the client displays them. But the client application can also store the tiles it receives in a local cache on the computer’s hard drive. You can kind of think of this like putting the map up on the wall of their office. As the person pans around the map, the application can just grab the tiles from the local cache and does not have to go back to the GIS office to get the tiles again. This makes the ArcGIS Server basemap layers always display the full extent of the current view of an application and makes them extremely fast.
Sometimes though things change, and our cached services need to be updated to show those changes. For each cached service, we can set the cacheControlMaxAge property (in seconds) which says how long a client will use its locally cached tiles for a service until it needs to get new tiles from ArcGIS Server. You can think of this as a time stamp on the wall map that says this map is good for some time, and after that time you need to go check at the office for an updated map.
Through this article we looked at how ArcGIS Server is used to create and store tiles for our cached basemap layers in ArcGIS. In our next articles, we will look at the analysts in our office to see how they are leveraged to respond to and optimize our operational layers by looking more closing at dynamic layers in ArcGIS Server.