 Figure. 3 Object Relationship support using relationship function between features in geodatabase It’s important to discern carefully between objects and attributes, and between non-spatial relationships and spatial topology, before the modelling started. In the modelling process, we may find hidden or implicit spatial objects and topological relationships not mentioned but implied in the guidelines, which are necessary to be modelled. This is where logical deduction based on planning and design experience is required from the modeller. Design guidelines generally consist of series of different rules, such as validity rules (or constraint), topology rules, relationship rules, and connectivity rules (Figure 2). In geodatabase, validity rules can be modelled into subtypes with specific value or domain with value range enforcing certain characteristic of the object. Relationship rules are modelled within the standard relational geodatabase functionality. An example shown in Figure 3, the “Parcel_Design” object is in relationships with other objects and rules, such as “Pedestrian_link”, “Pedestrian_Collonaded_Cove”, and “Parcel_Corner.” The relationships enable changes made in one object affect other related objects. Connectivity rules can be modelled into geodatabase network class, although lacking complex rules such as trinary (“a between b and c”) and directional rules. For the rules to be enforced to the proposed design, they have to be in the same datasets. Urban design guidelines are usually written as textual statements, and can only be transformed into geodatabase modelling through several stages. The first stage is transforming the guidelines text statements to conceptual Object Role Model (ORM) as objects and relationships between them. The guidelines in ORM are then transformable to Unified Modelling Language (UML) as a technical data model. The ORM model must be validated before the second transformation, against user requirements for data management, urban design practices and procedures, and basic data modelling principle. The final stage is from UML model into geodatabase model in a GIS system. There are several methods for the final transformation: (1) using GIS repository and Computer-Aided Software Engineering (CASE), (2) using geodatabase modelling with GIS customization, and (3) using eXtended Markup Language (XML) model. The geodatabase model can be transformed further to operate-able GIS geodatabase. The recent development allows modelled geodatabase to be mounted on existing Relational Database Management System (RDBMS). The UML Schema Generation has been tested to build geodatabase from existing features, but we discovered this method is only effective for building new and ‘empty’ geodatabase. The geodatabase modelling for SMU New Campus Competition Design Guidelines was done with the first method, using ORM, UML, and CASE. During the modelling process, there are four types of transformation from textual statements to database components. Statements indicating the existence of a type of physical reality can be modelled into feature classes, statements indicating the spatial arrangement between urban objects into topology rules, statements indicating non-spatial relationship between two objects into relationship classes, and statements indicating measured limitations and range of choices into domains. In order to effectively model the guidelines into geodatabase, there should be sufficient amount of model-able statements.  Figure. 4 Object topology support using geodatabase’s topology class. The modelled guidelines can only be implemented and tested whenever a design proposal is sketched into the GIS-based geodatabase. The guidelines then automatically validate the sketched proposal accordingly, identifying inappropriate design specification and breach of design rules and controls. The designer sketching the proposal is simultaneously alerted of guidelines’ breaches and violations by the GIS system. In the case of SMU competition, we’ve tested the modelled geodatabase with the design proposals of the finalists’ proposals, and modelling effectiveness can be validated because the geodatabase can detect the proposals’ breaches and trespasses (Figure 5). As an example, the sketched of proposed building in Figure 4 is breaching the topological polygon representing the topology rules, that the visual corridor should be kept undeveloped. The rules breached are indicated on the ‘Table of Contents’ window, which are ‘Must be larger than cluster tolerance’, ‘Must not overlap with’, ‘Must be covered by feature class of’, and ‘Must be covered by’. Different levels of guidelines enforcement, i.e. minor or major enforcement, can be set beforehand to allowflexibility in design process. |