Basic types of dynamic objects

Open Landscape Simulator

• OLS Open Landscape Simulator

Vision for project (Eliot)

Produce a computing tool that facilitates the creation of landscape simulation models for ecological systems. Fundamental requirements:

• Using this tool, one can build a broad array of currently relevant (and with future interest) ecological simulation models that have fast execution time
• Easy to build a novel model (e.g., time between conceptual model and functioning simulation model is small)
• Is a Geographic Information System (i.e., it is more than soft import/export links to a GIS)
• Has a GUI with two functions:
  • Users can run simulation models with visualisation
  • Builders can build models
• Is flashy visually
  • Easy integration to Google Earth or other terrestrial 3D visualtion
• Has at 2 target users:
  • Model builders
    • Quantitatively minded ecologists
    • Consultants for the private sector
    • Governments
  • Model users
    • Non-quantitatively minded practitioners (e.g., foresters, consultants in natural resources)
• Can run other already developed models (e.g., FORECAST, LANDIS II) if they have APIs or some other way to run them in batch mode
• Has modular sub-models that can be used as needed

Types of models that must be able to be built:

• fire
  • mechanistic
    • driven by values of raster or vector GIS layers and/or functions
  • empirical
• harvest scheduling
• dispersal
• road building
• individual-based (agent based)
  • movement
    • correlated random walk
    • biased movement
    • immigration/emigration
  • territorial
  • social interactions
    • positive (social family structure)
    • negative (competition, territoriality)
• Time
  • Can be Calendar Time
  • Or Simulation Time
• Climate
  • Projections (simple ... realistic?)

Basic types of dynamic objects

Other attempts

Spatially Explicit Landscape Event Simulator--SELES

Makes it possible for non computer programmers to build simulation models. Yes, but are the base concepts behind?

• A domain-specific language for models of landscape dynamics 

What it does well? Simple versions of the above models are done fairly well.

• Contexts
  • Each variable has a context, so you don't have to explicitly state whether it has a spatial context, individual context etc.

What it doesn’t do well?

• Once you start to get more complex, then the built in structure starts to become a hindrance.
• It is raster based only.
• Unlike object-oriented softwares, it allow to mix code from different agent in the same block (right?).
• It is proprietary, closed source and does not allow extensions or bug fixing.

Repast

Repast  is a simulation package that includes a simulation controler allowing to define/save/reload simulation context, to stop/resume simulation and to export result in analysis packages like R or MatLab. Agent are implemented as Java objects into the Eclipse platform.

• Pros
  • Already a wide used agent based modelling platform with a lot of developpers.
  • Full object oriented (Three version: Java, .NET and Python).
  • Provide a sophisticated development environment (Eclipse). (probably too sophisticated)
    • Direct coding or using a point-and-click model development environment .
  • Provide a sophistificated GUI simulation controler able.
    • to export results to R, MatLAB, etc...
    • to pause and resume the simulation.
• Cons
  • Support GIS data import/export but is not really based on GIS concepts.
  • Need very good programmer skills to implement agents. You still have to code them yourself.
  • There seem to be no library of ready-to-use agents
  • The simulation can not be run outside of the simulation environment (to confirm)

What do we need?

Minimal user features

• Capability to execute simulation in graphical mode, command line mode (no gui) or batch mode (no gui)
• Run on Windows and Linux
• Easy replication of a simulation on multiple machines
• Easy visualization - 2D, 3D
• Easy description and parametrization of simulation models by non-programmers based on real entities (defined as shapefiles) and (optionally) on a real time scale.
• Easy importing/exporting of text files (CSV), GIS rasters (TIFF), GIS vector files (shapefile). Exportation should be possible at any time during the simulation.
• Optimization of parameters based on results of replicate simulations
  • e.g., dispersal distance is an empirical quantity, but to simulate an individual, you do not impose the dispersal distance, you let the individual disperse itself based on habitats and configuration limitations. Thus, dispersal distance becomes an emergent property that must be simulated to estimate.
• Provides simple, GUI-based, examples, needing little or no programming
  • a mechanistic fire spread model
  • an individual-based movement model with individual territories and dispersion

A R draft! You can change
the draft by editing this PowerPoint file ,
create a gif and upload it back.

Minimal developper features

• Easy debugging environment (breakpoints, variable inspection)
• Easy creation of new agents that are archivable in a R-like online library for reuse by modellers
• Easy object-oriented style extension of existing agents hierarchy (i.e. can build a "bird" or a "bear" agent from an "animal" agent, can build a "randomWalk" action from a "walk" action
• Ability to build low level functions for speed (in C or C++)

What Makes this Project Fundamentally Different from Others?

1. GIS Based - Few simulation package are based on GIS concepts. GIS people model the world as discrete vectors (point, line and surface) and as continous rasters surfaces. This package should draw on this principle (and possibly being itself integrated in an existing GIS - (GRASS!)) so that GIS people can easily understand the basic concepts underlying modeling and simulation. This would assure a HUGE user base that are familiar with GIS technology.
2. Reality Based - Many simulation packages allow the creation of entities in a totally virtual environment having no link with reality in a computer based calendar not linkable to the gregorian calendar. This package should allow simulation of environment based on empirial (GIS) data on a real timeline (the gregorian calendar).
3. Collaborative and Reusable Component Agents - Few simulation package allow reuse of component entities (agents) developed by others. This package should make it easy to integrate entities developed by other modellers into our own model through a a R-like collaborative online library of entities (agents). Agent should be adaptive enough to recognize element in the target model they can interact with and configurable enough so we can activate/deactivate some of their properties/behavior (or actions).

Base Models to Develop for a First Prototype

1. Butterflies (as a vectorial point layer flying through a vectorial or a matricial landscape)
2. Fire diffusion (as a vectorial surface (or a matricial?) layer evolving through a matricial landscape)
3. Population genetic flow (?)

What is the best language to meet our needs?

JAVA

• Questions
  • Is it supported by GRASS?
    • There is a JGRASS  version in development. It is built over Eclipse .
• Pro
  • One of the most well know language
  • Object oriented
  • Provide access to GRASS and R routine via JGRASS and JRI.
• Cons
  • Too slow? Some people pretend it is not slower than C++ in certain cases.

R

• Pros
  • Provide access to GRASS (also 6.x) through the "spgrass6" package.
  • Can be object oriented using the R.oo package.
  • Does not provide a sophisticated development environment for debugging.
• Cons
  • Processor intensive routine would have to be implemented in C or C++.

Object-oriented programming in R - Useful readings

• Chap. 5 of R Language definition 
• Introduction to Data Types and Objects in R 
• Section 3 and 10.9 in An Introduction to R 
• Statistical programming with R, Part 3: Reusable and object-oriented programming 
• The Definition of Generic Functions and Methods 

What is the best platform to meet our needs?

GRASS

• Pros
  • Provides a useful series of geographical commands.
  • Provide a classical GIS environment.
  • Links with R.
  • SWIG  interface to Perl, Python, ... (SWIG also used in GDAL)
• Cons
  • Do not provide a developement environment (IDE).

What's needed? Some folks are using Eclypse as far as I know

JGRASS

• Pros
  • Give access to GRASS primitives through JAVA.
  • Provide a classical GIS environment.
• Cons
  • Might not provide access to R (to confirm).

ArcGIS

• Pros
  • The most popular GIS with a large user base.
  • Provide a classical GIS environment.
  • Provide a development environment (VBA).
• Cons
  • Does not link with R.

Eclipse

• Pros
  • A full featured development environment.
• Cons
  • Maybe too sophisticated for our intents.

Architecture Options

OLS as a R ABM Package Based on GRASS
You can change the draft by editing this PowerPoint file ,
create a gif and upload it back.

1 - OLS as a R ABM Package Based on GRASS

Characteristics

• Modelling Language: R
• Development Language: R & C
• Data Model: GRASS database
• Display Engine: GRASS

Pros

• The modeling language (R) is well known by many ecologists, social scientists
• Thousands of already implemented spatial and statistical algorythms through R packages
• Many spatial algorythms already implemented in GRASS
• All the modular and distribution advantages of R

Cons

• GRASS GUI not very user friendly
• Limited to the GRASS data model and format (since GRASS only operate on this format)
• Bad object orientation (?)
• Bad memory mangement
• Bad Distributed Computing (?)

OLS as an ABM Extension to QGIS Using PostGIS and WKT Raster
You can change the draft by editing this PowerPoint file ,
create a gif and upload it back.

2 - OLS as an ABM Extension to QGIS Using PostGIS and WKT Raster

Characteristics

• Modelling Language: Python
• Development Language: Python, R & C
• Data Model: PostGIS database
• Display Engine: QGIS
• Variant: GRASS as Data Model

Pros

• The modeling language (Python) is a bit known by ecologists and social scientists
• Thousands of already implemented spatial and statistical algorythms through R packages
• QGIS user friendly GUI
• Benefits from the new WKT raster Raster Object for modeling variable object like fires

Cons

• Not as many spatial manipulation services already implemented (WKT Raster in development)

OLS as a JAVA framework on top of R and GRASS
You can change the draft by editing this PowerPoint file ,
create a gif and upload it back.

3 - OLS as a JAVA framework on top of R and GRASS

Characteristics

• Modelling Language: Java
• Development Language: Java, R & C
• Data Model: GRASS database
• Display Engine: GRASS or Java
• Variant: PostGIS as Data Model

Pros

• Thousands of already implemented spatial and statistical algorythms through R packages and GRASS
• Highly Object Oriented modelling language
• Multi-threading
• Easy Distributed Computing

Cons

• The modeling language (Java) is not known by ecologists and social scientists
• Many GUI components to develop

OLS as a framework over Repast
You can change the draft by editing this PowerPoint file ,
create a gif and upload it back.

4 - OLS as a framework over Repast

Characteristics

• Modelling Language: R?
• Development Language: R & C
• Data Model: Repast?
• Display Engine: ArcGIS?

Pros

• Well known modelling environment
• Connect to R (and GRASS)

Cons

• The modeling language (Java) is not really known by ecologists and social scientists

Student Questions

1. We know OLS will be used by ecologists, consultants, government officials and foresters. Are there any other significant users we should know about? Yes, and we need to remember that there are 3 levels of user expertise...

1. Model User - no coding ability at all - can change parameters in a already created model
2. Model Developer - some coding ability, primarily in R or GRASS, good knowledge of GIS, minimal capacity to write in JAVA, or other low level programming language. Primarily these will be researchers or consultants or students learning modeling, e.g., graduate courses.
3. Model Framework Developer - the folks at École Polytéchnique or other software developers

2. Are there any standards involved in this project? We don't know what you are referring to. The likely answer is no.

3. It is quite evident that a project of this magnitude needs some form of documentation. What type of documentation would be needed and with what level of detail? (web site, doxygen, commented code, installation guide, readme files, user guide) web site, wiki project web site, commented code, installation guide, user guide, readme

4. It is mentioned that the system must run on Linux and Windows. Which version of Windows and Linux distribution would be preferable? XP, Vista, 7 and debian (though it should be others too)

5. In the same context, are there plans to use different Operating Systems in the future? no plans

6. To give us an idea of the usabillity of this software, could you tell us the expected duration of coding a simulation, running a simulation and running a batch of simulations?

• coding - days to weeks
• running - seconds to days
• batch - 10,000 times the running

7. Similarly, could you tell us the general level of computer knowledge of the average user of this system? Who will be this average user? (Undergraduates, Graduates, Professors?) Will users have already used a similar software? Model Developer will be Graduates, Professors, Technicians

8. In the ongoing questions section of the wiki, there is a question in regards to what kind of GUI should be used that is never answered. What kind of GUI is desired? A true GUI, a passive GUI or a command line interface? GUI – 3 types of graphical functionality

1. DYNAMIC RENDERING GUI - Maps and graphics (HIGH PRIORITY)
   1. Needs to be able view maps
   2. Needs to be able to view graphics of summaries (e.g., aspatial numbers, spatial quantities)
   3. Realtime visualization of these things (zoom in, out, pan, all maps)
2. PARAMETER GUI - a place where parameters can be changed, maps, etc... here the model is fixed (LOW INITIAL PRIORITY – HIGH FINAL PRIORITY) e.g., HexSIM
3. MODEL BUILDING GUI - A visual graphical way to specify a model (such as STELLA) (LOW PRIORITY)

9. Are you aware of some kind of constraint? (for example : computer's hardware) processors, RAM, interactions between R and GRASS, e.g., data sharing, manipulating, dynamic displays, interactions with other softwares (ARCGIS, GoogleEarth etc.)

10. Certain criterias such as speed are already expected from this project. Are there any other quality criterias we should know about sush as user friendliness, fault tolerence and security? The user type described above will largely determine user friendliness. Security is not seen as a problem. Flexibility to design new models Extensibility to add new components Open Source Documented Should be able allow faults, which indicate that the model is not correct

11. In the wiki, a base time frame is mentioned, but never defined. What is the smallest possible time frame? This is arbitrary, and should not matter. In practice, I have never thought it necessary to go smaller than a few seconds. Traditionally, this is on a positive real numbers time scale.

12. During the phone meeting, possible outputs were mentioned. What kind of information should be in these output files? (Birthrates, death rates, etc) Any properties of every object must be able to be produced for static or dynamic:

• graphical plot (i.e,. a figure one would see in a scientific paper)
• map
• other files that are transferable (e.g., txt, xls, dbf, csv)

13. Integration with Google Earth is also mentioned. How exactly do you envision this integration with Google Earth? To do the second type of output from question 12... ideally dynamic, but could be static

14. It is also mentioned that OLS will have modular sub-models that can be used as needed. Could you better define the notion of sub-model? What is the difference between a fully-fledged model and a sub-model? This distinction is a bit arbitrary. A model is the "whole thing" that is defined by a single Discrete Time Simulator. It can have many components (sub-models), such as objects, each with actions and schedules, and possibly other types of components (e.g., cellular automota, diffusion processes). Thus a given model can be potentially integrated into a second model if they are incorporated into the same Discrete Time Simulator.

15. In regards to time, just a clarification: you want the possibility to seamlessly switch between Calendar Time and Simulation Time? What exactly is Simulation Time? In a given "model", it is likely to be only one of these types of Time. However, we should be able to build a model using either.

16. In the minimal developper features section, the ability to build low level functions for speed in C or C++ is listed. How exactly do you envision this in the context of OLS? The term "Function" is an abstraction of a biological or statistical phenomenon, in this context. So, there will be some "Functions" that exist in R or GRASS already (such as random walk or random number generators). If we come across a "Function" that does not exist in R or GRASS, we will need to build it. This can initially be done in R or GRASS by the Model Developer or Model Framework Developer. If it needs to execute quickly, it will be necessary to build this "Function" in C or other low level language. NOTE: This capability already exists in R and GRASS, so it is not necessary to change this.

17. In the "What makes this Project fundamentally different from others" section, the second point is that OLS will be "Reality Based". What are the caracteristics of a reality based software? Is using a gregorian calendar and GIS data sufficient to make it "Reality Based"? Yes, as long as the data come from a real place.

18. In the open questions section, it is asked if we can run simulations without passing through the GUI simulation controller. What is the GUI simulation controller? By this, we meant both the DYNAMIC RENDERING and PARAMETER GUIs, or just the without the DYNAMIC RENDERING,

19. In the wiki, we saw that there were basic actions for fires and animals(spread or movement). Is there any other significant actions we should know about? These are two KEY types. There may be 10s or 100s of others. The idea is that new actions can be added easily as needed.

20. In the wiki: Could you define the whole Entities section? This section was not complete. It has been deleted.

21. In the wiki, there is an action that is defined as Succession that occurs at regular time intervals. Can this action be considered a major one similar to the Spread and the Movement actions? Yes. These all things that describe change. Some will have a spatial component (like spread and move), some not (like grow older, mate, reproduce)

22. In the wiki , there is a second type of succession that is described: The large scale succession. How is does this type of succession differ from the Individual based succession? Wouldn’t this type of succession occur automatically if the individual succession was processed on each individual? You are correct. However, sometimes, there is not enough data to describe individual-based succession. So we take a whole aggregate of many individuals and cause them all to do the same thing. This can be computationally essential if the spatial scale is large (e.g., 1000 km2... describing the change of every tree would be impossible).

23. In the wiki, there are a few events that can happen to entities, but the lists always end with "etc". What are all the possible events that can affect entities? Events are Actions. These are the ones that we just mentioned... spread, move, age, mate etc. There will be hundreds or more. The OLS framework is there to ease the creation of these actions.

24. In the wiki, there is a section about preferences that define the way some actions are taken. It mentions possible interactions without really defining them. (near and see are mentioned, but no other possibility is mentioned) How do you want these preferences to be modeled? We are currently debating these preferences, and it may be removed. Essentially, all objects will interact with their spatial and temporal environment (e.g., GIS layers, other objects) and there will be relationships between the environment and the action that they take. Example: a caribou will move more slowly through dense forest than through open forest.

25. During the phone meeting, the notions of individuals and groups were mentioned. Could these notions be clarified? This is just a way to say that there can be a hierarchy of objects. Higher levels of the hierarchy can have different actions than the lower levels.

26. In the wiki, you mention that building a new model should be easy and that the time between a conceptual and a functioning simulation model should be small. What do you mean by small? days to weeks. See question 6.

27. OLS should also be able to run simulations with already existing models (FORECAST AND LANDIS II are mentioned). How exactly are these models defined? Are they some type of code in a particular language or more of a list of attributes and equations? Don't worry about this at this point. We just want to be able to eventually run other models (e.g., by a shell command) built using other simulation packages (there are hundreds) and read the outputs of that model.

28. There is a list of models that should be able to be built. Is the dispersal model in the list linked with the Spread action from the other document? What is harvest scheduling? How is road building a simulated model? Dispersal is an action, spread is an action, harvesting trees is an action, road building is an action. Each of these and all other actions will be performed by objects, following rules defined in the object attributes, according to a schedule defined in the object attributes.

29. In the Pros and Cons of existing softwares section, it is mentioned that REPAST supports GIS data import and export, but is not really based on GIS concepts. What do you mean by being "really based on GIS concepts"? The REPAST connection to existing GIS software is fairly limited, and it has rudimentary GIS functionalities on its own.

30. In the minimal user features section, one of the important features is that it should be easy to replicate simulations on multiple machines. What exactly does this mean? A simulation model (i.e., a "model") has randomness built into it. Thus, to find out the average or extreme values that would come from the simulation, you need to run it many times. This is sped up if it can be distributed across many computers and processors. If a single simulation takes 10 minutes and we want 20,000 done, it will take too long on one processor. This can also occur if some of the parameters used to describe actions are not known. Thus, we can try simulations with some values and then try others, and find the ones that give us a result that is closest to reality. This is called optimization.

31. It is also mentioned that exportation should be possible at any time during the simulation. How exactly do you want this? A planned exportation after X number of steps defined at the beginning of the simulation or some kind of "Export Button" that can be pressed at any time during the simulation? Both. The button is lower priority.

32. There is also an explanation of "Optimization of parameters based on results of replicate simulation". Could you re-explain this since we don't quite understand the given explanation? See answer to 30.

33. The final product's purpose is to run simulations of different models. Could you tell us the possible range (upper bound) of elements present in a simulation? (such as the number of animals) The maximum number of agent objects so far that we have run is 200,000. But we can imagine 2,000,000 or more (arctic caribou herds). Rasters can be 100,000,000 pixels or more.

Here is a complete list of possible qualities, try to place them in order of importance :

Model Developer

• User friendliness ease of model development
• Performance

extensibility

• Evolvability
• Reusability
• Portability from one machine to another?
• Interoperability with R, GRASS, GoogleEarth

Model Framework Developer

• Verifiability
• Robustness
• Correctness
• Reliability

NOT seen as highest priorities

• Safety
• Repairability
• Understandability
• Productivity
• Size
• Timeliness
• Visibility
• Maintainability

34. In the wiki, we had a list of needs. Is this list complete? And if not, could you give us an exaustive list of your needs? This is what we have so far. We will try to put together a section of priorities for the summer 2009.

35. A use case is a series of actions taken by the user of a software that results in a certain desired behavior.

Example: ATM withdrawal:

• User inserts his bank card
• User enters his PIN
• User selects the withdrawal option from the menu
• User enters the amount to be withdrawn
• User enters his birthdate
• User picks up the withdrawn amount
• User picks up his bank card

Could you give us a complete list of use cases that describe the software?

Model User

• Run simulation
• Get results
• Examine results
• Change parameters
• Rerun simulation
• Re-get results etc.

Model Developer

• Conceive of type of model to build
• Examine existing models as a Model User
• Select model that is closest to required needs
• Change some parts of the code in R, GRASS or "OLS language" (e.g., add an agent, change schedule, add actions, implement new actions, change types of parameters, etc.)
• Run and debug simulation (via visualization, and data produced)
• Calibrate simulation with external, independent data
• Validate simulation with external, independent data (not the same as for calibration)
• Then become Model User and follow Model User use case actions

Model Framework Developer 2 types of actions:

1. Develop OLS
   • Design and spec this framework, with all the functionalities,
   • code it
   • debug it
   • document it
2. Extend OLS to include new functionality
   • Gets requests from Model Developer to extend functionality in R or GRASS
   • Code in R, GRASS or low level language
   • Debug it

36. Could you give us an initial taxonomy of entities? And, for each entity, could you give us the relevent proprieties? (behavior and activities)

• Object: Wolf
  • 2 types of actions that are dependent on its age (a property of the wolf agent)
    • Adult (age > 2)
      • Actions: Reproduce
    • Juvenile (age <= 2)
      • Actions: Correlated Random Walk (this is a function that exists in R or GRASS already)
        • They move faster or slower according to the value of the Habitat Suitability Map Object
• Object: Habitat Suitability Map
  • Action: None

Next step ... there will be other complexities to add as we advance

37. Could you clarify the relation between Spread, Movement and Succession, if any? These are each actions that will potentially be performed by different objects.

37. What would be the constraints on output representation? ?

38. What is the role of R or any other statistics package in OLS? All actions are defined in the R language, with potential calls to GRASS. It has 1000s of mathematical and statistical functions, can call GRASS, can run compiled code etc. We do not want to recode any functionality unless it does not exist in R or GRASS. If there is some functionality that does not exist, then it should be written such that R can use it. R is not just for statistics; it is the basis for all actions and objects.

Interesting links

Keywords: agent-based simulation, simulation, ecology, landscape, GIS, GRASS, SELES

Research Projects

• SEED  use SELES
• Dynamic Spatial Modelling  use SME
• GEM  use ??
• Agent-Based Models in Ecology  use COIN
• JDEVS 

Research Groups

• Duke's Nicholas School of the Environment and Earth Sciences - Landscape Ecology Laboratory 

Softwares

GRASS versions

• JGRASS 
• GRASS simulation packages  (page a bit outdated, see also mailing lists)

Java Development Environments (IDE)

• Eclipse 
• JSWAT 
• NetBeans 

Lightweight Java Development Environments (IDE)

• Jenuity 
• DrJava 
• Java Tools 
• TJI 
• BlueJ 
• jEdit 
• tIDE 
• Cube-J 

Major Simulation Frameworks/Packages/Softwares

• SELES 
• Repast  | A guide on Repast 
• Spatial Modeling Environment  (SME) - This project seems to be death since 2004 .
• Swarm 
• Mason 
• Cormas 
• NetLogo 

Minor Simulation Frameworks/Packages/Softwares

• SimEcol 
• RAMAS GIS 
• GEAMAS 
• MadKit 
• Ecopath with Ecosim 
• EcoSim 
• POP-II and POP-III 
• Sugarscape 

Journals

Ecology oriented

• Ecological Modelling 
  • Multi-agent simulations and ecosystem management: a review 
• Ecological Informatics 

Environment oriented

• Environmental Modelling & Software 
  • Conceptualization and implementation of a multi-agent model to simulate whale-watching tours in the St. Lawrence Estuary in Quebec, Canada 
• Environmental Software 

GIS oriented

• Transactions in GIS 
  • Special Issue on GRASS 
  • GRASS GIS-embedded Decision Support Framework for Flood Simulation and Forecasting 
• Simulation 

Other Interesting Articles

• Principles and Concepts of Agent-Based Modelling for Developing Geospatial Simulations 
• Agent-based Simulation Platforms - Review and Development Recommendations 
• Multi-Agent Systems for the Simulation of Land-Use and Land-Cover Change: A Review 
• Multi-Agent Simulation within Geographic Information Systems 
• Design and Application of an Object-Oriented, Web-Based, Model/Game System for Exploring Ecosystem Responses to Management Options. 
• A GISenabled Distributed Simulation Framework for Natural Resource Management 
• Eclpss: a Java-based framework for parallel ecosystem simulation and modeling 
• Modélisation et simulation multi-agent 
• Pattern-Oriented Modeling of Agent-Based Complex Systems: Lessons from Ecology 
• Towards a Community Framework for Agent-Based Modelling 
• Land-use/land-cover Change and Vector-borne Diseases: Remote Sensing and Multi-agent Simulations: Eric Lambin, BE , IMED 2007 Procs.
• The Role of Goal-Oriented Autonomous Agents in Modeling People- Environment Interactions in Forest Recreation 

Books

• Integrating Geographic Information Systems and Agent-Based Modeling 
• Geosimulation: Automata-based modeling of urban phenomena 
• 2D/3D MultiAgent GeoSimulation  This is a PHD thesis from Laval...
• Landscape Simulation Modeling:: A Spatially Explicit, Dynamic Approach 
• Individual-based Modeling and Ecology 
• Simulating ecological and evolutionary systems in C 
• Search for "landscape" & "simulation" in Amazon 

Directories

• Simulation for the social scientist 
• ECOBAS 
• David Hill links 
• A Collection of Modelling and Simulation Resources on the Internet 

People

• Eliot McIntire
• Giuliano Antoniol 
• Markus Neteler 
• Yann-Gaël Guéhéneuc 
• Steve Cumming
• Pierre Racine

Other people

• Michael barton 
• David Hill 
• Morshed Anwar  (Repast Specialist) with Lael Parrott
• Andrew Crooks 

Blogs

• GIS and Agent-Based Modelling 

Agent based modelling

• Agent-based_model in wikipedia 

Sample Model - Wolf Recolonization

Wolf_SELES_1.0.zip Δ