Request for r.edit

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

[neteler]

Code from d.rast.edit could be recycled (say, take relevant code to library level and use in both modules).

Markus

[glynn]

Replying to 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.

[cmbarton]

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.

Michael

[marisn]

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.

[glynn]

Replying to 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.