Ticket #1385 (new task)
r3.in.ascii man page improvements
|Reported by:||hamish||Owned by:||grass-dev@…|
the man page for r3.in.ascii (6.5svn) states:
Note lower-left (SW) corner of the bottom level comes first! This array format, where EW is preserved but NS is flipped, is some-times known as "ij" coordinates. This is opposite to r.in.ascii's format, which places the SW corner at the beginning of the last row of data.
but then shows data format example like:
,y1, ,y2, ,y3,
(although I think I might have added that :)
and importing data with NW corner as the first bytes of the file, then r3.to.rast to split into layers seems to successfully display north-up. So either the man page or the r3.in.ascii code has got it backwards..?
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. ??
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)
ps- don't try searching in trac for r3.in.ascii, as it treats the r3 as svn rev3 which is almost every file in the grass 5 source code! The web browser does not enjoy it.