Features Not Aligned

mpboyle · ‎01-13-2017

All of our production feature classes are in NAD 1983 Iowa State Plane North 2011 (wkid: 6463). We have a separate file gdb that we use for caching base maps where we load our production feature classes into this file gdb. The feature classes within our cache file gdb are in Web Mercator (wkid: 3857).

Below is a screenshot showing one of our parcel features overlaid on top of one of our base maps. You can see the parcel outline in gray within our base map. The pink parcel is the same feature as what is used to make the base map. The parcel service is in Iowa State Plane North spatial reference, while the base map is in Web Mercator spatial reference.

I'm wondering why the parcel service (pink) doesn't line up directly on top of the parcel outline in the base map? Am I missing something when publishing the service? Do I need to apply a transformation? Do I need to publish the service where the Data Frame is in Web Mercator as well?

MelitaKennedy · ‎01-13-2017

Possibly, you may need to apply a transformation. You also may want to set a transformation before you publish the service so that you know which transformation is being used.

It depends on the data. Some data, you can get away with calling WGS84 and NAD83 equivalent, so you want to use NAD_1983_To_WGS_1984_1 (parameters are zeroes). There are certain places where a default transformation is used and currently that one is NAD_1983_To_WGS_1984_5 (parameters are not zeroes) because NAD83 (later than the original 1986 version) and WGS84 are not coincident are now around 1 m apart in CONUS (more elsewhere).

The "default" transformation would be used in cases where a 'client' like ArcMap says "gimme the data in B" where the service was published in A. To save on processing and display time, the server reprojects the service data to B and sends it.

You might run some checks in ArcMap--is the base map still listed as 3857? What happens if you set either of the above transformations in the map?

mpboyle · ‎01-17-2017

Melita Kennedy‌,

Thanks for the reply! I did some testing on my end, re-publishing the service with various transformations (I didn't go through the entire list of possible transformations). Below are my results.

Based on the resulting alignments of each, is there any reason NOT to use None as a transformation?

Transformations that still resulted in an offset:

1) WGS_1984_(ITRF08)_To_NAD_1983_2011

2) WGS_1984_(ITRF00)_To_NAD_1983_2011

Transformations that resulted in alignment:

1) None

2) NAD_1983_HARN_To_NAD_1983_2011 + NAD_1983_HARN_To_WGS_1984

MelitaKennedy · ‎01-17-2017

Nope, feel free to do so. You might put a note into the data's metadata discussing the issue for the future.

mpboyle · ‎01-17-2017

This also got me thinking that perhaps it's our base map that needs to be adjusted.

Since our production data is in Iowa State Plane North projection, is it best practice to keep our data in State Plane and set the data frame to a transformation when creating cached base maps?...rather than what we are currently doing which is loading our State Plane data into feature classes with Web Mercator as the projection.

MelitaKennedy · ‎01-17-2017

Can you check your basemaps against other data--particularly NAD83/NAD83(2011)-based data? Let's say your NAD83 data is really 2011, and should be offset from "true" WGS84/ITRF coordinates. I think many basemaps and other datasets, even if they say they're WGS84 (ITRF), are probably NAD83 (and/or 2011)-based. So maybe try to compare your data with some other state data (Lidar) to see how it lines up?

Anonymous User · ‎03-28-2018

I have a plan to help make my viewers and their services faster - I have a production SDE with all the layers in GA State Plane E. However, I want to create a file gdb in 3857 to feed services for viewers. I'll set up a replication I can run weekly. Similar to Matthew's workflow.

I consulted How To: Create a replica where the child replica data is in a different coordinate system than the p...

One question is, what transformation does the JS API use by default? I looked at ProjectParameters | API Reference | ArcGIS API for JavaScript 4.6 and 3.23. I wonder what datum transformation to 3857 the JS API viewers use by default? If let's say I add a state plane layer into the operational layers in a viewer, if the viewer is in 3857?

Details....I located Extract Data (in Distributed Geodatabase toolbar). After finishing step 1 and 2 it advises usto set Datum transformation as step 3. However, you must do that first, since can't click things while the modal window of the Extract Data wizard is open. So do step 3 as step 1. Set the Data Frame and its transformation as desired. Things were off by 4 ft until I did that. It says it will project in the Schema step but it won't, if there is no transformation, for example State Plane's NAD83->3857. I set the Data Frame to 3857, and added my original layer. I selected ITRF00 to NAD83 as the transformation to bring it in, since this is the correct one apparently for Web Mercator's WGS84 datum to NAD83. I went through the Replication as above, and choosing ITRF00->NAD83. Works perfect!

The reason for this workflow for my viewers is that I have heard from Esri folks it's faster to load the Esri basemaps (topo, streets, etc) in their native 3857, and have your data on top of it as Web Mercator, as opposed to forcing the Esri basemap servers display their tiles into your local projection, such as a state plane system. No prob, can do. So I plan to have all my operational layers in a fgdb for speed, and in web mercator so they don't need to reproject on the fly. I'd imagine this is a common or quite useful workflow, for designing viewers. I hope this post is helpful for all.