There is an alternative to the Georectifier in the wxGUI, available in
6.4.1 and above, which has all the functionality of the Georectifier,
all features (as far as feasible) of i.points, and some new features,
including a manual. The new wxGUI GCP Manager also addresses the
tickets 142, 220, 686, 687, 688, 989, 1076. I have included Michael
Barton and Martin Landa as authors for the new GCP Manager because
even if the code base is quite different by now, the module has been
developed using the Georectifier as starting point.
Therefore I would vote for dropping the Georectifier and have only one
wxGUI module to set and manage GCPs.
Markus M
Hi,
2010/10/13 Markus Metz <markus.metz.giswork@googlemail.com>:
Therefore I would vote for dropping the Georectifier and have only one
wxGUI module to set and manage GCPs.
+1
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
this is a quick question, probably for Martin:
am I right that the nviz_cmd versions in GRASS64 and GRASS65 have some differences
that will make scripts written for the nviz_cmd in 64 fail in GRASS65 (and other way around)?
in particular,
grass64 wants 3 coordinates for position, eg.: position=0.50,0.9,0.00
while grass65 wants only two and in reverse order?
and there are other differences.
Perhaps the changes should be backported to GRASS64 to avoid issues with scripts that use nviz_cmd
or nviz_cmd should be disabled in 64?
Martin, would it be difficult for nviz_cmd to take the saved nviz state file as input
(or a 3Dview file) for at least some of the parameters ? It would make nviz_cmd
much easier to use, although even without it, nviz_cmd is a great tool for creating 3D animations.
thank you,
Helena
Hi,
2010/10/21 Helena Mitasova <hmitaso@unity.ncsu.edu>:
grass64 wants 3 coordinates for position, eg.: position=0.50,0.9,0.00
while grass65 wants only two and in reverse order?
and there are other differences.
Perhaps the changes should be backported to GRASS64 to avoid issues with scripts that use nviz_cmd
or nviz_cmd should be disabled in 64?
done in r44214.
Martin, would it be difficult for nviz_cmd to take the saved nviz state file as input
(or a 3Dview file) for at least some of the parameters ? It would make nviz_cmd
much easier to use, although even without it, nviz_cmd is a great tool for creating 3D animations.
I will take a look.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
We are trying to work with some volume data and we haven't been able to find a module that
would actually create a color file for grid3d.
Apparently nviz reads the colors from the color table if it is present
http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/lib/ogsf/Gvl3.c
and the G3D library provides functions for color support
http://grass.osgeo.org/programming6/g3dlib.html
G3D Color Support
Applications can use the standard grass functions to work with colors, except for the file manipulations.
int G3d_removeColor(char *name) Removes the primary and/or secondary color file. See G_remove_colr for details.
Returns always 0.
int G3d_readColors(char *name, char *mapset, struct Colors colors) Reads color file for map name in mapset into the colors structure. See G_read_colors(Raster_Color_Table) for details and return values.
int G3d_writeColors(char *name, char *mapset, struct Colors colors)Writes colors stored in colors structure into the color file for map name in mapset. See G_write_colors (Raster_Color_Table) for details and return values.
but there is no r3.color (based on r.color?) and rather surprisingly v.vol.rst does not create a color file (as v.surf.rst does),
neither do r.to.rast3 or v.to.rast3 (those probably are OK to use the default colors).
I assume that writing or copying a color file into the relevant grid3d directory would work (I can try it out),
but that is not a solution for normal users - I am wondering how difficult it would be to write r3.color module,
to make the colors on 3D rasters adjustable
Helena
just a follow up that copying a suitable color file to the given grid3 file directory works
and creating a pretty complex visualization with cut-off slices and isosurfaces was surprisingly easy
(there is apparently a small bug in the GUI when entering the value for isosurface - it does not
allow me to type anything until I accept it empty and re-open it - other than that it worked great).
This was with the Tcltk nviz - as far as I remember slices are not supported in wxnviz yet.
Suzanne, I will email you more details on how to modify your colors,
Helena
(attachments)
