[GRASS-dev] ascii export and import, large file problem

[Glynn Clements]

Gerald Nelson wrote:

> > I'm not sure what you're using to perform the projection, but r.proj
> > uses the region settings which the user specifies. If you set a region
> > with rectangular pixels, you get rectangular pixels.
> > 
> > Admittedly, there isn't any automatic mechanism to adjust the region
> > bounds to get square pixels; you have to calculate the bounds
> > yourself. If you don't do this explicitly, you're likely to end up
> > with rectangular pixels.
> > 
> > [If you use "g.region res=...", GRASS will divide the region extents
> > by the resolution to get the number of rows and columns. These values
> > will then be rounded to the nearest integer, and the actual n-s and
> > e-w resolutions computed by dividing the extents by these integers.]
> 
> As an economist, I'm learning that a little GIS information can be a
> dangerous thing ;-)
> 
> I was under the impression that you automatically ended up with
> rectangular pixels if you projected square lat long pixels to say utm. 
> Although I also noticed that arcgis doesn't do that.

If you apply most cartographic projections to straight lines, you end
up with curves. IOW, not only are projected squares not square, they
aren't even rectangles, or even quadrilaterals.

Obviously, that isn't a particularly good fit for raster data. So,
what r.proj (and most other raster projection tools) do is to
inverse-project the centres of the destination cells into the original
coordinate system, and sample the source data at the projected points.

The end result is that the projected raster has the exact grid which
the user specifies via g.region.

> Is there any way GRASS could be modified to force pixel dimensions to
> be the same in the output raster as in the input raster, at least as
> an option?

No. "same size" isn't meaningful when one set of data is in degrees
and the other is in metres (or occasionally US survey feet).

What *would* be possible would be to add an option to g.region to
adjust the extents rather than the resolution. This would make it
straightforward to get square cells without having to manually
calculate appropriate bounds.

Uh; hang on; this is what "g.region -a" does (although it has a
side-effect of shifting the grid slightly). If you use e.g.
"g.region -a res=119.05", you should get cells which are exactly
119.05x119.05m.

-- 
Glynn Clements <glynn at gclements.plus.com>