There is a tool for DEM to Raster in ArcGIS but I need to convert my ArcGIS DEM rasters (mostly LiDAR) into USGS DEM. The idea is to import this DEM into Sketchup and create a "sandbox" TIN surface and for this SketchUp needs the data to be in this particular format.

In the past I mostly used the Sketchup Plugin to export TIN from ArcGIS to Sketchup which worked great but since the plugin no longer works in version 10. I am trying to create a new workflow but I am not having much success. The "Collada method" does not work well for complex surfaces. It requires to first create a multipatch and there is the first issue as described here. Besides, it is painfully slow if the conversion even succeeds at all.

There is another option described here but I have not tried it. Can anyone comment on how well the Cloud v8 plugin mentioned there works?


I think gdal_tranlate is going to be your best bet. I too am having to do this now to get elevation data in Vue for 3D simulations. Right now, I am going from whatever grid format to tif, then using gdal_translate to go to dem. If there is a way to do this natively using ESRI tools, I'd love to know about it. You can use the -projwin flag to clip as you translate:

D:\Projects\VIESORE\GIS_Data\Raster\GTOPO>gdal_translate -of USGSDEM -projwin -1027394.693241 6566367.197442 -426789.325363 6545200.488441 gtopoUTM.tif gtopoUTM
Input file size is 4216, 6832
Computed -srcwin 1818 4208 737 26 from projected window.

Also, see this question here on GIS.se regarding using GDAL with C# to translate to DEM.

| improve this answer | |
  • Thanks Chad. I just commented on your answer in the fly-over question. What is the learning curve like with Vue? – Jakub Sisak GeoGraphics Oct 6 '11 at 14:46

If you have access to (that is: command line arcinfo) then use the LATTICEDEM command to convert from raster to USGS DEM. If you have Arcinfo License level then workstation is available from the original installation media (up to v10.0) but isn't installed by default.

Arc: latticedem
Usage: LATTICEDEM <in_lattice> <out_dem> {z_factor} {FLOAT | INT}

ArcGIS no longer supports write access (see supported raster formats), so without workstation you'll need to use gdal_translate as previously mentioned (which is an essential tool in my book anyway).

| improve this answer | |

If you have the Esri Interoperability Extension, then you can extend it using the FME ArcGIS Data Interop Edition. This gives access to most of the raster formats supported by FME: http://safe.com/solutions/for-applications/esri/esri-arcgis/data-interop-comparison/

| improve this answer | |
  • Yeah. Don't have it. Hopefully, they will include it in the next version (same as Maplex) – Jakub Sisak GeoGraphics Oct 6 '11 at 17:27

As you mentioned on another thread, @Jakub, 3DEM is another tool that will work for this. Unfortunately, it is no longer supported. Sometimes you will have to convert your input data to one of it's acceptable input formats to get it to accept it for import.

| improve this answer | |
  • That would be OK if its stable and does what i need it to do but doesn't seem to run at all on my machine (Win7 64) raising an application error (0xc0000005)- application was unable to start. – Jakub Sisak GeoGraphics Oct 6 '11 at 15:32
  • @Jakub - You know what? That's so weird as it just did that to me as well, and I have had it running on my Win7 64 box for months - I wonder if a Windoze update killed it? Very strange. – Chad Cooper Oct 6 '11 at 15:53
  • I rebooted and it launched fine. – Jakub Sisak GeoGraphics Oct 6 '11 at 17:28
  • @Jakub - That's Windows, when all else fails, reboot. I was going to try that, but I'm too lazy to shut everything down and then start over! – Chad Cooper Oct 6 '11 at 17:30

I have an additional detail to add which I am surprised hasn't come up. In my shop we work with high resolution remotely sensed data, but it seems the USGS .dem format only allows 16 bit integer elevation values. Even if you put -ot Float32 in your gdal_translate command, you get unsigned 16 bit values, so any submetre precision is truncated.

I found a workaround based on the zresolution parameter described here: https://gdal.org/drivers/raster/usgsdem.html

  1. Multiply your raster dem by 10
  2. Add zresolution=0.1 to your gdal_translate command

eg. gdal_translate -a_nodata 0.0 -ot Float32 -of USGSDEM -co zresolution=0.1 E:/Lidar/dem/be_dem_times10.tif E:/Lidar/dem/test.dem

(FYI if you are using QGIS Translate(Convert Format) as I was, put the zresolution parameter and its value of 10 under Name and Value.)

This produces a .dem file that appears to have 32 bit float Z values to 0.1 unit precision eg. 400.5 m rather than truncated to 400 m. (Not sure if it is REALLY a 32 bit float USGSDEM or just scaled on the fly to look like one?)

What does NOT work is trying to go for 0.01 unit precison by multiplying by 100. The result is all NODATA -clearly there is some kind of numeric overflow. Lots of frustration figuring this out. If anyone has further information please comment.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.