[GRASS-dev] Re: [GRASS GIS] #1385: r3.in.ascii man page improvements
GRASS GIS
trac at osgeo.org
Sat Jun 11 13:10:54 EDT 2011
#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>
More information about the grass-dev
mailing list