[GRASS-dev] Principle G3D library question

[Soeren Gebbert]

Dear developer,
i have a principal question regarding the coordinate system in the g3d library.

I currently review the g3d code and related modules to get a clear
picture of the order of the underlying coordinate system. It looks
like different approaches have been developed in the modules and the
g3d library. This is very confusing. I will try to harmonize this, so
here is my question:

What kind of coordinate system should be used in the g3d library?

>From my point of view: the original authors implemented the idea of a
cube coordinate system starting in the lower left (SW) corner. This is
the common cube coordinate system used in a wide range of software.
BUT this coordinate system uses a different row order than the raster
coordinate system which start in the upper left corner. Later
development of the g3d library tried to establish the upper left
corner as origin, but this messed up the code base and result in
confusion about the correct coordinate transformation and row
ordering.

I currently try to reestablish the lower left (SW) corner approach
using the common x, y, z cube coordinate system. The code works fine
and many tests have been implemented to assure correct behavior. BUT
the result is that volume maps created with several modules before
these changes have now flipped rows. AND the g3d cube coordinate
system is not row compatible with the raster coordinate system. For
example:

g.region b=0 t=1 s=0 w=0 e=120 n=80 res=10 res3=10 tbres=1

r.mapcalc --o expr="raster_map = row()"
r3.mapcalc --o expr="volume_map = row()"

This code will result in raster and volume maps with different row
counting. The raster lib counts rows from north to south but the g3d
lib counts from south to north.

#: r.out.ascii raster_map
north: 80
south: 0
east: 120
west: 0
rows: 8
cols: 12
1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 2 2 2
3 3 3 3 3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4 4 4 4 4
5 5 5 5 5 5 5 5 5 5 5 5
6 6 6 6 6 6 6 6 6 6 6 6
7 7 7 7 7 7 7 7 7 7 7 7
8 8 8 8 8 8 8 8 8 8 8 8


#: r3.out.ascii volume_map dp=0
version: grass7
order: nsbt
north: 80.000000
south: 0.000000
east: 120.000000
west: 0.000000
top: 1.000000
bottom: 0.000000
rows: 8
cols: 12
levels: 1
8 8 8 8 8 8 8 8 8 8 8 8
7 7 7 7 7 7 7 7 7 7 7 7
6 6 6 6 6 6 6 6 6 6 6 6
5 5 5 5 5 5 5 5 5 5 5 5
4 4 4 4 4 4 4 4 4 4 4 4
3 3 3 3 3 3 3 3 3 3 3 3
2 2 2 2 2 2 2 2 2 2 2 2
1 1 1 1 1 1 1 1 1 1 1 1

Booth modules export the data in the raster coordinate system printing
the rows from north to south.

What i don't know:
Is the row ordering irrelevant for g3d internal value storage, tile
storage and tile cache coordinates? So only coordinate transformation
functions should take care of correct counting? So all g3d modules can
use the raster coordinate system using x, y, and z coordinates and
interact with raster modules in the same coordinate system: "row ==
y":

         Top (z)
            |
            |     North
 West  | _ _ _ _ _ _ East (x)
           / Bottom
         /
       /
  South (y)

Or does the row ordering affect the internal g3d storage and caching
too and should always count from south to north??? So any module which
interacts with raster rows need to translate the y coordinate into the
correct raster row:  "row = rows - y - 1"?

I prefer the last solution (which i currently implement) to avoid
potential conflicts with the (by myself not fully understood) storage
and tile caching in the g3d library and to have a well understood and
consistent behavior:

   Top (z)     North (y)
          |       /
          |     /
          |   /
West | / _ _ _ _ _ _  East (x)
    Bottom     South


Maybe i am to blind to see the obvious?

Any hints or suggestions are very welcome.

Best regards
Soeren