[GRASSLIST:9686] Re: r.proj - painfully slow or bug? (Cygwin, latest 6.1 CVS)

[Glynn Clements]

Robert Kuszinger wrote:

> Is it normal that r.proj is running for an hour on a 9M raster data
> (from UTM to EPSG:23700) with nearest neighbour?

No.

> Grayscale DTM.
> 
> I don't know if it is working at all or simply frozen or buggy?
> 
> 
> I'm running Grass61 in Cygwin on a 1.4 MHz Pentium M Dothan with 1GB RAM (IBM TP R51)
> 
> Where to check for temporary files or how to get a progress information?

It doesn't create an temporary files. It prints progress information
during the actual projection, but you aren't getting that far.

> It displays this (see between lines), processor is running at 100% and nothing else happens....
> 
> -----------------------
> GRASS 6.1.cvs (magyarorszag):/cygdrive/m/grass > r.proj input=dk_cut location=latlong resolution=100 
> 
> Input Projection Parameters: +proj=latlong +no_defs +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000
> Input Unit Factor: 1
> 
> Output Projection Parameters: +proj=somerc +lat_0=47.14439372222222 +lon_0=19.04857177777778 +x_0=650000 +y_0=200000 +no_defs +a=6378160 +rf=298.247167427
> Output Unit Factor: 1
> -----------------------------

The next step after this is to trace the border of the current region
back to the source location in order to determine the portion of the
source map which needs to be read into memory.

It then projects the border of that region back to the target location
to determine the portion of the target location which actually needs
to be computed.

One of those two steps appears to be taking an excessive amount of
time. The most likely reason for that would be that one of the two
regions has an excessively fine resolution. Note that the resolution=
option doesn't affect this process, only the actual projection.

Check the region resolution for both the source and destination
mapsets.

Ian MacMillan wrote:

> Robert, you want to make sure that your region in the target location 
> is set to the same size as the raster coming in.  If your region is 
> bigger than the raster, then that blank space needs to get interpolated 
> as well.  The easy way to do this is to create a vector of the region 
> you want to project with v.in.region in the original location.  Project 
> that into your target location with v.proj (usually an ~instantaneous 
> projection) run from the target location.  Set your region in the 
> target location to that raster, g.region vect=projected_vector.  You 
> might need to change the resolution manually.  Then run r.proj.

r.proj already does this optimisation, unless you explicitly disable
it with the -n switch.

Specifically, it projects the boundary of the current region back to
the source location, and clips the projected boundary to the bounds of
the source map to determine the portion of the source map which will
actually be read. It then projects that back to the target location to
determine the portion of the target location which actually needs to
be computed.

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