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

[GRASS GIS]

#1385: r3.in.ascii man page improvements
-------------------------+--------------------------------------------------
 Reporter:  hamish       |       Owner:  grass-dev@…              
     Type:  task         |      Status:  new                      
 Priority:  normal       |   Milestone:  6.4.2                    
Component:  Docs         |     Version:  svn-develbranch6         
 Keywords:  r3.in.ascii  |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------
Changes (by hamish):

  * platform:  Linux => All
  * type:  defect => task
  * cpu:  x86-64 => All


Comment:

 Thanks, I was a bit mixed up, both top-bottom, and north-south.

 Actually now that I inspect it closely my data was already oriented upside
 down with SW corner first (this is Fortran output, maybe that's why the r3
 code was that way? ...oops, the fortran code comments even tell me the 'j'
 output will inverted. ISTR from matlab weirdness that fortran data arrays
 are ordered in memory first by column (not by row), but I'm pretty sure
 that is a different matter and irrelevant here)


 So yes, r3.in.ascii does as the man page says and wants n-s flipped data,
 and the main point of my bug report is invalid-- changing the ticket
 description and continuing on as a "improve man page" task.


 I'll change the help page example to read:
 {{{
 ,y3,
 ,y2,
 ,y1,
 ,y3,
 ,y2,
 ,y1,
 ...
 }}}

 and does this sound ok for the r3.in.ascii help page:

 {{{
 The bottom z-level is given first, the top z-level is given last.
 Thus the first data value in the ASCII input file refers to the SW
 corner of the bottom-most z-level, and the last data value in the
 ASCII file refers to the NE corner of the top-most z-level.
 }}}
 ?


 Soeren wrote:
 > r3.out.ascii and r3.in.ascii convert the upper left corner
 > in a lower left corner
 ...
 > I don't know why it was implemented using this behavior, because
 > this is not slice compatible to r.out/in.ascii.

 for grass7, should we change that to remove the flip row conversion?
 I guess we would add a "version: grass7" to the header for those and issue
 an error if the version line is missing?  G_fatal_error("Please add a
 `version: grass6` line to the header if it is from an earlier version of
 GRASS")


 > 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 agree, that must be wrong. (maybe the flipping was added mid-design?)
 But we could keep that text in the grass7 version if we decide to
 (un)invert the rows there.
 [It was a bit hard to understand at first, the word "One" should really be
 "Single"]


 re. flipped levels:
 > 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?

 my data was giving the top level first, but r3.in.ascii wants the bottom
 level first. So r3.out.vtk is fine, PBKAC. I can easily fix that with
 r3.to.rast and then r.to.rast3 with the level map order reversed.


 ----
 some more questions / ideas for grass7 before cleaning up the r3.in.ascii
 man page:


  * re. the type={float|double} option -- there is no CELL version for G3D
 rasters?


  * precision: default, max, 0-52
  -- if double is used, any point to go beyond %.15g (or %.16g) ?

  for *._in_.ascii why does it matter? shouldn't that be a function of
 type=CELL,FCELL,DCELL? shouldn't that option just be applicable to
 *.out.ascii?


  * nv: make the default "*" to match other grass ascii module convention?


  * compression: I can't remember, and r.compress doesn't mention it:
   was lzw ever reenabled after the patent expired?


  * tiledimension: this does override the values in the file header? does
 it obviate the need to give header values for rows,cols,levels?



 cheers,
 Hamish

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