Re: some GIS links and comments

[Alex Lancaster]

>>>>> "CD" == Catherine Dibble <address@hidden> writes:

CD> GRASS, like Idrisi, is limited to raster-only, is no longer free,
CD> and was never particularly user- or developer- friendly.  So I
CD> have trouble seeing advantages in pursuing this.  But that's only
CD> my two cents re GRASS, and perhaps someone closer to GRASS may
CD> care to comment?

Is the source code still available?

>> * totally-decoupled: * loosely-coupled: * highly-coupled:

CD> There is an enormous literature on integration and
CD> interoperability between GIS and complementary analytical and
CD> modeling software.  See, for example, papers in GIS/LIS Conference
CD> Proceedings or _GIS World_, and NCGIA Technical Papers (online
CD> list available at:
CD> http://www.ncgia.ucsb.edu/pubs/publications.html), especially
CD> Initiative 6.

I'll look into these URLs, thanks.

CD> Two things to note:

CD> (a) It isn't necessarily a choice between decoupled,
CD> loosely-coupled, OR highly-coupled, so much as a question of
CD> obvious stages, and then how far it's worth to push the coupling
CD> process (I heartily second 80/20 here).

Absolutely. I certainly never intended this loose/high coupling thing
to mean an either/or choice, rather more of a loose staging or
possibly a vague outline of a time-line.

CD> For example, the obvious first step would be to write Swarm
CD> landscape objects that can read and write to/from some
CD> widely-available GIS formats.

On this note, one issue that appears to be cropping up, is the actual
handling of spatial data, given that some GIS simulations consume vast
quantities of data. Swarm, in its current form anyway, is just not cut
out to be able to slosh around the huge quantities of data in memory
[see Paul Box's recent post on this matter]. So how does the idea of
using some GIS as a "backend" to manage Swarm data sound - and how
plausible/possible?

CD> (b) Note here that it is file formats that are relevant, which may
CD> or may not map 1:1 to GIS platforms.  For example, Arc/Info reads
CD> a wide variety of file formats from raster (x, y, and a z data
CD> value for each cell) to vector, to network.

CD> Imho, Arc/Info and/or Idrisi raster layer formats would be an
CD> obvious place to start.

CD> Once we can read and also write GIS layers to and from Swarm, then
CD> individual modelers can begin to push the interoperability
CD> envelope with respect to degrees of model integration, frequency
CD> of update, calling GIS operations from Swarm or calling Swarm
CD> batch models from AML/AVENUE style GIS macros.

CD> Although my models are fairly formal and abstract for the time
CD> being (sanity!), my research focus is on modeling
CD> human-environmental interactions via Swarm.  So I have a long-term
CD> interest in allowing my agents to *change* their landscapes in
CD> ways that can someday coordinate with actual GIS layers.

This does seem to sit reasonably well with the current Swarm
conception, where space should be considered as just another kind of
"agent". In the current Swarm framework, agent-space co-evolution
(which is sort of what I think you are getting at) is really just a
special case of agent-agent co-evolution. The problem seems to be
where and how (in implementation terms) the management of that
information is done.

As currently space is just another agent (as is the current
implementation for the Ca2d class) then you can send it methods (such
as -stepRule). All of the data maintenance of this information is now
done inside the Swarm machinery. If a GIS package could be found that
you can write some kinds of global macros to a GIS data layer (say
something like a field of grass) and specific macros to particular
locations on that field of grass (where animals exist, for example)
then you might be able to get the best of both worlds.

<swarm hacker mode>

So, in a future implementation, maybe you could do something along the
lines of (excuse the pseudo-code for non-programmers out there):

@implementation Field

-setGISDataSet: ptr {
    fieldLocation = ptr;  // could be a socket 
    return self;
}

-setAnimalList: lst {
    animalList = lst;
    return self;
}

-stepRule {
    int x,y, weight;

    index = [animalList begin: globalZone];
    fieldLocation->_call_GIS_macro_GrowField;  // does GIS stuff remotely

    while ( (animal = [index next]) ) {

        x = [animal getX];
        y = [animal getY];
        weight = [animal getWeight];
        fieldLocation->_call_GIS_macro_DepleteField(x,y, weight);
                // more remote GIS activity
    }
    [index drop];
    return self;
}

@end

thus when creating the instance, you do something like this:

   field = [Field createBegin: [self getZone]];
   [field setGISDataSet: pointerToGISLocation];  
       // GIS location already has the spatial data "preloaded", 
       // say - this could also be invoked from Swarm with the right macro
   [field setAnimalList: list];   // put animals "on" the landscape
   field = [field createEnd];

</swarm hacker mode>

It seems to me that it comes down to an issue of "heavy" objects,
versus "light" objects. In general, "agents" like "animals" or "bugs"
in an ecology are "light" in a memory sense - current Swarm has no
problem dealing with a moderate number of agents inhabiting a large,
but threadbare space - in fact, it's the canonical example - just like
"heatbugs". 

The GIS issue really crops up when you starting giving the "space"
"agent" rich dynamics of it's own - Swarm in its current form - has no
inbuilt mechanism to handle a huge Cartesian spaces with fine grained
resolution of multiple layers of real-valued data at each point - this
would be truly a "heavy" agent. Nor should it, in my opinion, GIS
systems do this, and do it well - the trick is to figure out how to
"out-source" the data for a space "agent", in a way that can also
continue to maintain its "Swarm-ness".

The example I give above, is another off-the-top of my head,
handwaving-type attempt to solve this problem. In the example above,
the "Field" class itself would only maintain the information it need
to make the changes that the "Field" instance would need to undergo
and not all the spatial data itself. Essentially, I am "animating" the
"dead" GIS data layer, by wrapping it in Swarm.

That is, it would basically "perturb" the potentially huge data set
for the Field, which would remain inside the GIS system (which would
presumably have already been optimised for storage of such data in a
relational way). This might be a first approximation to co-ordinating
the "Swarm" concept of an agent with the "GIS" concept of a data
layer.

Is this totally way off beam or not? ;-)

  --- Alex

-- 
  Alex Lancaster         |   e-mail: address@hidden
  Swarm Developer        |      web: http://www.santafe.edu/~alex
  Santa Fe Institute     |      tel: +1-(505) 984-8800 (ext 242)
------------------------------------------------------------------

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