Nope, this can happen, I am quite familiar with the issue. These days we’re seeing more and more of these “open-source” geodatabases exporting data that looks like yours when imported into Rhino.
The theory behind ASCII Grid files is that just the Z height data is contained in the file for compactness, and the “grid” is generated by a lower left corner coordinate plus a cell size (in theory square); the data is distributed cell by cell, the grid is actually created by the importer.
The problem is that the height data is in length units - usually meters in this part of the world, I guess it could be in feet as well - but the cell size variable can either be in the same unit as the height data, or, as in the case of what you’re seeing, the cell size value is in angular units - usually degrees. These are tiny compared to meters, one degree of arc on the earth’s circumference is about 111 kilometers or 111,000 meters ! 1 arc-second is about 30 meters, often we get files with one or three arc-second resolution.
So the importer has to be able to know what the grid units are , but the file format does not contain this specification…
So you have to guess (I guess).
The RhinoTerrain importer thinks the cell values are in meters and the cell values are very small, so that’s why the import looks like a vertical line. You can try fixing this by doing a Scale2D in the Top view and use a scale value of 111120 (basis for a nautical mile).
There are issues with this. The first is that if your file is in arc units, it likely has not been compensated for a spherical projection, so it may not be completely accurate. The second is that an arc-second has slightly different length depending on where you are on earth (the earth is not completely round), so the multiplier might also be a little off.
I do have an ascii grid importer (attached below FWIW) which tries to guess the cell size units (if it’s very small, then it’s likely arc, otherwise file units).
Good luck, --Mitch
ASCIIGridImporter-AngleCellSize.py (7.9 KB)