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

[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          |  
-------------------------+--------------------------------------------------

Comment(by huhabla):

 Replying to [comment:2 hamish]:
 ...
 > 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.
 > }}}
 > ?

 Thats fine.

 >
 > 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")

 I think we should support several different formats of data ordering in
 r3.out.ascii and r3.in.ascii:
   * north-south bottom-top order as default (nsbt)
   * south-north bottom-top order (snbt) -> the current standard
   * south-north top-bottom order (sntb)

 A new header entry "order:nsbt" will specify the storage structure. So two
 new leading header lines can be added:

 {{{
 version:grass7
 order:nsbt
 north:...
 south:...
 }}}
 In case the new header lines are not present, the old order scheme is
 assumed and imported by r3.in.ascii. This will make it backward
 compatible. A new option can be added to r3.out.ascii: "order" with values
 "nsbt, snbt, sntb" and the flag -b to create "backward compatible" grass6
 ascii output using the snbt order without the new header lines.

 What do you think?

 >
 >
 > > 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?#

 No, the type CELL is not present. Only FCELL and DCELL.

 >
 >
 >  * 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?

 The precision value is the number of digits used as mantissa in the
 internal storage 0 -23 for float and 0 - 52 for double -> this is only
 relevant for compression and NULL data handling.

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

 Good idea.

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

 No clue.

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

 No, the tile size is used for internal storage and does not affect any
 header information. G3d uses a (cached) tile based approach rather then a
 row based approach. This allows arbitrary value access when tile caching
 is enabled ... which is really cool.


 Best
 Soeren

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