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




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



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



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


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


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


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


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


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


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


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


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


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


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


Line Features

Use simple line symbols. Avoid cartographic lines.

For more complex symbology, use ESRI-optimized lines as much as possible.



The following figure shows the relative performance of different types of line



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


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


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



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



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


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


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


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


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


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


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


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


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.

http://help.arcgis.com/en/arcgisdesktop/10.0/help/00sq/00sq00000028000000.htm

http://help.arcgis.com/en/arcgisdesktop/10.0/help/00sq/00sq00000028000000.htm

Team HP


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


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


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


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


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


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


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


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


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


Set the Map Document Properties

Under “File” drop down menu, select the “Map Document Properties”

Team HP


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


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


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


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


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 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


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


<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


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


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


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


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




Team HP



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


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


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


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 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


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…


…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


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…


…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:


Team HP


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


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:


Example:

Figure 10: Layer Properties

Team HP


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


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


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


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


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


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


30006 Layer's data source references a Web service

Team HP


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

map service specifications - maps.alberta.ca...cached map services and edit the format and grammar,...

Documents