#169: Request for r.edit
-------------------------+--------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Keywords: |
-------------------------+--------------------------------------------------
I'd like to request a module with a suggested name of r.edit. This would
let you specify an existing map to edit, and then specify the xy
coordinages, cat, and optionally label of a cell to change. Preferably,
the input parameter would accept a list of
x y cat [label],x y cat [label],x y cat [label],...
so that multiple cells could be changed. I realize that you can accomplish
this with r.in.poly and r.patch and have even made a script to do it.
However, it is a clunky work around, slower than directly changing values,
seems to have some difficulties in maintaining labels for fp maps. This
could be used to create a nicer raster digitizer and can be used by ABM's
and other modeling scripts developed in Python and other OO languages.
Replying to [ticket:169 cmbarton]:
> I'd like to request a module with a suggested name of r.edit. This would
let you specify an existing map to edit, and then specify the xy
coordinages, cat, and optionally label of a cell to change. Preferably,
the input parameter would accept a list of
>
> x y cat [label],x y cat [label],x y cat [label],...
>
> so that multiple cells could be changed.
Specifying the label is bogus. The category is a property of the cell, but
the label is a property of the category. You can't have two cells with the
same category but different labels.
> I realize that you can accomplish this with r.in.poly and r.patch and
have even made a script to do it. However, it is a clunky work around,
slower than directly changing values, seems to have some difficulties in
maintaining labels for fp maps.
r.in.xyz and r.patch would seem more suitable.
Also, note that r.* modules don't generally modify maps "in-place"; they
create new maps based upon existing maps. There are some exceptions, but
these are usually low-level administrative utilities such as r.null and
r.compress.
Also, there's no performance benefit to in-place modification. The
underlying libraries don't actually support in-place modification; you
have to create a completely new map then replace the existing map upon
completion.
Too bad that there is no way currently to modify a raster in place. If ABM
simulations could be carried in the much more realistic landscape of a GIS
like GRASS, instead of the much more limited cellular landscapes of ABM
platforms, the number of raster cells being altered by agents is usually
much lower than the number of landscape cells (100's to 1000's of agents
vs. 100,000's to 1,000,000 landscape cells). In a program like GRASS that
is optimized to manage such large cellular landscapes, such simulations
could be carried out MUCH faster than now possible (as well as in a more
realistic setting). An ability to modify individual cells in place on the
basis of their position (rather than their current value) would help move
in that direction.
Seems like nobody is going to create such module within 6.x lifetime.
Bumping up to 7.x. Should be written after raster map modification in-
place is possible.
Replying to [comment:4 marisn]:
> after raster map modification in-place is possible.
That's just verbose way of saying "never".
The only cases where we allow in-place modification of rasters (r.null,
r.region, etc) are to facilitate multi-stage creation, where the actual
data is created first then the support data is created with subsequent
commands.
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Seems like nobody is going to create such module within 6.x lifetime.
Bumping up to 7.x. Should be written after raster map modification in-
place is possible.
If you're talking about d.rast.edit, it has already been re-written in
wxPython.
AFAICT, the "r.edit" concept was intended to be perform in-place
modification similar to v.edit.
I have no idea why we allow in-place editing for vectors, and I don't
see any reason to allow it for rasters (especially given that it would
only work for uncompressed rasters, which are hardly ever used).
On Nov 16, 2008, at 3:51 AM, Glynn Clements wrote:
Michael Barton wrote:
This already exists in GRASS 6 for TclTk.
It needs to be redone in wxPython for GRASS 7.
If you're talking about d.rast.edit, it has already been re-written in
wxPython.
My confusion. Thanks for clarifying it.
Michael
AFAICT, the "r.edit" concept was intended to be perform in-place
modification similar to v.edit.
I have no idea why we allow in-place editing for vectors, and I don't
see any reason to allow it for rasters (especially given that it would
only work for uncompressed rasters, which are hardly ever used).