Incorrect Elevations when Importing Design Surface

I created a TIN surface using the given contour data from the civil engineer’s existing grades. The TIN surface shows the correct elevations in feet in Civil3d.

I exported the surfacte to GEOTIFF using assigned coordinate system.

When I import the GEOTIFF into DroneDeploy, it appears that the lat/long are correct, but the elevations are pulling in the meters instead of feet. For example the 500 ft elevation is showing 1640 ft (1640m equals 500ft).

I am exporting to the imperial coordinate system, so I don’t understand why dronedeploy is seeing 1640 ft instead of 500 ft. If it were units issue, wouldn’t the X and Y also not match up?

How can I get this surface to import properly into drone deploy?

  1. Did you fly using GCP’s?

  2. How did you implement the benchmarks?

  3. Where are you and what EPSG did you use?

Yes, I flew with GCP’s
I tagged the GCP’s in drone deploy’s GCP workflow.
I used the NAD83 Texas North Central.

But regardless of any of that, I’m not exporting out of Drone Deploy, I’m trying to get a GEOTIFF surface into drone deploy to use the new cut/fill analysis tool. I’m adding it as a “Project File” (used to be called overlays).

I used the existing topo CAD file and created a surface to represent the existing grades. The surface is correctly showing elevations of 500 ft where it should.

My map data is correct - 500ft elevations are correct where they are supposed to be.
My surface is correct in Civil 3d - 500ft where supposed to be.

The issue is that when the GEOTIFF surface imports, it is incorrectly reading the meter elevation and pulling that in for the feet. The reason I know this is by clicking the “overlay” properties and looking at the color scale (see screen snip).Capture4

Ok, that makes more sense now. I thought you were coming out of DD and into something else. This use to happen with the model back in the day. It would assume the Z units were meters and it would jack up the elevations. Horizontal is fine because it is using WGS84 regardless of what EPSG you use for the GCP’s. What EPSG number specifically do you use?

When I imported the GCP’s, I chose the NAD83 Texas North Central (no epsg given).

If you are talking about when I export from Civil3D, I’ve tried exporting to several different coordinate systems (they don’t let you assign by EPSG number, just by a list/code).

I’ve tried:
NAD83 Texas North Central, US foot
NAD83 Texas North Central, meter

Perhaps I need to export to WGS84 and I guess zone 14N?

Haha, here I am still stuck on exporting from DD and choosing the EPSG. :crazy_face:

I am familiar with Civil 3D and agree on the options there, but I don’t think it will matter. You are probably one of the first to try to bring a surface in and I think it is a bug like the model was. Please email support@dronedeploy.com and be ready to provide as much data as you can including the surface you want to import. Another thing we are probably going to run into is when the CAD is truly positioned and has a scale factor…

Here are all the NAD83(2011) EPSG codes for Texas

EPSG:6577 - NAD83(2011) / Texas Central
EPSG:6578 - NAD83(2011) / Texas Central (ftUS)
EPSG:6579 - NAD83(2011) / Texas Centric Albers Equal Area
EPSG:6580 - NAD83(2011) / Texas Centric Lambert Conformal
EPSG:6581 - NAD83(2011) / Texas North
EPSG:6582 - NAD83(2011) / Texas North (ftUS)
EPSG:6583 - NAD83(2011) / Texas North Central
EPSG:6584 - NAD83(2011) / Texas North Central (ftUS)
EPSG:6585 - NAD83(2011) / Texas South
EPSG:6586 - NAD83(2011) / Texas South (ftUS)
EPSG:6587 - NAD83(2011) / Texas South Central
EPSG:6588 - NAD83(2011) / Texas South Central (ftUS)

These are the ones that work the best with the engineered plans and GIS information we use.

image