Glynn Clements wrote:
Markus Metz wrote:
Do you really mean "360 degrees plus the width of the window"? That
would be max 720 degrees?
Wrong window ;)
I'm talking about the buffer/kernel/etc "window", i.e. the size=
parameter for r.neighbors, 4 cells for r.proj method=cubic, etc.
E.g. for r.proj method=cubic, you need 360 degrees plus 4 cells.
Oh, that window :-)
The status quo is to restrict the width of the
current window to 360 degrees, maximum possible extends are 180W to
180E. So you say the current status quo is problematic?
It means that modules which operate upon a moving window cannot create
output which fully covers 360 degrees. Such modules need a full window
of non-null cells to generate a non-null result, so they leave a
half-window border of null cells on each side of the region where the
window bounds stray outside of the region bounds.
Two stupid questions:
1) If the resampling method only needs the values of the moving window,
can't you use a temporary array where you feed all the cell values in
and assume NULL when no cell value is available (e.g. outside current
region window)? Such a temporary array would not be bothered with the
region window, resampling can be done in that array and the resulting
value for the target cell put back to the array/structure used for
writing the output map.
2) If the resampling method needs the full map in memory (also applies
to segmented mode), I think RST needs that, I have the same question as
for question 1) only that now the array needs to have (region window +
resampling window) size in both dimensions (rows and columns).
Sorry, I haven't followed your work on resampling, so I don't know if
this can work at all.
The region used by the libraries defaults to the contents of the WIND
file (or WIND_OVERRIDE or GRASS_REGION), but can be changed by the
code. Code can even change it back and forth while operating, e.g.
r.resamp.{interp,stats} set the region to the input map's native
resolution for reading and the current (WIND) resolution for writing.
This is still what I mean with computational window, be it set by the
user or by the module. I haven't looked it up, but assumed that when a
module calls G_set_window(), also when using WIND_OVERRIDE,
G_set_window() checks if the requested window is legal, in case of
latlon if it is within the 180 lon and 90 lat limits.
I know you want to get r.resamp.{interp,stats} right, but I'm really
more interested in the vector handling. Because 1) I think you will
succeed and I'm far from knowing enough to help you in any way with that
and 2) the vectors are a bit neglected since Radim Blazek left (I'm not
stepping on anybody's feet?) so I start nagging a bit ;-) Here too I
don't know enough to make useful (precise) suggestions for the
libraries, but I'm looking for opportunities to improve them, and this
latlon 180 degree limit is one such opportunity. In my experience vector
operations really work much better when the coords stick to these
limits. My initial complaint about the datum border is obsolete, I
learned that the datum border is not a problem, for both raster and
vector operations.
Markus M
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
