very confused by cell size and pixel depth

[xxtraloud]

so I have created a model in arcmap to convert my data into .asc.
(following "Using the ArcMap model builder to reproject, clip, and
export to multiple ascii raster files") But I am still puzzled by some
parameters to be set into the projection part of the model. So the
world climate data cell size is 0.008333 with geographic coordinate
system WGS 84 and pixel depth 32. the problem is that when I project
into WGS 84 UTM zone 35S with the same cell size 0.008333 the
operation crashes or just runs forever. Instead if I use an output
cell size of 1000 then the operation goes through. Also the clip
operation output, which I run before the projection, has bit depth of
8-bit just like the output generated by the projection.
1. What is the world clim cell size unit?
2. and why am I losing bit depth with the clipping operation?
3. I know that cell size should be decided based on the study but I
just want to keep the same resolution as the world clim data, why is
that not possible?

thanks again

[Marwa Waseem]

Hi,,

You need to remember that when you project your data, you conevert from degrees, min, sec units to m or km units. So accepting the the same pixel size is the problem in your case. You have to either accept the defualt cell size that will be given by the program to you when you proceed with the projection step which I believe will be around 850 m, remember that wolrdclim is 30 arc sec (i.e. around 1km), OR, you need to specify the pixel size you desire in m unit (e.g. 900m or 1000m) .

I don't know the type of the data you have, but you need to know that storeing your data in 8 bits or 32 bits will be determined based on the type of the data you have. if you are going to store integer values, the 8 bits would be appropriate, if your values are floating or numbers with frcations or signed (+ve & -ve) the 32 bits would be appropiate. 

 

Marwa Waseem

--
You received this message because you are subscribed to the Google Groups "Maxent" group.
To post to this group, send email to max...@googlegroups.com.
To unsubscribe from this group, send email to maxent+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maxent?hl=en.

[John B]

It seems Marwa has beaten me to it, but here goes anyways...

1. Worldclim data units are degrees, so it seems you are working with 30 arc-second data. When projecting to UTM, your output grid will be in meters. By specifying an output cell size of 0.0083333, you are in fact instructing ArcGIS to give you a grid with cell size 8.3mm, so it's no surprise it's crashing! When you set it to 1000, you are asking for an output grid with 1km resolution. 

2. I suspect that the Worldclim data is at least 16-bit signed, at least for temperature grids which are expressed as temp*10 and therefore the range of values allowed by 8-bit signed (i.e. -128 to 127) would be insufficient. That said, I'm not sure why you're losing bit-depth. I'd perform each step of your model in turn, manually, and inspect the outputs to find out where this reduction in bit-depth is occurring.

3. Prepare yourself for a long-winded answer: Degrees of longitude shrink from about 100km wide at the equator, to infinitely narrow (i.e. a point) at the poles. However, cells in a lat/lon grid are all depicted as equal size, so the area they represent must differ from north to south. Because of this variation in cell size across your input grid, you can't create an output grid that has exactly the same cell size. You could make your cells have more-or-less exactly the same height as your input grid, i.e. 0.0083333 degrees. Assuming the datum that you've used (WGS 84), one degree of latitude (height) is 111319 m, so you would specify an output cell size of 111319 * 0.0083333 = 928 m. Cell width will be now also be 928 m, which is slightly different to that of your input grid, depending on location (cell width of the input grid would vary from ~928 m at the equator to cos(x) * 928 m at latitude x (e.g. ~914 m at 10 degrees latitude). As you can see, the difference is pretty trivial. For simplicity, people would typically just project to a 1 km grid if using 30" input data.

On another note: Usually we project a grid to more accurately represent some aspect (e.g. angles, area, etc.) of the sphere. Projecting to UTM preserves shape and direction, but distorts area and distance. We can use Tissot's indicatrix as a simple tool to visualise the distortion across a map. This involves drawing circles of consistent size at the center of each cell prior to projection, and examining the shape/area of those circles after projection. Here's one for the Mercator (90-degree rotation of the Transverse Mercator that you are using). You can see that while the shape of the circle is maintained after projection, the area varies markedly across the map. I assume your reason for projecting is to ensure equal area cells in order to prevent background sampling bias towards high latitudes. As UTM is a conformal projection, not an equal-area projection, I'm not sure that it's the right way to go. On the other hand I'm not familiar enough with projections to know whether it makes a difference at the scale of your study, either. I find it challenging to understand projections, and because I don't understand them fully, I would be inclined to leave the grids in lat/lon and correct for biased background sampling with a bias grid based on changing cell area.

[John B]

I should add, though, that interpretation of unprojected output grids (i.e. Maxent's output) requires the same consideration of varying cell area.

[xxtraloud]

Thanks guys very useful information. I did not realize what was
happening with the output cell size because arcmap used the default
value of the input raster which I assumed it was okay.
Regardless now the model is working and makes it very easy to prepare
the data. But now I am running into another problem.
I get the message "outside of bounding box"
I have projected all my worldclim data in WGS 84 utm 35s. I have
checked the rows and columns of my ASCII files and they match. The
only thing that puzzles me is that when I open one of the ASCII files
in arcmap and also my sample points they do not match. But if I open
them separately they are in the right spot. Obviously my samples
coordinates are in decimals. Can someone please help, I am rather
confused. I was under the impression that it was preferable to project
the environmental data before using it as an input in maxent.

Thanks again for the help

On Mar 14, 6:02 pm, John B <j.baumgart...@pgrad.unimelb.edu.au> wrote:
> I should add, though, that interpretation of unprojected output grids (i.e.
> Maxent's output) requires the same consideration of varying cell area.
>
>
>
> On Thursday, 15 March 2012 09:58:55 UTC+11, John B wrote:
>
> > It seems Marwa has beaten me to it, but here goes anyways...

> > *
>
> > 1.* Worldclim data units are degrees, so it seems you are working with 30

> > arc-second data. When projecting to UTM, your output grid will be in
> > meters. By specifying an output cell size of 0.0083333, you are in fact
> > instructing ArcGIS to give you a grid with cell size 8.3mm, so it's no
> > surprise it's crashing! When you set it to 1000, you are asking for an
> > output grid with 1km resolution.
>

> > *2.* I suspect that the Worldclim data is at least 16-bit signed, at

> > least for temperature grids which are expressed as temp*10 and therefore
> > the range of values allowed by 8-bit signed (i.e. -128 to 127) would be
> > insufficient. That said, I'm not sure why you're losing bit-depth. I'd
> > perform each step of your model in turn, manually, and inspect the outputs
> > to find out where this reduction in bit-depth is occurring.
>

> > *3.* Prepare yourself for a long-winded answer: Degrees of longitude

> > shrink from about 100km wide at the equator, to infinitely narrow (i.e. a
> > point) at the poles. However, cells in a lat/lon grid are all depicted as
> > equal size, so the area they represent must differ from north to south.
> > Because of this variation in cell size across your input grid, you can't

> > create an output grid that has *exactly* the same cell size. You could

> > make your cells have more-or-less exactly the same height as your input
> > grid, i.e. 0.0083333 degrees. Assuming the datum that you've used (WGS 84),
> > one degree of latitude (height) is 111319 m, so you would specify an output
> > cell size of 111319 * 0.0083333 = 928 m. Cell width will be now also be 928
> > m, which is slightly different to that of your input grid, depending on
> > location (cell width of the input grid would vary from ~928 m at the

> > equator to cos(*x*) * 928 m at latitude *x* (e.g. ~914 m at 10 degrees

> > latitude). As you can see, the difference is pretty trivial. For
> > simplicity, people would typically just project to a 1 km grid if using 30"
> > input data.
>

> > *On another note:* Usually we project a grid to more accurately represent

> > some aspect (e.g. angles, area, etc.) of the sphere. Projecting to UTM
> > preserves shape and direction, but distorts area and distance. We can use
> > Tissot's indicatrix as a simple tool to visualise the distortion across a
> > map. This involves drawing circles of consistent size at the center of each
> > cell prior to projection, and examining the shape/area of those circles

> > after projection. Here's one<http://en.wikipedia.org/wiki/Scale_(map)#Mercator_projection>for the Mercator (90-degree rotation of the Transverse Mercator that you