ArcGIS Pro Alignment Issues?

[JPaulo]

Hello,

I noticed that when I brought data in to ArcGIS Pro 2.0.1, that my polygons are not lining up with my images like it does in ArcMap 10.5. Here are my steps for both programs:

1. Add building shapefile data (NAD_1983_HARN_StatePlane_Hawaii_3_FIPS_5103_Feet)

2. Add Orthophotos (NAD_1983_UTM_Zone_4N)

Here are images that show my issues. Notice the difference in alignment:

1. ArcMap 10.5

2. ArcGIS Pro 2.0.1

Does anyone else have this issue?

[DanPatterson_Retired]

unless 2.1 got released today, you should be reporting this on the beta site

[Robert_LeClair]

One thing to compare is any geographic transformation issues.  Both feature classes are in NAD83 (GCS) so no issue there.  Is your basemap in WGS1984?  In ArcMap, you have to explicitly set the geographic transformation.  If you click "Close" in the Geographic Transformation Warning UI, then you'll have a slight discrepancy on location.  In Pro, the software sets the geographic transformation for you.  Perhaps this is what you're seeing?

[JPaulo]

Thanks Robert, I have a feeling that is the issue. No my basemap is not in WGS84.

In ArcMap, when the GCS Warning pops up, I usually just press "Close" and the resulting image matches with our topographic map closely- so I have been using that as a gauge of accuracy. Do you know if we can duplicate this in Pro? Meaning if we can manually set the geographic transformation?

[Robert_LeClair]

Yes, go the Project Core Tab (Blue Tab), click Options, click Map and Scene.  Scroll down to the bottom and expand the Spatial Reference Category.  From there, check the box "Warn if transformation between the geographic coordinate system is required to align data sources correctly."  Then when you add data to a new map, you'll see the warning message appear like ArcMap.  To mimic the Close option in ArcMap, remove the suggested transformation methods and then click OK.

[JPaulo]

That solved it. Thanks Robert!

[curtvprice]

Robert, I hope this makes it into a blog post or KB article somewhere!

[curtvprice]

Julius, I'm pretty sure with a base map in WGS84 and your data in NAD83 you have probably been digitizing incorrectly in ArcMap if you have just been clicking "close" instead of choosing a datum transformation, you are pretending your vectors are being digitized in NAD83 when you are actually digitizing them in WGS84.  Better user experience, maybe not so good for correct coordinate capture (depending on scale and accuracy).

These are three different datums being used on the same map (NAD83, NAD83_HARN, WGS84). To really do it right you'd need two transformations defined. (Robert, Pro is choosing these for you??) 

Another thing to think about here is we may be splitting hairs, in that the shift you are seeing may be beyond the basemap accuracy -- as which way the roof shifts from the ground (relief displacement) depends on the [unknown] geometry of the airphoto!

[JPaulo]

Curtis, I don't have any data in WGS84. My data are in the following format:

1. Vector data: NAD_1983_HARN_StatePlane_Hawaii_3_FIPS_5103_Feet

2. Raster data: NAD_1983_UTM_Zone_4N

My vectors are derived from a recent land survey that we had so that is the most accurate dataset that i have. I usually open this layer first to define the data frame projection. When I add my raster, ArcMap gives me a Geographic Coordinate Systems Transformation Warning. At first, I used the following settings:

Which resulted in this overlay:

The image does not line up with my vectors at all. However, if I use these settings:

I get this alignment which is correct:

Since the vectors are my primary source of information and the image is only a visual check, I have been using this method every time the Geographic Coordinate Systems Transformation Warning comes up- BUT only for this specific raster data! (It might very well be that this raster is actually in NAD83 HARN rather than NAD83). My initial question was how to replicate this process which Robert has answered.

[curtvprice]

(It might very well be that this raster is actually in NAD83 HARN rather than NAD83)

This sounds likely given what you have shown. Thanks for sharing the details.