[Update: The LAStools was updated on January 3, 2016 to include many more EPSG codes. The text below was changed to reflect that.]
Today we’re going to take a look at some of the different NAD83 realizations and their implications for properly georeferencing lidar data. We won’t dive into exactly what is meant by a “realization” of NAD83, but if you’re interested, a good place to start is Modern Terrestrial Reference Systems, Part2: The Evolution of NAD83. For our purposes, they are just refinements of the NAD83 datum with a “datum tag” in parenthesis, such as NAD83(86) and NAD83(NSRS2007). What we will look at is how those realizations are coded and used in some typical GIS formats and software compatibility.
What’s my motivation for looking into this? I spend a fair amount of my time with lidar data distribution through the Digital Coast Data Access Viewer (DAV) and lately it has come to my attention that I need to be a little more accurate about the reference systems for the data we serve out. One particular data set that pushed this issue was the post-Sandy lidar collection along the East Coast. It was collected by NOAA/NGS and they tend to pay attention to datums. They wanted to make sure the data was georeferenced as NAD83(2011). Unfortunately, our data was going out with georeferencing that would be considered NAD83(86).
So, how are the lidar data georeferenced? Most public domain lidar you’ll find is in LAS format. The majority of that data is in LAS versions 1.0 through 1.3, which use the same georeferencing method as a GeoTiff using “GeoKeys.” The current version, 1.4, supports well known text georeferencing, but also allows the GeoTiff method for compatibility. There isn’t much LAS 1.4 data available yet, so the vast majority of lidar data you’ll find uses the GeoKeys. The GeoKeys are sets of (tag, value) pairs that define the projection, units, datums, and so on. These pairs are found in the International Association of Oil and Gas Producers EPSG Geodetic Parameter Dataset, though it’s probably easiest to see how they work by looking at the GeoTiff documentation and looking up codes at epsg.io, spatialreference.org, or similar sites.
For example, the table below shows the keys that could be used to describe lidar data in North Carolina state plane with NAVD88 elevations.
|tag name||tag||value name||value|
|Projected Coord Sys Key||3072||NAD83 North Carolina||32119|
|Projected Linear Units||3076||US survey foot||9003|
|Vertical Coord Sys Key||4096||NAVD 1988||5103|
|Vertical Units||4099||linear foot||9002|
The only North Carolina state plane value you’ll find in the GeoTiff documentation is 32119, as in my example. However, if you search for North Carolina on espg.io, you’ll find a lot more. One thing you’ll find is a possible error in the coding in my table. Value 32119 is supposed to have units of meters, not survey feet. The right value would be 2264. Both of those reference NAD83(86) as their datum. There are other values to use for each of the other NAD83 realizations, such as NAD83(HARN), NAD83(NSRS2007), and NAD83(2011). See, it’s getting confusing. By the way, I’m using North Carolina for my examples and testing, but recognize that this applies to all the other states and UTM zones.
So far, that looks like a pain for someone to code up and maintain, but nothing for a user to worry about, right? It turns out that your GIS or other software might not know all those new values for the projected coordinates tag yet. I took a look at a few of the packages I had on hand to see if they knew the state plane and UTM values for the different NAD83 realizations. Primarily, I wanted to figure out if it made sense to distribute data with NAD83(2011) tags since it wouldn’t be helpful to distribute with tags that your software couldn’t interpret.
My lineup of software is LAStools, ArcGIS, Global Mapper, and ERDAS Imagine. The first one works with point cloud lidar data. The rest are GIS packages that can also work with point cloud data, but I checked their ability to interpret a GeoTiff DEM too. As you can see in the table below, the general GIS packages all did pretty well until you get to NAD83(2011), then they fail. Why? Well, I’m probably not perfectly up to date on the software releases, though I don’t think anything is more than a year old. For any packages that use the open source proj.4 to handle the georeferencing, the NAD83(2011) values were not included until version 4.9.0, which included an upgrade to EPSG 8.5, about a year ago. That upgrade of the EPSG database would have brought in the new values and lots of GIS packages use proj.4.
|Software||NAD83 (86): 2264||NAD83 (HARN): 3404||NAD83 (NSRS2007): 3632||NAD83 (2011): 6543|
|Global Mapper (v17.0)||yes||yes||yes||no|
|ERDAS Imagine 2014||yes||yes*||yes||no|
Days after I initially wrote this post, LAStools put out an update that reworked how the EPSG codes were found by using the pcs.csv file from GDAL. This greatly increased the number of codes it recognizes and I’ve updated this post to reflect that. I haven’t dug through the other packages to see if a similar pcs.csv could be updated, though there may be a similar mechanism.
[Update June 21, 2016: Global Mapper 17.1 does recognize NAD83(2011), ArcGIS 10.4.0 does not.]
What does all that mean for you? It may mean that you could see data sets that load without the georeferencing being set. You may then have to set it manually to the right thing or something close enough. The bottom line for me is that I may need to hold off distributing with NAD83(2011) values for a little longer. Unfortunately, the only code for North Carolina (my proxy for all the states) that all my packages understand is the old 32119 that is in meters. I expect these packages will all know NAD83(2011) in their next version releases.
In case you’re wondering what might be “close enough,” if you have to choose, NAD83(86) is sufficiently different from the other realizations that it could be a problem. It is around a meter away from the rest for a given latitude longitude pair. The others all cluster pretty close together; close enough that there might not be published ways to translate between them. Programs from NOAA/NGS that do coordinate translations (e.g. VDatum and HTDP) treat datum tags CORS96, NSRS2007, and 2011 as the same.