Re: Swarm and GIS libraries

[Dr. Paul Box]

> <snip>
> 
> >> You are right - this is a quite fundamental distinction between the
> >> GIS and Swarm way of "looking at the world" - is there a way of
> >> reconciling the two? Any ideas folks have out there?
> >> 
> >I figure that modeling the landscape from the pixel up is the best way to do 
> >this.  I especially look forward to discussing this with people who think
> the 
> >idea is off the wall.  I hope that many beers will be downed over this
> subject!
> > 
> Not off the wall as such, it looks like a cool way of doing things, for the
> right data sets.  But it looks a bit memory hungry when we start to deal with
> coverages that are polygon based, or even noncontinuous point coverages.
> Would each cell for example have to record the fact that it is NOT a tree?
> 
> Cheers 
> James (who really should get swarm installed :-)
> 
 
Yes, the idea is memory-hungry to almost criminal proportions.  That is my 
biggest gripe about representing GIS data in swarm at the present times.  One 
problem that this has for continuous polygons is that the cells that are inside 
the polygon (completely surrounded by cells of a like value for that variable) 
are carrying information that may not be used-- that variable will sit 
unchanged 
throughout the course of the simulation, doing nothing but take up space.  For 
aspects of the landscape that are continuous and homogeneous (the assumptions 
that a polygon makes), I guess that it could be feasible to have borders 
delimited in the area and assume that all pixels inside the boundary contain a 
like value for that variable.  This could possibly be coordinated with a vector 
GIS's libraries.  The equivalent dialogue to the pixel from a GIS object might 
be something like "you don't need to carry a variable with this value, but if 
anyone asks, I will tell them that you have "X".

I haven't given much thought to an object functioning in this capacity, though 
I 
don't see why it couldn't work.  It would be more cumbersome to code, but the 
potential payoff in freeing memory could be great.

As for non-continuous point coverages, and especially how a tree would be 
represented:  right now, I have each pixel object with a list of variables, 
each 
variable representing some aspect of the landscape that overlays it.  It would 
be easy enough to have a variable "tree", stating the presence or absence of a 
tree in that pixel (or what kind of tree, age, or anything else for that 
matter).  In the simplest form, all the other pixels with no trees would then 
have its "tree" variable set to 0 or null.  Again, this is a memory pig.

One potential solution I am considering is having the number of variables that 
a 
pixel object carry be dynamically expandible during the simulation.  Then, as a 
pixel-object is queried, the agent that wants to know about it's tree would 
first ask if a "tree" variable exists.  If it exists, it would then proceed to 
find out the vital information about that tree.  In perl, this would be done 
using hash tables.  When I posted a query to the group about this recently, I 
got suggestions that I use a dynamically expandable array instead for 
implementing this in objective-C.  It seems like a good idea, I just haven't 
got 
around to doing it yet.  I hope that these are the kinds of things that will 
come about as the code is released to the user community.

Cheers

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