Figure 4 a screen shot of the rule editor. Classes defined in the ontology can be related to each other to form a conditional pattern. The rule engine will search for the pattern and execute the script.
Concept Modellers
The following cases demonstrate the use of the concept modeller as a generic tool for specific urban design related ‘problems’. Therefore the initial focus of this research has been on building a generic tool and less on resolving full real urban design related problems. The different concept modellers use the same software environment but have different ontologies. Predefined ontologies, such as the Geometry Classes ontology, the decision table (meta-) ontology, rule ontology, chart ontology, etc, are imported. A specific ontology is developed for each case study building on the predefined ontologies. Classes in the specific ontology can for example extend classes in the shape ontology. This offers these classes the ability to capture shape information, use shape characteristics, such as orientation, and to be visualised.Case #1: Urban Water Supply Pipes
The goal of this small case study is to demonstrate the ability to automatically dimension water supply pipes by calculating the water demand which goes through each pipe in the pipe network. With this information the total material usage of the water supply pipes can be calculated. In order to determine the pipe network many geometry and topology related instructions have to be defined and carried out. First the pipe network has to be established which can be done by searching for overlapping pipes (with a certain variance). After that a direction of the network has to be determined from a starting point (Water supply instance). Next, the individual demand of each urban block (division with dwellings which need water) has to be determined which need to be supplied by the ‘nearest’ water pipe. Then the water throughput for each pipe can be determined including its dimensions by traversing the network (Figure 5).
Figure 5 screenshot of the throughput of each waterpipe in the network
Case #2: Urban Concept Modeller
The second and most ambitious case study is an integrated computer environment to automate assessments of new neighbourhood design plans [Schevers & Drogemuller, 2005]. The main concept is to develop and reuse existing guidelines such as AMCORD [1992] and software models, such as cost, bushfire, traffic, and energy and water usage. Currently the Urban Modeller can undertake simple assessments, such as calculating the average distances between houses, public transport, roads, parks and shopping malls. In addition the system is able to calculate area usage of infrastructure, lot sizes and house sizes and can aggregate these results to produce a summary of the design solution. As values such as the amount of people per house type, water demand, etc are available, total water demand and density calculations can be performed as well. CAD geometry can be re-used to get the design information into the system. Colour codes or layer information in the CAD files can be used to create semantic objects such as roads, lots, subdivisions, parks, etc. The client can use this system and make minor geometry changes, change the house types on a certain lot, etcetera. This will result in a new density, new average distances, new water usages, etc. The calculations are done on the fly and are directly visible in the charts (Figure 6). Importing CAD and GIS is quite easy, however the amount of data can become a problem as each line, coordinate, etc has to be converted into an instance in the ontology which can be very memory intensive. At the moment the system is not very scalable. Scalability may be improved by pre-processing the CAD data into higher level concepts. The following screenshot shows that it is possible to handle large datasets but the performance of the system is poor. Several possible methods for resolving the scalability issue are under consideration.
Figure 6 Changes in the design can directly be processed.
Figure 7 handling larger datasets is not currently scalable.
Case #3: Solar Orientation
The assessment of solar energy usage for dwellings raises several important aspects. One of them is the lot orientation. For this small case study, the geometry package has been extended to include new capabilities. One capability is to determine the orientation of polygon at an arbitrary orientation. The instruction determines the primary lot orientation in degrees. The first screenshot contains test data to test the algorithm. The second screenshot uses the same algorithm for an existing suburb. This ontology will be used to provide a wider range of options in Case 2.
Figure 8 shows two screenshots of the concept modeller determining solar orientation of individual lots.
Future Work
The immediate plans for this work are to: 1. Extend Case 1 to handle other engineering services provided through networks, such as energy (electricity and gas) and transportation; 2. Use Case Study 3 as the basis for a more comprehensive analysis of activities at the cadastre (site) level based on explicitly entered data and inferred information; 3. Extend Case Study 2 by adding the extra capabilities from steps (1) and (2); 4. Develop methods to improve the scalability of the system by either pre-processing input data into higher levels of granularity or by using a modular software architecture to more clearly define interactions between systems. These extensions will allow this system to be actively tested in urban design offices.Conclusions
A generic software environment for modelling urban scale design problems enables rapid generation of customized tools for specific urban problems. This is possible by re-using ontology driven software components. The necessary flexibility to use a generic software component to a specific problem is offered by the ontology. This approach enables the quick construction of software tools by developing an ontology and including rules and other knowledge representations. By developing new models with re-usable components we expect to build a large library of software modules which are all ontology driven and therefore easily re-usable for other projects. One of the problems at the moment is when classes are defined in the ontology having complicated super types, it is very difficult to determine if functionality offered by the various implementations is conflicting or not. Therefore we need to infer which software component is influencing what to make sure conflicts are avoided or at least identified at design time. In addition large data sets are difficult to import as the conversion from GIS/CAD data to instances of an ontology consumes significant memory.References
AMCORD,(1998) Guidelines for urban housing, AGPS, Canberra, Australia,1992
Baader F., Calvanese D., McGuinness D., Nardi D., Patel-Schneider P. (eds.) (2003). The description logic handbook. Cambridge University Press, UK.
Michel Klein, Combining and relating ontologies: an analyses of problems and solutions, Vrije Universiteit Amsterdam, NL, 2002.
Gruber, T., Towards Principles for the Design of Ontologies Used for Knowledge Sharing, International Journal of Human and Computer Studies, 43(5/6), 907-928, 1995.
Holger Knublauch. An AI tool for the real world: Knowledge modeling with Protégé. JavaWorld, June 20, 2003.
Schevers, H., Demand Support Systems, PhD thesis, Delft University of Technology, Delft, the Netherlands, 2004.
Sowa, John F., (2000), Knowledge representations, Pacific Grove Brooks/Cole, USA.
SoE,State of the environment, http://www.deh.gov.au/soe/.
Protégé, Stanford Medical Informatics, the Protégé Project, http://protege.stanford.edu
Racer, Accessed 2005 at http://www.racer-systems.com/
Pellet, Accessed 2005 at http://www.mindswap.org/2003/pellet/index.shtml
Hypertext References
- HREF1
- http://www.cmit.csiro.au/