Update, March 2, 2021: I believe I’ve figure out what was happening with our GeoTIFFs and AutoCAD. We upgraded to GDAL version 3.2 a few months ago and it defaults to the newer OGC specification for GeoTIFF keys (version 1.1). AutoCAD, at least the versions some people were using, didn’t fully understand that specification and got a few things wrong. I’ve set our system up to use the old key specification with a -co GEOTIFF_VERSION=1.0 argument, so they should get data they can read again. I’m leaving the post up as I think there are still some useful things in it.
A few months ago I wrote about georeferencing and noted that sometimes your software doesn’t read it right. I showed a couple of examples from ArcGIS. Those examples are why the Data Access Viewer will georeference with NAD83(NSRS2007) tags instead of NAD83(2011) tags. Recently I’ve been hearing from AutoCAD users that our data isn’t landing in the right place. I don’t have a license for AutoCAD, so debugging is difficult, but a bit of back and forth with our users is suggesting that AutoCAD Civil3D isn’t liking files tagged with State Plane NAD83(NSRS2007) but does fine with the same files tagged with NAD83(2011). I don’t know for sure that this is the problem and I’ve only gotten reports for Mississippi and Massachusetts using survey feet, so it could be a very isolated problem. The point of this blog is not to point out a particular software issue, but to show you how you might change that georeferencing to something that works.
First, verify
Before you do anything else, you’ll want to verify that the data says it’s what you expect it to be. We went through that in the earlier post. If it says the data is something you’re not expecting (e.g. meters instead of feet), you’ve got a different problem to solve. If it does say what you’re expecting, such as Mississippi State Plane West ftUS, but your software isn’t putting it in the right place, then it’s worth some slight tinkering to see if it’s the software.
Set the projection
When we looked at this sort of problem for ArcGIS, I suggested using the Arc toolbox to set the projection for the data to what it should be. I haven’t found anything online to tell me how to do that in AutoCAD. You can set it for the drawing, but it’s not clear how you change a dataset. That being the case, we’re going to use some open source tools. First we’ll look at raster data and then lidar LAS/LAZ data.
Raster using GDAL
The GDAL library and tools is your friend for lots of raster work and is likely already leveraged in GIS package you use. It’s good to have it on hand for all sorts of work. Those packages that might already leverage GDAL probably have a slick GUI that will let you set the projection too, but we’re going to use the command line. For this example, let’s assume our data is a TIFF file georeferenced as NAD83(NSRS2007) Massachusetts Mainland State Plane in US survey feet and our software is misinterpreting that information. We want to try setting it to the same thing, except with NAD83(2011) as our datum instead of NAD83(NSRS2007).
Using EPSG codes to georeference has become a de facto standard and we’ll use them here. You can look up the codes you need at epsg.org. You can start by searching for Massachusetts Mainland in the search box on the left side of the page. After you get some results, refine them by adding NAD83(2011). That should get you something like the screenshot below, where I’ve circled the code we want (6492).
Once we have the code the rest is pretty easy. We just have to run gdal_translate with that code, the original file (input.tif here), and a new fixed file name (output.tif).
gdal_translate -a_srs EPSG:6492 input.tif output.tif
If this was an elevation data set with the value representing NAVD88 survey feet (EPSG code 6360), we’d want to add that information by making it -a_srs EPSG:6492+6360. Note that we didn’t change any of the data itself or any coordinates. All we changed was the information that said what the spatial reference system is. If it puts it in the right place now, then it was an issue of the software misreading the original information. If it doesn’t, then maybe we really have a problem with our data file or the software doesn’t like the new one either. If it puts it in the same place, it’s probably the data. If it puts it somewhere else, it’s probably the software.
Lidar using PDAL
The PDAL open source code for point clouds uses a lot of the same approaches as GDAL. It has a few different ways to combine commands using pipelines, which are a pretty slick way to make things more efficient, but we can do what we need with a simple command line and the LAS reader’s override_srs option. For our same case as above and LAZ files, we could do this:
pdal translate --readers.las.override_srs EPSG:6492+6360 input.laz output.laz
There are a few ways to install PDAL, including using docker or conda. See the quickstart guide for more information.
Lidar using LAStools
The LAStools are partly open and partly commercial. We only need the las2las command, which is in the open part. The tools are compiled for Windows, but the source is in the zip for the open part and you can compile for other operating systems. You can also use git to clone the open code from https://github.com/LAStools/LAStools.git. There is some online help for las2las, but it’s missing a couple things we’ll need for the vertical. Similar to the other tools you can specify the horizontal using an EPSG code with the -epsg argument. For example:
las2las -epsg 6492 -i input.laz -o output.laz
However, the vertical doesn’t use the epsg code, but does give the opportunity to specify the geoid. While I didn’t find the options in the help, you can find them in the code. Some examples:
# NAVD88 using geoid12b in vertical meters
las2las -epsg 6492 -vertical_navd88_geoid12b -i input.laz -o output.laz
# NAVD88 using geoid09 in survey feet
las2las -epsg 6492 -vertical_navd88_geoid09 -elevation_surveyfeet -i input.laz -o output.laz
# NAVD88 in international feet, no geoid specified
las2las -epsg 6492 -vertical_navd88 -elevation_feet -i input.laz -o output.laz
More explicit georeferencing?
Where does all this leave the Data Access Viewer? The failure of multiple package to understand EPSG codes is unfortunate. Being able to describe a projection based on a specific reference frame with a single number and have it understood is a pretty handy thing. If that’s a pipe dream, we may have to step back and explicitly code all the parameters. That means the standard parallels, false eastings and northings, and so on. That’s a pretty unpleasant task, but it may be one we have to explore. In the meantime, I hope I’ve given you some tools you can use. Those same tools can do a lot more than just set the projection. They are also very handy for reprojecting data too, though that still only scratches the surface.
Digital Coast GeoZone 