Just a warning.?ÿ Civil 3D seems to have a known issue creating surfaces from geotiff DEMs.?ÿ The data is shifted approximately 1/2 the grid size of the geotiff.?ÿ I found references to this going, in AutoDesks form, back to 2015.?ÿ As a test I exported at sample area with 0.5 foot, 1 foot, 3 foot and 10 foot resolution and imported them all.?ÿ The results confirmed the shift of ~1/2 pixel size.?ÿ It sounds like they may have fixed it temporarily in version 2022 but broke it again in 2023.?ÿ It issue exists in versions 2020 & 2021 for sure.?ÿ I might need to load 2022 to see if it really fixes the issue.
It's been a long time, but this seems to ring a bell. It has something to do with reading the header information incorrectly - it moves everything over by a half-cell width and starts to write the data there because it reads the upper left corner as the start of the data.
Excellent PSA.
@rover83?ÿ
Yeah, that is what it sounds like.?ÿ What I cannot believe is that AutoDesk has known about this for almost a decade and not either A, fixed the problem, or B removed the feature.
While I understand the need to continually add new features to justify subscription cost, it would be nice if software manufacturers would make sure the features they have work as planned.
Generally, there are two ways of "referencing" a "pixel" in a georeferenced image; those being block-centered and grid-centered. I would suggest that you strip the georeferencing (I use PhotoShop) from the GeoTiff and insert the Tiff with a Tiff World File (.tfw).
Some of my image software uses the grid-centered (upper left of the pixel is assigned a pixel coordinate of (1, 1)) and other software uses block-centered where the center of the pixel is (1, 1).
I would add or subtract half the pixel size from the georeferenced coordinates of the upper left corner of the image until you find the correction that places the image where it belongs.
One of my image-processing software packages (ENVI) makes this easy because it ties the pixel coordinates to the georeferenced coordinates of the image. For example, pixel coordinate of (1, 1) = georeferenced coordinates (1170004.56, 3000064.48 based on grid-centered, which can be changed to (1.5, 1.5) = (1170004.56, 3000064.48) if the images georeferenced coordinates are based upon a block-centered scheme.
BTW....I'm envious that your data is so good that half a pixel offset is noticeable!!
I read about that half pixel width explanation too and I think I tried something similar to what you tried: importing the same TIFF with different pixel sizes.. but I can??t remember what conclusion I came to (swearing at C3D was almost surely involved tho).
Anyway, I think I came up with a different explanation that still befuddles me. I??ll outline it below to see if it advances the convo or someone can point out my mistake:
Most of my TIFFs are projected into State Plane, with USFT coordinates in the 5000000,2000000 range. Most of my TIFFs also come out of QGIS, where I have been as careful as possible to maintain the integrity of the projections (i.e. no unnecessary or innaccurate transformations). Using QGIS??s ??Raster Calculator?, I make a binary raster from my TIFF, where any no-data cell gets changed to 0, else 1.
a statement like:
@raster =! -99999
or, @raster > 0 should do the trick.
QGIS also has a ??Raster to Polygon? utility that will now create an outline of the binary TIFF. (I believe you need this and not just the traditional ??extent? because of what @gene-kooper said - C3D applies all the TIFF header info starting with the lower left cell)?ÿ
Exporting that polygon as a shapefile in the same projection as the TIFF (which should be the same as the project??s projection). Import this into C3D, then import the TIFF. If working in State Plane with coordinates in the 5000000,2000000 range, the LOWEST LEFT corner of the TIFF will show up about 13?? northeasterly of the same corner of the shapefile.
Set a point on the lower left corners of the TIFF and the shapefile and note the coordinates (assuming your TIFF is a surface, change the style to show the boundary and you??ll be able to snap to it). Measure between the two points and note the X and Y components. Now multiply each coordinate from your shapefile by 3.280833333/3.28084. The numbers should match.
So, if all this is correct, it shows that C3D will not recognize that your TIFF is ALREADY in USFT (despite the TIFFs headers).. and so it will locate the lower left corner of the TIFF in the wrong location (it multiplied the correct location by 1.00000203?? which is significant when multiplying by 1000000).
I haven??t figured out yet how C3D messes up the scaling, but knowing C3D, I??m betting it??s something else equally lame.