A spatial reference is a characteristic of a geometry that identifies how its coordinates relate to real-world space. It is important for ensuring that spatial data in different layers, graphic overlays, and feature sets can be used together for accurate viewing or analysis.

Spatial references can be referred to by a well-known ID (WKID)—an integer value. Some common WKIDs are mentioned in the text below; for a more complete description, see Spatial reference specifications in this topic.

## Why spatial references are important

To integrate spatial data together into a map or when performing analysis, map coordinates are used to locate things on the Earth's surface. Coordinates are expressed with respect to a coordinate system, which is a frame of reference around a model of the Earth's surface. Not all coordinates and their associated coordinate systems are the same; they can use various units (for example degrees minutes seconds, decimal degrees, or meters) and they can be based on different types of models. Mathematical transformations are used to reproject coordinates from one coordinate system to another. A spatial reference provides all the information needed for reprojection.

## Coordinate systems and projections

Data is defined in both horizontal and vertical coordinate systems. Horizontal coordinate systems locate data across the surface of the earth, and are split into categories: geographic, projected, and local:

- Geographic coordinate systems (GCSs) use a three-dimensional ellipsoidal surface to define locations. The coordinates are based on angles from the center of the Earth to the surface. Typically GCSs use latitude and longitude specified in degrees. The coordinates derived from a GPS device are returned in a GCS named WGS84 (WKID=4326).
- Projected coordinate systems (PCSs) are variously described as planar (two-dimensional), Cartesian, or "flat." Unlike a GCS, a PCS has constant lengths, angles, and areas across the two dimensions. PCSs use a geographic coordinate system projected onto a flat surface for display. There are various projections with different desirable characteristics. Some preserve accuracy in particular areas of the Earth, others are better at maintaining the shape of features, while others favor accurate area or distance measurements. Coordinates are identified by x,y coordinates on a grid. Most basemaps from ArcGIS Online, Google, and OpenStreetMap use the same projected coordinate system named Web Mercator Auxiliary Sphere (WKID=3857).
- Local coordinate systems are often unrelated to any other coordinate system. The origin and the x,y coordinate units correspond to a local point of reference. Because the relationship of a local coordinate system to another coordinate system cannot be established easily, these are sometimes referred to as unknown coordinate systems.

Vertical coordinate systems (VCSs) are important when working with 3D data. A VCS defines vertical linear units of measure, the origin of z-values, and whether z-values are "positive up" (representing heights above a surface) or "positive down" (indicating that values are depths below a surface). There are two main types of VCS. Ellipsoidal systems measure z-values are from a mathematically-defined three-dimensional ellipsoidal surface. Most data collected via Global Navigation Satellite System receivers, for example GPS, is in an ellipsoidal VCS. Gravity based systems measure z-values from an analytical surface that represents mean sea level. Gravity based VCSs are more commonly used to display and work with 3D data. A spatial reference may or may not have a VCS set. Any particular vertical coordinate system may be used with different horizontal coordinate systems.

The following resources related to spatial references are available in the download area

- Coordinate Systems and Transformation Tables
- Projection Engine Data

## When you need to know about spatial references

When you use layers with different spatial references, where possible geometries are automatically reprojected for viewing and data is requested in the appropriate spatial reference. Nevertheless, occasionally you'll need to know about how spatial references are used.

### When you add data to the map

When you create a map, the spatial reference of the first layer you add is used as the spatial reference of the entire map; this is typically the basemap. When a map is renderered, it draws all the data using the same spatial reference so that the data lines up properly. If a group layer is the first layer added to a map, the map will use the spatial reference of the first layer in the group layer. If that layer is also a group layer, the group layer will be searched recursively until a non-group layer is found.

As you add additional layers to your map, you may need to request those layers from the service in the same spatial reference your map is using. Whether or not you must request this depends on what type of layer you’re adding. The following sections describe layer types as they relate to setting your map’s spatial reference.

**Graphics overlays**

Graphics overlays support on-the-fly reprojection of graphics. On-the-fly reprojection requires extra processing that could slow down the map view rendering time. When you add a graphic to a graphics overlay, it is best if the geometry in the graphic has the same spatial reference as the map. You can explicitly convert geometries to the required spatial reference.

**Feature layers from feature services**

When using a feature service table created from a feature service from ArcGIS Online or ArcGIS Enterprise, the service supports reprojection. When initialized, the table and its associated feature layer will automatically be set to the same spatial reference as the map. This ensures the data is requested from the service in the correct coordinates, without the need to explicitly define the spatial reference for the feature table.

**Feature layers from geodatabase feature tables**

Your tables in the geodatabase do not need be in the same spatial references as the map you are adding them to, because on-the-fly reprojection of data from these tables is supported. However reprojection comes with a cost in drawing performance, and avoiding reprojection can help maximize performance. To control the spatial reference of your tables, ensure the ArcMap map frame is using the desired spatial reference before you run the Create Runtime Content tool. If you're using the services workflow, set the desired spatial reference in the parameters used to generate the geodatabase. For details on the desktop and services workflows, see Offline maps, scenes, and data.

**Dynamic map service layers**

If these are ArcGIS Online or ArcGIS Enterprise map services, then the server supports reprojection on the fly. When you add an ArcGIS dynamic map service layer to the map, the map image is requested in the map's spatial reference.

**Tiled layers**

Tiled layers are cached layers. At the time of caching, a spatial reference is used and is therefore predefined for the tiled layer. It's typically not possible to request tiled layers in a different spatial reference from the one defined in the service using that cache (unless the server supports doing this on the fly; most do not). If an ArcGIS tiled layer is added to a map with a different spatial reference from the tiled layer, it cannot be drawn.

**Raster layers**

Raster layers support on-the-fly datum transformation and reprojection. You can add a raster layer to a map as either a basemap or an operational layer. When adding a raster layer as an operational layer to a map with different spatial reference, the layer will be reprojected on the fly and be added to the map.

### When you edit data

When creating new features from coordinates, the coordinate values must match the spatial reference for the layer; otherwise, the features will not show up in the correct location on the map.

### When you perform analysis

Geometry objects used for analysis (for example, determining spatial relationships, such as where polygons intersect) require that the spatial reference be known before the analysis is performed. Otherwise, results may not be accurate. Likewise, it's meaningless to compare two geometries or determine their spatial relationship if they have different spatial references. To display a geometry in a map layer, the geometry must have either the same spatial reference as the layer or be projected to the layer's spatial reference. To use two geometries together, they should have the same spatial reference.

### When you convert geometries from one spatial reference to another

When using the geometry engine to convert geometries from one spatial reference to another, the source and destination spatial references must be specified. An appropriate datum transformation is used by default. You can also specify the transformation you want to use. You can also convert strings containing coordinates formatted as latitude and longitude directly to points, and vice-versa. Other types of coordinates such as Universal Transverse Mercator (UTM) and United States National Grid (USNG) are also supported.

Use the `GeometryEngine`

class to project geometries to a different spatial reference. For details, see the Geometry topic.

## Spatial reference specifications

To define a spatial reference, you can use either a Well-Known ID (WKID) integer value or a text string definition referred to as Well-Known Text (WKT). WKIDs are defined by standards bodies or organizations, with each value representing a specific spatial reference. ArcGIS supports a variety of WKIDs, typically those defined by the European Petroleum Survey Group (EPSG) or Esri, as well as a few other commonly used IDs. You can optionally define a vertical coordinate system for a spatial reference, by using a second WKID. In contrast, WKT text describes of all of the parameters of a spatial reference. To see a list of supported WKIDs and their WKT definitions for geographic coordinate systems, projected coordinate systems, vertical coordinate systems, and transformations, download the Coordinate Systems and Transformation Tables from the download area (login required).

Linear, angular, and area units can also be defined by WKID or WKT, and are used by many spatial reference and geometry related API members. These WKIDs are also included in Coordinate Systems and Transformation Tables.

## Datum transformations

Datum transformations are used when geometries must be projected from one spatial reference to another when there is a difference in the datum that underlies the two spatial references. The following transformations are supported:

- Horizontal (geographic) and vertical datum transformations
- Ellipsoidal and grid-based transformations

As a developer, you can:

- Obtain the default transformation for the projection.
- Customize the default transformation used by your app through a JSON configuration file.
- Consider the best transformation for a specific work area.
- Choose from a list of suitable transformations from the transformation catalog for a given pair of spatial references and optionally a given geographic area.
- Create a transformation using WKIDs.
- Create a custom transformation using WKT, if you have even more specialized needs.

### Horizontal and vertical transformations

Exactly how coordinates should be transformed is defined by agencies such as the US National Geodetic Survey. Esri's Projection Engine supports many predefined transformations, and more than one transformation may be available for a given datum change. Each transformation is identified by a WKID integer number and WKT text string definition, similarly to how spatial references are identified. Transformations vary in accuracy, and using the most suitable transformation for your specific case ensures the best possible accuracy for the reprojection.

Geographic transformations translate horizontal (x,y) coordinates from the geographic coordinate system of the input spatial reference to the geographic coordinate system of the output spatial reference, accounting for the difference in geographic (horizontal) datum. For spatial references with a vertical coordinate system set, vertical transformations translate vertical positions (z-values) from one vertical coordinate system to another, accounting for the difference in vertical datum. Horizontal and vertical transformations can be used together if there is a change in both datums.

Each of the supported predefined transformations and is represented by one or more steps (the `Geographic`

or `Horizontal`

type) in a transformation (the `Geographic`

or `Horizontal`

type).

### Grid-based transformations

Datum transformations can be mathematically defined (equation-based transformations), or may rely on external supporting files (grid-based transformations). Certain Projection Engine data files must be present when you use a grid-based transformation in your app; attempting to use a transformation with missing Projection Engine files will cause an error. The API can detect whether the necessary files are available on the local file system.

The data files should reside in the Projection Engine location specified in the transformation catalog. To set the Projection Engine location(`projection`

), you must do so at app startup, before other calls that use the Projection Engine.

#### Check for Projection Engine files

If the supporting file for a grid-based transformation cannot be located on the local file system, that transformation cannot be used. This will not happen when relying on the default transformation, but can happen if the Projection Engine location is not set or specific datasets are missing when using a transformation from a list returned by the transformation catalog, or when creating transformations from WKID or WKText.

You can identify such cases using the `i`

method on the transformation step object (the `Geographic`

or `Horizontal`

type). Your app could go so far as informing the user about precisely which files are missing, or even automatically download the missing files from a known location. Retrieve the list of required files using the `projection`

method of the transformation step object.

### Default transformations

When data is reprojected from one spatial reference to another, an internal algorithm uses the best transformation available by default without you needing to specify one.

Using the transformation catalog you can find out which transformation is used by default when projecting between any two spatial references.

The accuracy of each transformation, and the extent of the spatial reference covered, are together used to determine the default transformation. If no transformation is required for the two spatial references (for example, two projected coordinate systems that have the same underlying geographic coordinate system), `get`

will return `null`

. If both spatial references have a vertical coordinate system, and there is a difference in vertical datum, then a horizontal-vertical transformation is returned; otherwise, a geographic transformation is returned.

The default transformation is also checked to ensure it is usable. For example, a grid-based transformation must have grid files present on the local file system.

### Customize default transformations

There may be cases where you want to specify your own default transformations. For example, if you wish to ensure default transformations match those used by an older version of ArcGIS Server or Desktop, or if you otherwise need to ensure a specific transformation is used but it is not feasible to specify a transformation every time you need to use one.

To change geographic transformation defaults, create a JSON file named `gtdefaults_`

and place it in the location returned from the transformation catalog method `projection`

.

An example of file content is:

```
{ "geogtran" : [
[ 3819, 3906, 3817, 0, 3962, 1 ],
[ 3819, 4075, 3817, 0, 4077, 1 ],
[ 104248, 104896, 108038, 0, 0, 0 ],
[ 104257, 104896, 108019, 1, 0, 0 ]
]}
```

This file contains one line per datum pair ("from" and "to"). Only include lines for the default geographic transformations that you want to override. The six columns have the following information.

- The WKID of the "from" geographic coordinate system.
- The WKID of the "to" geographic coordinate system.
- The WKID of the first geographic transformation.
- Whether to use the first geographic transformation forward (
`0`

) or use its inverse (`1`

). - The WKID of the second geographic transformations WKID (or
`0`

if this is a single-step geographic transformation). - Whether to use the second geographic transformation forward (
`0`

) or use its inverse (`1`

). (`0`

if this is a single-step geographic transformation).

To change horizontal-vertical transformation defaults, name a JSON file `hvtdefaults_`

. An example of the file content is:

```
{ "hvtran" : [
[ 4326, 3855, 4326, 115700, -110019 ],
[ 4326, 3855, 4463, 115786, -110019, -4477 ]
]}
```

The columns have the following information.

- The WKID of the "from" geographic coordinate system.
- The WKID of the "from" vertical coordinate system.
- The WKID of the "to" geographic coordinate system.
- The WKID of the "to" vertical coordinate system.
- The WKID of the first horizontal or geographic transformation. Include a minus (
`-`

) to use the transformation in the inverse direction. Repeat multiple times to create a multi-step transformation.

A geographic transformation, defined in this file, is checked to determine whether it is usable. If it is not usable, the internal default is used.

### Consider the work area extent

Your work area may be small and located where the default transformation (that is, the best transformation for the entire spatial reference) is not the best for your work area. You may be able to improve accuracy by finding the best transformation for your specific work area. This transformation can then be used, for example, when calling the geometry engine (the `Geometry`

type) to project a geometry.

Use the overloads of the transformation catalog's `transformation`

and `transformations`

methods to pass in the extent for which you'll be transforming geometries.

### Choose a transformation from a list

From the transformation catalog, you can retrieve a list of transformations useable between two spatial references. The `transformations`

method on the `Transformation`

returns a list of transformations in descending order by suitability. With this, you could provide your app users with a workflow wherein they are able to choose from a list of suitable transformations.

The list returned from `transformations`

may include grid-based transformations whose supporting files are not found on the local file system. If both spatial references have a vertical coordinate system, and there is a difference in vertical datum, then a list of horizontal-vertical transformations (`Horizontal`

) are returned; otherwise, geographic transformations (`Geographic`

) are returned.

### Project geometries with a specific transformation

A common use case is to project a geometry, creating a new geometry that uses the same spatial reference as the map view or another data source. The `project`

method on the geometry engine (the `Geometry`

type) uses the default transformation without you needing to specify one. Alternatively, you can specify a transformation each time you use the method to project a geometry, for example by passing in a transformation from a list returned from the catalog, or one created by WKID.

### Create a specific transformation by WKID

You can create a geographic transformation by passing a WKID to a `Geographic`

, then adding one or more steps to a `Geographic`

. To account for vertical datum change as well, create a horizontal-vertical transformation by passing in a geographic (horizontal) or vertical transformation WKID to a `Horizontal`

, then adding one or more steps to a `Horizontal`

. This transformation can then be used, for example, when calling the geometry engine (the `Geometry`

type) to project a geometry.

There is not a defined transformation from every geographic datum to every other, and from every vertical datum to every other—such a collection would be very large.

The list of supported WKIDs includes a geographic transformation from every supported geographic (horizontal) datum to the datum named World Geodetic System 1984 (WGS84). Therefore, a geographic transformation is commonly composed of two steps, each step defining a datum transformation and the inverse of another datum transformation. Each geographic transformation step can be constructed from a well-known ID (WKID) that represents a datum transformation. Geographic transformations with more than one step typically go via WGS84, with one forward and one inverse datum transformation chained together to perform the complete geographic transformation. Additionally, there is limited list of geographic transformations directly between two non-WGS84 datums, such as WKID `4461`

, named `NAD_1983_`

. These may be used to create one-step geographic transformations. For vertical transformations, there is no common intermediate step.

If the transformation is grid-based, you must ensure that the supporting Projection Engine data files are found on the local file system.

### Create a custom transformation

Some users adjust the components of a transformation to suit their specific needs. These custom transformations use the existing methods of transformation (`Position Vector`

, `Geocentric_`

, and so on) but have different parameter values than the well-known definitions. Create a custom transformation object by passing in a text string containing your custom transformation expressed in WKT format. The resulting transformation will have a WKID of zero. If the transformation is grid-based, you must ensure that the supporting Projection Engine data files are found on the local file system.