Scheduled Downtime
On Friday 21 April 2023 @ 5pm MT, this website will be down for maintenance and expected to return online the morning of 24 April 2023 at the latest

Small HGT error when running geogrid on high-res dataset

jota

New member
Hello,

I downloaded USGS 1/3" topographic data for some simulations I am working on. I was able to stitch together multiple tiles into my own dataset according to WRF guidelines (i.e. the whole 0xxxx-0xxxx.0yyyy-0yyyy naming conventions), and can successfully run geogrid.exe and generate maps. However, at the boundary between tiles, I get this repeating effect, where it looks like the same data is contained in each tile. The repeating overlap is constrained to less than 0.01 degrees of longitude.

I would expect that this would be fixed by specifying the "tile_bdr" field in my data index files -- but nothing I have tried has worked. Any value that I put in there besides 0 spits out complete nonsense. I have tried checking my maps to see how many grid spacings away these similar elevations are, but could not find a simple solution.

Does anyone have any advice or suggestions for me? I used the "convert_geotiff" routine described here (How to convert data for Geogrid - openwfm) on each of my individual .tiff files, renamed the binary files to correspond to the correct locations in the combined grid set, and then wrote the index file attached below for the combined set of four tiles (2x2).

Thanks for any help yall can give!

Best,
Joey
 

Attachments

  • index_file.txt
    460 bytes · Views: 11
I think we've found in the past that some tiled datasets include redundant rows and columns with each tile, and perhaps there's something similar happening in your case? If it's the case that your index file actually corresponds to a 1" (~0.000277778 deg) resolution DEM, then having 3600x3600 pixels per tile works out to 1-deg x 1-deg tiles; that you've had to specify tile_x=3612 and tile_y=3612 suggests that there may be, say, 6 redundant rows and columns on each side of the tiles?

If we assume that the redundant rows and columns are evenly split along all sides of the tiles (rather than, say, having all 12 extra columns on the eastern edge of the tile and all 12 rows on the northern edge), then you may be able to make a few small changes to your index file to get correct results:

known_x = 1800.5
known_y = 1800.5
tile_bdr = 6
tile_x = 3600
tile_y = 3600

Note that I'm not confident the known_x and known_y values proposed above are correct, so you may want to look closely for any positional shifts.
 
Hello,

Thanks for your reply! I’m sorry for such a long return response.

I tried your fix, which makes a lot of sense intuitively, but it did not work for my problem. geogrid ran fine, but I ended up with a netCDF output eith only 0s in the data fields (lat/lon were still populated correctly). As far as I could tell it wasn’t just a problem with shifting one way or the other, either, as there were no lats/long pairs at all that were populated with data.

I attached a plot of my terrain data and my geogrid table to help show what exactly I mean by an overlap at the boundary. The size of the error would fit really well with what you’re describing, but I can’t seem to get it to go. By shifting the domain around, I found that this error exists all along the boundary between tiles, and does not appear to favor one end of the domain versus the other (i.e. no shift, the error is centered at 40N or 106W exactly).

Thank again for your suggestions.
- Joey
 

Attachments

  • terrain.png
    terrain.png
    259.6 KB · Views: 1
  • GEOGRID.txt
    9.4 KB · Views: 2
Top