Re: Swarm and GIS libraries

[Dr. Paul Box]

Hi Group

I am very excited to see all this discussion on swarm and GIS.  I have been 
playing around with this for a while, with lots of dead ends and a few 
successes.  

My first attempts at bringing GIS data into swarm was using the most loosely 
coupled way available.  I simply dumped the ascii values of a raster coverage 
into a file, and read the values into a grid2d and had agents wander around on 
top of that.  When it came time to have multiple coverages, I tried making a 
series of grid2ds, with the agent consulting each grid as it made its decision 
on where to move about.

This approach had two disadvantages.  1- representing a raster coverage as a 
series of integer or floating point values increases by orders of magnitude the 
        
size of the coverage (I had a 500k grass layer turn into a 17Meg ascii file!), 
and the way swarm is currently written, all of the values that are in the 
grid2d 
have to go into active memory (or swap). The second disadvantage,  having a 
series of grid2ds for each layer, is that all my attempts at having each agent 
consult each relevant layer at each step produced very ugly and unsatisfying 
code.

I then tried the grass2d code that Jim Westervelt released (this was announced 
early on in this swarm-gis list).  This had the advantage of reading grass data 
layers directly, but the resulting surface that the agents run around on is 
still interpreted as a series of integer or float values on a grid2d; this 
again 
becomes very large and needs to live in the active memory of the computer 
running the simulation.  I currently see no easy way to get around this.

I have been working on my own swarm-gis libraries here at USU.  I had funding 
for about two months to hire a technician to help with the coding, and we have 
produced a sample application using agents that run around in a 2d space that 
is 
initialized with values from GIS datafiles.  The funding ran out for that 
technician a couple of months ago, and I have been trying to finish the coding 
job myself between my other duties here, and scrambling for whatever funding 
source to be able to continue this work.  I will be unveiling these libraries 
at 
the swarmfest this year, and later at the RT conference in Toronto in April.

The code requires substantial revisions before it is available for release.  
For 
the truly eager and curious, I will make what I have available to those who 
contact me privately.  The essentials of what I have been working on are as 
follows:

--The difficulty of having a grid2d have more than one value per cell is 
problematic in this setup.  I have resolved this by having each cell contain an 
object: the object can then have variables representing the value of each data 
layer that overlays that object.  This allows for any arbitrary number of data 
layers (coverages) to be contained in a single grid2d.

--The objects occupying the grid cells also contain functions for interpreting 
the various datalayers they contain.  This allows each cell to do it's own 
"overlay" functions (express values that are recombinations of the various 
original data layers).  This places the responsibility for this on the cell 
instead of the GIS package.

--The objects also have functions for exchanging data with neighboring cells.  
This allows the rasters to have CA-like functions.  I currently have a 
"nonsense" function that has grass from one cell encroaching into neighboring 
cells when the environmental conditions suffice.  I have every intent of 
applying this to real-world data.  This would be a nice tool for having 
diffusion processes, such as groundwater or fire, be simulated.

--The agents, when running around on this surface, get placed into 
pixel-objects 
instead of actual grid2d locations.  By being associated with the object, the 
object can tell the agent where it is (getXY).  This allows for more than one 
agent to occupy a cell when needed.  This also allows the agents to modify the 
values of the pixel-object.  If (hypothetically) the agent is a cow and the 
surface represents a pasture, the cow can eat and trample the grass, compact 
the 
soil, and even deposit fertilizer on top of it (sorry) before it moves into the 
next cell.  The cell can then grow its grass back according to its modified 
state.


I wil discuss this more as requested.  However, there are a couple of 
conclusions I have come to while working on this.

1- The current data model of the GIS is essentially top-down (a series of 
layers 
overlayed on top of one another).  This seems incompatible with swarm's 
bottom-up formulation of things.  I find it much more interesting to model 
individual cells in the GIS, and let the cell be responsible for itself.  Many 
landscape processes can then come out as emergent processes.

2- This model is limited to small datasets (small areas and/or coarse 
representations of the landscape).  To apply this to larger areas, swarm needs 
an ability to take advantage of the data compression that raster GISs use.  
This 
is pretty much out of my ken, though someone else may find this a 
straightforward problem.

I intend to release this to the swarm community as soon as I have the code 
stabilized somewhat, and enought documentation to allow users  to start working 
on it.  I intend to follow the 'bazaar' style of development (for those of you 
who read 'the cathedral and the bazaar' a couple of weeks ago).

I am very eager to discuss this more at swarmfest and via email for whoever is 
interested.

Cheers or whatever

                  ==================================
   Swarm-GIS is for discussion of Geographical Information Systems (GIS)
   and their integration or use with Swarm.  For list administration
   needs (esp. [un]subscribing), please send a message to
   <address@hidden> with "help" in the body of the message.
                  ==================================