1

I have some DEM rasters (from the same data source so I think they're uniform in all file specifications) that I'm symbolizing using the same stretched color ramp. I set the stretch type to min-max, then edit high/low values to cover the low - high values for these rasters (0 - 128 in this case). For most of the rasters this works perfectly to create a nice seamless map, however for 3 of the rasters it is still not using the same symbology resulting in big ugly seams.

Any ideas on what may be causing this?

I'm using ArcMap 10.2.2.

PolyGeo
  • 65,136
  • 29
  • 109
  • 338
Alpheus
  • 542
  • 3
  • 14
  • You could try copying the statistics from one of the files that worked, use Set Raster Properties http://resources.arcgis.com/en/help/main/10.1/index.html#//00170000015z000000 also confirm the data_type is generic or elevation for all the rasters (view properties in ArcCatalog). – Michael Stimson Sep 09 '14 at 22:39
  • What format are the rasters in? Are they ASCII (.asc) files? There is a bug with ambiguous types in text format: if the first few records are integer the whole file is considered to be integer; if your nodata value is an int type like -9999 and the values start like -9999 -9999 -9999... then the image is assumed to be an integer, to fix this open the file in Notepad++ or other TEXT editor and change the first value at least to -9999.0. Any chance of a screen grab to show what's happening? – Michael Stimson Sep 09 '14 at 23:08
  • Tried copying statistics from one of the working ones to no avail. The rasters are in SDTS/.ddf format, I can convert them to the singular .dem format easy enough if I want, but that doesn't help the problem. The data type is all generic. Looking at the raster properties I've noticed they are not the same - the ones that work are pixel type signed interger with 16 bit depth, while the ones that aren't working are pixel type floating point of 32 bit depth. NoData value is -32766 for all, if I open with text program it shows all start with alphanumeric string. Guess I need to downsample. – Alpheus Sep 10 '14 at 21:20
  • Convert to 16bit, Copy Raster http://resources.arcgis.com/en/help/main/10.1/index.html#//001700000094000000 with pixel_type 16 bit signed or use GDAL_Translate http://www.gdal.org/gdal_translate.html with -ot CInt16 – Michael Stimson Sep 10 '14 at 21:32
  • Copy raster down to 16 bit signed doesn't change. I've noticed the raster properties format reads FGDBR after the copy, it also builds pyramids resampling from nearest neighbor. – Alpheus Sep 11 '14 at 21:04
  • Here's what it looks like: http://i57.tinypic.com/102s474.jpg Also tried converting the format to .dem before copy raster, no change. I'll see if I can get different results form GDAL_translate. – Alpheus Sep 11 '14 at 21:05
  • You need to specify the output cell type as 16 bit to match the others, if Esri isn't doing it then I know for a fact that GDAL_Translate will. Try .img (ERDAS Imagine) or .tif (GeoTiff) format, both of those have good pixel type support and interchangeability between packages. Also consider Esri Mosaic Dataset or Virtual Raster (GDALBuildVRT) which will reference these rasters as one dataset instead of grappling with individual statistics. – Michael Stimson Sep 11 '14 at 21:09
  • BTW the pyramid method (and whether to build pyramids or not) is in your geoprocessing environments GeoProcessing::Environments... and look for Raster Storage, uncheck for no pyramids, choose method from NEAREST, BILINEAR or CUBIC and whether or not to compress them (not supported on all formats) – Michael Stimson Sep 11 '14 at 21:22
  • I got it to convert properly with GDAL_translate, same problem with the symbology though. I tried outputting it in .dem & .tif formats with no change in results. I noticed that if I convert the original data, which came in .ddf format, to .dem format the raster properties will then read floating point 32 bit, but I can get the symbology to work property between the 16 & 32 bit rasters. Or if I convert said .dem down to 16 bit signed integer it also works fine with the 16 bit signed .ddf rasters. Seems strange. – Alpheus Sep 12 '14 at 21:46
  • This is the program I used to convert the .ddf files into a .dem file: – Alpheus Sep 12 '14 at 21:46
  • http://www.cs.arizona.edu/projects/topovista/sdts2dem/

    USGS recommends it since the ddf/SDTS format is messy to use.

     – Alpheus Sep 12 '14 at 21:47
  • Just wanted to update this - I figured out why - the pixel values in the rasters that aren't displaying correctly are simply wrong for some reason, they range 17-26, should be about 70-40. – Alpheus Sep 19 '14 at 16:34

1 Answers1

1

Alpheus, I'm not sure if you've already solved your problem or not but I would recommend against converting your DEM to a 16-bit raster. This is very likely to reduce the precision with which the elevation data are stored and can be very disruptive for any subsequent analysis, e.g. flowpath modelling or slope analysis. If your data are currently floating point, and I don't know if they are, then this conversion will also result in a degradation to integer values, i.e. nearest metre or foot. If you are finding seams between your tiles despite all of them having the same display minimum and maximum values, then this could only be caused by a different binning strategy among some of the tiles, e.g. you might be using an equal area stretch or something similar for a few tiles. However, given your problem is mainly with display, you might consider mosaicing your DEM tiles into a single larger raster. That way their colour ramp and display parameters are guaranteed to be the same throughout. There was a similar question to this a short time ago,

Is there any way to 'clean' up ASTER v2 DEM data?

That person found that mosaicing was the solution to their problem with creating a seamless display of elevation data.

Community
  • 1
WhiteboxDev
  • 11,025
  • 1
  • 35
  • 65
  • Thanks! The main problem turns out was just a meters to feet problem :P Most of their DEMs are in feet but a few are in meters. My data source isn't much for mentioning this sort of thing up front. The mosaic command is a huge help though as I aim to ultimately put together about 300 rasters to cover the entire region. – Alpheus Oct 02 '14 at 16:14
  • @Alpheus Ah, that too is a common 'binning' problem. I can't tell you how often I've run into that particular problem! Glad you resolved it. – WhiteboxDev Oct 02 '14 at 16:20