[GRASS-dev] latlon support

[Glynn Clements]

Markus Metz wrote:

> >> How about reversing the current policy? Restrict both raster and vector 
> >> maps to the 180 degree lon and 90 degree lat limit, that avoids 
> >> duplicate features within a map. Allow the region to be set anywhere 
> >> between -360 and 360 lon but restrict the width of the computational 
> >> region to 360 degrees lon to avoid duplicates.
> >>     
> >
> > That is problematic for computations which use a window (e.g. 
> > r.neighbors, r.proj, r.mfilter etc) on a whole-earth map. For that,
> > you need 360 degrees plus the width of the window.
> >   
> 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.

> 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.

> This limit 
> applies to the computational region, a module is free to override that 
> for internal calculations, but as soon as a module calls 
> G_put_raster_row(), the current computational region is respected, right?

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.

It's debatable whether you would want to do this in the case where
you're enlarging the window for the above reasons. It would be simpler
and more efficient to just generate a map which is slightly larger
than the current region, given that the excess will consist entirely
of null cells.

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