Sometimes I find myself pondering on how map services are magical. You and your users can access your data from anywhere, have it draw in seconds flat, and updates to data can appear to be unnoticeable to your users. The list goes on. I have been working with publishing map services for just over 3 years now for MarineCadastre.gov and am still amazed by the magical powers they possess. I want to share with you some of the best practices I use to make my services even more magical to our users.
When you publish map services it all begins with the data. You have to have the data first, then the map document to publish it from, then the server to publish this to. So, naturally when you are looking to enhance or improve the performance of your map services you will want to progress through the items in that order as well: data, map, and then server. Always keep in mind the audience you are appealing to. And while your end user could be quite possibly anybody, I try to think of what I would want to see and how I would want things to behave.
Read through these 10 spells you can perform to get your map services to work like magic. All of these are intended to help make your data and services more responsive and intuitive for your audience. Again, these start with the data itself and progress through the map and then server – as you would step through publishing services.
(The below information is in specific regards to publishing map services through Esri’s ArcGIS Server environment at 10.1 and beyond, but the concepts can be applied to other server platforms as well.)
REFRAIN FROM USING UNIVERSAL FEATURES
When a service draws a layer it draws the whole layer not just the portion of features shown within your screen. Layers draw much quicker when all the features are separate. In other words no multi-part geometries!
(Tip: use the multipart to singlepart tool to explode your features).
PROJECT YOUR DATA IN WEB MERCATOR
All web services are drawn in the web mercator projection whether or not the data contained within them have this projection attributed to them. If the data are in a different projection, the server has to do the work of projecting the data on the fly which could slow down the drawing of your service. Lift the load off the server by doing the work up-front. Project all the data in the map service to web mercator.
SPELL OUT WHAT YOU MEAN IN YOUR LAYER AND FIELD NAMES
Avoid abbreviations within layer and field names. Do not leave your user guessing or left searching for metadata to find out what your layer or field names mean. Spell out the layer and field names themselves or at least take advantage of using aliases to spell these out for your users.
(Tip: Include units of measure within field aliases when applicable.)
USE SENSIBLE COLORS AND SYMBOLS
Use intuitive colors within the cartography of your layers. Use typical associations like red could mean stop or bad, green is go or good, water is blue, etc. Consider removing scale dependencies or at least having scale dependent cartography set-up so a user at least knows data exists no matter which scale they are viewing. Imagine being zoomed out to the contiguous United States turning on a layer and have nothing appear. You think there is no data or something is broken and you become dissuaded from using that layer again. This experience could even discourage users from using any associated products or even keep them from visiting your website again. By removing scale dependencies, even if things are slow to draw, this provides your users feedback – showing your users that data does exist.
THINK ABOUT HOW THE LAYERS INTERACT WITH EACH OTHER
Within the map document you are using to publish your data, think about the layer order in a logical manner. Not just the usual geometry based order of points, lines, and polygons but also think about the order between these geometry types. How do the layers themselves work with each other? Which layers may your users determine to be more important? Think about the interaction between the layers. How do they complement or interfere with each other?
DO NOT OVERWHELM YOUR MAP WITH TOO MANY LAYERS
On the same topic of layers in your map document do not overwhelm a map with too many layers or layer groupings. Weigh the possibility of splitting the groupings into separate “themed” map services. Try to think about how your user will interact with the layers and which layers are best suited to be drawn on top of the next.
PROVIDE GOOD DESCRIPTIONS OF WHAT THE DATA IS AND HOW IT COULD BE USED
Within the map document there are several locations where you can provide contextual information to your users. Within each of the layer properties you can provide a description and give credit to the data provider (including your own organization). You can also provide more information within the data frame and map document properties, such as including: author, credits, and tags. Information within these locations get carried over to your map service REST page.
DETERMINE THE FOCUS AREA FOR YOUR SERVICE
Did you know you can set the map service to magically zoom into a particular area on the map? This can be set within the data frame properties under the extent settings. This helps users know where they should be looking for the data. It also is very useful when you have data that crosses the International Date Line as most maps default to the extent of the layers. When the data in the map crosses the International Date Line the point of origin for the service gets set to zoom into the Prime Meridian. If you would like the map to be centered on a particular county, state, region or even the contiguous United States, you will want to explore changing these settings.
PROVIDE YOUR USERS WITH MORE CAPABILITIES
Once you are ready to share your data as a service, you can allow end users to manipulate the cartography and layer order of the service when using your services within their own applications. Within the Services Properties dialog box, under capabilities click-on Mapping and select the check-box to “Allow per request modification of layer order and symbology”. You will then have to go in and manage the data store your end-users can connect to. Make sure you select a read-only database and lock the version.
ENSURE YOUR SERVICE COMPLIES WITH AN OPEN STANDARD
Also at the map service publishing stage help make your data more open by enabling the WMS capability. Here at OCM we enable KML and WMS to ensure OGC-compliance. We are also aware that some of our users prefer these formats. If you know of other capabilities that may be useful to your users, consider enabling these as well.
Finally test, test, test! It’s best to test the service on a computer that is off the network so you can truly understand the performance from a user perspective. If you have exhausted all the things you can do with your data to get it to perform magically and notice performance issues when testing outside your network, you may want to consider publishing the data as a cached tile service rather than a dynamic map service.