[GRASS5] Asking about feasibility of an addition to r.recode

[Glynn Clements]

Michael Barton wrote:

> I¹m involved in a project to develop a linkage between agent based modeling
> platforms and GRASS. One item that seems will be very important is way to
> change a group of cell values (i.e., cat values) given their xy coordinates.
> I realize that it is possible to use the map calculator to create a new map
> with 1 new cell changed. But AFAICT, there is no way to send a set of xy
> values, along with new cat values for each xy pair and change cells in an
> existing map or create a new map with the changed cells (and old values for
> the rest of the cells).

If you can create a raster map containing only the new cells, with
null elsewhere, you can patch it together with the old map to get the
updated map. In 5.3, the first step could be done with s.in.ascii +
s.to.rast; does v.in.ascii + v.to.rast not work with points?

> Markus suggested that I run this by the developers
> list. I can make this a formal Œwish¹ if it helps.
> 
> >From the perspective of someone who is fairly ignorant of C, it seems to me
> that the (conceptually at least) easiest thing to do is to alter r.recode to
> accept input (stdin or text file) in the form of
> 
> x1,y1,val1
> x2,y2,val2

r.recode doesn't seem like a significantly better match than any other
raster processing tool. IMHO, this should be a separate tool rather
than a modification to r.recode.

> or even better, if we want to keep a similar format to that now used for cat
> value recoding
> 
> x1:x2:y1:y2 val1
> x3:x4:y3:y4 val2
> 
> where x1:x2 defines a range of x coordinates and y1:y2 defines a range of y
> coordinates. This way single cells or blocks of cells could be referenced
> and changed. This mode would probably open up a number of new modeling
> possibilities within GRASS too.
> 
> This mode could be controlled by a flag. What do you all think? Is this
> feasible? Is it fairly easy or fairly difficult? Is there a better way to
> change a group of cell values based on their xy coordinates?

The implementation is straightforward enough, at least for individual
pixels. Primarily, the input list needs to be sorted in descending
order of y coordinate (i.e. ascending row numbers), so that the map
can be processed one row at a time.

For rectangles, the process is similar, but you need to maintain a
list of "active" rectangles (those which intersect the current row).
The list would need to be sorted in order of the top edge.

I wouldn't make it read an existing map, just write out nulls for
cells which aren't defined by the input. r.patch can be used to update
an existing map if desired.

The main problems I foresee is feature creep. If you support points
and rectangles, you will end up getting requests to add circles,
lines, polygons, etc. There will always be a point at which the
specific tool is inadequate and you need to import your updates as a
vector map then rasterise it with v.to.rast.

-- 
Glynn Clements <glynn at gclements.plus.com>