[GRASS5] 5.7: most r3.* modules included

GRASS GIS GRASS GIS developer
1

Hi,

most r3.* modules are present now in GRASS 5.7
(in the new raster3d/ directory)
     r3.in.ascii r3.info r3.in.v5d
     r3.mask r3.null r3.out.ascii
     r3.out.v5d r3.timestamp

For now I left r3.mapcalc out because the Makefile is
not to be written straightaway. And once we talked about
the idea of extending the new 2D r.mapcalc to a
3rd dimension with #defines to optionally compile
it with two or three dimensions. As far as I remember
basically all loops have to be extended to additionally
browse the z direction.

If the expected time to extend the new 2D r.mapcalc to a
3rd dimension would be predicted with > 2 month, I
suggest to include the old r3.mapcalc.

Markus

PS: the old s.vol.rst is now called v.vol.rst

2

Markus Neteler wrote:

For now I left r3.mapcalc out because the Makefile is
not to be written straightaway. And once we talked about
the idea of extending the new 2D r.mapcalc to a
3rd dimension with #defines to optionally compile
it with two or three dimensions. As far as I remember
basically all loops have to be extended to additionally
browse the z direction.

If the expected time to extend the new 2D r.mapcalc to a
3rd dimension would be predicted with > 2 month, I
suggest to include the old r3.mapcalc.

It shouldn't take more than a week at most, and probably just the time
taken to learn the relevant bits of the G3d API plus a day to
implement.

FWIW, this is the list of functions which need to be changed to their
G3d counterparts:

evaluate.c G_unopen_cell
evaluate.c G_window_cols
evaluate.c G_window_rows
main.c G_get_window
map.c G_close_cell
map.c G_find_cell2
map.c G_get_raster_row
map.c G_open_cell_old
map.c G_open_raster_new
map.c G_put_raster_row
map.c G_raster_map_type
map.c G_read_cats
map.c G_read_colors
map.c G_read_history
map.c G_short_history
map.c G_write_cats
map.c G_write_colors
map.c G_write_history
xcoor.c G_col_to_easting
xcoor.c G_row_to_northing

Essentially, I intend to move G_get_window() to the top of execute()
in evaluate.c, then produce 3d versions of evaluate.c, map.c and
xcoor.c.

I/O will need to use cached mode, although that should eliminate the
need to use rowio.

Also, G3d provides equivalents of G_{read,write}_{cats,colors}, but I
can't find anything related to history; does G3d not support map
histories?

From the perspective of the build system, it would be better to
unconditionally build src/libes/g3d, then build r.mapcalc and
r3.mapcalc simultaneously.

--
Glynn Clements <glynn.clements@virgin.net>

3

> For now I left r3.mapcalc out because the Makefile is
> not to be written straightaway. And once we talked about
> the idea of extending the new 2D r.mapcalc to a
> 3rd dimension with #defines to optionally compile
> it with two or three dimensions. As far as I remember
> basically all loops have to be extended to additionally
> browse the z direction.
>
> If the expected time to extend the new 2D r.mapcalc to a
> 3rd dimension would be predicted with > 2 month, I
> suggest to include the old r3.mapcalc.

It shouldn't take more than a week at most, and probably just the time
taken to learn the relevant bits of the G3d API plus a day to
implement.

can this wait until after 5.3.0 is released?

Hamish

4

Hamish wrote:

> > For now I left r3.mapcalc out because the Makefile is
> > not to be written straightaway. And once we talked about
> > the idea of extending the new 2D r.mapcalc to a
> > 3rd dimension with #defines to optionally compile
> > it with two or three dimensions. As far as I remember
> > basically all loops have to be extended to additionally
> > browse the z direction.
> >
> > If the expected time to extend the new 2D r.mapcalc to a
> > 3rd dimension would be predicted with > 2 month, I
> > suggest to include the old r3.mapcalc.
>
> It shouldn't take more than a week at most, and probably just the time
> taken to learn the relevant bits of the G3d API plus a day to
> implement.

can this wait until after 5.3.0 is released?

Too late; I've just committed an update to r.mapcalc to support 3d
volumes. Testing would be appreciated.

Building src/raster/r.mapcalc3 will now generate both r.mapcalc and
r3.mapcalc. r3.mapcalc uses the 3d region and reads and writes G3d
volumes, but is otherwise identical to r.mapcalc.

Almost everything is shared, except that there are 3d versions of
map.c (the core map-handling functions), xcoor.c (the x(), y() and z()
functions) and xres.c (the ewres(), nsres() and tbres() functions).

Some points to note:

1. The two programs accept the same language, with the same set of
functions. Using the third dimension in r.mapcalc has reasonable
(IMHO) behaviour: z() and tbres() always return NULL, depth() always
returns 1, and using the third dimension in a neighbourhood modifier
(i.e. map[x,y,z] where z is non-zero) will always return 1. IOW, a 2d
map is essentially treated as a 3d map where depths=1 and the region's
top/bottom are NULL.

2. G3d doesn't support integer values. Input maps are always float or
double; creating a map from an integer-valued expression will result
in it being promoted to double.

3. There doesn't appear to be a G3d equivalent of G_unopen_cell(),
which is used to "uncreate" a map if an error occurs.

4. I've just remembered that this won't work on 64-bit platforms yet;
I fudged the fact that G3d uses void* for handles (as opposed to int
for libgis) by stuffing the void* into an int. If
sizeof(void*)>sizeof(int), you lose. This will be fixed in due course.

--
Glynn Clements <glynn.clements@virgin.net>

5

On Tue, May 11, 2004 at 08:19:09AM +0100, Glynn Clements wrote:
[...]

Too late; I've just committed an update to r.mapcalc to support 3d
volumes. Testing would be appreciated.

Great - impressive response time! Thanks for your efforts.

Building src/raster/r.mapcalc3 will now generate both r.mapcalc and
r3.mapcalc. r3.mapcalc uses the 3d region and reads and writes G3d
volumes, but is otherwise identical to r.mapcalc.

Almost everything is shared, except that there are 3d versions of
map.c (the core map-handling functions), xcoor.c (the x(), y() and z()
functions) and xres.c (the ewres(), nsres() and tbres() functions).

Some points to note:

1. The two programs accept the same language, with the same set of
functions. Using the third dimension in r.mapcalc has reasonable
(IMHO) behaviour: z() and tbres() always return NULL, depth() always
returns 1, and using the third dimension in a neighbourhood modifier
(i.e. map[x,y,z] where z is non-zero) will always return 1. IOW, a 2d
map is essentially treated as a 3d map where depths=1 and the region's
top/bottom are NULL.

A related question: A long-standing wish was to have access to 2D maps
within r3.mapcalc (old version). Does the new implementation permit
to access 2D and 3D raster at the same time?

Background idea: get amount of rainfall from 2D map, then feed the
volume model to percolate the water within the volume using these
"seed" cell values.

2. G3d doesn't support integer values. Input maps are always float or
double; creating a map from an integer-valued expression will result
in it being promoted to double.

3. There doesn't appear to be a G3d equivalent of G_unopen_cell(),
which is used to "uncreate" a map if an error occurs.

4. I've just remembered that this won't work on 64-bit platforms yet;
I fudged the fact that G3d uses void* for handles (as opposed to int
for libgis) by stuffing the void* into an int. If
sizeof(void*)>sizeof(int), you lose. This will be fixed in due course.

Maybe Jaro or Helena have a comment here, they are closest to the
original development/developers.

Markus

6

Markus Neteler wrote:

A related question: A long-standing wish was to have access to 2D maps
within r3.mapcalc (old version). Does the new implementation permit
to access 2D and 3D raster at the same time?

I had thought about that. But there would need to be some way to
indicate whether a name referred to a 2d or a 3d raster.

Alternatively, a separate program to convert a 2d raster to a 3d one
should suffice. [Presumably it would only need to be one "depth" high;
G3d should resample it to the current region, right?]

--
Glynn Clements <glynn.clements@virgin.net>

7

On Tue, May 11, 2004 at 05:15:26PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> A related question: A long-standing wish was to have access to 2D maps
> within r3.mapcalc (old version). Does the new implementation permit
> to access 2D and 3D raster at the same time?

I had thought about that. But there would need to be some way to
indicate whether a name referred to a 2d or a 3d raster.

Alternatively, a separate program to convert a 2d raster to a 3d one
should suffice. [Presumably it would only need to be one "depth" high;
G3d should resample it to the current region, right?]

Yes, it might be better to keep that separated.

A parameter to define which "layer" in the volume to populate
with values would be needed.

Markus