Explore

Week 14 Geographic Datums

Introduction

Geographic datums are the foundation of accurate mapping because they define the reference framework used to measure positions on Earth. In UAS work, datums directly affect how drone imagery lines up with control points, basemaps, elevation models, and other GIS layers. Even small datum mistakes can lead to major errors in outputs like orthomosaics, DSMs, DTMs, and survey-grade deliverables. In lecture, we reviewed multiple datums and discussed how incorrect datum use can ruin UAS datasets. This lab purposely used a real-world dataset that was bad on multiple levels to show how these problems look and how to troubleshoot them correctly.

⁠

Instead of working with a clean “perfect” Ground Control Point (GCP) dataset, this lab involved a messy file that lacked metadata, had confusing field order, and contained a vertical datum issue. The goal was to practice identifying common problems, correcting coordinate-field order errors (XYZ vs YXZ), and diagnosing height differences caused by ellipsoid/geoid confusion. The lab also introduced how ArcGIS Pro and ArcGIS Earth handle coordinate input and terrain visualization differently, and how external authoritative sources like the National Geodetic Survey (NGS) can be used to determine datum offsets.

⁠

Objectives

This lab focused on four main objectives:

Discover, identify, and apply basic concepts behind geographic datums.

Recognize, relate, and compare different types of datums in ArcGIS Pro.

Demonstrate proficiency importing XYZ coordinate data into ArcGIS Pro and ArcGIS Earth.

Evaluate dataset quality and identify issues with the vertical datum.

⁠

Resources / Tools Used

ArcGIS Pro (data import, XY point creation, coordinate interpretation, map layouts)

ArcGIS Earth (visual terrain comparison and approximate elevation checks)

National Geodetic Survey (NGS) Map / Data Explorer (geoid height, orthometric height, ellipsoid height, datasheet lookup)

⁠

Data Preparation and Context

Folder Setup

A folder was created in C:\temp named:

username_UASmapdata

Then the folder GCPs_and_Datums was copied from the class server location:

T:\AT309\AT309_Classdata

or \\ecn-usalab.ecn.purdue.edu\Classes

This dataset was large and took time to copy. The lab also emphasized that local hard drives are not backed up, so saving a backup copy is important if you need the data later.

The Core Problem: No Metadata

Normally, you start a geospatial workflow by reviewing metadata. In this case, the surveyor provided no metadata at all. The only file provided (besides imagery) was:

GCPs_Ellipsoid.csv

Opening the file in Excel showed how “database language” applies:

Rows = records

Columns = fields

This file contained four fields: Name, X, Y, Z, but without metadata it was unclear what the units and coordinate system were. Based on the number ranges, it appeared that X/Y were geographic coordinates (lat/long) in decimal degrees, and Z was likely meters. However, the lab reinforced an important rule:

Never guess the projection/datum of a dataset.

Even if you can “kind of tell” from the numbers, you still need confirmation.

⁠

Procedure and Analysis

Step 1: Open ArcGIS Pro Project

The project GCPs_and_Datums was opened in ArcGIS Pro. The contents panel showed a basemap only. This was intentional so the lab could demonstrate importing XYZ data the wrong way first, then the correct way.

Step 2: Understanding X/Y/Z in GIS

A key concept in this lab was that GIS uses X, Y, Z, which often confuses people who are used to “Latitude, Longitude” order.

In GIS:

X = Longitude (east/west position; the “vertical” meridian lines on a map)

Y = Latitude (north/south position; the “horizontal” parallel lines)

Z = vertical value (not automatically “elevation” until you know the vertical datum)

When the mouse was moved over the center of the map, coordinates displayed:

X = 43.4810782 degrees N

Y = 90.4725060 degrees W

This output looked reversed because longitude is normally the “W/E” value and latitude is the “N/S” value. That mismatch was a hint that confusion about field order was going to matter in the next step.

The coordinate system appeared unprojected, because the values were in degrees (decimal degrees), which indicates a geographic coordinate system rather than a projected coordinate system (like UTM in meters/feet).

⁠

Importing the Data the Wrong Way (On Purpose)

Step 3: Import the bad TXT file using XY Point Data

The file GCP_groundvalue_xyz.txt was inspected in Windows Explorer. Two issues were noticeable:

the XYZ labeling was incorrect / field order was not reliable

control points were not in a clean numerical order

Without editing the file, it was imported using:

Map tab → Add Data dropdown → XY Point Data

After running the tool, points appeared but the basemap turned white. Zooming out showed the points in the wrong place.

Coordinate location shown at the bottom of the screen:

42.7590272 degrees W

89.8371481 degrees S

Where were the points located and why? They were located in Antarctica, because the coordinates were flipped/reversed (X and Y were interpreted incorrectly).

This step was important because it shows what happens when field order is wrong: ArcGIS Pro will still plot points, but they will be in a totally incorrect location.

⁠

Importing the Data Correctly

Step 4: Import the corrected file (YXZ order)

Next, the correct import was done using the same XY Point Data tool, but this time using:

GCP_groundvalue_yxz.txt

This placed the points in the correct geographic area.

The “Antarctica” layer was removed from the contents panel and deleted from the catalog to prevent confusion. This reflects a real best practice: delete bad data quickly so you don’t mix it up later.

⁠

Evaluating Dataset Quality (GCP Layout + Z Values)

Even once the points were in the correct XY location, the dataset still had issues.

Issue 1: Poor GCP distribution

The first quality issue noticed was GCP placement: points were biased toward the edge of the mission area and there were not enough in the center. This matters because good GCP distribution improves accuracy across the entire project, not just near the edges.

Issue 2: Z values may not match terrain

Next, the Z values were checked by clicking each marker and recording Z:

Control 00 – 280.1

Control 01 – 246.7

Control 02 – 243.69

Control 03 – 241.37

Control 04 – 247.98

Control 05 – 271.96

Control 06 – 280.58

Control 07 – 270.51

Control 08 – 266.98

Control 09 – 249.04

Flag 03 – 263.61

At this point, the points looked reasonable on the map, but the question was: Do these Z values actually match the terrain elevation?

⁠

ArcGIS Earth Terrain Check (Finding the Vertical Datum Problem)

ArcGIS Earth was opened while keeping ArcGIS Pro open. ArcGIS Earth was used because it makes it easier to visually understand terrain relief and quickly compare approximate elevations in the field.

The table import feature was used:

Add Data → Add Files → Select Files → GCP_groundvalue_yxz.txt

The points displayed on the terrain surface, showing noticeable relief, with the north end higher than the south end.

Highest vs Lowest point comparison

Northern-most point (hillslope): 280.58 m

Southern-most point (by creek): 246.7 m

Then, the mouse elevation readings near those same locations were recorded:

Northern-most approximate elevation: 312.39 m

difference: 31.81 m

Southern-most approximate elevation: 278.35 m

difference: 31.82 m

These consistent offsets strongly suggested a vertical datum issue, not random error.

⁠

Solving the Datum Mystery with NGS Data Explorer

Since the offset looked systematic, the lab used the National Geodetic Survey (NGS) Map/Data Explorer to find geoid/orthometric height information near the study area.

Steps used:

Navigate to NGS Map

Search Bloom City, WI

Zoom and locate nearby geodetic marks using roads/terrain context

Click a marker near the survey location (near County Road I)

Marker information recorded

Geoid height: -33.852 m

Ellipsoid height: 238.926 m

Ortho height: 272.77 m

X: -39,664.430 m

Y: -4,635,039.152 m

Z: -4,366,921.213 m

Ellipsoid vs Ortho difference

Difference between Ellipsoid Ht and Ortho Ht:

272.77 − 238.926 = 33.844 m

This closely matched the ~31.8 m differences observed in ArcGIS Earth. The small mismatch is normal because Earth values were approximate from a DEM surface and the survey point values are specific.

Datasheet questions

From the datasheet:

NAVD 88 Ortho Height: 272.77 m

NAVD 88 Ortho Height in feet: 894.9 ft (note: your earlier entry had a unit typo; “894.9m” should be feet)

Geoid model used: GEOID12A

Geoid Height (GEOID12A): -33.852 m

Geoid Height (GEOID18): -33.852 m (as recorded)

⁠

Applying the Geoid Offset to Correct Z Values

Because the survey Z values were effectively ellipsoid-based (or not properly described), the geoid separation needed to be applied to bring the values closer to orthometric elevations (mean sea level / NAVD88 style heights).

You recorded applying the offset and noted:

elevation values won’t match exactly because Earth elevations are approximations across an area (not a single surveyed point)

You also provided corrected Z outputs (rounded):

Table 16

Table 16

Point

Corrected Z (approx.)

Control 01

281

Control 02

278

Control 03

275

Control 04

282

Control 05

306

Control 06

314

Control 07

304

Control 08

301

Control 09

283

Control 00

314

Flag 3

297

There are no rows in this table

⁠

This correction process is what made the dataset usable and explained why the Z values didn’t match the terrain initially. The main takeaway is that vertical datum problems often appear as a consistent offset across many points.

⁠

Final Deliverable Maps (What to Include)

For the final cartography deliverable(s), the maps should show:

GCP marker distribution (to evaluate quality of placement)

Coordinate values for each GCP (label or table in layout)

At least one layout with a Lat/Long grid

Vertical datum information clearly stated on the map (ex: ellipsoid vs orthometric/NAVD88, and geoid model if applicable)

Recommended map elements (cartography fundamentals):

Title

North arrow

Scale bar

Locator map

Legend (if needed)

Watermark

Data sources/metadata text (including datum and vertical datum statement)

⁠

Questions Answered (Included at the End)

1) What are the names of 4 fields in this data file?

Name, X, Y, Z

2) Do you know what the numbers and units are for each field? Speculate.

Based on the numbers it looks like the elevation is in meters. And it looks like it was measured in decimal degrees.

3) How does metadata relate to the lack of information here?

I have no idea what I am looking at due to the lack of labels.

4) Move the mouse over the center of the map. What are the X/Y/lat/long and order listed?

X = 43.4810782 degrees N Y = 90.4725060 degrees W Lat = 90.4725060 degrees W Long = 43.4810782 degrees N

5) Does this appear projected or unprojected? How can you tell?

It appears to be unprojected coordinate system because it is just a plain map.

6) What might be wrong with the dataset fields in GCPs_ground_xyz?

The XYZ is off and the control points are not in numerical order.

7) After importing wrong XY, what coordinate location is shown at bottom of screen?

42.7590272 degrees W 89.8371481 degrees S

8) Where are the points located and why?

They are located in Antarctica because the coordinates are reversed.

9) Z values for each marker:

Control 00 – 280.1 Control 01 – 246.7 Control 02 – 243.69 Control 03 – 241.37 Control 04 – 247.98 Control 05 – 271.96 Control 06 – 280.58 Control 07 – 270.51 Control 08 – 266.98 Control 09 – 249.04 Flag 03 – 263.61

10) ArcGIS Earth elevations: northernmost & southernmost survey points

Northern most point would be the 280.58m Southern most would be 246.7 m

11) Approx elevation and differences (and what’s going on)

Northern most is 312.39 m Difference is 31.81 m (higher one observed; ellipsoid) Southern most is 278.35 m Difference is 31.82 m (higher one observed; ellipsoid)

12) How do you plot geodetic marks on NGS map?

Press on a spot and right click and press add marker.

13) Marker information recorded

Geoid height -33.852 m Ellipsoid height 238.926 m Ortho height 272.77 m X -39,664.430 m Y -4,635,039.152 m Z -4,366,921.213 m

14) Difference between ellipsoid and ortho, and relation to what you noted

33.844 m — it is off compared to mine by about 2 m.

15) Datasheet questions

NAVD 88 Ortho Height: 272.77 m

NAVD 88 Ortho Height in Feet: 894.9 ft

Geoid model used: GEOID12A

Geoid Height (Geoid12A): -33.852 m

Geoid Height (Geoid18): -33.852 m

16) Apply Geoid12A height differences (your recorded work + note)

33.852+33.85 =67.704 33.852+238.926 =272.778 33.852+272.77 =306.622 33.852+39,664.430 =39698.282 33.852+4,635,039.152 =4635073.004 33.852+4,366,921.213 =4,366,955.065

(Note: exact matches vary because ArcGIS Earth elevation is approximate across an area.)

⁠

Summary / Conclusion

This lab showed why geographic datums and vertical datums are critical for UAS mapping and survey workflows. A dataset that appears “fine” at first can contain major issues if it lacks metadata, has fields mislabeled, or uses the wrong vertical reference. By importing the same dataset incorrectly (XYZ) and correctly (YXZ), the lab demonstrated how easily points can be plotted in the wrong location. By comparing Z values to terrain elevations in ArcGIS Earth, a consistent height offset was identified and traced back to ellipsoid vs orthometric height differences. Using NGS Data Explorer and the datasheet information (including GEOID12A), the offset was identified and used to correct the dataset. Overall, this lab reinforced the idea that datum mistakes are not small — they can completely ruin UAS products if not caught early.

⁠

Want to print your doc?
This is not the way.

Try clicking the ··· in the right corner or using a keyboard shortcut (

CtrlP

) instead.