Map Service Specifications - maps.alberta.ca...Cached Map Services and edit the format and grammar,...
Transcript of Map Service Specifications - maps.alberta.ca...Cached Map Services and edit the format and grammar,...
Team HP
Map Service Production Specifications & Best
Practices
For Map Service Publication in the GENESIS Infrastructure
In support of the Fundamental Spatial Services Project
Version 11
22 October 2015
Team HP
Map Service Specifications 1
Revision History
Last saved by: brandon.mol
Last save time: 2015-10-15 10:49 AM
Version Date Author Description
0.1 2011-09-20 Mario Plante Initial TOC contents
0.2 2011-09-21 Brandon Mol Re-styled document to conform to Team HP
standards.
Added some content stubs regarding MXD
configuration in section 3.1
0.3 Mario Plante Populated main document content
0.4 2011-11-17 Brandon Mol Final edits, content changes, additional
content, styling, etc
0.5 2011-11-21 Brandon Mol Further revisions and clarifications
0.6 2011-11-22 Andre Leclerc Peer-review feedback, minor revisions
1 2011-11-22 Brandon Mol Release 1 Deliverable - Final version
2 2012-03-20 Brandon Mol Major updates based on feedback and
consultations.
Addition of detailed Service-Level Metadata
requirements.
3 2012-03-24 Brandon Mol Release 2 Deliverable – Final version
Swapped chapter 2 and 3
Renamed chapters to reflect “Specs” and
“Best Practices”
Moved naming conventions, service-level
metadata, and Quality control to specs
chapter.
Added some figures re: map cache scales
other misc re-structuring and clarifications
4 2012-04-30 Brandon Mol Minor corrections and a few rewordings for
clarity.
5 2012-05-24 Leanne Mowat Minor changes due to testing.
Team HP
2 Map Service Specifications
Version Date Author Description
6 2012-10-25 Leanne Mowat Minor changes due to testing.
7 2012-12-19 Leanne Mowat Minor changes due to testing.
8 2013-03-20 Leanne Mowat Updated Application examples
Changed Branch name in the example
Updated acceptable and non-acceptable
characters
Updated the Transparency section.
9 2013-06-24 Leanne Mowat Updated Application Section with Short
Name List.
Updated acceptable and non-acceptable
characters
10 2014-04-28 Diane Olson Under the Symbology Selection Section 2.4,
updated Use of Transparency Section with
Use of Transparency Notes
Updated Use of Labelling and Annotation
Section 2.5with note on label conflicts
between map services.
In Map Service Definition Section 3.1,
remove extra “this” and correct grammar.
Under Map Service Definition Section 3.1,
update with note on MXD-file template
creation.
Under Naming Section 3.2, updated section
adding in Map Services Template and
Template Creation Procedure
Under Naming Section 3,2, Map Document
(MXD) Files, update to reflect current name
standards, which will include the editing of
the number parts of the file name from five to
three, the number of parts for Application
specific services from six to four, addition of
the Data Access Only type, the removal of
“the type of map service” and “the security of
the map service”, addition of map document
format examples for Application Specific,
Non-Application Specific and Data Access
Only map documents.
Team HP
Map Service Specifications 3
Version Date Author Description
10 2014-04-28 Diane Olson Under Naming Section 3,2, Map Document
(MXD) Files,removal of MBP, OPR, the
editing of APP to read “Application Specific
Names”, re-formatting of Application Specific
Names, add in Application Name change for
CENSUSALTA (formerly GEODATA,
formerly CENSUSGEO and ACT (formerly
SAAB), edit “The security should be
displayed in the file name as one of the
following:” bullet to read “Map Document
Security” and remove types listed, move the
“Note” on security to the bottom of the
section, add “See Section 3.2, Naming
Conventions, Map Services.” To “The name
will be the name of the map service as
described above.” bullet, create a bullet for
Cached Map Services and edit the format and
grammar, edit the format for “The date of
publication:” bullet, remove map document
examples, edit the Map Document Security
bullet, removing references to SEC and PUB
security level map document naming.
In Section 3.2, Naming Conventions,
Dataframes, re-formatted and edited grammar
for all bullets.
In Section 3.2, Naming Conventions, Layers
and Group Layers, re-formatted and edited
grammar for all bullets.
Team HP
4 Map Service Specifications
Version Date Author Description
11 2015-10-15 Brandon Mol Cleaned out old/outdated/irrelevant content –
particularly regarding naming conventions or
some best practices that nobody was
following.
Moved a few sections that were under the
specifications section into the Best practices
section since they are general in nature and
not specific to GENESIS.
Fixed some errors in the Layer metadata
section, and several other cosmetic changes.
Removed references to “SRD” and “ESRD”
and replaced it with “the Ministry” or some
other generic term so that it is more future-
proof to Ministry name changes.
Updated the logo on the cover page.
Updated the naming convention section to
reflect the current way services ought to be
named.
Deleted a few sections entirely that just made
no sense anymore. Specifically around
application-specific services and the examples
service scenario which was so out of
alignment with what we are doing that it
wasn’t worth fixing.
Team HP
Map Service Specifications 5
Table of Contents
REVISION HISTORY .................................................................................................................................. 1
TABLE OF CONTENTS .............................................................................................................................. 5
LIST OF FIGURES ...................................................................................................................................... 6
LIST OF TABLES ........................................................................................................................................ 7
1 INTRODUCTION ............................................................................................................................... 8
1.1 OBJECTIVES ....................................................................................................................................... 8 1.2 HOW THIS DOCUMENT IS ORGANIZED................................................................................................ 8 1.3 DISPLAY ORDER OF SERVICES ........................................................................................................... 9 1.4 ORGANIZATION OF DATA WITHIN MAP SERVICES ............................................................................ 10 1.5 GROUP LAYERS ............................................................................................................................... 10 1.6 SPATIAL CONTEXT ........................................................................................................................... 10
2 BEST PRACTICES FOR THE PRODUCTION OF MAP SERVICES ....................................... 11
2.1 SELECTION OF DATAFRAME PROPERTIES ......................................................................................... 11 2.2 ADDING A FEATURE CLASS MULTIPLE TIMES TO THE SAME MAP ................................................... 12 2.3 INDEXING AND LAYER DEFINITION QUERIES ................................................................................... 12 2.4 SYMBOLOGY SELECTION ................................................................................................................. 14 2.5 USE OF LABELLING AND ANNOTATION ............................................................................................ 20 2.6 DIFFERENCES BETWEEN DRAWING ENGINES ................................................................................... 21 2.7 BASEMAP SERVICES VERSUS OPERATIONAL DATA SERVICES .......................................................... 29 2.8 DISPLAY ORDER OF SERVICES ......................................................................................................... 30 2.9 ORGANIZATION OF DATA WITHIN MAP SERVICES ............................................................................ 31 2.10 GROUP LAYERS ........................................................................................................................... 31 2.11 SPATIAL CONTEXT ...................................................................................................................... 31
3 SPECIFICATIONS FOR THE PRODUCTION OF MAP SERVICES REQUIRING
PUBLICATION IN GENESIS ................................................................................................................... 32
3.1 MAP SERVICE DEFINITION ............................................................................................................... 32 3.2 NAMING CONVENTIONS ................................................................................................................... 33 3.3 VIEW-OPTIMIZED SCALES AND DISPLAY-RANGE THRESHOLDS ...................................................... 45 3.4 SUPPORTED COORDINATE REFERENCE SYSTEMS ............................................................................. 52 3.5 SERVICE-LEVEL METADATA............................................................................................................ 52 3.6 QUALITY CONTROL ......................................................................................................................... 58
4 REFERENCES .................................................................................................................................. 65
Team HP
6 Map Service Specifications
List of Figures
FIGURE 1: POINT MARKER SYMBOL PERFORMANCE ..................................................................................... 14 FIGURE 2: LINE SYMBOL PERFORMANCE....................................................................................................... 15 FIGURE 3: POLYGON FILL SYMBOL PERFORMANCE ....................................................................................... 17 FIGURE 4. CACHED MAP IMAGE AT 1:36112 (USES LEVEL 14 CACHE TILES) ................................................. 47 FIGURE 5. CACHED MAP IMAGE AT 1:54167 (USES LEVEL 14 CACHE TILES) ................................................. 48 FIGURE 6. CACHED MAP IMAGE AT 1:54568 (USES LEVEL 13 CACHE TILES) ................................................. 48 FIGURE 7. CACHED MAP IMAGE AT 1:72224 (USES LEVEL 13 CACHE TILES) ................................................. 49 FIGURE 8: MAP DOCUMENT PROPERTIES ...................................................................................................... 54 FIGURE 9: DATA FRAME PROPERTIES ............................................................................................................ 56 FIGURE 10: LAYER PROPERTIES .................................................................................................................... 57
Team HP
Map Service Specifications 7
List of Tables
TABLE 1: OPTIMISED LINE WIDTHS ............................................................................................................... 16 TABLE 2. SRD STANDARD VIEW-OPTIMISED SCALES .................................................................................... 46 TABLE 3: MAP CACHING PARAMETERS .......................................................................................................... 50 TABLE 4: STANDARD ESRI MXD ERROR CODES........................................................................................... 59 TABLE 5: STANDARD ESRI MXD WARNING CODES...................................................................................... 61 TABLE 6: STANDARD ESRI MXD INFORMATION CODES ............................................................................... 63
Team HP
8 Map Service Specifications
1 Introduction
1.1 Objectives
This document provides a set of guidelines and best-practices to follow during the
production of map documents for publication as map services in SRD’s GENESIS1
system. It is targeted towards technical staff involved in the authoring and publication of
map documents (MXD-files) to be used for this purpose only. It is, therefore, not
intended to dictate requirements for the creation of large format cartographic map
products that are not being published in GENESIS as map services. It is, however,
dictating the technical requirements for a set of fundamental map services that will serve
the needs of many spatial data users in the department. Naturally, deviations in the
requirements of the user-base will dictate that additional services will, over time, need to
be created to address the needs of some niche user groups. With enough care, the
requirement for this to happen can be minimized.
In addition to the specific technical requirements for map services in GENESIS, this
document can also be used as a handbook of best practices for any author of ArcGIS
Server map services. It combines content from various ESRI documentation sources, the
experience of several experts, and the results of a collaborative business analysis effort by
Team HP and various SRD staff. This document does not intend to replace the ESRI
documentation, but rather serves as a supplementary resource with additional
information. Many topics covered by this document require that the reader is already
familiar with the software as well as the freely available documentation from ESRI,
available on their web site.
1.2 How this Document is Organized
This document is divided into two main sections: Best Practices for the Production of
Map Services and Basemap Services versus Operational Data Services
In web-mapping applications, the general premise is that you have one or more
“basemaps” which contain some contextual information, and you have “operational data”
that you overlay on top of the basemap. To facilitate this process, a map service should be
created as either a basemap service or an operational service, with different usage
intentions accordingly.
The following is a list of guidelines to help a map document author determine which is
required for their purpose.
Basemap services should be kept as simple as possible. “Simple”, of course, is
relative to the discretion of the map author.
1 GENESIS is an acronym for Generic Enterprise Spatial Information Services, which is an enterprise
ArcGIS Server cluster implementation
Team HP
Map Service Specifications 9
Avoid including data in a basemap service that is used to make specific, location-
based decisions. These types of layers are "operational" layers that should be
displayed differently, within an operational service.
Basemaps are simply for context and to help you visualize the location, scope, and
extent of the area in which you are viewing operational data.
A basemap should be replaceable with imagery or any other basemap without losing
the context of the map.
Do not confuse basemap layers with “base features” layers. Context is everything,
and it is safe to say that most “base features” layers are probably operational layers
rather than basemap layers in most circumstances.
A basemap may be useful on its own, or used as a backdrop for operational data
layers, so it should have a muted, neutral, visually non-encroaching colour scheme
that supports having virtually anything overlaid on top of it.
Operational data symbology should stand out on the map relative to the basemap
symbology (i.e.: more vibrant colours, bolder lines, bolder/larger text, text halos,
etc.).
If a basemap service has a background texture, layer, or colour; that texture, layer, or
colour should remain visible at all scales, even when all other data layers are turned
off. Otherwise, when overlaying operational data, the background will disappear as
the user zooms in past the scale where layers are shown in the basemap.
A basemap is an ideal candidate for map caching
1.3 Display Order of Services
When conceptualizing the various map services to be published for a given audience,
consider that the symbology of the various map services should be optimized to be
displayed in the following order when the services are combined (top to bottom):
Vector Operational data services
o Positional grids such as ATS or NTS
o Imaginary points, lines, or areas such as jurisdictional boundaries. It is
recommended that these items have no fill as polygons.
o Points, lines, or polygons representing physical things on the ground.
Vector basemap services
o Basemap services should only include features used for general orientation
and localization. Features such as populated places, hydrography and
transportation networks could be combined in a global basemap, made
available as distinct operational services, or both depending on display scale,
level of detail, etc.
Raster data services
o Imagery, hillshades, DSMs, etc.
The basemap services are displayed as background information on top of which
operational services are displayed. If available, imagery services are displayed under all
other services. Naturally, a user can order the services how he wishes, but the idea is that
Team HP
10 Map Service Specifications
the services be optimized for this order and the author assumes that they will be
consumed using this stacking order.
1.4 Organization of Data within Map Services
Within any given map service, the layers should conform to the following drawing order,
from top to bottom:
Point features
Linear features or polygon features without fill
Polygon features with fill
Raster data
1.5 Group Layers
Avoid embedding group layers more than two levels deep. Beyond two levels of group
layers, they become a hindrance rather than a help for users navigating the table of
contents. Instead, flatten out the layer structure with more descriptive layer names.
1.6 Spatial Context
It is recommended that a spatial context is provided in the basemap to the extent of one or
more jurisdictional boundaries larger than the one of interest. For example, if the area of
interest is the Province of Alberta, then having the whole of Canada present for context is
helpful to users. If the area of interest were the City of Edmonton, then the Province
would be a sufficient level of contextual information. Simple, small-scale basemap
products exist from ESRI and other sources than could be leveraged for this purpose for
no cost if the appropriate data cannot be found internally.
Specifications for the Production of Map Services Requiring Publication in GENESIS.
The former deals with a set of best-practices for the production of MXD-files that define
map services published in ArcGIS Server, whether they are to be used in GENESIS, or
elsewhere. The latter addresses the unique requirements for publication of map services
in the GENESIS system.
Team HP
Map Service Specifications 11
2 Best Practices for the Production of Map Services
2.1 Selection of Dataframe Properties
The dataframe within the MXD serves as the data structure that defines the map service.
Properties of the data frame are reflected as properties of the service once it is published.
Although it is possible to publish a map service from an MXD with more than one
dataframe, only one dataframe can be used per map service. Limiting MXDs to having
only one dataframe ensures that the correct content is published and simplifies
management of the files. There are two settings within the dataframe properties that are
of great importance:
Frame Background Colour.
By default in ArcMap, the background colour is “none”. This is fine except that every
pixel in the images rendered by the map server has a value and by not defining a
background colour, you are forcing the software to decide for you which colour to
treat as transparent.
The “Frame background colour” should, therefore, be explicitly set to some other
value.
If this isn’t done, then symbols with colours that happen to be the same as the default
background might render inappropriately in certain web browsers.
Don’t use RGB 255,255,255 (white) because other symbols tend to make use of white
and this could create unintended areas of transparency.
RGB 254,255,255 is a good alternative when you want labels and symbology to blend
to a white background during the anti-aliasing process. This will result in light
coloured halos around text or linework when the service is overlain on top of other
darker services.
Use other mid-tone values if you want the haloing effect to be reduced for use over
mid-tone backgrounds such as imagery. For example, a shade of grey like RGB
200,201,201 might be a good choice.
In general, this is going to take some experimentation to find a good balance.
It is a good idea to use an RGB value-set where the three values are not the same.
This avoids inadvertently blending with pure white-grey-black shades.
Full Extent Envelope
The Data Frame Full Extent of the map should be explicitly set
This is referring to the “Extent Used By Full Extent Command” option
o Leave the “Extent” set to Automatic.
By default, the spatial extent is set to be automatically determined from the union of
the extent of all the layers in the map.
o In ArcGIS 10 this reads “Extent of data in all layers (Default)”
If you don’t change this, mobile data services cannot be used
If authoring a map of Alberta in 10-TM, specify the following custom extent in
degrees:
Team HP
12 Map Service Specifications
o Top: 64 dd
o Right -88 dd
o Bottom: 42 dd
o Left: -130 dd
If a map is changed from 10-TM to Web-Mercator, these values update automatically.
If authoring a map of Alberta directly in Web Mercator, specify the following custom
extent in degrees:
o Top: 65.5 dd
o Right -88 dd
o Bottom: 41 dd
o Left: -141 dd
These values were selected to include a close-to-square area that includes most of BC
and Saskatchewan and allows for tile caching to work properly at all scale levels.
These values are an estimate of what will work well for SRD. Changes to these values
may be required after some trial and error.
2.2 Adding a Feature Class Multiple Times to the Same Map
As a general rule, minimize the number of times the same feature class is added to the
same MXD-file. If this is required to support multiple scale display thresholds for
different types of features within the same feature class, then you should always use
spatial views in the database or definition queries in the layers properties rather than
performing the selection by disabling symbology for selected features. Known as
“selective symbology” this way of removing items from the legend can often give the
same result, it is not as efficient in terms of performance as the use of a spatial view or a
definition query. This is because when views or definition queries are used, the database
only needs to return the features you are actually displaying and ArcGIS Server only
needs to render those features.
When selective symbology is used, all the features are retrieved, and ArcGIS Server must
determine which symbols to not draw. In situations where the number of features not
being drawn is small, this may not be an issue. But for situations where the number of
features that are given no symbology is large, then a significant impact on performance is
experienced; especially if this is done multiple times within the MXD.
2.3 Indexing and Layer Definition Queries
ArcGIS uses spatial indices to quickly retrieve features in a feature class based on spatial
location. It is absolutely critical that every feature class that supports it has an up-to-date
spatial index. If the feature class is a spatial view of another feature class, the source
feature class(es) should have spatial indices. A spatial index can become out of date if the
extent of the data changes significantly over time or if a significant number of features
are added. In this case, the spatial index should be updated in the feature class properties.
The use of spatial views or layer definition queries to filter features based on other
attributes is recommended as a way of simplifying the data at different scales. Doing this,
however, requires that the fields used in the query are indexed in order to achieve the best
Team HP
Map Service Specifications 13
performance. In addition, it is recommended to create specific indices on all attributes
used in any kind of query operation commonly performed by users.
Due to the level of database access required to update indices, it can only be done using
the schema-owner account. For more information on field or spatial indices and how to
update them, please see the ArcGIS help documentation. If the map author is not the
database schema owner, then the map author must request of the scheme owner that a
spatial index update/refresh be done.
Team HP
14 Map Service Specifications
2.4 Symbology Selection
Point Features
Use character marker symbols.
Do not use halos. Use a larger symbol under the main one instead.
Do not use multi-field unique symbology: feature services do not support this.
Instead, use one field for symbology or combine multiple fields before hand.
The following figure shows the relative performance of different types of point
symbology. You can use this to help guide you in selecting symbology when
performance is a concern.
Figure 1: Point Marker Symbol Performance
Team HP
Map Service Specifications 15
Line Features
Use simple line symbols. Avoid cartographic lines.
For more complex symbology, use ESRI-optimized lines as much as possible.
Do not use multi-field unique symbology: feature services do not support this.
Instead, use one field for symbology or combine multiple fields before hand.
The following figure shows the relative performance of different types of line
symbology. You can use this to help guide you in selecting symbology when
performance is a concern.
Figure 2: Line Symbol Performance
Keep in mind the differences in rendering of line widths between ArcGIS Desktop
and other software, with respect to sub-pixel rendering. Use only the optimized line
widths discussed below in Table 1. The recommended values for 96 dpi are 1, 1.5,
2.25, and 3 pts.
Team HP
16 Map Service Specifications
Table 1: Optimised Line Widths
Original
Width
Optimised Width by Target DPI2
96 120 150 300
0.5 0.5 0.5 0.5 0.48
0.6 0.6 0.6 0.6 0.72
0.7 0.7 0.7 0.7 0.72
0.8 0.8 0.8 0.96 0.72
0.9 0.9 1.2 0.96 0.96
1 1 1.2 0.96 0.96
1.1 1.1 1.2 0.96 1.2
1.2 1.5 1.2 1.44 1.2
1.3 1.5 1.2 1.44 1.2
1.4 1.5 1.2 1.44 1.44
1.5 1.5 1.8 1.44 1.44
1.6 1.5 1.8 1.44 1.68
1.7 1.5 1.8 1.92 1.68
1.8 1.5 1.8 1.92 1.92
1.9 2.25 1.8 1.92 1.92
2 2.25 1.8 1.92 1.92
2.1 2.25 2.4 1.92 2.16
2.2 2.25 2.4 2.4 2.16
2.3 2.25 2.4 2.4 2.4
2.4 2.25 2.4 2.4 2.4
2.5 2.25 2.4 2.4 2.4
2.6 2.25 2.4 2.4 2.64
2.7 3 3 2.88 2.64
2.8 3 3 2.88 2.88
2.9 3 3 2.88 2.88
3 3 3 2.88 3.12
3.1 3 3 2.88 3.12
3.2 3 3 3.36 3.12
3.3 3 3.6 3.36 3.36
3.4 3.75 3.6 3.36 3.36
3.5 3.75 3.6 3.36 3.6
3.6 3.75 3.6 3.84 3.6
3.7 3.75 3.6 3.84 3.6
3.8 3.75 3.6 3.84 3.84
3.9 3.75 4.2 3.84 3.84
4 3.75 4.2 3.84 4.08
2 96 dpi is the standard screen resolution for windows-based PCs and the resolution most likely to be used.
Team HP
Map Service Specifications 17
Polygon Features
Use marker fill using simple marker
Use simple outline instead of cartographic outline
Use line fill using simple line instead of cartographic line.
Use ESRI optimized symbol when possible
Do not use multi-field unique symbology: feature services do not support this.
Instead, use one field for symbology or combine multiple fields before hand.
As much as possible, do not use a fill or use a very light fill to symbolize polygons on
your map. When using a fill, the outline should be a darker or more-saturated version
of the fill colour
The following figure shows the relative performance of different types of polygon
symbology. You can use this to help guide you in selecting symbology when
performance is a concern.
Figure 3: Polygon Fill Symbol Performance
Use of Transparency
Avoid using layer transparency unless you absolutely need transparency between layers
within the same service. On the client side, an entire service can have transparency
applied to it so layer transparency is often unnecessary and just makes the service slow.
Additionally, the transparency values may be overridden by other settings and some
artefacts might show through. For more detail see the ArcGIS Desktop help article
entitled 10009: Enabling the option to convert layer transparency to color transparency
may improve performance.
Team HP
18 Map Service Specifications
Use of Transparency Notes
Enabling Layer Transparency option is set by right clicking on the
corresponding error in the Map Analyzer “Prepare” window, and setting it
for each layer causing the warning.
Never use layer transparency greater than 80% as it may not show up at all
depending on the colors chosen for the fill.
NOTE: Layer Transparency only works between layers within a group in the
mxd used to publish the map service. It does not make the group itself
transparent to other map services. Transparency between map services is set in
Geocortex Essentials Manager using opacity. If you want the group of layers
with layer transparency applied to them, to be transparent to other map
services as well, the transparency value must be taken into consideration for
that additional transparency percentage required to make the map service
transparent to other map services, otherwise the fill may not show up very
well or at all (see the following example).
Example: A desired transparency effect of 40% for Map Service A with
Group A containing three layers requiring transparency between each layer
within Group A due to overlapping polygons which also needs to be
transparent to the Map Service B.
Map Service A: Transparency setting for Group A Layers in the mxd should
equal 30%.
In order for Map Service Group A to be transparent to show the Map Service
B in Geocortex, and give the appearance of a 40% transparency, the opacity
setting must be set in Geocortex Essentials Manager to equal 10% or 0.90 for
Map Service A.
The combined total of the layer transparency of 30% in Map Service A, and
the 10% opacity set in Geocortex Essentials Manager for Map Service A will
equal the desired 40% transparency.
An alternative to using transparency is to duplicate your layer and create an
outline layer and a fill layer in your mxd so that the user could easily turn off the
fill to see what is contained within the polygonal extent. When labelling the layer
entry for the ‘Table of Contents’, use the full layer name in the label description,
not just “Outline” or “fill”, as some tools display a listing of available layers and
if several layers have the same label description they are indiscernible as to which
actual layers are being referred to.
Team HP
Map Service Specifications 19
A best practice is to create a group using the layer name for the group name, and then
place all of the following under the group that would make up the display for the layer:
Have one entry for the layer that is symbolized using both the outline and fill
symbology. This will be the default display.
Duplicate this layer above the fill layer in the mxd with the fill removed, add
‘Outline’ to the end of the layer name and do not make this layer visible. This will
ensure that there will be no automatic duplication of layer boundary drawn in the map
view. Ensure both layers attribute field’s match for query purposes, this would entail
that the same field aliases are used and the same fields are checked on for each layer.
This should not be an issue as you should be copying the layer and only changing the
symbology and layer name, but a quick check will ensure that they match. More
information on how to display the attributes can be found in section 3.2 Naming
Conventions, under sub-section “Layers and Group Layers”.
If labels are necessary duplicate this layer again above the outline layer adding
‘Label’ to the end of the layer name so the user can turn labels on or off as needed.
The symbology should be blanked out by setting the fill and outline color to ‘No
Color’ and the outline width to ‘0’. Turn off all attributes on this layer with the
exception of the OBJECTID field and the field used for labelling. When we move to
ArcGIS 10.1 this extra label layer will be unnecessary.
The above image shows the best practice to display a layer.
Team HP
20 Map Service Specifications
2.5 Use of Labelling and Annotation
Note: Label conflicts are not recognized between map services at this time and
label overlap between map services may occur.
Only use label features that are large enough to warrant labelling at the scale
at which they are viewed. Remember that digital maps can be zoomed in an
out so err on the side of simplicity and use labels conservatively. A good rule
of thumb is that you should not show labels for polygon features for which the
label does not fit inside or linear features shorter than the label text. The label
should not have to be outside the polygon or extend beyond the polyline. This
causes interference with other labels and crowds the map. The user can always
zoom in for more detail, unlike what is possible with paper maps. With paper
maps, the cartographer must include all information that is to be
communicated at a single scale. Paper maps are often cluttered in an effort to
communicate as much useful information as possible. With digital maps, this
problem does not exist. Take advantage of this and avoid showing too much
detail when it isn’t needed.
Minimize the number of fonts used in all map services within your
jurisdiction. Be consistent with font sizes for different layers at the same scale
and try to keep font sizes the same between map scales. Vary the number of
labels, not their size.
Labels should never change colour between visible scales. For example, do
not label a lake with a blue font at one scale, a black font at the next, then blue
again. This is extremely confusing to the user and makes it difficult to visually
associate features between scales when zooming.
Place labels consistently in the map. If labels follow the geometry of
hydrography features, do the same for other linear features. Try to keep labels
horizontal for polygons and always use horizontal labels for points that are
actually points on the ground (as opposed to points in the data that represent
areas or linear features on the ground). This goes back to label density – if
there isn’t room for the label, chances are it shouldn’t be there at that scale.
Set the labelling engine to Maplex, create nice looking labels, and then export
it to annotation for quick display and no label duplication.
To be able to turn labels on and off create a duplicate layer and turn off all
feature symbology so that the user can turn the annotation layer on and off.
Team HP
Map Service Specifications 21
2.6 Differences between Drawing Engines
Note: This section is an excerpt from the ESRI ArcGIS 10 Documentation, reprinted here
for convenience. Some content has been removed from the original if it was deemed
unnecessary in the context of this document. All of the content of this section is Copyright
© 1995-2010 ESRI.
The original can be found at the following URL:
http://goo.gl/O4PiB
Basemap layers and optimized map services in ArcGIS Server use a high-performance
drawing engine to achieve better performance and drawing quality. This drawing engine
provides excellent performance for all symbol types supported.
The optimized map service drawing engine (right) includes features such as anti-
aliasing to improve appearance.
Because this drawing engine is different from the drawing engine used in ArcMap or a
standard map service, you should be aware of some important differences in the
appearance of a map drawn in the optimized map service. The Prepare window provides
warnings that inform you of many of these differences.
The Prepare window (opened from analyzing a basemap layer or via the Map Service
Publishing toolbar) shows warnings for many drawing differences.
Team HP
22 Map Service Specifications
However, because the differences in appearance can be subjective, you should always
verify the proper appearance of your map as it is displayed. If you are preparing a
basemap layer, use the basemap layer in ArcMap to visualize any differences. Use
the Prepare window, accessible on the Map Service Publishing toolbar, when publishing
to an optimized map service. The following sections describe some of these differences in
drawing and why they occur.
Text and character marker anti-aliasing
In ArcMap and in the standard map service, text and character marker anti-aliasing is
controlled by the font smoothing settings that are configured in the machine's display
settings. These settings are set per user and are not configured as part of the map service.
Because of this, the behavior of font smoothing may be different when a map is published
to the server as a standard map service.
Font smoothing settings vary between operating systems. The
above dialog box is from Windows XP.
In the optimized map service, these settings are configured per service and stored as part
of the Map Service Definition. These text anti-aliasing settings are accessed from the
Options button on the Map Service Publishing toolbar.
Team HP
Map Service Specifications 23
Text anti-aliasing settings are chosen from the
Options button on the Map Service Publishing
toolbar.
Text drawn in a basemap layer will always be drawn with the Force option. Note that
labels in a basemap layer will always be drawn using the standard display in ArcMap and
will respect the machine settings mentioned above.
Because the basemap layer and optimized map service drawing engine uses a different
method of enabling text and character anti-aliasing, and the algorithms used to execute
this anti-aliasing are different, the rendering of text and character markers may exhibit
some differences when compared with a standard map service.
Left: ArcMap (no font smoothing). Right :Optimized map service
with font anti-aliasing set to Force.
Coordinate rounding differences
In ArcMap and in the standard map service, elements of the on-screen display are
specified with integer coordinates. If the real coordinate of a feature (for instance, a line
or a marker) does not lie exactly on that integer coordinate, it will be rounded up or
down. This can result in some inaccuracies, particularly in the case of very thin lines or
lines with very thin elements such as cased lines. Lines whose sizes are less than one
pixel at a given zoom level or display extent are rounded up to one pixel.
Team HP
24 Map Service Specifications
In ArcMap at 96 dpi, there's no visible difference between these two line symbols at
2.6 points (left) and 1.9 points (right).
In basemap layers and optimized map services, the drawing engine can use subpixel
coordinates to place and draw features on the map. This results in greater accuracy of
feature placement and symbology.
In basemap layers and optimized map services, there is a definite difference between
2.6 points (left ) and 1.9 points (right).
However, if the map's symbology was originally designed in ArcMap, the appearance
may be different in a basemap layer or optimized map service. This is especially evident
in line symbology.
Team HP
Map Service Specifications 25
Left: Original line widths of expressway symbol rendered in optimized map service.
Right: After correction—note that the casing lines no longer appear dashed in the
corrected version.
See the section Designing Lines for a Specific Resolution in the topic3 Line aliasing in an
optimized map service for more information on these issues and how to design line
symbols for a given target resolution. In most cases, this issue will not occur in basemap
layers, since basemap layers automatically correct this problem.
Simple symbols in basemap layers and optimized map service
Simple symbols (Simple Line Symbol, Simple Fill Symbol, and Simple Marker Symbol)
as provided in ArcMap are displayed in a manner that can sometimes be inconsistent.
Because of these inconsistencies in simple symbols, they may sometimes draw differently
in a basemap layer or optimized map service. You might be informed of some of these
differences by one of the analyzers in the Prepare window.
For instance, Simple Line Symbols using a dash or dash dot pattern do not honor a map's
reference scale and will draw with different spacing depending on the dpi requested. In a
basemap layer or optimized map service, these symbols honor the map's reference scale
and do not change with the requested dpi.
For Simple Marker Symbol, the behavior of the simple markers changes depending on
the size at which they are displayed, causing some variations in their size and shape.
Basemap layers and optimized map services always display marker symbols at the
requested size. In the standard map service or ArcMap, when a simple marker symbol's
size is below a certain threshold, it will draw no smaller. This means that when this
threshold is reached, the basemap layer or optimized map service continues to display
these symbols at an accurate size, whereas the standard map service and ArcMap do not,
resulting in an apparent mismatch.
3 This is a topic in the ESRI ArcGIS 10 help documentation, not this document.
Team HP
26 Map Service Specifications
Line decorations in basemap layers and optimized map services
Line symbols containing line decorations in ArcMap, such as line arrowhead, will not
draw the decoration when the decoration is larger than the line length of the feature being
decorated. The drawing engine used by basemap layers and optimized map services will
always draw line decorations regardless of the size of the line. At some scales, this can
lead to a more cluttered appearance than in ArcMap, but line decorations are drawn
consistently and predictably.
Color in basemap layers and optimized map services
The drawing engine used by basemap layers and optimized map services uses a color
management engine. Because of this, some colors may not exactly match the appearance
of the ArcMap standard display.
The ArcMap application and standard map services do not utilize color management. In
particular, you may notice differences in color when using the following:
Colors defined in color spaces other than RGB (for instance, colors defined in
HSV, CMYK, or grayscale)
Algorithmic color ramps using HSV, CIELab, or LABLch algorithms
Viewing a basemap layer in ArcMap or by using the Preview window opened from
the Map Service Publishing toolbar allows you to evaluate the appearance of the map
using the new graphics engine and determine whether the colors and symbology are
acceptable.
One thing that can be done to minimize the color differences in an optimized map service
is to change the monitor settings within ArcMap. This can be useful when authoring a
map for use in an optimized map service.
To access the monitor settings, on any Symbol Properties dialog box, click the drop-
down menu on the color swatch and choose More Colors.
Team HP
Map Service Specifications 27
On the Color Selector dialog box, click the arrow button in the upper right corner and
choose Monitor Setup.
On the Monitor Setup dialog box, change the Gamma setting to 2.2 and click OK to
close the dialog box.
Team HP
28 Map Service Specifications
This will change ArcMap to use a gamma value that more closely matches the color
profile used by the drawing engine of basemap layers and optimized map services and
should result in more closely matched color transformations.
Note:
This setting will only affect the appearance of maps drawn by the user and the computer
on which this modification is performed. This also applies to maps served as standard
map services.
Font handling differences in basemap layers and optimized map services
Fonts are handled slightly differently in a basemap layer or optimized map service when
compared with ArcMap or the standard map service. There are two main differences:
Basemap layers and optimized map services will not draw faux italic or faux bold
styles. This case triggers a warning when the map document in question is
analyzed.
Basemap layers and optimized map services do not provide font fallback in cases
where a specific character set or type face is not available.
Faux italic or faux bold refers to situations where a font is not available in the bold or
italic styles, or the combination of properties does not have a corresponding font
installed. For instance, a user might have Verdana Bold and Verdana Italic but be missing
Verdana Bold Italic.
In these cases, ArcMap or the standard map service attempts to simulate these properties
by graphically skewing (italic) or thickening (bold) the original font.
Team HP
Map Service Specifications 29
The faux italic version of a font in ArcMap (left) and the actual
font displayed in an optimized map service without faux
properties (right)
This does not often correspond visually to the actual bold or italic version of the typeface.
Indeed, for some fonts (such as the ESRI fonts designed for use as marker symbols), it
does not make sense to display them in bold or italic styles. Basemap layers and
optimized map services only display with fonts and font styles that are available on the
system.
The faux bold version of a font in ArcMap (left) and the actual font displayed in an
optimized map service without faux properties (right)
Always ensure that your text renders as you expect. If you do not see bold or italic
properties in your text, check to be sure that you have that particular style of typeface
available on your system.
All of the content of this section is Copyright © 1995-2010 Esri.
The original can be found at the following URL:
http://goo.gl/O4PiB
2.7 Basemap Services versus Operational Data Services
In web-mapping applications, the general premise is that you have one or more
“basemaps” which contain some contextual information, and you have “operational data”
that you overlay on top of the basemap. To facilitate this process, a map service should be
created as either a basemap service or an operational service, with different usage
intentions accordingly.
Team HP
30 Map Service Specifications
The following is a list of guidelines to help a map document author determine which is
required for their purpose.
Basemap services should be kept as simple as possible. “Simple”, of course, is
relative to the discretion of the map author.
Avoid including data in a basemap service that is used to make specific, location-
based decisions. These types of layers are "operational" layers that should be
displayed differently, within an operational service.
Basemaps are simply for context and to help you visualize the location, scope, and
extent of the area in which you are viewing operational data.
A basemap should be replaceable with imagery or any other basemap without losing
the context of the map.
Do not confuse basemap layers with “base features” layers. Context is everything,
and it is safe to say that most “base features” layers are probably operational layers
rather than basemap layers in most circumstances.
A basemap may be useful on its own, or used as a backdrop for operational data
layers, so it should have a muted, neutral, visually non-encroaching colour scheme
that supports having virtually anything overlaid on top of it.
Operational data symbology should stand out on the map relative to the basemap
symbology (i.e.: more vibrant colours, bolder lines, bolder/larger text, text halos,
etc.).
If a basemap service has a background texture, layer, or colour; that texture, layer, or
colour should remain visible at all scales, even when all other data layers are turned
off. Otherwise, when overlaying operational data, the background will disappear as
the user zooms in past the scale where layers are shown in the basemap.
A basemap is an ideal candidate for map caching
2.8 Display Order of Services
When conceptualizing the various map services to be published for a given audience,
consider that the symbology of the various map services should be optimized to be
displayed in the following order when the services are combined (top to bottom):
Vector Operational data services
o Positional grids such as ATS or NTS
o Imaginary points, lines, or areas such as jurisdictional boundaries. It is
recommended that these items have no fill as polygons.
o Points, lines, or polygons representing physical things on the ground.
Vector basemap services
o Basemap services should only include features used for general orientation
and localization. Features such as populated places, hydrography and
transportation networks could be combined in a global basemap, made
available as distinct operational services, or both depending on display scale,
level of detail, etc.
Raster data services
o Imagery, hillshades, DSMs, etc.
Team HP
Map Service Specifications 31
The basemap services are displayed as background information on top of which
operational services are displayed. If available, imagery services are displayed under all
other services. Naturally, a user can order the services how he wishes, but the idea is that
the services be optimized for this order and the author assumes that they will be
consumed using this stacking order.
2.9 Organization of Data within Map Services
Within any given map service, the layers should conform to the following drawing order,
from top to bottom:
Point features
Linear features or polygon features without fill
Polygon features with fill
Raster data
2.10 Group Layers
Avoid embedding group layers more than two levels deep. Beyond two levels of group
layers, they become a hindrance rather than a help for users navigating the table of
contents. Instead, flatten out the layer structure with more descriptive layer names.
2.11 Spatial Context
It is recommended that a spatial context is provided in the basemap to the extent of one or
more jurisdictional boundaries larger than the one of interest. For example, if the area of
interest is the Province of Alberta, then having the whole of Canada present for context is
helpful to users. If the area of interest were the City of Edmonton, then the Province
would be a sufficient level of contextual information. Simple, small-scale basemap
products exist from ESRI and other sources than could be leveraged for this purpose for
no cost if the appropriate data cannot be found internally.
Team HP
32 Map Service Specifications
3 Specifications for the Production of Map Services Requiring Publication in GENESIS
3.1 Map Service Definition
Each map service shall be prepared, updated, and stored as a separate MXD-file. This file
will serve as the source of truth for the definition of the map service. MXD-files will be
used to generate an optimized MSD (Map Service Definition) file prior to publication.
This task will be done on the GENESIS system either manually by the system
administrator or via a geoprocessing service by the author of the MXD-file. It is this file
that GENESIS uses to configure and start the service. As a result, the service author will
not be doing this directly in ArcMap. Despite this, the author should analyse the
document using the map-service publishing toolbar to ensure initial quality control
checks are performed prior to submission.
Note: To facilitate consistency in MXD-file creation, a starting “template” could be
created which has all the basic and consistent information in it. See section 3.2 Naming
Conventions for further information.
Team HP
Map Service Specifications 33
3.2 Naming Conventions
Map Services Template
To facilitate the consistency for the initial creation of the MXD-file, a base template
could be created in ArcGIS.
Template Creation Procedure
Create the Initial Template.
Open an ArcGIS Untitled document. Under “File” drop down menu, Select “Save
As…”
Team HP
34 Map Service Specifications
Browse to the directory in which you wish to save the template. Change the File Name
from “Untitled” to the template name.
Note: The template’s naming convention should reflect its name, projection and date
created.
Example: Genesis_Template_<projection>_YYYYMMDD
For this example the projection will be in 10TM.
Team HP
Map Service Specifications 35
Set the Map Document Properties
Under “File” drop down menu, select the “Map Document Properties”
Team HP
36 Map Service Specifications
Fill in the “Title” box with the word “Template”. The “Author” and “Credits” boxes
should be filled in with the appropriate information specific to your business area.
Team HP
Map Service Specifications 37
Example: This particular template is used for the creation of MXD-files specific to IDPS
business, so the Author reflects: “Information and Data Provisioning Services,
Informatics Branch, Corporate Services Division, Alberta Environment and Sustainable
Resource Development, Government of Alberta” and “Credits” reflects “Copyright
Government of Alberta”
Once you have filled in the appropriate areas, Click “OK”.
Save your document.
Set the Data Frame Properties.
Team HP
38 Map Service Specifications
In the Table of Contents, right click on “Layers” and from the drop down menu,
select “Properties”.
In the Data Frame Properties, select the “General” tab
Team HP
Map Service Specifications 39
Fill in the Credits with the same business area information as in the Map Document
Credit information above.
Click the “Apply” button, rather than the “OK” button as there is another tab which you
have to access. If you click “OK”, then you will have to re-open the Data Frame
Properties again.
Example: In this case, the Credits information is listed in the screen shot.
Team HP
40 Map Service Specifications
Click on the “Coordinate System” tab. Set the appropriate supported co-ordinate
reference system for the purpose of the publication of map services (see Section
3.11 Supported Coordinate Reference Systems).
Click the “OK” button. This will exit you from the Data Frame Properties menu.
Save your document.
Example: For NAD83/Alberta 10-TM (Forest).
Team HP
Map Service Specifications 41
Map Services
Map service names will vary somewhat from the names of the MXD-files that define
them. The name of the service does not change over time due to version changes nor due
to release dates, however, the name of the MXD-file does change (see below). Deciding
on a name for your map service is important because applications and users will
eventually connect to your service and will expect that it continues to exist in the same
place with the same name. Do not take lightly the proposition of changing the name of a
service once it is published into the production environment; particularly if it has been in
use for long enough that the various stakeholders have come to expect it to function.
The name of the service shall be unique from all other map services, otherwise, it will
be rejected by the GENESIS administrator.
The name will contain only the following characters:
o A to Z
o a to z
o 0 to 9
o _ (underscore)
o - (hyphen)
Use title case: capital letters are only used for acronyms and the first letters of words,
except for articles. Do not use CamelCase.
Words are separated by underscores.
Hyphens are used in two situations only:
1. To separate an application name prefix from the rest of the service name
in the case of an Application-Specific Service, discussed below
2. To separate a special suffix form the rest of the name, such as the “-Data”
suffix used to denote map services created specifically for sue as a feature
service.
Keep the title simple. You don’t need to write a book and the name is best kept
simple.
Example: “Provincial_Basemap_C” is a perfectly reasonable name for a generic
basemap.
Generic names should contain a unique number or letter or something to differentiate
them from similar services, even if no such similar services currently exist.
o Example: Generic Basemap:“My Alberta Map 01”
Non-Generic Basemap: “My Alberta Map”.
Ask the GENESIS administrator if you are uncertain about a potential naming
conflict.
Although the map document author has no control over setting the name of services
in ArcGIS server, the name will be used as part of the MXD file name, as indicated
below and the ArcGIS Server administrator will use this to name the service on
publication.
Examples:
My_Alberta_Map_01
Standard_Basemap_Dark
Team HP
42 Map Service Specifications
Standard_Basemap_Light
Forest_Health_Data_Internal
Forest_Health_Data_External
LAT_Sentitivity_Areas
SomeApplicationName-A_Service_Name
SomeApplicationName-Another_Service_Name
Some_Feature_Service-Data
The naming convention for the service is extremely important. It captures the important
characteristics of the map to facilitate update and management. The service name will be
used as part of the MXD name and this must be set correctly or automated publication
processes will fail.
Using the above as examples, your service name must follow these rules:
The service name will have at between one (1) and three (3) parts, with the additional
parts for Application-specific or data-access services.
“Parts” are separated by hyphens
No spaces anywhere in the name
Parts:
1) IF the service is to be application-specific, then the name (acronym/short-name)
of the application will be first (in itself cannot contain hyphens), a hyphen (-),
2) the logical name of the service,
3) IF the service is to be used for data access only (i.e. querying and feature access)
then “-Data” should be appended.
Map Document (MXD) Files
The naming convention for map documents (MXD-files) is extremely important. It
captures the important characteristics of the map to facilitate update and management.
The file name will conform to the following:
The file name will be the service name, from above, followed by a hyphen and the 8-
digit date of publication in YYYYMMDD format
o This is the date that the MXD was considered ready for publication.
o NOTE: It is recommended to be, but must be no earlier than, the last modified
date of the file as delivered by the author and it must be formatted as ISO
8601 - Representation of Dates and Times - Basic Format, (time is not
necessary):
o Date of Publication Format: YYYYMMDD
Example: For 2012-03-08, the proper format would be “20120308”
the file extension ought to be (.mxd)
No Spaces anywhere in the name
Map Document Format Examples:
Application Specific:
Team HP
Map Service Specifications 43
<Application name>-<map service name>-<date of publication>.<file extension>
Example: Species Inventory map document to be used for the publication of the
FWIMT internal use only map service.
FWIMT-Species_Inventory-20140101.mxd
Normal Non-Application Specific:
<Map Service Name>-<date of publication>.<file extension>
Example: Disposition Mapping map document to be used for the publication of the
Disposition Mapping map service.
Disposition_Mapping-20140101.mxd
Data Access Only <Map Service Name including data suffix>-<date of publication>.<file extension>
Example: Disposition Mapping map document to be used for the publication of the
Disposition Mapping map service used for data searching purposes.
Disposition_Mapping-Data-20130101.mxd
The name will be the name of the map service as described above. See Section 3.2
Naming Conventions, Map Services.
Cached Map Services
If caching is required you will need to create mxd’s separately for each coordinate system
you want the map service cached in. Use the coordinate reference system alias at the
end of the service name
- 10TM
This is the alias for NAD83 / Alberta 10-TM (Forest) (i.e. EPSG: 3400)
- WMAS
This is the alias for WGS 1984 Web Mercator Auxiliary Sphere (i.e. EPSG: 3857)
Dataframes
The name of the dataframe is important because it is what is used to define the logical
name of the map service.
The dataframe name should correspond to the service name portion of the MXD-file
name, above, but with spaces instead of the underscores. This name will be used to
display the service name when a user adds this service to a viewer application.
Example:
Map Service name portion of the map document filename: My_Alberta_Map_01
Team HP
44 Map Service Specifications
Dataframe Name: My Alberta Map 01
Dataframe names can contain any character with the exception of the following
characters:.
“ ‘ < > &
NOTE: The ESRD MXD Scanner Tool automatically replaces the exception
characters with underscores. If this is not desirable, it should be done manually.
Consecutive spaces and characters cannot be used, that is, no two of the same
character together, with the exception of letters (A to Z) or (a to z) and numbers (0 to
9).
Use title case: Capital letters are used for first letter of words except for articles
Layers and Group Layers
Layer names and Group layer names can contain any character with the exception of
the following characters:
“ ‘ < > &
NOTE: The ESRD MXD Scanner Tool automatically replaces the exception
characters with underscores. If this is not desirable, it should be done manually.
Consecutive spaces and characters cannot be used, that is, no two of the same
character together, with the exception of letters (A to Z) or (a to z) and numbers (0 to
9).
Use title case. Capital letters are used for first letter of words, except for articles.
If the users can query the attributes of the layers shown, the information displayed
should be normalized to be easily interpreted.
Notes on the layer properties (attribute fields of the layers):
- The SHAPE field must be visible to allow the geometry to be queried. If you want
users of the service to be able to obtain the geometry for individual features, then
it is recommended the field be enabled (checked on).
- The OBJECTID will appear whether you turn it off or not, so assign the alias of
“Object ID” to the field.
- All irrelevant fields should be set to non-visible (unchecked) in the layer
properties unless required. To the contrary, GUIDs used as primary or foreign
keys should be left enabled (checked on), such as the GLOBALID column, if it
exists.
- The SHAPE.STLength() and SHAPE.STArea() fields should also be disabled
(unchecked) as they are projection-specific and contain too many decimal places,
and as a result, they can be misleading. Geometry measurement tools should be
used instead to calculate length/perimeter/area at runtime.
- Meaningful aliases should be created for all visible fields even if the field name is
readable and should be in Title Case rather than ALL CAPS.
Team HP
Map Service Specifications 45
3.3 View-Optimized Scales and Display-Range Thresholds
Before creating any maps it is important to determine a set of scales at which the map
will be optimized. For the purpose of this document we will refer to these as the “view-
optimized scales”. The midpoints between the view-optimised scales are where layer
visibility transitions should occur. These are referred to as the minimum and maximum
viewable scales for any given view-optimised scale.
The view-optimised scales also serve as the scales used by the map cache scheme (also
known as a “tiling scheme”), if the service were to be cached. The scales to be used will
be those used by the Web-Mercator Auxiliary Sphere Cache Scheme, even if a different
map projection is to be used, such as 10-TM Forest. Table 2 on the following page lists
the view-optimised scales to be chosen from, and the corresponding minimum and
maximum viewable scales.
Using these view-optimised scales ensures that map documents created in any projection
can be easily published and cached using the Web Mercator Auxiliary Sphere map
projection, which is the one required for interoperability with Google, Bing, and ArcGIS
Online map services and is quickly becoming the de facto web standard for cached map
services. Although dynamic services are not limited to particular scales, data and label
display should be optimized using the same scale values. This ensures a consistent user
experience, enables caching to be used easily in the future with minimal changes to the
MXD, and ensures compatibility with other services.
Team HP
46 Map Service Specifications
Table 2. SRD Standard View-Optimised Scales
Scale
Level
Minimum Viewable
Scale
View-Optimised
Scale
Maximum Viewable
Scale
00 887,486,291 591,657,528 443,743,146
01 443,743,145 295,828,764 221,871,573
02 221,871,572 147,914,382 110,935,787
03 110,935,786 73,957,191 55,467,893
04 55,467,892 36,978,595 27,733,947
05 27,733,946 18,489,298 13,866,974
06 13,866,973 9,244,649 6,933,487
07 6,933,486 4,622,324 3,466,743
08 3,466,742 2,311,162 1,733,372
09 1,733,371 1,155,581 866,686
10 866,685 577,791 433,343
11 433,342 288,895 216,672
12 216,671 144,448 108,336
13 108,335 72,224 54,168
14 54,167 36,112 27,084
15 27,083 18,056 13,542
16 13,541 9,028 6,771
17 6,770 4,514 3,386
18 3,385 2,257 1,693
19 1,692 1,128 846
For example, if a data layer is to be displayed from scale levels 6 – 19 then, the minimal
scale value could be set to 1: 13,866,973 and the maximum scale value to 1:846.
When the map service is dynamic, the data will be visible between and including these
scale threshold values. When the map service is cached, data will either be displayed only
Team HP
Map Service Specifications 47
at the view-optimized scales or at all scales, depending on the client software. Displaying
the data at all scales is done by resampling the cache-tile image resolution. The tile used
to generate the resampled image is the one at the scale-level where the target scale falls
between the minimum and maximum viewable scale thresholds for that scale-level. Both
ArcMap and Geocortex Essentials use this method to display cached map services at all
scales. The switch between cache levels happens at the midpoint between them, similar to
the threshold values noted above.
The following four figures are an example of this transition. The first two use the level 14
cache tiles, and the second two use the level 13 cache tiles:
Figure 4. Cached Map Image at 1:36112 (Uses level 14 cache tiles)
Team HP
48 Map Service Specifications
Figure 5. Cached Map Image at 1:54167 (Uses level 14 cache tiles)
Figure 6. Cached Map Image at 1:54568 (Uses level 13 cache tiles)
Team HP
Map Service Specifications 49
Figure 7. Cached Map Image at 1:72224 (Uses level 13 cache tiles)
It should be noted that for operational use in the Province of Alberta, scale-levels 6 to 19
are required for full-screen, desktop display, while smaller scales may only be required to
support smaller viewers such as overview maps or other small viewers, mobile devices,
or in cases where data is being viewed at national or international extents. The minimum
recommended range is from level 4 to 17. Depending on the data there may be value is
showing it at even larger scale levels 18 & 19.
As long as these scales are used in the production of map documents destined for
publication as map services, the map author generally does not need to be concerned with
the selection of map caching parameters. Rather, the person with the role of ArcGIS
Server administrator (who may or may not be the same person) is responsible for this
within the ArcGIS Server environment.
For testing purposes, it may be useful to build test caches to be able to see how one’s map
will look and feel once it is cached in the production environment (GENESIS) and to
determine if any special caching requirements exist (particularly with regard to
transparency). The following table lists the caching parameters that are the standard at
this time, but are subject to change. The document is not defining these parameters – they
are listed here merely for convenience. Refer to the GENESIS System Documentation for
this information.
Team HP
50 Map Service Specifications
Table 3: Map Caching Parameters
Parameter Value
Draw this map service: Using tiles from its cache
Scales See Table 2. SRD Standard View-Optimised Scales
Storage Format Compact
Create tiles on demand No
Allow clients to cache
tiles locally
No
Use local cache directory
when generating tiles on
the server
Yes
Origin Default numerical values
Tile Format PNG8
Use PNG 8 for overlay services that need to have a
transparent background, such as roads and boundaries. PNG
8 creates tiles of very small size on disk with no loss of
information.
Do not use PNG 8 if your map contains more than 256
colours. Imagery, hillshades, gradient fills, transparency,
and anti-aliasing can easily push your map over 256 colours.
Even symbols such as highway shields may have subtle
anti-aliasing around the edges that unexpectedly adds
colours to your map.
PNG24
PNG24 does not have the alpha channel and is not
supported in all browsers. Use PNG32 instead
PNG32
Use PNG32 for overlay services, such as roads and
boundaries, which have more than 256 colours. PNG32 is
an especially good choice for MSD-based overlay services
that have anti-aliasing enabled on lines or text. PNG32
creates larger tiles on disk than PNG24, but the tiles are
fully supported in all browsers.
Team HP
Map Service Specifications 51
Continued…
Tile Format (continued) JPEG
Use this format for basemap services that have large colour
variation and do not need to have a transparent background.
For example, raster imagery and very detailed vector
basemaps tend to work well with JPEG.
JPEG is a lossy image format. It attempts to selectively
remove data without affecting the appearance of the image.
This can cause very small tile sizes on disk, but if your map
contains vector linework or labels, it may produce too much
noise or blurry area around the lines. If this is the case, you
can attempt to raise the compression value from the default
of 75. A higher value, such as 90, may balance an
acceptable quality of linework with the small tile size
benefit of the JPEG.
Mixed
A Mixed cache uses JPEG in the centre of the cache with
PNG 32 on the edge of the cache. Use the mixed mode
when you want to cleanly overlay raster caches on other
layers.
When a mixed cache is created, PNG 32 tiles are created
anywhere that transparency is detected (in other words,
anywhere that the data frame background is visible). The
rest of the tiles are built using JPEG. This keeps the average
file size down while providing you with a clean overlay on
top of other caches. If you do not use the mixed mode cache
in this scenario, you will see a non-transparent "collar"
around the periphery of your image where it overlaps the
other cache.
Compression Valid for JPEG only, see above.
Height 256
Width 256
Dots per inch 96
Advanced Options|
Cache Type
Fused Cache
Cache Directory Not applicable.
Team HP
52 Map Service Specifications
3.4 Supported Coordinate Reference Systems
SRD has selected two coordinate reference systems (CRS) to officially support for the
purpose of the publication of map services:
WGS-84 Web Mercator (Auxiliary Sphere)
o Shortcut to documentation from Microsoft
http://goo.gl/Hw50a
o Shortcut to documentation from ESRI
http://goo.gl/e9kIx
o Coordinate Reference System IDs:
EPSG Well-Known ID: 3857
a.k.a. ESRI Well-Known ID: 102100
NAD83 / Alberta 10-TM (Forest)
o Coordinate Reference System IDs:
EPSG WKID: 3400
a.k.a. ESRI WKID: 102184
Keep in mind that map data doesn’t need to actually be displayed in a particular CRS to
enable the use of alternate CRSs with measurement and coordinate entry tools. If multiple
CRS are used, cached map services will need to be produced with each (a separate, but
virtually identical MXD-file). For optimal performance, copies of the source data should
be stored in each of the supported CRSs. Multi-database replication with on-the-fly
reprojection can handle this well and is easily achieved in an ArcSDE environment.
Dynamic map services can reproject data on the fly, but this has a significant impact on
performance of the service. Performance testing done during the GENESIS
implementation found significant performance impacts resulting from reprojection on-
the-fly. For this reason, the data should be housed in each of the supported projections to
maximize performance.
3.5 Service-Level Metadata
There are various text properties within an MXD-file that support service-level metadata.
There are essentially three types of metadata content that can be entered in the MXD-file.
Metadata documenting the MXD-file itself
Metadata documenting the service, as a whole, that the MXD-file is meant to define
Metadata documenting the individual data layers within the service
These properties are exposed within the service to describe their respective service
elements.
Team HP
Map Service Specifications 53
Map Document Properties
The MXD-file document properties are a place to store information that is relevant to the
actual MXD-file. In the document properties, there are 7 textual values that can be
entered: Title, Summary, Description, Author, Credits, Tags, and Hyperlink Base. Of
these, the adopted citation approach is to fill in only the Title, Author, and Credits.
Title o Official logical name of the map service contained in the map document
o Example:
For a document named…
Urban_Rural_Municipality-20120331.mxd
…the map document Title citation is Urban and Rural Municipality, which
was identified as the “Service Name” as per section 3.2.
Author o The fully-qualified name of the business unit publishing the map.
o Must follow the following format:
<Branch Name>, <Division Name>, <Department Name>, Government
of Alberta
o Example:
Informatics Branch, Corporate Services Division, Alberta
Environment and Parks, Government of Alberta
o Guidance:
Author citation is provided by the map document author business unit, and
should conform to GeoDiscover Alberta best practice for citation of
Government of Alberta agencies. Also, best practice is to avoid the use of
abbreviation or acronyms.
Credits o A copyright statement.
o For services published from within the Government of Alberta, this will
always be:
Copyright Government of Alberta
Team HP
54 Map Service Specifications
Example:
Figure 8: Map Document Properties
Data Frame Properties
The data frame properties are a place to store information that is relevant to the map
service as a whole, once it is published. On the General tab in data frame properties,
there are 3 textual values that can be entered: Name, Description, and Credits.
Name o Official logical name of the map service defined by the data frame. This
should be the same as the document Title and serves as the definition of the
logical name of the map service. Changing this value has the same effect as
changing the name of the data frame from the layer list.
o Must adhere to the allowable character requirements listed in section 3.2.
o Example:
For a document named…
Urban_Rural_Municipality-20120331.mxd
…the data frame Name citation is Urban and Rural Municipality, which
was identified as the “Service Name” as per section 3.2.
o Guidance:
Team HP
Map Service Specifications 55
Data frame Name citation is provided by the map document author business
unit. Best practice is that the data frame Name citation corresponds to the
citation for the map document Title, as there is only one data frame permitted
per map document, as per these specifications. Also, best practice is to avoid
the use of abbreviation or acronyms.
Description o Brief general reference to the contents of the whole map. Remembering that
the data frame is the data structure that defines the map service, this text is
exposed as the description of the map service, after it is published in the
ArcGIS Server environment.
o Example:
For the document named…
Urban_Rural_Municipality-20120331.mxd
…the data frame Description citation might read:
Identity and location of municipality types administered under
authority of the Municipal Government Act. Also included are
certain unincorporated and federally administered population
centres.
o Guidance:
Try and be brief. Keep in mind that this is often times shown in search results
within the system and is used as a description to determine if the service
contains the information the user is looking for, not as a source of detailed
information about the contents of the service. It is not designed to be a place
to document technical details or other complex information.
Credits o A copyright statement.
o For services published from within the Government of Alberta, this will
always be:
Copyright Government of Alberta
Team HP
56 Map Service Specifications
Example:
Figure 9: Data Frame Properties
Layer Properties
The layer properties are a place to store information that is relevant to the specific layer
within the map service. Try to remember the distinction between the data and the layer;
specifically that the layer is a visual representation of the data with symbology applied
and may or may not have cartographic representations, selective symbology, definition
queries, etc. that modify the display of the content. With that said, describe what is
actually being displayed, not the raw source data used.
Official citation is required for all layers in a data frame. If the layers are part of a group
layer, citations of the group layer properties are also required, including group layer
name, description, and credits. On the General tab in layer properties, there are 3 textual
values that can be entered: Layer Name, Description, and Credits.
Layer Name o Must adhere to the allowable character requirements listed in section 3.2.
o Example:
Hamlet Locality and Townsite Point
o Guidance:
Layer Name citation is provided by the map document author business unit.
Layer Name citation should correspond to the source data layer Title cited in
metadata catalogued in GeoDiscover Alberta, if available. If the layer
represents a subset of a data set that is catalogued as a whole, the name should
make this clear. For example, if only hamlets were to be displayed, the layer
name might be “Hamlet”. If not catalogued in GeoDiscover Alberta, the
citation shall be the adopted official logical identifier assigned by the Data
Authority. There may be a need to modify the Layer Name to remove illegal
characters not allowed for Services citations, but allowed for use in the
Team HP
Map Service Specifications 57
GeoDiscover Alberta naming. For example, in GeoDiscover Alberta the noted
example here is cited as Hamlet, Locality and Townsite Point (comma
included). Also, best practice is to avoid the use of abbreviation or acronyms.
Description o Brief general reference to the contents of the layer.
o Example:
For the layer named…
Hamlet Locality and Townsite Point
…the layer Description citation might read:
Identity and location of Hamlets, Localities and Townsites in
the Province of Alberta. Location representation is by point,
not area (polygon). Hamlet is a municipality type administered
under authority of the Municipal Government Act. Locality is
an unincorporated place or an area with scattered population.
Townsite is a federally administered village.
o Guidance:
Try and be brief. Keep in mind that a user can read the metadata for a layer if
required. This is not the place to store and maintain detailed layer-level
metadata but rather a mechanism that allows the map author to describe the
layers used in a map so it can be viewed by a client application.
Credits o A copyright statement. For services published from within the Government of
Alberta, this will always be:
Copyright Government of Alberta
Example:
Figure 10: Layer Properties
Team HP
58 Map Service Specifications
3.6 Quality Control
A set of quality control checks has been developed that shall be performed on an MXD
prior to publication. Many things that should be checked are handled automatically with
the in-house MXD Scanner Tool, while others need to be performed manually. This tool
also performs all of the standard ESRI checks. It is available as a geoprocessing service
on GENESIS. Please email the ESRD GENESIS Admin shared mailbox for more
information.
Manual Verifications
The following verifications should be performed manually:
An index should be created on all fields used by definition queries. Note that a layer
based on a database view cannot have an index built and you may receive a warning
in the log file which should be ignored, however, the source data for the view should
be indexed.
The background colour of the dataframe should be set (i.e. RGB: 254,255,255)
The map extent should be set specifically to include all features
Before sending the mxd through the scanner, zoom to full extent and save
Automated Verifications
In addition to standard ESRI checks, a number of additional verifications could be
performed on the maps. For example, the following warnings are documented by the
aforementioned MXD Scanner Tool and must be corrected manually:
Map document has no credits set
Map document has no author set
Map document has no title set
Data frame has no credits set
Data frame has no description set
Layer has no credits set
Layer has no description set
Layer draws at all scales (Standard ESRI check)
Group layer level depth exceeding the specified limit
Group layer is empty (Standard ESRI check)
Layer does not have a spatial index (Standard ESRI check), a view will not have an
index, please see note above in “Manual Verifications”
Layer is using transparency greater than 80%
The MXD Scanner Tool also provides a list of layers that require special attention from
the author to make sure the best approach was taken:
Layer is using a different projection than the dataframe (Standard ESRI check)
Layer is using transparency (Standard ESRI check)
The following errors detected by the MXD Scanner Tool are corrected automatically:
Team HP
Map Service Specifications 59
Layer names contain invalid or unsafe characters
The dataframe name contains invalid of unsafe characters
ESRI Error Codes
The following tables list the standard error codes from ESRI’s MXD analyzer tool.
Table 4: Standard ESRI MXD Error Codes
Code Description
00001 Data frame does not have layers
00002 Data frame does not have a spatial reference
00003 Layer's data source is inaccessible
00004 Layer's data source is not supported
00005 Layer type is not supported
00006 Layer's symbology is not supported
00007 Layer's definition query is invalid
00011 Raster symbology uses statistics from the current display extent
00012 The combination of spatial reference and the units used in the layer's
proportional symbology is not supported
00013 Layer uses a symbol that is not supported
00014 Annotation layer does not draw in table of contents order
00015 Annotation layer is being drawn with the densify annotation baseline option
enabled
00016 The option to not rotate marker symbols with the data frame is not supported
00017 Data frame has at least one annotation group that is enabled and contains
graphics
00018 Data frame uses a background symbol that is not a solid fill
00019 Layer contains a symbol type that does not match the referenced data source's
geometry type
00020 Annotation layer uses a symbol that is not supported
Team HP
60 Map Service Specifications
Code Description
00021 Feature selections are not supported
00022 Data frame uses unsupported 8.x style symbol level drawing
00023 Layer uses unsupported dynamic hillshade illumination
00024 Route hatch symbology is not supported
00025 Selection layers are not supported
00026 Data frames with a clip shape are not supported
00027 Layer uses a simple fill symbol that is a non-solid fill
00028 Annotation layer's feature class contains a symbol in the symbol collection that
is not supported
00030 Layer participates in layer masking
00031 Layer contains representation rule which uses custom geometric effect or
marker placement.
00032 Standalone table's data source is inaccessible
00033 Standalone table's data source is not supported
00035 Layer contains representation rule with geometric logic error
00036 Layer uses a page definition query
00037 Basemap layers cannot be published directly to an optimized map service
00038 Layer's workspace is currently being edited
00039 Accelerated raster layers cannot be published directly to an optimized map
service
00040 Accelerated raster service layers cannot be published directly to an optimized
map service
00041 Layer's cache properties do not allow local caching
00042 Raster catalog displays with Display as wireframe when rasters are within the
display extent option
Team HP
Map Service Specifications 61
Code Description
00043 Unique value layer symbology contains values with the field delimiter
40001 The layer type or data source is not supported for packages
40002 The layer type or data source is not supported for schema only packages
40003 A layer description is required for packaging
40005 Layer's dataset is using an unknown coordinate system
Table 5: Standard ESRI MXD Warning Codes
Code Description
10001 Layer's data source has a different projection than the data frame's projection
10002 Layer's data source doesn't have a spatial index
10003 Layer doesn't have an attribute index on fields used for a join
10005 Layer's data source is a personal geodatabase
10006 Layer's definition query uses unqualified field names for fields that exist in more
than one table
10007 Label class value has an SQL query that uses unqualified field names for fields
that exist in more than one table
10008 Label class value has a label expression that uses unqualified field names for
fields that exist in more than one table
10009 Enabling the option to convert layer transparency to color transparency may
improve performance
10010 Raster layer's data source does not have image statistics
10011 Layer's data source uses wavelet compression
10012 Layer uses dynamic panchromatic sharpening
10013 Layer uses dynamic orthorectification
10014 Layer's draw time may be affected by slow join access times
Team HP
62 Map Service Specifications
Code Description
10017 Layer uses symbol level drawing with a picture marker symbol
10018 Layer uses symbol level drawing with a character marker symbol
10019 Layer uses symbol level drawing with a non-simple fill symbol
10020 Layer uses symbol level drawing with a marker symbol with a halo
10026 Layer uses symbol level drawing with field-based transparency
10027 Layer's data source is referenced via a UNC path
10028 Annotation layer's feature class does not have a symbol stored in a symbol
collection
10029 Raster layer's data source does not have pyramids
10030 Layer's data source is ArcSDE not accessed via a direct connection
10031 Raster catalog layer uses color correction
10032 Layer's data source consists of nested joins
10033 Layer uses symbol level drawing with layer transparency
10035 Layer's definition query references field names that are not indexed
10036 Label class value has an SQL query that references field names that are not
indexed
10037 Label class value has an SQL query that is not optimizable
10038 Data Frame uses the Maplex Label Engine
10040 Layer uses representations
10041 Layer uses symbol level drawing with layer masking
10042 Layer uses symbol level drawing with feature masking
20001 Layer uses a picture symbol with a reference scale
20002 Layer uses an EMF picture symbol with image separation
20003 Layer uses a simple marker symbol with a halo
Team HP
Map Service Specifications 63
Code Description
20004 Layer uses a simple line symbol with a style other than solid
20005 Annotation feature class contains a symbol in the symbol collection with the
Rotate With Transform option disabled
20007 Layer contains a multilayer line symbol whose symbol widths may result in
aliasing
20008 Layer uses a text symbol which draws with faux bold or italic styles
20009 Layer uses the size renderer with an arrow marker symbol
20010 Data frame uses unsupported background symbol
20011 Layer's data source references a dynamic map service
20012 Layer supports time data
50001 The layer type or data source is not supported in 9.3.1 packages
50002 Topology errors will not be included in the package
50003 Layer's data source will be converted to a file geodatabase
50005 Layer does not support intersecting the data frame
50006 Basemap layers will be converted to group layers in 9.3.1 packages
Table 6: Standard ESRI MXD Information Codes
Code Description
30001 Annotation layer's feature class does not have an index on the
AnnotationClassID field
30002 Annotation layer's feature class does not have an index on the Status field
30003 Layer draws at all scale ranges
30004 Layer uses a gradient fill
30005 Group layer is empty
Team HP
64 Map Service Specifications
30006 Layer's data source references a Web service
Team HP
Map Service Specifications 65
4 References
Tips and best practices for map caches:
http://help.arcgis.com/en/arcgisserver/10.0/help/arcgis_server_dotnet_help/index.html#//
009300000079000000
Drawing differences between the ArcGIS drawing engines:
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Drawing_differences_betw
een_the_ArcGIS_drawing_engines/00sq0000000w000000/
Layer transparency:
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00sq0000001v000000.ht
m
Symbology performance:
http://support.esri.com/en/knowledgebase/techarticles/detail/33098