[GRASS-dev] Re: [GRASS GIS] #1385: r3.in.ascii man page vs. r3.in.ascii source code

[GRASS GIS]

#1385: r3.in.ascii man page vs. r3.in.ascii source code
-------------------------+--------------------------------------------------
 Reporter:  hamish       |       Owner:  grass-dev@…              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.2                    
Component:  Docs         |     Version:  svn-develbranch6         
 Keywords:  r3.in.ascii  |    Platform:  Linux                    
      Cpu:  x86-64       |  
-------------------------+--------------------------------------------------

Comment(by huhabla):

 Hi,
 the internal addressing of voxel data in the g3d lib is equal to the
 raster library in x,y coordinates -> the counting starts at upper left
 corner. The depths are counted from the bottom to the top. All modules
 which i have implemented following this approach.
 You need to look deep in the code, because this behavior is not explicitly
 documented, but this code from the g3d lib makes it clear:

 {{{
 void
 G3d_getRegionValue(G3D_Map * map, double north, double east, double top,
                    void *value, int type)
 {
     int row, col, depth;

     /* convert (north, east, top) into (row, col, depth) */

     row = map->region.rows -
         (north - map->region.south) / (map->region.north -
                                        map->region.south) *
 map->region.rows;
     col =
         (east - map->region.west) / (map->region.east -
                                      map->region.west) * map->region.cols;
     depth =
         (top - map->region.bottom) / (map->region.top -
                                       map->region.bottom) *
         map->region.depths;

     /* if (row, col, depth) outside window return NULL value */
     if ((row < 0) || (row >= map->region.rows) ||
         (col < 0) || (col >= map->region.cols) ||
         (depth < 0) || (depth >= map->region.depths)) {
         G3d_setNullValue(value, 1, type);
         return;
     }

     /* get value */
     map->resampleFun(map, row, col, depth, value, type);
 }
 }}}

 r3.out.ascii and r3.in.ascii convert the upper left corner in a lower left
 corner, including confusing comments.

 r3.in.ascii conversion code:
 {{{
 for (y = region->rows - 1; y >= 0; y--) /* go south to north */
 }}}

 r3.out.ascii conversion code:
 {{{
 for (y = rows - 1; y >= 0; y--) {       /* north to south */
 }}}

 I don't know why it was implemented using this behavior, because this is
 not slice compatible to r.out/in.ascii. But the r3.out.ascii manpage says
 this:

   One level maps can be imported with r.in.ascii (Raster 2D) after
 removing
   the header lines "top", "bottom" and "levels".

 which is obviously wrong?

 >I also notice that r3.out.vtk exports celldata with the data south-up
 within the ascii.vtk file, but I'm not sure if that is part of the VTK
 design, or the export module flipping what it doesn't actually have to. ??

 This is VTK design. The corner of VTK image data is lower left.

 >tangent: I don't know Paraview well enough to reliably say which way
 'should' be up there. The first thing I notice in Paraview 3.8.0 after
 loading the data, apply, Display|Style->representation,Surface +
 Color->Color by->layer name is that the top level is on the bottom and the
 bottom layer is on the top. again in the display tab setting
 Transformation->Scale->z to -1 makes it ok, but it gets very dark, as if
 it is all in shadow. (test data is cube containing 0/1 boolean values,
 similar to what r.to.rast3elev would create from a 2.5D DEM for land/air.
 I'm still struggling to visualize that well in NVIZ or paraview.) ??or
 perhaps I set top: and bottom: backwards in the r3.in.ascii header?
 r3.to.rast shows level 0001 as top layer, level 25 (of 25) as bottom
 layer. (data is all below sea level)

 In case r3.out.vtk is used for Paraview data export, the data should have
 a correct coordinate system, no shifting or mirroring is needed.
 Maybe the input data is flipped?

 Best
 Soeren

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/1385#comment:1>
GRASS GIS <http://grass.osgeo.org>