Dear GeoNet community.
I was wondering if somebody could help me with an issue related with cell width of an esri grid format (.asc file).
What I would like to do is to import an elevation data from an .asc file to Rhino 5 application.
In Rhino 5 I am opening an .asc file with IronPython 2.7, and then generating a terrain model from elevation values.
However, there is one thing that confuses me:
is the width of the cells always constant?
To make it more understandable, here is a small example of how an .asc file looks like:
ncols 38 # number of cells in x direction
nrows 29 # number of cells in y direction
xllcorner 2.140416666625 # bottom,left corner's (origin) longitude
yllcorner 41.350416666671 # bottom,left corner's (origin) latitude
cellsize 0.000833333333 # size of the cell in decimal degrees
NODATA_value -32768 # no elevation value.
36 34 35 33 34 36 32 29 32 35 39 39 41 40 38 41 38 39 37 40 38 38 37 34 ... # elevation values
I also attached that .asc file bellow. It's an elevation data for Barcelona.
Here is a visual representation of upper mentioned values from .asc file taken from wikipedia (which is copied from ArcGIS help😞
I simplify the Earth model to sphere, and assume that one degree of latitude and longitude at equator is 111120 meters.
Then I use the "yllcorner" variable's value (origin's latitude) to calculate the width of the cell size:
cellWidthMeters = cellsize * 111120 * math.cos(yllcorner)
The value of "cellWidthMeters" that I get is the width of the cell at that (yllcorner) latitude. It is also the cell height at any longitude, as this one is constant.
What I do not understand is, why isn't the width of the cells changing, as the latitude is changing? Something like this:
Why is it always constant?
The width of the cell is in degrees of longitude at "yllcorner" latitude.
So the width of the cell should be shrinking as we go further from the origin, because the degree of longitude is shrinking the larger the longitude is.
Or did I get this completely wrong?
Thank you for the reply.
Regards,
D
Solved! Go to Solution.
The cell size is correct... it is in decimal degrees ... it cannot be converted to meters unless you have software to do so (ie Project it) ... there is no equation etc that will produce an accurate conversion from what it is, to what you want it to be. Hope it is clearer this time.
the cell size is defined as a portion of a decimal degree. The cell width and height are equal giving cell area in square degrees. the unit of degree doesn't change...its representation in euclidean/planar coordinates does. By using degrees for coordinates/width/area Earth can be represented as a big xy grid with the poles having the same width as the equator and every other line of latitude. Once you have assembled your ascii data into an esri 'grid' (or tiff or whatever) in decimal degrees, you can then project it to a suitable coordinate system should you wish to makes measures of area/distance and the like.
Thank you for the reply Dan.
"The cell width and height are equal..."
What does this mean?
That if one simplifies Earth as a sphere, the width and height of the cell will always be equal to:
cellWidthAndHeight = cellsize * 111120 meters
regardless of the origin's ("yllcorner") latitude?
(1 degree of latitude and longitude on equator is approximately 111120 meters).
No it means that the cell is always expressed in degrees
cellsize 0.000833333333 # cell width and height in degrees
0° | 110.574 km | 111.320 km |
15° | 110.649 km | 107.550 km |
30° | 110.852 km | 96.486 km |
45° | 111.132 km | 78.847 km |
60° | 111.412 km | 55.800 km |
75° | 111.618 km | 28.902 km |
90° | 111.694 km | 0.000 km |
plus many more other links for more information and the governing equations.
I appreciate the reply Dan.
The table you have given me shows the lengths of a single degree of latitude and longitude depending on latitude, for WGS84 model, which depicts Earth as a modified reference ellipsoid.
I am not asking for equations on how to calculate the length of a single degree of latitude, longitude depending on latitude.
What I would like to do is to make a terrain model (in Rhino, not ArcGIS) from upper attached .asc file and its elevation data, by simplifying Earth as a sphere.
.asc file elevation data is always in meters, so this is not a problem.
The issue is: which length needs to be taken for each cell width(height) of the xy grid, when building a terrain model:
Should cell width and height always be:
cellWidthAndHeight = cellsize * 111120 meters
regardless of the "yllcorner" value (this is the latitude of DEM's origin)?
Or should the cell width and height take into account origin's latitude:
cellWidthAndHeight = cellsize * 111120 meters * cos(latitude)
?
(111120 meters is approximate length of 1 degree of latitude and longitude on equator, in case of simplified sphere Earth model).
Thank you.
If the units are expressed in degrees, build it in degrees. Once you have that raster, then you can Project it to a projected coordinate system so that the units are in meters. You can't skip that step.
Thank you for the reply Dan.
I think the misunderstanding part is than Rhino application can not express its terrain model in degrees.
Only in length units: meters, feets, inches...
As elevation values from .asc file are in meters, there has to be a way to convert cell's width/length from decimal degrees to meters too.
This is what the upper two equations are doing.
Then Rhino doesn't handle unprojected data. You will have to use ArcMap or some other open source software to do the Projection to a projected coordinate system (ie. like UTM )
Then, if you need it out in asc format, you can export it out using the Raster to ASCII tool.
It is often the case that raster data comes with geographic coordinates and planar Z values. A seamless coverage can be created... the onus is on the user to project the geographic coordinates (aka decimal degrees) to something useful if the file is to be used in analysis.
I already have the .asc file. I do not have the initial model from which attached .asc file is derived. And why would I have to make a raster from that initial model (which I do not have) and then reexport it to .asc again (which is what Raster to ASCII tool does)?
Upper photo is digital terrain model created in Rhino, based on attached .asc file. The problem is: whether the cell width/height is correct or not.
The cell size is correct... it is in decimal degrees ... it cannot be converted to meters unless you have software to do so (ie Project it) ... there is no equation etc that will produce an accurate conversion from what it is, to what you want it to be. Hope it is clearer this time.