Hamish and Helena, We have finally had an initial production test of methods to create a raster point using xy coordinates. If you remember, I've periodically whined a bit about the lack of a way to create and change a raster cell based on its xy coordinates instead of its cat value.
The 2 suggestions I got to work around this were to... 1) use r.in.poly to create the raster map; make an input file such that for each point, the input is set to line (L) with 2 points that are identical. 2) use v.in.ascii and then use v.to.rast to create the raster map. We are coupling an agent-based simulation to GRASS, such that the simulated land use activities will affect land cover, which in turn will affect a landscape evolution routine. Optimizing the speed of this is critical, and so we prefer to reduce the number of steps needed to accomplish this. This means that the r.in.poly approach is the one we prefer. However, in tests conducted today, we ran into an unexpected problem. If the coordinate of the point to be created happens to fall on a cell boundary, we get a 2-cell 'line' instead of a point even though the beginning and end points are identical. Apparently, r.in.poly looks for a cell center closest to end point one and then searches for a cell center for end point 2 that is different from the first cell, resulting in a 2 cell line. This does not happen if the point does not fall on a cell boundary. Attached is the raster file created from the following r.in.poly input. The first input creates the 2 yellow cells, the other 2 create the red and green single cells. L 592250.0 4924400.0 592250.0 4924400.0 = 40 household0 L 592362.0 4924531.0 592362.0 4924531.0 = 41 household1 L 592142.0 4924277.0 592142.0 4924277.0 = 43 household3 This is a potential problem, since an agent might not know that the the coordinates it chooses for a field to farm or graze like on a cell boundary. It is OK if r.in.poly substitutes the nearest grid cell center to make the raster point for the xy coordinates that the agent chooses, but not OK if it picks 2 different cells instead of one. The simplest solution is to allow r.in.poly to make points as well as lines and areas. I'm not sure why it doesn't allow points in the first place. It seems like an oversight. Is this difficult to implement? * * * * Also, there is still no one-step way to change a cell value based on its xy coordinates. You can change it based on its position relative to another cell, and based on its cat, but not its coordinates. Currently, the only way to do this is to create some cells (e.g., using r.in.poly) and then patch them back into the original map, overwriting it. This is not a problem for our own current modeling efforts, given the way we are doing it (making an impact map of agent landuse activities and using r.mapcalc to alter a land cover map accordingly), but it might help us better optimize the running of these models in the future. However, if there is interest in doing agent and cellular modeling within a GRASS platform, it will become necessary to be able to do this to simulate dynamics. Patching may simply not be practical for this kind of work. As Python becomes more used as a scripting environment, this is an attractive kind of application to build in Python, given its object oriented structure, and couple with GRASS. Looking ahead, I can see such modeling as having being increasingly important to researchers doing research in the social and natural sciences. Coupled with an OO language like Python, GRASS could be a real leading application in this area. So another whine from me about this. Michael __________________________________________ Michael Barton, Professor of Anthropology School of Human Evolution & Social Change Center for Social Dynamics & Complexity Arizona State University phone: 480-965-6213 fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton
impacts.png
Description: Binary data
_______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
