OBEUS (Object-Based Environment for Urban Simulation) Shareware Version Yaffo model is based on partition of the area into Voronoi polygons, which correspond to real-world houses; neighborhood relationship between houses are defined on the base of direct view, that is houses are neighbors when their Voronoi polygons have common boundary. Householders are neighbors if their houses are neighbors. Itzhak Benenson 1,2, Slava Birfur 1, Vlad Kharbash 1 1 Revson Environment Simulation Laboratory, 2 Department of Geography and Human Environment, Tel Aviv University bennya@post.tau.ac.il, http://www.tau.ac.il/~bennya, http//eslab.tau.ac.il Presented at AGILE 2004 conference We built neighborhood relationships between houses with MapInfo GIS application and then uploaded the resulting 1:N table into the model. The table of neighborhood relationships, necessary to exploit Voronoi partition in the model, brings overheads in case of regular grid. But it is a source of inspiration, our models are, actually dynamic databases. Talking about urban CA and MAS we actually talk about the objects and relationships between them, it s Entity-Relationship Model, thus, with The model worked well and inspired the idea of a city dynamics driven by bounded rationality agents, Erez Hatna presents at this meeting. Entities and Relationships changing in time Working on Yaffo model, we wanted to test some abstract idea regarding its mechanism. The irregular partition was just a noise for this problem. So what to write a parallel CA-MAS model? The answer is NO! Namely, (1) Build square point grid in GIS (Mapinfo SQL is enough), (2) Apply GIS algorithm of Voronoi partition (we used it for houses) (3) Apply algorithm for building the table of neighborhood relationships, (4) Substitute real Yaffo data by this artificial set. The OBEUS came from this. Paul Torrens came independently to similar views and working on the Geosimulation book, we ve formalized the idea as Geographic Automata Systems 1
We claim that GAS concept is formal enough to build a software, and in what follows I present such a software. Some illustrations, to demonstrate that the idea is not that abstract BASIC TYPES OF GEOGRAPHIC AUTOMATA FIXED GEOGRAPHIC AUTOMATA (analogies with CA cells): Do not change location over time - e.g., road links, land parcels. They are subject to all rules except movement. TWO FORMS OF GEO-REFERENCING Direct geo-referencing, by coordinates, characteristic of the fixed automata, when coordinates are the component of the S (vector) state of the automata Indirect geo-referencing, by pointing to other GA, characteristic of the non-fixed automata, the location is defined by D-F relationship NON-FIXED GEOGRAPHIC AUTOMATA (analogies with MAS agents): Can change location over time - e.g., pedestrians, vehicles, householders, landlords. Subject to the full range of rules. For cells of the CA, as well as for other fixed geographic automata, e.g. houses, lots, road segments - direct geo-referencing is a natural approach. Direct geo-referencing depends on geographic scale. R - Relationships (including neighborhood relationships) In CA, neighbors are given a priori, and specified via fixed pattern (as von Neumann and Moore neighborhoods). Indirect geo-referencing is characteristic of the non-fixed GA (D- F). Householders point to fixed households, landlords point to fixed lots, cars or pedestrians point to fixed network link (and located exactly by means of natural coordinate (dynamic segmentation). GAS utilize GI Science views to express neighborhood and other spatial relationships between fixed automata. Relationships can express adjacency, contiguity, accessibility, visibility, distance, etc. 2
Indirect geo-referencing entails indirect definition of neighborhood relationships between non-fixed objects. Neighbors OBEUS OBJECT-BASED ENVIRONMENT for URBAN SIMULATION Neighbors Neighbors OBEUS GOALS: Putting it arrogantly: To build an ultimate environment for urban high-resolution simulations, which makes models comparable and transferable. Putting it modestly: To let the modelers to code just what they want to code the rules of urban of behavior of the urban objects IN BOTH CASES GAS PARADIGM IS SUFFICIENT FOR DEVELOPING A SOFTWARE OBEUS details MANAGEMENT OF RELATIONSHIPS IN OBEUS (or how to make them consistent) We limit ourselves to Leader-follower pattern (Noble 2000): One of the sides is set as a leader, and is responsible for managing the relationship. The other, passive, side is a follower. The leader object provides an interface to manage the whole relationship, and invokes the followers, when it is necessary. Non-fixed entities always act a leader. Leader-follower pattern resolves concurrency problem, which rises up when applying transition rules. Leader-Follower pattern is sufficient in representing relationship objects for all the urban models we know. Whatever, we don t use the system because it s based on clever idea, we use the system that helps us in work So, let us begin studying OBEUS You begin design of your model by defining entities and relationships. In parallel with each new type of entities, OBEUS creates the population, which stores the global characteristics of the entities of this type 3
1. You defined an entity ROAD and you push Add. You can proceed with properties of roads on your own or you can upload roads and their properties from GIS 2. If you have chosen GIS source, you have to select a shape file of roads and to determine which properties should be uploaded into the model database. 3. To view the layer you use right-click 4. You proceed in this way until you feel that the time came to define the relationships 5. Don t forget to make save from time to time all you work is stored in the data base and can be restored in case of crash (we, just as Microsoft, still have some debugging ahead) 6. You establishing leader and follower in each relationship 7. You define the properties of relationship in the same way you did that for entities 8. You can upload relationships from the GIS (this is always a dbf file) 9. You might define population global parameters - constants, constraints, etc. at this step 10. But we recommend to proceed to transition rules first - you will edit all of the stuff above when formulating them. It s hardly possible to define components of the model before formulation the rules of behavior for the urban entities. 11. To formulate transition rules you have to know how to write code. 12. We recommend C#, just because we use it ourselves, but you can also use Basic, C++, or other language supported by.net 13. Transition rules are called in OBEUS behavioral rules. The entity changes its state and/or relationships according to the automation rule. To formulate an automation rule, you usually define many assessment rules, that provide an information, necessary to apply an automation rule. 14. You have a specific areas in a C# module to code the automation rules. 15. Saving you project, you get all the entities, relationships, their properties, automation rules you defined till then at prompt 16. You debug your C# code as you used to 17. Population have their own automation rules. 18. Entities automation rules are executed each tick 19. Populations automation rules are executed each iteration 20. Don t forget save your model from time to time. 4
What might be population behavioral rules? Usually this is updating of global constraints How we recognize self-organizing patterns? Set of predicates, spatial and non-spatial to define ensemble of yellow buildings B Y Non-spatial: The building is YELLOW, if the value of more than half of apartments in it is above the 75th percentile of the distribution of apartment value in a city. Spatial: For each b from B Y, more than 60% of b s neighbors within 3x3 Moore neighborhood satisfy criterion Y. B Y contains sufficiently many buildings. B Y is continuous. You though that s all? Not at all, here comes the hard stuff MANAGEMENT OF TIME IN OBEUS Two synchronization modes: Synchronous: All objects change simultaneously. Asynchronous: Objects change in turn and each sees the urban reality as the previous one left it. Sometimes (often? usually? always?) we, modelers, are inconsistent in managing events in time. We hide some components of the information from our agents till next iteration, while release the other components just after the event happens. For example, in models of housing, we provide the agents with the instantaneous information regarding the occupied and vacant apartments, while agents usually do not know who are their neighbors till next iteration. The decision depends on the coding ability of the modeler usually. Irregular treatment of time makes model incompatible. 21. No matter what is the synchronization mode, relationships in OBEUS are updated immediately, at each tick 22. In synchronous mode for the entities of a given type, OBEUS creates the read-only copy of each entity at the beginning of the iteration. Each update then creates the new copy of an entity, which substitutes the read-only one at the end of the iteration. 23. At the level of a city, the user of OBEUS must establish the hierarchy of updating. 24. OBEUS checks cascading, just as each DBMS does, and does not permit to the follower to destroy the relationship Some technical details. OBEUS is based on Microsoft.NET environment and is written in C# For people like me C# syntax is just as that of Java; Microsoft s.net exploits the idea of Java virtual machine, that is an intermediate binary code is created from any source, and it does not matter which.net language you use..net demands Windows, and we never checked what goes on regarding the other platforms. But on applications we tried,.net is 3-5 times faster than Java, and experts told me that C# has essential advantages over Java. Terrible thing is that in C# you can use pointers You need C# compiler, to use OBEUS. We use Microsoft Visual Studio, 89$. but a weeks ago came across free Borland C#. It was announces in March or so and looks really good! You need the basic components of SQL server, which are free 5
Some general questions Is it a temporal GIS? Yes, it is. What are OBEUS limitations? 1. Leader-follower relationship pattern, 2. Unified time-flow 3. Relationships between agents are not allowed and users must code them themselves I think all that are necessary to make model code understandable. There does exist hidden problem quite a lot of things we need can be formulated as an SQL expression, but there are no means to execute SQL in memory. Different solutions are possible, we still didn t decide what to do. What you get with OBEUS? Ability to write just the core of the model, nothing else. GAS-based simulation language Do we have a couple of minutes for live demonstration? 6