qgis
I used worldclim 2.5 arc minutes data set for creation of ASCII file. According to worldclim 2.5 ac minutes represent spatial resolution of 4.5 km, therefore the cell size 4.5 x 4.5 = 20.25km2. but the properties of ASCII file showing cell size of 0.1 (x) and 0.1 (y), therefore the cell size is 0.01 square.
What is the correct one to calculate area of the desired pixel or cell in QGIS?
I believe you can use some map algebra (raster > raster calculator) before you can preform your volume measurements in grass.
Assuming that your bathymetric data use positive values to represent the sea depth, and using your example for the range as 50 the min_depth and 200 the max_depth. For each of the raster cells you need to "remove" anything below the 200 and above the 50. You have 3 possible situations:
your cell depth is higher than the max_depth
(@bathymetry > 200)
your cell depth in the min_depth - max_depth range
(@bathymetry <= 200) * (@bathymetry >= 50)
your cell depth is lower that your min_depth
(@bathymetry < 50)
In case 1 the size of the water column will be the entire size of our range:
(@bathymetry > 200.0) * (200.0 - 50.0)
In case 2 the "water column" is from your bathimetry depth until the minimum value of the range:
(@bathymetry <= 200.0) * (@bathymetry > 50.0)*(@bathymetry - 50.0)
In case 3 there is no useful "water column" for your specie therefore it would be:
(@bathymetry <= 50)*0.0
Since the 3 cases never occurs at the same time, all we need is to sum the expressions:
(@bathymetry > 200.0) * (200.0 - 50.0) + (@bathymetry <= 200.0) * (@bathymetry > 50.0)*(@bathymetry - 50.0) + (@bathymetry <= 50)*0.0
Since the last expression is always zero, the is no point in including it:
(@bathymetry > 200.0) * (200.0 - 50.0) + (@bathymetry <= 200.0) * (@bathymetry > 50.0)*(@bathymetry - 50.0)
And the generic version of the expression would be:
(@bathymetry > max_depth) * (max_depth - min_depth) + (@bathymetry <= max_depth) * (@bathymetry > min_depth)*(@bathymetry - min_depth)
After this, you can use the output raster in r.volume to sum all "water columns" values
This seems to be a bug in QGIS, utilizing some odd behaviour of the gdalwarp utility. If gdalwarp does not like the input raster (in this case due to the y axis positive down), it creates a new raster with a square cell size by default.
On the command line, you can override this with
gdalwarp -tr 0.125 0.5 -s_srs EPSG:4326 -t_srs EPSG:4258 import_test_data.txt warped.tif
which gives an output corresponding to the points read as delimited text in QGIS:
Direct import:
warped import:
The gdalinfo output changes from
Driver: XYZ/ASCII Gridded XYZ
Files: Import_test_data.txt
Size is 240, 60
Coordinate System is `'
Origin = (0.000000000000000,0.000000000000000)
Pixel Size = (0.125000000000000,0.500000000000000)
Corner Coordinates:
Upper Left ( 0.0000000, 0.0000000)
Lower Left ( 0.0000000, 30.0000000)
Upper Right ( 30.0000000, 0.0000000)
Lower Right ( 30.0000000, 30.0000000)
Center ( 15.0000000, 15.0000000)
Band 1 Block=240x1 Type=Float32, ColorInterp=Undefined
Min=-991.760 Max=3333.000
to:
Driver: GTiff/GeoTIFF
Files: warped.tif
Size is 240, 60
Coordinate System is:
GEOGCS["ETRS89",
DATUM["European_Terrestrial_Reference_System_1989",
SPHEROID["GRS 1980",6378137,298.2572221010042,
AUTHORITY["EPSG","7019"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6258"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4258"]]
Origin = (0.000000000000000,29.999999999999996)
Pixel Size = (0.125000000000000,-0.500000000000000)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 0.0000000, 30.0000000) ( 0d 0' 0.01"E, 30d 0' 0.00"N)
Lower Left ( 0.0000000, -0.0000000) ( 0d 0' 0.01"E, 0d 0' 0.00"S)
Upper Right ( 30.0000000, 30.0000000) ( 30d 0' 0.00"E, 30d 0' 0.00"N)
Lower Right ( 30.0000000, -0.0000000) ( 30d 0' 0.00"E, 0d 0' 0.00"S)
Center ( 15.0000000, 15.0000000) ( 15d 0' 0.00"E, 15d 0' 0.00"N)
Band 1 Block=240x8 Type=Float32, ColorInterp=Gray
Note that the pixel size Y is now negative, and the coordinate origin has moved from Upper Left to Lower Left (where you would expect it in a North-up degree coordinate system).
Another choice is to load the data into LibreOffice Calc, and let it sort for column B decreasing, and column A increasing. Despite of http://www.gdal.org/frmt_xyz.html noting:
The value of the Y coordinate can increase or decrease however.
it should better decrease.
Best Answer
EDIT: My previous claim was false and I apologize for that. I thought I knew of arc-minute and all but I clearly had no idea. Here is the actuality:
2.5 arc minute data set is each pixel being worth 2.5/60 of one degree (since 1 degree is made of 60 minutes, and each of these is 60 seconds)
You can view the resolution in raster properties under Metadata and Properties. In this you will find your raster's dimensions as well as pixel size, however be careful. Pixel size will depend on the coordinate system you are using. In your case, I am thinking pixel size being 0.1 is due to it's value in regarding it's unit of measurement.