Why is esri grid cell width always constant?

4064
9
Jump to solution
10-15-2015 04:52 PM
DjordjeSpasic
New Contributor

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😞

a.png

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:

b.png

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

0 Kudos
1 Solution

Accepted Solutions
DanPatterson_Retired
MVP Emeritus

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.

View solution in original post

9 Replies
DanPatterson_Retired
MVP Emeritus

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.

DjordjeSpasic
New Contributor

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).

0 Kudos
DanPatterson_Retired
MVP Emeritus

No it means that the cell is always expressed in degrees

cellsize     0.000833333333 # cell width and height in degrees

\phi\Delta^1_{\rm LAT}\Delta^1_{\rm LONG}
110.574 km111.320 km
15°110.649 km107.550 km
30°110.852 km96.486 km
45°111.132 km78.847 km
60°111.412 km55.800 km
75°111.618 km28.902 km
90°111.694 km0.000 km

Dr Google link

plus many more other links for more information and the governing equations.

0 Kudos
DjordjeSpasic
New Contributor

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:

grid_size.jpg

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.

0 Kudos
DanPatterson_Retired
MVP Emeritus

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.

0 Kudos
DjordjeSpasic
New Contributor

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.

0 Kudos
DanPatterson_Retired
MVP Emeritus

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.

0 Kudos
DjordjeSpasic
New Contributor

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.

0 Kudos
DanPatterson_Retired
MVP Emeritus

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.