Performance Enhancements: Using sourceSpatialReference with feature services in ArcGIS Pro

Welcome to the wonderful world of spatial references! If you’re here, that means that you want to learn how you can take advantage of sourceSpatialReference for querying and editing your data. Feature services may be projecting your data on the fly without you even knowing it, which can cause sub-optimal performance. You can avoid this costly projection on the fly in ArcGIS Pro 2.4. It’s a great way to speed up both querying and applying edits to your data.

Before we get into how exactly using sourceSpatialReference does this, we’ll have to understand the difference between spatialReference and sourceSpatialReference. Both properties can be found through the REST API’s layer JSON view, providing your data was published using ArcGIS Pro 2.4 and published from an enterprise geodatabase that has been registered to a federated server. If you’re not sure what the REST API is, it is a core API for interacting with your services to accomplish tasks like managing your content, performing edits, queries, and administrative operations. If you’re not sure what the layer JSON is, visit this page for more information.

First, let’s look at the spatialReference property. It’s found within the layer extent property and describes the coordinate system of a map published with a defined coordinate system. It has information about the vertical coordinate system (VCS) if you’ve defined one, tolerance, and resolution. When you publish a feature service with a defined coordinate system, you should see something like this in the layer JSON spatialReference property:

“spatialReference”: {
“wkid”: 102646,
“latestWkid”: 2230,
“vcsWkid”: 115702,
“latestVcsWkid”: 115702,
“xyTolerance”: 0.001,
“zTolerance”: 0.001,
“mTolerance”: 0.001,
“falseX”: -10000000,
“falseY”: -10000000,
“xyUnits”: 99999.99999999999,
“falseZ”: -100000,
“zUnits”: 99999.99999999999,
“falseM”: 0,
“mUnits”: 1
}

sourceSpatialReference (the property we’re really here for) is different in that instead of describing the coordinate system of the map, it describes the coordinate system of the feature class in the enterprise geodatabase you referenced to publish your data. If you’re looking at the sourceSpatialReference property in the layer JSON, it should look something like this:

“sourceSpatialReference”: {
“wkid”: 102646,
“latestWkid”: 2230,
“vcsWkid”: 5713,
“latestVcsWkid”: 5713,
“xyTolerance”: 0.00328083333333333,
“zTolerance”: 0.001,
“mTolerance”: 0.001,
“falseX”: -10000000,
“falseY”: -10000000,
“xyUnits”: 100000,
“falseZ”: -100000,
“zUnits”: 100000,
“falseM”: 0,
“mUnits”: 1
}

Even though spatialReference and sourceSpatialReference look pretty much the same, it’s important to remember the distinction between the two: spatialReference is derived from the map that was published to create the service, and sourceSpatialReference is derived from the underlying source feature class.

Now that you know the difference between the two, you may be asking yourself, how does sourceSpatialReference give a performance improvement? Well, I already mentioned that it provides faster querying and editing workflows. How does it do that? By using the sourceSpatialReference, the server does less work on the back end. Before ArcGIS Pro 2.4, query and edit requests were sent in the spatialReference, which required projecting to and from the source spatial reference in order to generate the correct result. This is an expensive operation on the server, especially if your data is large or has particularly large or complex geometry.

To avoid this workflow and make operations faster, ArcGIS Pro 2.4 now uses sourceSpatialReference when it can. Services published from maps with datum transformations, however, will still use the layers spatial reference . If transformations are not defined, ArcGIS Pro will use the sourceSpatialReference to query and apply all edits by default, eliminating the need for projecting the data. Right now, ArcGIS Pro 2.4 is the only client that makes use of this enhancement by default when consuming feature services, but custom applications could make use of it as well going forward if the data is configured properly, and the publishing server is at least ArcGIS Server 10.7.1.

If that sounds like something that would benefit you, let’s dive in to the best practices when configuring and publishing your data to make use of sourceSpatialReference in Pro 2.4 (finally!).

When configuring your data for publishing, you want to make sure that either 1) the spatialReference and sourceSpatialReference are the same, or 2) that spatialReference and sourceSpatialReference are at least in the same datum.

Making sure they are the same:

You might be saying, “hold on, how would they be different?” When you add a feature class into a new map in ArcGIS Pro, the map will assume the spatial reference of the source data. In certain circumstances, data added to a new map can also contain datum transformations (which you don’t want). If you add your data to a new map, datum transformations will automatically be applied with the standard basemaps in ArcGIS Pro. When you’re using ArcGIS Pro, a new map will open with the default basemap, which is most often defined in WGS84. If you’re data’s spatial reference is WGS84 and your map is defined as WGS84, you should have no transformations. If your data is in any other spatial reference, removing the basemap before publishing is the best option.

Datum transformations can also be present however, if you’re adding data to an existing map, even if all feature classes do have the same spatial reference. This happens if the existing map was originally created with data that had a different spatial reference than the data you want to add to the map. The map will be defined in the original feature classes spatial reference, causing a difference between the map (spatialReference) and newly added feature classes (sourceSpatialReference). If you were to publish the data in this case, the resulting service would contain a datum transformation, preventing ArcGIS Pro 2.4 from using sourceSpatialReference. To prevent this, you need to change the spatial reference of the map to either the spatial reference defined in your data, or at the very least, a spatial reference that has the same datum (which is the next section) before publishing to make use of the enhancements with ArcGIS Pro 2.4 and sourceSpatialReference.

Making sure the map and data are in the same datum:

As mentioned above, sometimes you might have the case where the map’s spatial reference (spatialReference) and your data’s spatial reference (sourceSpatialReference) are different. However, if they are in spatial references with the same datum, you will still be able to take advantage of sourceSpatialReference in ArcGIS Pro 2.4. As an example, any spatial reference using the WGS84 datum (Web Mercator, etc…) will not result in transformations in the resulting published service. Likewise, any spatial references using the NAD83 datum (UTM Zone 11N, etc…) will not include transformations.

If neither of the methods described above are used before publishing, the resulting published service will not be making use of the enhancements ArcGIS Pro 2.4 including using the services sourceSpatialReference property. Whether you make use of this enhancement or not (it’s pretty cool, why not?), it’s important to know the recent improvements in functionality with querying and editing your data through feature services in ArcGIS Pro.