Have you ever made a checklist for yourself to ensure that your map service is not missing anything? No? Good news, we’ve done that for you. Feel free to use the checklist below, at least as a starting place.

General Checks:

Basic Map Checks:

• Are all the layers listed in the Table of Contents necessary for your map service? (If you have unnecessary layers here, remove them before publishing.)
• Are you using simple and appropriate symbology?
• Do you add information as the user zooms in? E.g., if showing locations of 10,000 doctor’s offices around the country, you may not want to label them until the user zooms in far enough. Is the right information available at each scale?
• Have you zoomed all the way in, then out, in numerous places, to judge how the map works at each scale? Are any scales more important than others?

Layer Checks:

• If building a basemap, are you using separate group names for basemap content vs. operational content?
• Are you using plain English names (not jargon) for layers and group layers?
• Are point and line information overlaid on top of polygons?
• Have you set the right min and max scale dependencies on all layers? (Why is this important? If you leave a large-scale layer to draw at all scales, down to 1:1, but you only cache down to 1:72k, the app developer will waste time trying to figure out why their code is trying to draw the map at scales that the map service indicates are supported, but the cache does not support.)
• If labeling dynamically, have you considered switching to annotation if you are going to cache the map?

Attribute Checks:

• If your data is in file geodatabases, have you collapsed all data into single folder or file geodatabase? This reduces the number of steps required to migrate your data and services from a development environment to staging, QA, and production.
• Have you turned off any unnecessary attributes in each layer? Time permitting, delete unnecessary attributes from each layer. Try to nail this down as early as possible. Consider your attribute schema “final” once you publish a service. If you have the same attributes for multiple geography levels (e.g., states and counties), best practice is to build the data in a consistent schema throughout all layers. E.g., if your states layer has “TotalPopulation”, “MedianIncome”, and “DiversityIndex” in that order, your Counties layer should be structured using that same sequence. The consistency of that sequence helps significantly when building pop-ups and other information products.
• Have you set consistent and easy-to-understand aliases for each attribute that the user or developer will see?

Performance Checks:

• Have you reprojected source data to the projection to be used in the map service (typically Web Mercator)?
• Are you using relative paths? Remove any UNC paths for file-based data (avoid \mymachinedata…).
• Have you updated the spatial indexes in each layer?
• If your layer is too detailed for certain scales (coastlines, etc.), are you using a generalized version? This is most important if your service will be used by applications which ship the geometries of the features to the client application. Some apps are “slow” only because they are shipping unnecessary detail down to the client. Read more about Generalizing Boundaries.

Service Checks:

• Is your service name easy for an app developer to understand while still avoiding spaces or special characters?
• Have you examined and addressed any performance-related warnings that come up using the Analyze option?
• Is the feature limit of 1,000 appropriate for your purposes?

In Your .MXD File:

Map Document Properties:

• Have you set the Title, Summary, Description, and Author text (change this by going to File -> Properties)?
• Have you set the Credits text that reflects the source of the data you’re using (e.g., ©2012 U.S. Census Bureau, U.S. Department of the Interior)?
• Have you set at least 5 Tags (relevant words or phrases to facilitate your map appearing in search results)?
• Have you checked “Store relative pathways to data sources”?

Data Frame Properties:

• Have you changed the name from the default “Layers,” if desired (change this in the General tab)?
• Do you have text in the Description section? If not, copy your Description from Map Document Properties.
• Do you have a source listed in Credits? If not, copy your Credits from Map Document Properties.

Group Layer Properties:

• Have you changed the name from the default “Layers,” if desired (change this in the General tab)?
• Have you set the description for something specific to the layer, if desired?
• Have you included the source of the data in the Credits?

Layer Properties:

• Is the layer name set to something simple, clear, and easy to read (change this in the General tab)?
• Is the description set to something specific to the layer?
• Is the text in the Credits field the name of the organization providing this data?
• Have you set the scale range? Out Beyond should end in 0, In Beyond should end in 1. Best practice is to assign an “Out Beyond” value and an “In Beyond” value to each individual layer so that app developers are not wondering why a layer is not drawing.
• Have you verified that the definition query is set properly for this layer?
• Have you removed any fields that do not need to be visible, set aliases that avoid abbreviations and jargon, and set the desired field order (change this in the Fields tab)?

Attributes that need indexing:

Have you asked the application developer which fields their app uses, even if only in the pop-up? These are all fields that need to be indexed:

• Does your symbology use any fields for exclusions, normalizations, etc.?
• Are you using a definition query?
• Does your labeling use any expressions or SQL queries?
• Are any fields used to join or relate tables?
• Are any fields used in the Time tab?

In ArcCatalog:

• Have you indexed all attributes that need to be indexed?  (change this in Feature Class Properties / Indexes tab).

Also available as a PDF. Other Intelligent Maps Checklists are available for Web Maps and Thematic Image Services.

About the author

Diana Lavery

(she/her/hers) Diana loves working with data. She has 15 years experience as a practitioner of demography, sociology, economics, policy analysis, and GIS. Diana holds a BA in quantitative economics and an MA in applied demography. She is a senior GIS engineer on ArcGIS Living Atlas of the World's Policy Maps team. Diana enjoys strong coffee and clean datasets, usually simultaneously.