nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Project Tool Process for Transforming Layers from NAD 1983 to NAD 1983 (2011)

PaulAndrews_ncleg

Hi, this is a question mostly to verify (or counter) my understanding of a very, very small difference in the results from suggested workflows for transforming NAD83 data to NAD83 (2011). I am not trying to split hairs over this question, but just trying to know why. I realize that I am exceeding the resolution of the data.

The following blog is a great guide for this transformation by Bojan Šavrič.

https://www.esri.com/arcgis-blog/products/arcgis-pro/data-management/prepare-your-data-for-the-nsrs-2022#how_to_transform_data_in_arcgis_pro

I used the suggested workflow 1 (2 step process) and 2 (1 step with all 4 transformations). I also experimented and ran the tool 4 times, each with 1 step of the transformation process.

The results using NC House District boundaries come out very, very close in all 3 processes (much less than an inch apart in the real world); thus, for our purposes any of the 3 are probably great. The resolution of the data is probably exceeded when you zoom that close.

So, my question is: why are they different lines at all? My speculative answer is that when running the math for each transformation, slight rounding differences in the steps between each transformation lead to slight "errors" that get picked up between each step. When all 4 transformations are run in one Project Tool step, this would likely cause the least rounding difference.

Is this a good basic understanding? Can anyone comment my reasoning or if one way is necessarily more appropriate? Thanks very much.

Encontre mais publicações marcadas com

Accepted answers

All comments

JonathanLebowitz

Hi Paul, I downloaded a shapefile in Geographic Coordinate System (GCS) NAD 1983/WKID 4269 containing the North Carolina congressional districts from 2025 TIGER/Line® Shapefiles and reprojected it to GCS NAD 1983 (2011)/WKID 6318 using all three workflows that you mentioned. I could not see any observable difference between them. The features line up exactly using workflows one and two from Prepare your data for the NSRS modernization of 2022. When re-projected from NAD 1983 to NAD 1983 (2011) using four separate runs of the Project tool with a single transformation path, the difference from the other two feature classes could not be perceived by the Measure tool. Where were you seeing a difference of one inch?

Bojan≈†avriƒç

@PaulAndrews_ncleg, thank you for your question.

Your slight "errors" you see could be caused by many different reasons. To properly verify this, we first need to know what are your source and target coordinate reference systems in the Project tool. Are you using geographic coordinate system or one of the State Plane zones in each run of Project tool?

It would be also helpful to see what differences you see between each workflow, map's zoom level in Pro, etc.

Thanks!

PaulAndrews_ncleg

Thanks to both of you for commenting back. Basically, this was a test to try out the newly downloaded transformations, prior to applying it to all of our NAD83-based holdings. I look forward to your further comments.

Jonathan: Again, my question is really an academic one, rather than a serious precision concern. I was surprised to not get the same line using the same 4 transformations in different ways. So if you zoom to full zoom in ArcGIS Pro (1:0.04), the boundaries are less than 1/10th of an inch apart on the ground. You are right, it is less than measurable by the measure tool, but not exactly the same line or quite the same intersection points. See my answer to Bojan's question here:

Bojan: I started with WKID 32119 NAD 1983 StatePlane NC FIPS 3200 (Meters). Target was WKID 6542 NAD 1983 (2011) StatePlane North Carolina FIPS 3200 (Meters). All 3 results seem to have the same output coordinate system and all started from the same coordinate system. See the attached screen captures of the tool interfaces for all 3 tests. Let me know if you need the Python that the tool created or the Parameters window. Note I will be out of the office next week, so if you respond after tomorrow (Friday 7/31), it might be next Friday before I get back to you.

NAD83toNAD83-2011_3MethodsToolCaptures.docx

JonathanLebowitz

Hi @PaulAndrews_ncleg, I do see very small differences (sub-millimeter) in the coordinates of features after being re-projected to PCS NAD 1983 (2011) StatePlane North Carolina FIPS 3200 (Meters)/WKID 6542 using the three different workflows. The issue is likely due to the original geodatabase feature class, defined in PCS NAD 1983 StatePlane North Carolina FIPS 3200 (Meters)/WKID 32119, having a default XY resolution of 0.0001 meter (0.1 mm storage precision).

Per XY Resolution, "By default, a tool that uses this environment setting will use the x,y resolution of the input feature class's spatial reference." Effectively, the Project tool is storing the coordinates in the output datasets to no more than four decimal places each time it is run. Properties of a spatial reference discusses the resolution property in greater detail.

The easiest way around this is to perform the workflows with shapefiles instead of geodatabase feature classes as XY resolution is not taken into consideration during geoprocessing.

Bojan≈†avriƒç

@PaulAndrews_ncleg, thank you for providing all of these details. This is exactly the information Jonathan and I needed.

Yes, the small differences you see between the workflows are expected and are the result of accumulated rounding errors. Let me explain in a bit more detail.

Internally, when converting coordinates from one coordinate reference system to another, ArcGIS performs all calculations using full double precision. However, when data is stored in a geodatabase, the coordinates are rounded to the configured storage resolution. As Jonathan mentioned earlier, the default XY resolution in a geodatabase is 0.0001 meter (0.1 mm). Therefore, each time data is stored, the coordinates are rounded to 0.1mm.

In your first workflow (a single step with four transformations), this rounding occurs once. In your second workflow (two steps with two transformations), it occurs twice. In your third workflow (four steps with a single transformation each), it occurs four times. As a result, you may see very small differences, less than one-tenth of an inch, between datasets produced using the different workflows.

I hope this answers your question, and thank you again for reaching out.

PaulAndrews_ncleg

Thanks to both of you for the helpful responses. We will move forward soon with our migration of our internal holdings to NAD83 (2011), where appropriate. To summarize my impression: It is best to run the project tool once with all necessary transformations, whenever possible.

Bojan≈†avriƒç

Correct! Thank you!

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.