0

Sorry this is a novice question. I am completely new to the GIS domain and inherited a parser that expects a .bil file to get elevation at latlon points.

From what little documentation there was, it seems like the USGS NED database has all the information I need, but it now only provides the 1deg grid files in ArcGrid, GridFloat, or IMG formats.

I tried using GDAL and QGIS to convert the data for the parser but whenever I query it for elevation, it gives me a long int.

EX: at (39.5, -104.5), if I query from https://nationalmap.gov/epqs/ it's 6207.71ft, my predecessor ingested data from here and returns 6220ft (not exactly the same but reasonable difference). However when I convert GridFloat to BIL then query, I get 1156302165. I have no idea what this number is or means. The parser thinks it's elevation.

My questions are:

  1. Did NED used to provide BIL format and recently changed? My predecessor did not leave notes on where to get files and did not even have example files from when he loaded data. And this was only 1 year ago.

  2. Both GDAL and QGIS tools seemed to convert successfully, I got BIL files but obviously something is wrong with either my parser or the conversion.

I've been reading a lot from this site as well as various gov sites but the only solution I can come to is to update the parser to read one of the 3 provided formats and hope it works.

I am asking for insight from experts since I am absolutely brand new to this field and it's data.

0

The GDAL driver's documentation gives us some clues: https://www.gdal.org/frmt_various.html#EHdr

GDAL supports reading and writing the ESRI .hdr labeling format, often referred to as ESRI BIL format. Eight, sixteen and thirty-two bit integer raster data types are supported as well as 32 bit floating point.

So the BIL format supports both integer and floating point data...

This driver does not always do well differentiating between floating point and integer data. The GDAL extension to the .hdr format to differentiate is to add a field named PIXELTYPE with values of either FLOAT, SIGNEDINT or UNSIGNEDINT. In combination with the NBITS field it is possible to described all variations of pixel types.

... but there's no standard way to differentiate between them, so GDAL uses its own system to do this.

What's likely happening is that the parser doesn't know the data type, and it's interpreting the 32-bit values as integers rather than floats. If the parser is based on GDAL, you can probably override which data type it reads as when you open the file. Or modify the HDR file as shown in the docs there, specifically ensuring nbits 32 and pixeltype float are present so GDAL knows the correct type when it's opening the file.

If the parser's not based on GDAL then I can't help you much since I don't know how it works, but the issue is likely the same.

  • 1
    You were 100% right. gdal_translate assumed pixeltype float but the parser (while referencing pixeltype) only accepted INT32. By simply changing the translate parameter to switch to INT32, it worked perfectly. Thank you so much! – Jonathan-2J Nov 6 '18 at 15:41

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.