[GRASS-dev] latlon support

[Markus Metz]

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