Using Projection Elements

Introduction
- Reasons for using a projected coordinate system
- Choosing a map projection
Projection Elements in ArcIMS
Using the Projection Elements
Defining a Coordinate System
Using Datum Transformations
Data Densification
Processing Time

Introduction

Features on a map refer to the actual locations of the objects they represent in the real world. The positions of objects on the earth's spherical surface are measured in degrees of latitude and longitude, also known as geographic coordinates. Though latitude and longitude can locate exact positions on the surface of the earth, they are not uniform units of measure; only along the equator does the distance represented by one degree of longitude approximate the distance represented by one degree of latitude. To overcome measurement difficulties, data is often transformed from the three-dimensional geographic coordinate system to the two-dimensional planar surface in a projected coordinate system. Projected coordinate systems describe the distance from an origin (0,0) along two separate axes: a horizontal x-axis representing east-west and a vertical y-axis representing north-south.

Because the earth is round and maps are flat, getting information from the curved surface to a flat one involves a mathematical formula call a map projection. A map projection transforms latitude and logitude to x,y coordinates in a projected coordinate system.


Locations are expressed as latitude and longitude on the globe (left) and as x,y coordinates on a map (right).

This process of flattening the earth causes distortions in one or more of the following spatial properties: distance, area, shape, and direction. No projection can preserve all these properties, and as a result, all flat maps are distorted to some degree. Fortunately, you can choose from many different map projections. Each is distinguished by its suitability for representing a particular portion and amount of the earth's surface and by its ability to preserve distance, area, shape, or direction. Some map projections minimize distortion in one property at the expense of another, while others strive to balance the overall distortion. As a mapmaker, you can decide which properties are most important and choose a projection that suits your needs.


Displaying the world using the Sinusoidal projection (left) and the Robinson projection (right).

Reasons for using a projected coordinate system

You want to make accurate measurements from your map and be sure that spatial analysis options calculate distance correctly. Latitude/Longitude is a good system for storing spatial data but not very good for viewing, querying, or analyzing maps. Degrees of latitude and longitude are not consistent units of measure for area, shape, distance, and direction.
You are making a map in which you want to preserve one or more of these properties: area, shape, distance, and direction.
You are making a small-scale map such as a national or world map. With a small-scale map, your choice of map projection determines the overall appearance of the map. For example, with some projections, lines of latitude and longitude will appear curved; with others they will appear straight.
Your organization mandates using a particular projected coordinate system for all maps.

Choosing a map projection

Here are a few things to consider when choosing a projection:

Which spatial properties do you want to preserve?
Where is the area you're mapping? Is your data in a polar region? An equatorial region?
What shape is the area you're mapping? Is it square? Is it wider in the east-west direction?
How big is the area you're mapping? On large-scale maps, such as street maps, distortion may be negligible because your map covers only a small part of the earth's surface. On small-scale maps, where a small distance on the map represents a considerable distance on the earth, distortion may have a bigger impact, especially if you use your map to compare or measure shape, area, or distance.

Answering these questions will determine what map projection and thus what projected coordinate system you'll want to use to display your data.

Map projections can be generally classified according to what spatial attribute they preserve:

Equal Area projections preserve area. Many thematic maps use an equal area projection. Maps of the United States commonly use the Albers Equal Area Conic projection.
Conformal projections preserve shape and area useful for navigational charts and weather maps. Shape is preserved for small areas, but the shape of a large area such as a continent will be significantly distorted. The Lambert Conformal Conic and Mercator projections are common conformal projections.
Equidistant projections preserve distance but no projection can preserve distances from all points to all other points. Instead, distance can be held true from one point (or a few points) to all other points or along all meridians or parallels. If you will be using your map to find features that are within a certain distance of other features, you should use an equidistant map projection.
Azimuthal projections preserve direction from one point to all other points. This quality can be combined with equal area, conformal, and equidistant projections, as in the Lambert Equal Area Azimuthal and the azimuthal equidistant projections.
Other projections minimize overall distortion but don't preserve any of the four spatial properties of area, shape, distance, and direction. The Robinson projection, for example, is neither equal area nor conformal but is aesthetically pleasing and useful for general mapping.

Projection Elements in ArcIMS

Projections in ArcIMS are handled by the ArcIMS Spatial Server. Three projection elements are used to retrieve data in the correct projected coordinate system:

With ArcIMS, the term coordinate system, which includes both geographic and projected coordinate systems, is used to describe the information about the projection, as well as other specifics such as datum, units, and meridians.

Each projection element defines a coordinate system by either an ID or a definition string. For a complete list of supported IDs and definition strings, see:

Projected Coordinate Systems Listing [Sorted by projection ID] [Sorted by name]
Geographic Coordinate Systems Listing [Sorted by projection ID] [Sorted by name]
Datum Transformation Listing [Sorted by projection ID] [Sorted by name]

It is highly recommended to use FEATURECOORDSYS and FILTERCOORDSYS in your map configuration files. Many clients, including ArcMap and WMS clients, may not handle projections correctly if this information is not included in the service.

COORDSYS

COORDSYS defines the projection metadata for a data layer. It does not reproject the data to another coordinate system; it merely states what projection that layer is in. COORDSYS can be used with:

Vector data including shapefiles, coverages in ArcSDE for Coverages, and ArcSDE layers. With vector data, if COORDSYS is not included with the layer, the ArcIMS Spatial Server reads any *.prj file associated with a shapefile or coverage or the spatial references table in ArcSDE.
Imagery including images in a directory and images in ArcSDE. COORDSYS should be used for all image layers in a map configuration file. If an image layer is missing in a response, check if COORDSYS is included in the map configuration file.
Acetate layers when the attribute units="database" is used in OBJECT.

If no *.prj file or spatial references table or COORDSYS is present, the layer is not projected. If a layer does not project as expected, check whether the layer has a *.prj file or spatial reference table or COORDSYS. For ArcMap Image Services, the coordinate system for each layer is handled in the ArcMap document (*.mxd or *.pmf).

FEATURECOORDSYS

FEATURECOORDSYS is used to specify a common coordinate system in an ArcIMS service to which each layer should be transformed. In an ArcIMS service, FEATURECOORDSYS represents the overall projection and can be thought of as the default coordinate system. This coordinate system can be different than the coordinate system of any of the layers.

Requests with no projection elements made to an ArcIMS service will receive data in the default coordinate system of the service. A request can override the service FEATURECOORDSYS with its own FEATURECOORDSYS. For example, if a service is in Robinson and a request includes a FEATURECOORDSYS of Mollweide, then the ArcIMS Spatial Server returns the data in Mollweide.

When FEATURECOORDSYS is present, the map units are calculated automatically by the ArcIMS Spatial Server. If MAPUNITS is present, it is ignored. Having the correct map units is important to make sure scale dependencies in LAYER, SCALEDEPENDENTRENDERER, and OBJECT are correctly calculated.

FILTERCOORDSYS

FILTERCOORDSYS is used to specify the coordinate system of the requesting client. Much like COORDSYS, FILTERCOORDSYS can be thought of as metadata, this time for the client. In the request, coordinates in the extents and spatial filters are in the coordinate system of the FILTERCOORDSYS.

FILTERCOORDSYS must be included in a map configuration file if FEATURECOORDSYS is present. In the service, FILTERCOORDSYS and FEATURECOORDSYS must have the same ID or string value. In requests, the two elements can have different values.

Using the Projection Elements

This next section discusses different scenarios for using the projection elements. One important note: the ArcIMS clients do not support projections. All projections must be handled by the ArcIMS Spatial Server. In addition, when using the ArcIMS viewers, FILTERCOORDSYS and FEATURECOORDSYS must have the same ID. The ArcIMS HTML Viewer can be customized to accommodate different IDs for FEATURECOORDSYS and FILTERCOORDSYS. The ArcIMS Java Viewers cannot be customized this way.

Map configuration file without FILTERCOORDSYS and FEATURECOORDSYS

The example below shows a map configuration file that does not use FILTERCOORDSYS or FEATURECOORDSYS but does use COORDSYS for the layers. The two layers are both world shapefile layers. One is in World Mollweide (id="54009") and the other is in World Robinson (id="54030"). Remember, if a shapefile has a *.prj file associated with it, COORDSYS does not need to be included. If neither a *.prj file nor COORDSYS is present, the layer is not projected.

Using COORDSYS in a map configuration file

To view a map, a GET_IMAGE request can be made to this Image Service. The following request includes no projection elements.

GET_IMAGE request with no projection elements

<?xml version="1.0" encoding="UTF-8" ?>
<ARCXML version="1.1">
  <REQUEST>
    <GET_IMAGE>
      <PROPERTIES>
      </PROPERTIES>
    </GET_IMAGE>
  </REQUEST>
</ARCXML>

In the returned image, the two layers do not overlay correctly because they are not in the same coordinate system.

In the next GET_IMAGE request, FEATURECOORDSYS and FILTERCOORDSYS are included and are set to World Sinusoidal, which has an id="54008".

GET_IMAGE request using FILTERCOORDSYS and FEATURECOORDSYS

<?xml version="1.0" encoding="UTF-8" ?>
<ARCXML version="1.1">
  <REQUEST>
    <GET_IMAGE>
      <PROPERTIES>
        <FILTERCOORDSYS id="54008" />
        <FEATURECOORDSYS id="54008" />
      </PROPERTIES>
    </GET_IMAGE>
  </REQUEST>
</ARCXML>

In the returned image, the two layers are aligned in the Sinusoidal projection.

The last GET_IMAGE example worked correctly because the two layers have coordinate systems with similar minimum and maximum X and Y extents. In reality, an ENVELOPE is normally included in the request. Coordinates used in ENVELOPE and inside SPATIALFILTER should be in the coordinate system of FILTERCOORDSYS. In the next example, an ENVELOPE is included in the request. The map units are calculated by the ArcIMS Spatial Server based on the ID selected for FEATURECOORDSYS. Hence, MAPUNITS is not required in requests.

GET_IMAGE request with ENVELOPE

<?xml version="1.0" encoding="UTF-8" ?>
<ARCXML version="1.1">
  <REQUEST>
    <GET_IMAGE>
      <PROPERTIES>
        <ENVELOPE minx="-14628440.851850007" miny="-9020047.848073646" maxx="15705351.712200116" maxy="8748562.401522137" />
        <FILTERCOORDSYS id="54008" />
        <FEATURECOORDSYS id="54008" />
      </PROPERTIES>
    </GET_IMAGE>
  </REQUEST>
</ARCXML>

With the above request, the returned ENVELOPE is guaranteed to be correct.

IMAGE response with ENVELOPE

<?xml version="1.0" encoding="UTF8"?>
<ARCXML version="1.1">
  <RESPONSE>
    <IMAGE>
      <ENVELOPE minx="-14628440.85185" miny="-11510914.9347945" maxx="15705351.7122001" maxy="11239429.488243" />
      <OUTPUT file="C:\ArcIMS\output\proj_paper_MYCOMPUTER79217360.jpg" url="http://mycomputer.esri.com/output/proj_paper_MYCOMPUTER79217360.jpg" />
    </IMAGE>
  </RESPONSE>
</ARCXML>

The returned image is the same as the previous image.

Map configuration file with FEATURECOORDSYS and FILTERCOORDSYS

FILTERCOORDSYS and FEATURECOORDSYS can be included in the map configuration file as shown in the next example. For both elements, the coordinate system ID is set to World Sinusoidal (id="54008"). Although MAPUNITS is included, it is ignored when FEATURECOORDSYS is present.

Using FILTERCOORDSYS AND FEATURECOORDSYS in a map configuration file

<?xml version="1.0" encoding="UTF-8"?>
<ARCXML version="1.1">
  <CONFIG>
    <ENVIRONMENT>
      <LOCALE country="US" language="en" variant="" />
      <UIFONT color="0,0,0" name="Arial" size="12" style="regular" />
    </ENVIRONMENT>
    <MAP>
      <PROPERTIES>
        <ENVELOPE minx="-14628440.851850007" miny="-9020047.848073646" maxx="15705351.712200116" maxy="8748562.401522137" name="Initial_Extent" />
        <MAPUNITS units="meters" />
        <FEATURECOORDSYS id="54008" />
        <FILTERCOORDSYS id="54008" />
      </PROPERTIES>
      <WORKSPACES>
        <SHAPEWORKSPACE name="shp_ws-12" directory="c:\data" />
      </WORKSPACES>
      <LAYER type="featureclass" name="Ocean" visible="true" id="22">
        <DATASET name="WORLD30" type="polygon" workspace="shp_ws-12" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL fillcolor="240,255,255" />
        </SIMPLERENDERER>
      </LAYER>
      <LAYER type="featureclass" name="Robinson" visible="true" id="0">
        <DATASET name="cntry94_Robinson" type="polygon" workspace="shp_ws-12" />
        <COORDSYS id="54030" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL filltype="solid" fillcolor="0,153,102" />
        </SIMPLERENDERER>
      </LAYER>
      <LAYER type="featureclass" name="Mollweide" visible="true" id="1">
        <DATASET name="Cntry94_Mollweide" type="polygon" workspace="shp_ws-12" />
        <COORDSYS id="54009" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL filltransparency="0.0" boundarywidth="3" boundarycolor="27,27,127" />
        </SIMPLERENDERER>
      </LAYER>
    </MAP>
  </CONFIG>
</ARCXML>

Once again, a GET_IMAGE request with no projection elements is made to the service.

GET_IMAGE request with no projection elements

<?xml version="1.0" encoding="UTF-8" ?>
<ARCXML version="1.1">
  <REQUEST>
    <GET_IMAGE>
      <PROPERTIES>
      </PROPERTIES>
    </GET_IMAGE>
  </REQUEST>
</ARCXML>

This time in the returned image, the two layers overlay in the Sinusoidal projection, the default from the service.

Regardless of the coordinate system of the service, a request can always include projection elements that override the service. If you want to know the projection of a service you are accessing, you can send a GET_SERVICE_INFO request to find out which FEATURECOORDSYS and FILTERCOORDSYS are in use.

GET_SERVICE_INFO request

<?xml version="1.0" encoding="UTF-8"?>
<ARCXML version="1.1">
  <REQUEST>
    <GET_SERVICE_INFO fields="false" envelope="false" renderer="false" extensions="false" />
  </REQUEST>
</ARCXML>

The response includes FILTERCOORDSYS and FEATURECOORDSYS if they are present in the ArcIMS service.

SERVICEINFO response

<?xml version="1.0" encoding="UTF8"?>
<ARCXML version="1.1">
  <RESPONSE>
    <SERVICEINFO>
      <ENVIRONMENT>
        <LOCALE language="en" country="US" />
        <UIFONT name="Arial" color="0,0,0" size="12" style="regular" />
        <SEPARATORS cs=" " ts=";"/>
        <CAPABILITIES forbidden="" disabledtypes=""/>
        <SCREEN dpi="96"/>
        <IMAGELIMIT pixelcount="1048576" />
      </ENVIRONMENT>
      <PROPERTIES>
        <FEATURECOORDSYS id="54008" />
        <FILTERCOORDSYS id="54008" />
        <ENVELOPE minx="-14628440.85185" miny="-9020047.84807364" maxx="15705351.7122001" maxy="8748562.40152213" name="Initial_Extent" />
        <MAPUNITS units="meters" />
      </PROPERTIES>
      <LAYERINFO type="featureclass" visible="true" name="Ocean" id="22">
        <FCLASS type="polygon"></FCLASS>
      </LAYERINFO>
      <LAYERINFO type="featureclass" visible="true" name="Robinson" id="0">
        <FCLASS type="polygon"></FCLASS>
      </LAYERINFO>
      <LAYERINFO type="featureclass" visible="true" name="Mollweide" id="1">
        <FCLASS type="polygon"></FCLASS>
      </LAYERINFO>
    </SERVICEINFO>
  </RESPONSE>
</ARCXML>

You can override FEATURECOORDSYS and FILTERCOORDSYS in a request. To summarize the relationship of the projection elements in requests and responses:

FEATURECOORDSYS - what you want to project the results to.
FILTERCOORDSYS - the current projection of the client.
ENVELOPE and geometry coordinates - In the request, values must be in the coordinate system of the FILTERCOORDSYS projection. In the response, ENVELOPE and geometry coordinates are in the coordinate system of the FEATURECOORDSYS projection.

In the next GET_IMAGE request, FEATURECOORDSYS and FILTERCOORDSYS are both set to geographic coordinates with an id="4326". Since the client is in geographic coordinates (represented by FILTERCOORDSYS), the ENVELOPE needs to be in geographic coordinates.

GET_IMAGE request using FILTERCOORDSYS and FEATURECOORDSYS

<?xml version="1.0" encoding="UTF-8" ?>
<ARCXML version="1.1">
  <REQUEST>
    <GET_IMAGE>
      <PROPERTIES>
        <ENVELOPE minx="-180" miny="-90" maxx="180" maxy="90" />
        <FILTERCOORDSYS id="4326" />
        <FEATURECOORDSYS id="4326" />
      </PROPERTIES>
    </GET_IMAGE>
  </REQUEST>
</ARCXML>

In the returned image, the two layers are aligned in geographic coordinates.

Changing projections in a request

Assume now that your client viewer is currently in geographic coordinates ("4326"), but you want a map returned in Robinson ("54030"). In this scenario, FILTERCOORDSYS, the current projection of the client, is set to id="4326". Coordinates in the request, such as those in ENVELOPE, must also be in geographic coordinates.

FEATURECOORDSYS defines the coordinate system of the map returned to the client. In this case, FEATURECOORDSYS is set to id="54030".

GET_IMAGE request using FILTERCOORDSYS and FEATURECOORDSYS with ENVELOPE in decimal degrees

<?xml version="1.0" encoding="UTF-8" ?>
<ARCXML version="1.1">
  <REQUEST>
    <GET_IMAGE>
      <PROPERTIES>
        <ENVELOPE minx="-180" miny="-90" maxx="180" maxy="90" />
        <FILTERCOORDSYS id="4326" />
        <FEATURECOORDSYS id="54030" />
      </PROPERTIES>
    </GET_IMAGE>
  </REQUEST>
</ARCXML>

In the response, the ENVELOPE is in Robinson coordinates.

IMAGE response with ENVELOPE in Robinson coordinates

<?xml version="1.0" encoding="UTF8"?>
<ARCXML version="1.1">
  <RESPONSE>
    <IMAGE>
      <ENVELOPE minx="-16986727.8564406" miny="-12740045.8923304" maxx="16986727.8564406" maxy="12740045.8923304" />
      <OUTPUT file="C:\ArcIMS\output\proj_paper_MYCOMPUTER79217360.jpg" url="http://mycomputer.esri.com/output/proj_paper_MYCOMPUTER79217360.jpg" />
    </IMAGE>
  </RESPONSE>
</ARCXML>

In the returned image, the two layers are now in Robinson.

Defining a Coordinate System

A coordinate system can be defined in two ways: using a predefined coordinate system ID or a coordinate system definition string. The predefined IDs are a quick way to reference a coordinate system by using a single reference number. The coordinate system definition string uses a string to describe all parameters for a projection. The advantage of using the definition string is that parameters in the string can be modified.

For a complete list of supported IDs and definition strings, see:

As an example, the coordinate system ID for World Robinson is 54030.

The coordinate system definition string for World Robinson is:

World Robinson,54030
PROJCS["World_Robinson",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Robinson"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",0],UNIT["Meter",1]]

In the examples so far, only the IDs have been used. These IDs can be replaced by the definition string. In the next example, an Image Service includes the definition string for World Robinson for FEATURECOORDSYS and FILTERCOORDSYS. Note that the quotation marks (") in the definition string must be escaped with ".

PROJCS["World_Robinson",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Robinson"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",0],UNIT["Meter",1]]

Using a projection definition string for FILTERCOORDSYS AND FEATURECOORDSYS in a map configuration file

<?xml version="1.0" encoding="UTF-8"?>
<ARCXML version="1.1">
  <CONFIG>
    <ENVIRONMENT>
      <LOCALE country="US" language="en" variant="" />
      <UIFONT color="0,0,0" name="Arial" size="12" style="regular" />
    </ENVIRONMENT>
    <MAP>
      <PROPERTIES>
        <ENVELOPE minx="-14628440.851850007" miny="-9020047.848073646" maxx="15705351.712200116" maxy="8748562.401522137" name="Initial_Extent" />
        <MAPUNITS units="meters" />
        <FEATURECOORDSYS string="PROJCS["World_Robinson",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Robinson"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",0],UNIT["Meter",1]]" />
        <FILTERCOORDSYS string="PROJCS["World_Robinson",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Robinson"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",0],UNIT["Meter",1]]" />
      </PROPERTIES>
      <WORKSPACES>
        <SHAPEWORKSPACE name="shp_ws-12" directory="c:\data" />
      </WORKSPACES>
      <LAYER type="featureclass" name="Ocean" visible="true" id="22">
        <DATASET name="WORLD30" type="polygon" workspace="shp_ws-12" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL fillcolor="240,255,255" />
        </SIMPLERENDERER>
      </LAYER>
      <LAYER type="featureclass" name="Robinson" visible="true" id="0">
        <DATASET name="cntry94_Robinson" type="polygon" workspace="shp_ws-12" />
        <COORDSYS id="54030" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL filltype="solid" fillcolor="0,153,102" />
        </SIMPLERENDERER>
      </LAYER>
      <LAYER type="featureclass" name="Mollweide" visible="true" id="1">
        <DATASET name="Cntry94_Mollweide" type="polygon" workspace="shp_ws-12" />
        <COORDSYS id="54009" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL filltransparency="0.0" boundarywidth="3" boundarycolor="27,27,127" />
        </SIMPLERENDERER>
      </LAYER>
    </MAP>
  </CONFIG>
</ARCXML>

If a GET_IMAGE request is made to this service, the returned image includes the two layers in Robinson.

In the next example, an attribute in the definition string is changed. The central meridian for the FEATURECOORDSYS and FILTERCOORDSYS definition strings has been changed from 0 to 180.

Changing the central meridian in a projection definition string

<?xml version="1.0" encoding="UTF-8"?>
<ARCXML version="1.1">
  <CONFIG>
    <ENVIRONMENT>
      <LOCALE country="US" language="en" variant="" />
      <UIFONT color="0,0,0" name="Arial" size="12" style="regular" />
    </ENVIRONMENT>
    <MAP>
      <PROPERTIES>
        <ENVELOPE minx="-14628440.851850007" miny="-9020047.848073646" maxx="15705351.712200116" maxy="8748562.401522137" name="Initial_Extent" />
        <MAPUNITS units="meters" />
        <FEATURECOORDSYS string="PROJCS["World_Robinson",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Robinson"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",180],UNIT["Meter",1]]" />
        <FILTERCOORDSYS string="PROJCS["World_Robinson",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Robinson"],PARAMETER["False_Easting",0],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",180],UNIT["Meter",1]]" />
      </PROPERTIES>
      <WORKSPACES>
        <SHAPEWORKSPACE name="shp_ws-12" directory="c:\data" />
      </WORKSPACES>
      <LAYER type="featureclass" name="Ocean" visible="true" id="22">
        <DATASET name="WORLD30" type="polygon" workspace="shp_ws-12" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL fillcolor="240,255,255" />
        </SIMPLERENDERER>
      </LAYER>
      <LAYER type="featureclass" name="Robinson" visible="true" id="0">
        <DATASET name="cntry94_Robinson" type="polygon" workspace="shp_ws-12" />
        <COORDSYS id="54030" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL filltype="solid" fillcolor="0,153,102" />
        </SIMPLERENDERER>
      </LAYER>
      <LAYER type="featureclass" name="Mollweide" visible="true" id="1">
        <DATASET name="Cntry94_Mollweide" type="polygon" workspace="shp_ws-12" />
        <COORDSYS id="54009" />
        <SIMPLERENDERER>
          <SIMPLEPOLYGONSYMBOL filltransparency="0.0" boundarywidth="3" boundarycolor="27,27,127" />
        </SIMPLERENDERER>
      </LAYER>
    </MAP>
  </CONFIG>
</ARCXML>

If a GET_IMAGE request is made to this service, the returned image includes the two layers in Robinson centered on the Pacific Ocean.

Although the above examples with definition strings use map configuration files, definition strings can also be used in requests.

Using Datum Transformations

A datum is a reference frame defined by a spheroid and the spheroid�s position relative to the center of the earth and is associated with a geographic coordinate system (GCS). A datum transformation converts one GCS to another GCS. Common geographic coordinate systems include, for example, WGS 1984, NAD 1927, and NAD 1983.

What happens behind the scenes during a datum transformation is a four-step process. In the following figure, the desired result is to transform a layer from State Plane coordinates in NAD 1927 to UTM coordinates in NAD 1983. All datum transformations take place to and from WGS 1984, so there are some intermediate steps.

In Step 1, the original layer is in State Plane NAD 1927. This information should be included with COORDSYS within the layer. The projected data is transformed to geographic coordinates.
In Step 2, the datum transformation is made from NAD 1927 to WGS 1984.
In Step 3, the datum transformation is made from WGS 1984 to NAD 1983.
In Step 4, the data is projected from geographic coordinates to the new projection, in this case UTM coordinates. The projection information is contained in FEATURECOORDSYS.

The attributes datumtransformid and datumtransformstring are used with the projection elements when datum transformation information needs to be included.

When these attributes are used with COORDSYS in a map configuration file, the datum transformation is from a non-WGS 1984 GCS to WGS 1984. In the following example, the datum transformation is NAD_1927_To_WGS_1984_4. The datumtransformid is "8073".
When these attributes are used with FEATURECOORDSYS, the datum transformation is from WGS 1984 to a non-WGS 1984 GCS. In the next example, the datum transformation is NAD_1983_To_WGS_1984_4 (datumtransformid="8088"). Note that a datum transformation is always specified as non-WGS 1984 to WGS 84, regardless of the direction of the transformation. In this example, a transformation is made from WGS 1984 to NAD 1983.

Transforming a layer in NAD 1927 State Plane coordinates (id="26745") to NAD 1983 UTM coordinates (id="26911")

In the following request, a projection is made on-the-fly in a GET_IMAGE request. FILTERCOORDSYS is the value the map is currently in, which is NAD 1927 State Plane coordinates. FEATURECOORDSYS is what you want to project the map to, which is NAD 1983 UTM coordinates.

<?xml version="1.0" encoding="UTF-8" ?>
<ARCXML version="1.1">
<REQUEST>
<GET_IMAGE>
<PROPERTIES>
<ENVELOPE minx="347654.382887469" miny="3721249.75028362" maxx="434350.824485004" maxy="3785710.57603101" name="Initial_Extent" />
<FEATURECOORDSYS id="26745" datumtransformid="8073" />
<FILTERCOORDSYS id="26911" datumtransformid="8088" />
</PROPERTIES>
</GET_IMAGE>
</REQUEST>
</ARCXML>

Some datum transformations convert a non-WGS 1984 GCS to another non-WGS 1984 GCS. You can choose to use one of these transformations, but you should be aware that they perform more slowly than if they were transformed directly to or from WGS 1984. The reason is internal secondary transformations must be made.

In the following example, the data layer used is in GCS NAD 1927 and the service is in state plane with a NAD 1983 GCS. The datum transformation NAD 1927 to NAD 1983 is achieved using NAD_1927_To_NAD_1983_NADCON (datumtransformid="1241"). No datumtransformid is needed for FEATURECOORDSYS or FILTERCOORDSYS because the projection is already in the desired GCS.

<?xml version="1.0" encoding="UTF-8"?>
<ARCXML version="1.1">
<CONFIG>
<ENVIRONMENT>
<LOCALE country="US" language="en" variant="" />
<UIFONT color="0,0,0" name="SansSerif" size="12" style="regular" />
<SCREEN dpi="96" />
</ENVIRONMENT>
<MAP>
<PROPERTIES>
<ENVELOPE minx="383421.497486699" miny="73940.2061398798" maxx="385034.996095684" maxy="74781.8529969841" name="Initial_Extent" />
<MAPUNITS units="meters" />
<FEATURECOORDSYS id="32148" />
<FILTERCOORDSYS id="32148" />

</PROPERTIES>
<WORKSPACES>
<SHAPEWORKSPACE name="shp_ws-2" directory="c:\data\wa" />
</WORKSPACES>
<LAYER type="featureclass" name="Shorelines" visible="true" id="2">
<DATASET name="shorelines_nad27" type="line" workspace="shp_ws-2" />
<SIMPLERENDERER>
<SIMPLELINESYMBOL width="4" captype="round" color="255,0,0" />
</SIMPLERENDERER>
<COORDSYS id="4267" datumtransformid="1241" />
<!- GCS_North_American_1927 -->
</LAYER>
</MAP>
</CONFIG>
</ARCXML>

When deciding what datum transformation to use, keep the following guidelines in mind:

If you can, select a datum transformation that goes to and from WGS 1984. In a map configuration file, a layer COORDSYS should use a datum transformation that goes from the GCS of the layer to WGS 1984.
When no datum transformation is available to or from WGS 1984, use an alternate. Remember that these transformations perform less well.

The following table provides some examples of datum transformation combinations:

Example 1: The data layers are in WGS 1984. The service is in state plane with a HARN datum.

Data layers:	WGS 1984	id="4326"
Datum transformation:	None
Service:	State plane	id="2770"
Datum transformation:	NAD_1983_HARN_To_WGS_1984	datumtransformid="1580"

Layers:
<COORDSYS id="4326" />

Service:
<FEATURECOORDSYS id="2770" datumtransformid="1580" />
<FILTERCOORDSYS id="2770" datumtransformid="1580" />

Example 2: The data layers are in state plane using a NAD 1927 datum. The service is in UTM using a NAD 1983 datum.

Data layers:	State plane	id="26745"
Datum transformation:	NAD_1927_To_WGS_1984_4	datumtransformid="8073"
Service:	UTM	id="26911"
Datum transformation:	NAD_1983_To_WGS_1984_4	datumtransformid="8088"

Layers:
<COORDSYS id="26745" datumtransformid="8073" />

Service:
<FEATURECOORDSYS id="26911" datumtransformid="8088" />
<FILTERCOORDSYS id="26911" datumtransformid="8088" />

Example 3: The data layers are in UTM using a NAD 1983 datum. The service is in WGS 1984.

Data layers:	UTM	id="26911"
Datum transformation:	NAD_1983_To_WGS_1984_4	datumtransformid="8088"
Service:	WGS 1984	id="4326"
Datum transformation:	None

Layers:
<COORDSYS id="26911" datumtransformid="8088" />

Service:
<FEATURECOORDSYS id="4326" />
<FILTERCOORDSYS id="4326" />

Example 4: The data layers are in state plane in NAD 1983 datum. The service is in state plane using HARN datum.

Data layers:	State plane	id="26945"
Datum transformation:	NAD_1983_To_WGS_1984_4	datumtransformid="8088"
Service:	State plane	id="2770"
Datum transformation:	NAD_1983_To_HARN_CA_S	datumtransformid="8422"

Layers:
<COORDSYS id="26945" datumtransformid="8088" />

Service:
<FEATURECOORDSYS id="2770" datumtransformid="8422" />
<FILTERCOORDSYS id="2770" datumtransformid="8422" />

Example 5: The data layers are in state plane in NAD 1927 datum. The service is in state plane using HARN datum.

Data layers:	State plane	id="26745"
Datum transformation:	NAD_1927_To_WGS_1984_4	datumtransformid="8073"
Service:	State plane	id="2770"
Datum transformation:	NAD_1983_HARN_To_WGS_1984	datumtransformid="1580"

Layers:
<COORDSYS id="26745" datumtransformid="8073" />

Service:
<FEATURECOORDSYS id="2770" datumtransformid="1580" />
<FILTERCOORDSYS id="2770" datumtransformid="1580" />

The complete list of supported datum transformations is included in the Datum Transformation Listing.

Data Densification

The process of data densification adds virtual points to a layer before the layer is projected. When data is projected, the line geometry changes. For example, a square in one projection may be trapezoidal in another projection. In some cases, the number of points defining the geometry in the original layer is not enough to describe the geometry correctly in the projected layer. In the following figure, without densification, the square in Projection 1 is projected to the trapezoid as seen with Projection 2. When the data for Projection 1 is densified, the geometry for Projection 2 shows more detail.

DENSIFY can be used on a layer to define how much data should be densified before the layer is projected. If you find that features are missing from a layer in a requested image, usually around the periphery, try using DENSIFY on the layer. A word of caution about DENSIFY: if the tolerance value is too small, the ArcIMS Spatial Server can slow down considerably. It is better to start with a large number for tolerance. A guideline is to start with a value about 20 to 30 percent of the distance between the minimum and maximum x-coordinates of the current map extent.

Processing Time

Whenever the projection elements are used, the time to process a request on the ArcIMS Spatial Server can take considerably longer than when no projection elements are used. This is important when considering performance issues. If FILTERCOORDSYS and FEATURECOORDSYS are used, the amount of time to transform data can be an order of magnitude more than not using the elements depending on the complexity of the data. When using densification, it takes even longer to process the data depending on how much each layer has been densified. Ideally, if you have control over the data, all data and the service should be in the same projection and datum to minimize the need for using the projection elements.