Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Zoning in Vancouver : an expert system to assess development proposals Atkins, Julian Francis 1990

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-UBC_1990_A8_2 A84.pdf [ 10.16MB ]
Metadata
JSON: 831-1.0098511.json
JSON-LD: 831-1.0098511-ld.json
RDF/XML (Pretty): 831-1.0098511-rdf.xml
RDF/JSON: 831-1.0098511-rdf.json
Turtle: 831-1.0098511-turtle.txt
N-Triples: 831-1.0098511-rdf-ntriples.txt
Original Record: 831-1.0098511-source.json
Full Text
831-1.0098511-fulltext.txt
Citation
831-1.0098511.ris

Full Text

Z O N I N G IN V A N C O U V E R : A N E X P E R T S Y S T E M T O A S S E S S D E V E L O P M E N T P R O P O S A L S By J U L I A N F R A N C I S A T K I N S B . A . Hons., Simon Eraser University, 1986 A THESIS S U B M I T T E D IN P A R T I A L F U L F I L L M E N T O F T H E R E Q U I R E M E N T S F O R T H E D E G R E E O F M A S T E R O F A R T S (PLANNING) in T H E F A C U L T Y O F G R A D U A T E STUDIES (School of Community and Regional Planning) We accept this thesis as conforming to the required standard T H E U N I V E R S I T Y O F BRITISH C O L U M B I A September 1990 © Julian Francis Atkins, 1990 In presenting this thesis in partial fulfillment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department of by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. School of Community and Regional Planning The University of British Columbia Vancouver, Canada Date S^^Z.J^ 1£K (99o A B S T R A C T A sample of Vancouver's zoning has been expressed as an expert system, microcomputer program, - Euclid - in order to demonstrate the feasibility of applying this tool in municipal planning, and to explore the desirability of such computer applications. Review of the literature on Expert Systems from a planning practice perspective showed that this is considered one of the more exciting and potentially useful developments emerging from Computer Science. Expert Systems are thought to be applicable to some planning tasks which are difficult to handle using the computer tools currently available yet suited to automation, however, there is in the literature very little empirical work on developing systems and testing the potential utility of expert systems in land use planning. Euclid is programmed in Turbo Prolog 2.0, a language accessible without extensive or specialized computer training. The first conclusions of the thesis are that simple but useful expert systems can be built rather quickly by planners, and that development control is a good application domain. The thesis also uncovered several weak-nesses and inconsistencies which appear related to the way Zoning By-laws have been written, and suggests that the discipline of programming in logic may avoid or resolve such problems. Finally the process of developing a system is shown to be just important as the system itself: Expert systems are a way of thinking about a problem just as they are a way of solving it. ii Table of Contents C H A P T E R O N E : I N T R O D U C T I O N page 1 Thesis page 1 Context page 1 Contribution page 4 Methodology page 5 Scope & Assumptions page 5 Organization of Chapters page 7 C H A P T E R T W O : D E F I N I N G E X P E R T S Y S T E M S page 10 Artificial Intelligence page 10 Expert Systems page 11 A n Illustrative Definition page 13 Expert Systems Structure page 14 The Knowledge Base page 16 The Inference Engine page 17 Representational Structures page 20 Software Tools for Developing Expert Systems page 28 LISP page 30 Prolog page 33 Turbo Prolog 2.0 page 36 Expert Systems & Shells page 37 Landmark Expert Systems: M Y C I N & P R O S P E C T O R page 39 A Sample of Expert Systems in Planning page 42 Other Systems of Interest page 45 Application Areas in Urban Planning page 48 Characteristics of Tasks suited to Expert Systems Solutions page 53 C H A P T E R T H R E E : A N E V A L U A T I V E F R A M E W O R K F O R A S S E S S I N G P L A N N I N G T O O L S page 56 Towards an Evaluative Tool page 61 The Evaluative Framework page 62 C H A P T E R F O U R : A D E S C R I P T I O N O F T H E D E M O N S T R A T I O N S Y S T E M - E U C L I D page 67 Euclid page 70 The Planner/computer Interface page 77 The Inference Engine page 78 Table of Contents (continued) The Knowledge Base page 79 The Development Process page 85 A Sample Run Session page 88 Conclusions page 94 C H A P T E R F I V E : A N E V A L U A T I O N O F T H E D E M O N S T R A T I O N S Y S T E M - E U C L I D page 96 In Relation to the Evaluative Framework page 96 Conclusions of Applying the Evaluative Framework page 106 Turbo Prolog As A Development Tool page 107 Lessons Learned from the Zoning By-laws page 108 Conclusions page 110 C H A P T E R SLX: A G E N E R A L C R I T I Q U E O F E X P E R T S Y S T E M S page 112 Theoretical Limitations page 113 Practical Limitations page 114 Professional Planning Limitations page 121 Conclusions page 125 C H A P T E R S E V E N : C O N C L U S I O N S page 128 THESIS B I B L I O G R A P H Y page 135 A P P E N D I X 1 Z O N I N G D A T A B A S E SPECIFICATIONS page 147 A P P E N D I X 2 I N D E X O F P R E D I C A T E S C O N T A I N E D W I T H I N E U C L I D page 150 A P P E N D I X 3 E U C L I D P R O G R A M M I N G C O D E pago 151 iv List of Figures Figure 2.1 Expert Systems Structure page 15 Figure 2.2 Backward & Forward Chaining page 18 Figure 2.3 Representational Structures page 21 Figure 2.4 The Frame Structure page 22 Figure 2.5 The Blackboard Structure page 23 Figure 2.6 Examples of Rules & Facts page 25 Figure 4.1 Euclid Study Area page 71 Figure 4.2 Zoning By-law Structure page 72 Figure 4.3 Euclid Programme Modules page 73 Figure 4.4 Planner/Computer Interface page 75 Figure 4.5 Euclid System Flow Chart page 89 V A C K N O W L E D G E M E N T I would like to acknowledge Canada Mortgage and Housing Corporation for supporting part of my M . A . studies through their Scholarship programme. I would also like to thank Mr. John French for very generously offering to help me produce the thesis on his computer. Without his help, the task of finishing the thesis would have been much more difficult. A final note of thanks must also go to my parents for supporting me throughout my studies and to my fellow students from whom I have learned so much. vi C H A P T E R O N E : I N T R O D U C T I O N Thesis The nature of planning practice is such that planners are routinely faced with numerous different tasks which require, for their completion, qualitative information just as much as quantitative information, if not more so. Computer tools which are available at present have difficulty in handling the former and so are almost exclusively confined to the latter. Thus, there are some planning tasks which have the potential to be automated and yet lack the requisite computer tools to do so. New research in both computer science and planning suggests that Expert Systems may be suited to some of these planning tasks since they can handle both types of information and provide a means by which professional judgement and expertise can be expressed in a microcomputer program, in a way which is transparent to the user and does not appear as some kind of magical black box. The purpose of this thesis is to evaluate the claims made in the Expert Systems literature by developing a demonstration system and to assess the feasibility and desirability of developing such tools in a municipal planning context. Context Society has, in recent years, witnessed an increasingly rapid pace of change as we move • from an industrial to a post industrial society and beyond. More sophisticated technology, improved communications globally, and higher levels of education have resulted in much faster cycles of innovation and a more rapid diffusion of ideas. The pace with which urban growth is taking place has also increased. At the same time, society is experiencing a fiscal crisis, especially in its cities, as the cost of providing municipal services and upgrading civic infrastructure increases dramatically (see Gottdiener, 1986, for a discussion of fiscal stress). 1 Planners and other municipal officials are also faced with more immediate pressures as the growth ethic demands greater development which in turn results, particularly when the development industry is buoyant, in increased numbers of rezoning and development applica-tions. Yet despite these increasing pressures, technology and the pace of innovation have, to some extent, also provided planners with a means of dealing with them. The development of the modern digital computer over the last 40 years or so has revolutionized the ways in which people work and solve problems. Many professions, including planning, have adapted to, and incorporated the power of the computer into their day-to-day activities. The advent of the personal, stand-alone, computer (PC's or microcomputers to use the accepted industry jargon) has accelerated the recognition by planners of the computer as a piece of equipment necessary for successful planning practice. Indeed, Planners and Municipalities have not been slow in adopting both mainframe and Personal Computers (Micro Computers) in order to handle more effectively repetitive or routine tasks such as word processing and basic number crunching. Thus many departments employ database, spreadsheet, graphics, statistical, and/or integrated pack-ages (Bardon, 1988, p.347) for storing information, analyzing data, forecasting & projection, as well as producing reports. At the same time, Planners also appear to be becoming more computer literate and are beginning to undertake more and more 'in-house' development and to produce more and more tailor-made software. The majority of these packages, models and programs, however, require that real world situations be reduced to quantities, formulas and algorithms. These requirements have led some planners to become disenfranchised with such positivist computing approaches because they fail to incorporate the richness, or conversely the scarcity, of the real world and cannot represent all the elements of most 'planning problems'. They have also been criticized because they fail 2 to handle changes that occur in the context of a 'problem' and to clarify here, a 'problem' in the context of planning can mean the thing or area being evaluated. Such a definition encompasses a wide range of planning activity from developing goals, formulating plans, evaluating projects, and controlling development, to economic impact assessment, forecasting, projection, environ-mental impact assessment, and others. Despite the development of such techniques and tools though, the primary functions of computers in planning departments today are the more menial tasks of information storage and word processing. Pencil, paper, and files have simply been replaced by keyboards, monitors, and disks and planners have not fundamentally restructured their working methods in order to take advantage of the capabilities of the computer tools available. Furthermore, most of the software being used: spreadsheets; database systems; and word processing packages, for example; is generic in nature. That is, each package is designed to be of use to more than one group of professionals. Unfortunately, in designing something for everyone's needs the software engineers have developed tools which meet no one's needs completely. Consequently, users have had to adapt their techniques to the software at hand. Planners are no exception to this adaptation but, in translation, refined and complicated planning techniques become simplified, or omitted altogether, in order to make the software work. Such a situation of making 'reality' fit the 'model' does little to address the apprehension users have of computers or of their faith in the possibilities of computers. What planners require is software which can support and enhance the planning process as well as meet the requirements of the planner/user, not vice versa. Such software though would have to address the criticisms levelled at quantitative and procedural computing methods and provide the planner with greater flexibility. 3 To this end, some planners are exploring the possibilities in a number of key areas, and research is progressing on three broad fronts: Computer Aided Design (CAD); Geographic Information Systems (GIS); and, to a lesser extent, Artificial Intelligence (AI)/Expert Systems. In the long term, combining all three areas is an obvious and desirable objective since it may allow the development of comprehensive and flexible tools which are geographically based yet make use of sophisticated graphics and which function in ways far more acceptable to professionals and staff than at present. However, while there are obvious overlaps between these three areas, current research is progressing along more or less separate lines. A perusal of recent conferences focussing on information technology and its application to the urban domain reveals that the most progress has occurred in C A D and GIS software. Indeed, numerous systems are already commercially available for these tasks (URISA, Conference Programs, 1989 & 1990). Much less work has been done in the area of AI and Expert Systems, and it is only in the last five years or so that Planners have become interested in the field and only in the last two or three that the first demonstration systems have started to appear. The application of A I techniques and software to Urban and Regional Planning though has the potential to make the greatest impact, of the three, upon the profession. Contribution The contribution that this research makes to the field of planning is to introduce expert systems to a planning audience by providing a comprehensive, balanced discussion of their structure and capabilities. Current planning research into Expert Systems has revealed substan-tial potential but as yet very little empirical research has been done. Therefore, another important contribution of this thesis is to take research to the next level by developing a simple 4 demonstration system, based upon current development control legislation, and by evaluating the system itself, the process of development, and the information on which the system is based (i.e. zoning schedules). Finally, another contribution is the identification of weaknesses and inconsistencies in the content of the zoning schedules; these making the zoning regulations themselves hard to interpret. Methodology The demonstration system presented - Euclid - has been built around a sample of the City of Vancouver's zoning schedules, specifically those schedules governing two-family residential districts in Kitsilano, Grandview Woodlands, and Mount Pleasant. It is written in Turbo Prolog 2.0 as a self-contained executable program and took approximately two person-months to develop. In essence, the system is a translation of the six zoning schedules into a series of logical rules, each corresponding to a specific zoning regulation or set of regulations, with a set of rules corresponding to each of the six schedules. The system operates interactively, asking the user a series of questions which determine whether or not a particular land/use and site combination is permitted under the current zoning regulations. It then informs the user whether the use/site proposed meets the current regulations or not. If the use fails, the system will say why and in some cases will indicate relaxations which may be permitted. Scope & Assumptions The scope of the thesis is focused squarely upon the development and evaluation of the demonstration system above and so is fairly technical in nature. Since the majority of readers will be unfamiliar with the field of expert systems it has been necessary to preface the chapters 5 describing and evaluating the system with a fairly lengthy and detailed introduction to the concept of expert systems. Consequendy, the thesis is not concerned with the philosophical or ethical discussions which surround expert systems and artificial intelligence research. It assumes that the theoretical literature behind expert systems is valid in order to proceed with the development of the demonstration system and that Euclid, although it is a very simple tool, is an expert system because it represents a fundamental shift in computer programming and problem solving techniques. Thus, questions regarding the definition of what makes an expert system an expert system are not treated in any detail and are assumed to be of secondary importance to the main focus of the thesis. In addition, efforts were made to collaborate on the development of Euclid with one of the local planning departments in Greater Vancouver. It was felt that such collaboration could help to provide Euclid with some form of rudimentary discretionary judgement in its analysis of development proposals. However, these efforts were met with a lack of interest and no offers of assistance were forthcoming. The scope of Euclid has therefore had to be restricted to the textual material contained in the Zoning Schedules. Consequently, Euclid represents only a portion of what would be necessary in a fully developed system. The reader should also be aware that terminology plays a key role in expert systems literature and that such terms usually have very specific meanings. Thus terms which may appear to be familiar should not be interpreted with the meanings that are more generally associated with them. The term 'expert' in 'expert system', for example, does not necessarily mean that the system exhibits human or intelligent judgement and expertise, but more that it employs 6 techniques, in the way it functions and represents information, which are associated with the AI/Expert System field. Some of these terms are also found in the planning literature - 'top down' and 'bottom up' for example - and planners should be very careful not to read into the text meanings which are more commonly associated with their use in planning since this could lead to erroneous interpretations concerning the capabilities of expert systems. Organization of Chapters The thesis is divided into seven chapters each of which addresses a particular theme within the context of Expert Systems: Chapter One consists of the introduction and places the thesis within the context of technological change, the increasing pace of innovation, fiscal stress, and increasing develop-ment pressures. It also outlines current practice in terms of computer applications in planning and identifies the three main areas of 'new' computer research within planning. Chapter Two provides a fairly detailed definition and description of expert systems, drawing as it does on the existing planning literature vis a vis expert systems, as well as the literature which has emerged from the fields of computer science, psychology, and philosophy. At the same, time Chapter Two explains how expert systems work and reviews the types of software and programming tools which are available. The chapter also reviews several existing demonstration systems which are relevant to an urban planning sphere and concludes with a discussion of potential urban planning applications. Chapter Three presents an evaluative framework for use in assessing the performance of various software tools, including expert systems, in terms of their suitability for contemporary 7 planning practice. This framework draws on critiques of the positivist tradition as well as contemporary planning theory and artificial intelligence/expert systems literature outlining the supposed capabilities of 'intelligent' software. This framework then forms the foundation for evaluating the demonstration system described in Chapter four. Chapter Four begins with the rationale for selecting development control and in particular zoning schedules as the domain around which the demonstration system - Euclid - is built. The chapter then describes how Euclid works, as well as the development process used to develop the system. It concludes with a description of how a sample interactive session would work. Chapter Five assesses Euclid using the evaluative framework developed in Chapter Three and discusses problems which arose during the development process as well as the limitations of the system developed. A n analysis of Turbo Prolog as a development tool is also included. Chapter Six analyzes expert systems, and the claims which some supporters of the field make, from a critical perspective. This critique is based upon social sciences literature from such sources as Philosophy and Psychology and upon an evaluation of Artificial Intelligence/Expert Systems concepts from the planner's perspective. Chapter Seven concludes the thesis with a short discussion of the principal findings. It reveals that Expert systems can indeed be developed quite easily around the domain of development control and that expert systems may also be applicable in other areas of planning. Furthermore, several weaknesses and problems with the written zoning schedules were un-8 covered which seem to stem from the lack of a consistent writing style and the legal constraints which govern the drafting of By-laws. These can, in some cases, serve to hinder the clarity of the document and create an atmosphere of uncertainty and confusion concerning the correct interpretation. Finally, Turbo Prolog's suitability as a programming and system development tool is discussed and it is suggested that initial efforts may be likelier to succeed if an expert system shell is used instead. 9 C H A P T E R T W O : D E F I N I N G E X P E R T S Y S T E M S The development of Expert Systems has its roots in a branch of computer science known as artificial intelligence (Al). Research into A l and it computer applications has been ongoing since the early 1950s (Shipley, 1989, vol.2, no.3, pp.64-74) although the roots of the field arguably go back to the Greek's development of deductive logic (Aleliunas, 1989). Until the early 1980s, this activity was confined primarily to academic and R & D institutions, and only recently have a number of practical or commercial successes materialized; these mainly in the area of "expert systems" (Shipley, 1989, vol.2, no.3, p.67). Artificial Intelligence The essential thrust of A l is to develop computer hardware and software tools which mimic and exhibit the intelligent characteristics of humans. Tello provides one of the clearest definitions of Artificial Intelligence: A basic definition might be that artificial intelligence is concerned with making computers do things that would be. intelligent if humans did them. But this is too vague from either a practical or philosophical point of view. Some clarification might result from identifying some of the directions that are being pursued within the field. Currently, the following focuses can be identified within A l : (1) A l as a body of techniques and approaches for solving problems; (2) A l as the leading edge of computer science research in general; (3) A l as a class of currently available development and application products; (4) A l as a research tool for understanding how the human mind works...; and (5) A l as a venture to develop the equivalent of human intelligence by artificial means. (Tello, 1988, p.3) (N.B. - Items 4 and 5 above are beyond the scope of this thesis.) Within A l there are a number of sub-fields and knowing what these are is beneficial in grasping the full nature and scope of A l research. Again, Tello (1988, p. 17) proves the clearest 10 and most complete source in outlining current applications and research areas, and has identified the following distinct sub-fields: Natural-language processing. Expert systems and knowledge based systems. Automatic programiriing. Intelligent robotics and autonomous systems. Machine learning and discovery. Vision and sensory recognition. Intelligent training and education. Intelligent user interfaces. Automated software and engineering design. Planning and general problem solving. This thesis is primarily interested in item two above but it will be seen that items seven, eight, and ten also have potential value within the sphere of Planning. These four categories are mirrored in the application areas which have already been identified by planners and which will be discussed later in the chapter. Expert Systems Many of the successes hailed in AI to date, most notably MYCIN, DENDRAL, PROSPECTOR, and R l , are a product of expert systems research. Some have gone so far as to say that"... the one application area most synonymous with AI is flourishing. Expert systems are no doubt the most mature and resilient products to come out of the AI research community." (Shipley, 1989, vol.2, no.3, p.73). Indeed "... expert systems are widely thought to represent AFs first major achievement..." (Pfaffenberger, 1988, p.64). Others have been more cautious in their praise: "While the development of Expert Systems clearly marks a watershed in computer 11 science, however, it could also represent one of the greatest potential dangers yet posed by the Mechanist Thesis." 1 (Shanker, 1987, p. 114). While it is proper to be cautious about the advent of any new technology, it is also clear that expert systems represent a new and different approach to those software packages and programming languages currently available in the market place. Conventional programming languages such as F O R T R A N , B A S I C , or Pascal, as well as general application software popular in planning departments (such as Lotus 1-2-3 or SPSSX), have to approach a problem or issue by collecting numerical data, assigning numerical values to, or ignoring completely, qualitative information, and then defining procedures, functions, and algorithms for reaching a solution. Data and procedures are intertwined and interdependent; a change or addition to one also requires modifications to the other. These tools are also predicated on a brute force approach to problem solving. That is to say these programs test every bit of the database they are given in searching for solutions. In the same way, spreadsheets like Lotus recalculate the entire spreadsheet every time a change is made or data entered. Expert systems on the other hand approach problems in a way which separates data from procedures and they are thus far more flexible. The Mechanist Thesis implies that computers can communicate and can therefore understand whatever is being processed. The corollary of this is that human beings are machines and can therefore be 'duplicated' using computers. Shanker argues that supporters of the Mechanist Thesis commit the homunuclus fallacy in that they view the computer in anthropomorphic terms and ascribe human traits to something which is merely an electro-mechanical machine. Just as a pencil cannot write a computer cannot communicate or understand (Shanker, 1987, p.82). 12 An Illustrative Definition While no definitive description of expert systems exists (Leary, 1988b, p.8), and while numerous variations on the theme have been developed, there are several distinctive features common to nearly all expert systems. These features help to explain how expert systems are applied to problem solving and how they differ from conventional techniques. Expert systems approach problems and issues by describing and defining the problem itself. They can work with information that is known, partly known, intuitively felt, or guessed about a problem or range of issues. Consequently, they can and have to work with uncertain or missing pieces of information (Leary, 1988b, p.8; and others). This may be one of their biggest advantages over algorithmic and linear programming techniques, especially in applications for the social sciences. Another important feature is that expert systems use rules of thumb (or "heuristics") as part of their information processing and reasoning structure. These heuristics are "... problem solving strategies that point in the direction of a solution but unlike algorithms, do not guarantee that the right answer will be found." (Leary, 1988b, p.8). An additional and important feature of expert systems is that they have the facilities to "explain", on the basis of the information, heuristics, and assumptions they employ, how results were achieved (Leary, 1988b, p.8; and others). This ability means that expert systems have strong potential in the areas of education and job training but at the moment these explanations amount to little more than a listing or tracing of the information and rules triggered during a session with a user. It is hoped that research in the area of natural language interfaces (another of AI's sub-fields) will improve the quality of such explanatory facilities and allow the user to employ a representational formalism closer to their native language than the somewhat cryptic and symbolic formalisms currently used for "communicating" with expert systems software. 13 Townsend gives an indication of the fields which have the potential to benefit from expert systems applications in his definition of expert systems themselves: Expert systems are a class of computer hardware and software that can help advise, diagnose, analyze, consult, and categorize. They are tools for problems that normally require the use of a human expert, professional or specialist. Unlike traditional computer hardware and software that attempts to solve problems using defined procedures, expert systems attempt to solve problems in specific disciplines using deductive reasoning. As a result, expert systems are capable of solving problems that are unstructured and poorly defined. (Townsend, 1987, p.4) Another facet of expert systems is revealed by the following description: Expert systems actually have built into them the knowledge of human experts, and they draw on it to solve problems.... this differs markedly from conventional computer programs, which manipulate numbers and quantities, pluses and minuses, in precisely specified ways. (Van Horn, 1986, p.5) This description illustrates how expert systems are linked to the field of A l and are imbued with A l philosophy. Implicit in Van Horn's definition is the fact that expert systems can capture all human knowledge perfectly and thus perform a specific task as well or better than their human counterparts. They should therefore be able to replace human experts in virtually any limited area. It is sufficient at this stage to simply point out that there is considerable debate concerning the development and use of expert systems for this purpose; this is something which will be discussed in more detail later on. For now we will limit our discussion to the positive, and hence biased, literature on expert systems. Expert Systems Structure Expert systems consist of two basic elements - a knowledge base (analogous to a database) and an inference engine - although additional components may also be incorporated 14 f Figure 2.1 •a o H V3 E u 0) o . u c w> c •J uo u V! c V u 'c / c .2 E p - I Expert Systems Structure Source: Proceedings of the Workshop on the Appl i r-afinn of Rvpgrt-Systems to T r a n q p n r ^ H n ^ Transport Canada. 1985, p.4. 15 into any given system. A central element of expert systems (also called knowledge-based systems) is the fact that the inference engine and knowledge base are separate and independent entities not only in terms of content but also structure (Cullen, 1986, p. 243). Figure 2.1 shows the basic structure of a generic expert system as developed currently. The theory behind expert systems is that professionals and experts use facts, heuristics, and logical, easily identifiable, reasoning processes to evaluate and solve problems. "Heuristic methods include rules of thumb, intuitions, simplifications, judgements, and other problem-solv-ing approaches that may not find the best solution but often find useful solutions quickly." (Ortolano & Perman, 1987, p.98) A l l one has to do to encapsulate this knowledge, and the reasoning processes used, into an expert system is to extract them from the expert - a process known as Knowledge Elicitation - and to use a suitable representational structure, or formalism, for 'storing' the information in the knowledge base - known as Knowledge Engineering. Obviously, all of an expert's knowledge could not possibly be encoded into a knowledge base in its entirety since a human's range or domain of experiences is so vast. The way expert systems designers have addressed this problem is to identify specific tasks (from the range of tasks a human expert handles) which are amenable to expert systems solutions. Thus, expert systems are designed to favour domains (i.e. problem areas) which are well structured and narrow in scope and which represent a portion of a human expert's domain. The Knowledge Base The Knowledge base acts as a kind of library or repository of knowledge or information. It contains both quantitative and qualitative information such as facts, definitions, data, heuris-tics, and other 'expert knowledge', which describe the character of aparticular domain. "Sources 16 of that knowledge include published materials, quantitative analysis programs, and the intuitions and problem-solving strategies of experts in the subject area." (Ortolano & Perman, 1987, p.98). This information is then stored using a symbolic shorthand notation which can be processed by the inference engine and which can be modified or added to relatively easily. The Inference Engine T o use this stored knowledge one has to create a mechanism - the inference engine - for searching the knowledge base and manipulating the information contained within. The engine describes (using the same representational structure as the knowledge base) how the 'symbols' (or information) contained in the knowledge base are to be manipulated and the order in which inferences are to be made in any given situation. "The main requirements for an inference engine are (1) a way of determining when and where to start, (2) a procedure that defines how to search toward a result, and (3) a way of determining either that the result has been found or that no result can be found." (Tello, 1988, p. 106). To achieve these objectives the engine must be able to carry out two functions: A) Control the way in which the knowledge base is searched, and B) Make inferences about and between elements of the knowledge base. The two most common control strategies employed for searching a knowledge base are forward chaining and backward chaining (Townsend, 1987, p. 139). Backward chaining is goal directed, or to use the computer jargon a "top down" search method. The system takes a goal as given and tries to substantiate it from information contained within the knowledge base. Forward chaining operates on the reverse principle and is a 'data-driven' or "bottom up" search strategy. Forward chaining takes facts and tries to deduce conclusions (i.e. goals) from them (Leary, 17 Figure 2.2 Backward Chaining: I n i t i a l F a c t s Source: Townsend, Carl; Mastering Expert Systems with Turbo Prolog: Howard W.Sams & Co..Indianapolis, Ind.; 1987, p. 138. 18 1988b, p.9). The difference between these two strategies is illustrated in Figure 2.2. For a more detailed and comprehensive discussion of search and control strategies see Tate (1985). The inference engine also contains the mechanisms by which inferencing, that is the system's 'reasoning process' is carried out. These mechanisms are dependent on the repre-sentational structure employed (these are discussed below) and therefore on the type of software tool used, but regardless of these the inference engine performs several functions which make the reasoning process work. The basic functions that an inference engine requires, as expressed by Townsend (1987, pp. 132-3), concern missing information, uncertainty, and the facility for producing explanations. First, in the event that the system cannot prove a goal or reach a conclusion due to missing information (or for any other reason) the engine must be able to backtrack and try different avenues of enquiry. In this way the engine directs the search only to those areas of the knowledge base which are likely to lead to success. Second, much information, especially in fields like planning, has a level of uncertainty associated with it. The most common way of dealing with this problem is to attach uncertainty values (usually between 0 and 1 and hence similar to probabilities) to elements of the knowledge base and to include a function for propagating these values through the knowledge base as goals or sub-goals are substantiated or conclusions reached. It should, however, be noted that serious theoretical flaws have been discovered with this approach and that nearly all the other techniques which have been developed to deal with uncertainty are ad hoc at best. Finally, as has already been discussed, the inference engine needs to contain a component which explains how and why a result was achieved. At this stage it should also be noted that some expert system software tools have a built in inference engine, leaving the user to supply only the information for the knowledge base. 19 Some of these tools allow one to manipulate and modify the engine although quite a few, especially the cheaper ones, do not. Representational Structures Several representational structures have been developed for encoding information into the knowledge base and for programming the components of the inference engine. Among these are frame representations, blackboard environments, and production-rule systems, and some software tools allow combinations of these structures to be used (Townsend, 1987, p. 136). Neural networks, another representational structure, represent knowledge in terms of intercon-nections between nodes. Neural nets are thus themselves information whereas conventional schemas are merely representations and store information as discrete packages."... neural nets emulate the webs of neurons that make up the brain itself. Thus, neural nets are composed of thousands of interconnected, simulated neurons. Unlike conventional rule-based computer systems, in which instructions are executed serially, neural nets can process multiple instructions synchronously." (Jerome, 1989, vol.2, no.3, pp.72-3). While fascinating in and of themselves, neural nets are really beyond the scope of this thesis since we are interested more in tools for urban planning rather than in systems which model the brain (for a wider ranging discussion of neural nets see the December 1989 issue of A l Expert). While the form of the knowledge base depends upon the representational structure used it is convenient for present purposes to think of the knowledge in terms of an hierarchical tree structure similar to a semantic network (Figure 2.3). Each node in the tree can be thought of as a piece of information - a fact for example - while the links between the nodes indicate the 20 Figure 2.3 A Semantic Network to Diagnose a Car's Failure to Start: CAR! — NODE iPONTIACr has a / has a is A L T E R N A T O R has B A T T E R Y BRUSHES -j S T A R T E R M O T O R H N O T DEFECTIVE] has ICONNECTIONSl is lLOWl NOT DEFECTIVE Source: Townsend, Carl; Mastering Expert Systems with Turbo Prolog; Howard W.Sams & Co..Indianapolis, Ind.; 1987, p. 121 A Hierarchical Tree Structure Describing Design Guidelines for Ensuring Internal Privacy HOUSE ENVELOPE - INTERNAL PRIVACY PUBLIC ZONE PRIVATE ZONE SET S M A L L SET FORWARD WINDOWS B A C K SCREENING DESIGN REMOTENESS Source: Leary, M.E.; "Knowledge and reasoning in development control and urban design: an expert systems approach; Environment and Planning B: Planning and Design; 1988; Vol. 15, p. 391. 21 Figure 2.4 The Frame Structure: Frame Concept Slot #1 Value #1 Slot #2 Value #2 Slot #3 Value #3 Slot #4 Value #4 Procedure #1 Procedure #2 Procedure #3 -*»• Procedure #4 A Frame Representation for Classifying Computers: Format: Microcomputer Example: John's PC CPU Monitor Keyboard Ports Printer CPU 80286 Monitor Colour Keyboard | Enhanced Ports | 2 Printer Yes Source: Floyd, Michael; "Suitable for framing: An object-oriented approach using frames can make an unruly knowledge base more manageable."; Turbo Technix: March/April, 1988, pp. 80-4. 22 Figure 2,5 A Blackboard System for Job Indentification Control Blackboard: Controls how the occuoation and Dersonalitv blackboards function. Problem Control Strategy: Strategy Level of Focus General Abstraction Policy 1 To-do-set t Chosen Action Specific Occupation Blackboard: Identifies suitable jobs Direction of Inferencing Specific Jobs Job Types Level Abilities Interests 4 - input School Subjects 4 - input Occupation Personalitv Blackboard: Identifies Dersonalitv traits and Dasses them on to the Occupation Blackboard Direction of Inferencing A Relationship Level Character Features ^ - input Personality Source: Boyle, C.D.B.; "Acquisition of Control and Domain Knowledge by watching in a Blackboard environment." in: Martin Merry (Ed); Expert Systems '85: Cambridge University Press, Cambridge, 1985, pp. 274-5. 23 explicit relationships - e.g. rules of thumb - between nodes which the inference engine uses to search the knowledge base (Leary, 1988a, p.389; Townsend, 1987, p. 121). Frame representations are similar in structure to databases, or records in a spreadsheet program and "... are useful in handling complex situations involving objects and classes of objects." (Ham, 1984, vol.2, no. l , p. 37). The frame is used as a tool for organizing disparate pieces of information, such as objects or concepts, into groupings and each frame has 'slots' for storing all the information associated with the object or concept it represents (see Figure 2.4). Each slot can have a value or attribute attached to it as well as a procedure describing how the information in that slot is to be handled (Floyd, 1988, p.80) and the frames are linked to each other by a hierarchical structure. A n important feature of hierarchical frame structures is that frames can inherit the properties of frames above them in the hierarchy (Townsend, 1987, p. 124). For a more detailed explanation of frame representations see the rest of Floyd's article (1988, pp. 80-8) which shows an example of a frame representation using Turbo Prolog, as well as Townsend (1987, pp. 124-7, 135-6), and Tello (1988, pp.414-6). Blackboard systems consist of a common workspace - the 'blackboard' - and multiple processing components, each of which works on a particular aspect of the overall task (see Figure 2.5). "Blackboard systems are used when external events arrive at the system sporadically and many levels of knowledge are required." (Ham, 1984, vol.2, no. l , p. 37). The blackboard itself controls how the various components are used and contains procedures which handle each component as if it were a database. Information and results retrieved into the blackboard from a particular 'database' become accessible by all of the other 'databases' for use in further computations (Ham, 1984, vol.2, no. l , p. 37). It should be clear that the individual 'databases' 24 Figure 2.6 An Example of Rules and Facts in a Rule Based Expert System: The URBYS  System URBYS contains rules in the following semi-English format: (1) public land(43); (2) IF public land (X) THEN any new construction should be limited in (X). (3) IF public land (X) AND close to center (X) THEN any new construction should be limited in (X) AND reserved for green spaces (X). (4) IF (X) is the town center A N D (Y) is a direct neighbour of (X) THEN (Y) is close to the town center. These can be translated as meaning the following: (1) area 43 is public land; (2) if a zone is public land, then any new construction must be limited in this area. (3) if a zone is public land and it is close to the center then any new construction should be limited in this area and the zone should be reserved for green space. (4) if an area is the town center and another area is next to the first, then the latter area can be defined as being close to the town center. Source: Tanic, Emile; "Urban Planning and Artificial Intelligence: The URBYS System."; Computers. Environment, and Urban  Systems: 1986, Vol. 10, Nos. 3/4, p. 139. 25 in such a blackboard system could be expert systems themselves and these could be rule- or frame-based, thus creating quite a powerful and flexible structure. For an example of an expert system which uses this blackboard architecture see Boyle's description of the J O B B E S system, in Merry (1985, pp. 273-86). Production-rule systems are by far the most common representational structure employed in expert systems (Townsend, 1987, p. 129) and express information in the knowledge-base in terms of statements (i.e. facts) and IF—TFfEN rules. Logical operators - A N D , OR, N O T (see Schnieder et al, 1982, p. 101) - can also be incorporated into the rules to create conjunctive and disjunctive clauses. Figure 2.6 illustrates what a rule-based system looks like in its English language equivalent, using information from an urban planning domain, and is taken from Tanic's discussion of the U R B Y S system (Tanic, 1986, p. 139). Thinking back to the semantic network discussed earlier it should be clear that the factual statements in a rule-based system are analogous to the nodes of a semantic network and the I F — T H E N rules are the linkages which explain the relationships between facts. These rules and facts can represent qualitative information since they are based on predicate and not proposi-tional logic (Van Horn, 1986, p. 137). Under predicate logic (or predicate calculus as it is also called) the I F - T H E N rules are treated as LE-proposition(s)-THEN-conclusion statements. To verify if the conclusion is true, a backward chaining system would search the knowledge-base to determine if the proposition(s) is true (i.e. if the information in the knowledge base supports the proposition). If it is true then the conclusion would also be treated as true whereas if the information in the knowledge base is insufficient or refutes the proposition(s) then the con-clusion is considered to be false (Van Horn, 1986, pp. 137-41). Such true/false determinations 26 can be made because predicate logic operates using a principle known as MODUS PONENS. This "... states that if a rule exists such that TP A, THEN B' and if A if known to be true, then B is true." (Townsend, 1987, p. 132). Note that these true/false judgments are only true/false in a logical sense. All a return of "true" means is that the system can 'prove' the conclusion, while "false" simply means that the conclusion cannot be proved using the information currently contained in the knowledge base. It does not mean that a conclusion has any inherent truth or falsity built into it. Note also that the use of a true/false test does not allow for uncertainty to be incorporated into the rules and statements since predicate logic in its strictest sense can only deal with absolute truths and absolute falsities. This problem can be solved to some extent by incorporating relational operators (such as <, <, =, * , >, >, see Schnieder et al, 1982, p. 101) into the rules and statements of the knowledge base although this would also require the inclusion of numeric values for testing the relations and would still not provide a method of handling uncertainty. In order for the system as a whole to work, the conclusion section of a rule has to be tied to the proposition section of other rules in the knowledge base. Rules and facts are thus triggered by others which are linked to them or as a result of asking the user the answer to a specific question through what is known as a 'query-the-user' facility. Notice that in this regard a fact can be thought of as a rule which is always true (i.e. it is not conditional since it does not have a proposition attached to it). Production-rule systems allow information to be stored in a well structured manner, the rules and facts in the knowledge base creating a very clear description of the task which makes the system easy to both build and read. As the knowledge base becomes larger and more 27 complex, however, it becomes unwieldy, difficult to control, and less easy to interpret since more and more rules are required to express the problem clearly (Aleliunas, 1989; Floyd, 1988, p. 80). Nevertheless, for the purposes of this thesis and the demonstration system, this rule-based approach is sufficient for presenting the concept of expert systems applications in urban planning. Software Tools for Developing Expert Systems There are two principal types of software available commercially for developing expert systems applications: 1) Programming languages; and 2) Purpose built expert systems and expert system shells. Within these two categories there are a wide variety of software tools. Indeed, a quick survey of the marketplace (based upon lists of vendors published in the magazine A l  Expert) reveals that some 39 expert system tools are available (Anon, 1988, vol.3, no.9, pp. 71-2,74, 76-7) as well as 22 versions of the A l language LISP (Hildebrand, 1988, vol.3, no.3, pp. 67-72) and 24 versions of Prolog (Shafer, 1988, vol.3, no.6, pp. 71-5). Other languages, such as Smalltalk and OPS5, have also been developed for A l and Expert Systems research, and procedural languages such as Pascal, FORTRAN, or C can also be used although developing workable applications with the latter can prove to be difficult (Tello, 1988, p. 323). Obviously, the choice of which software tool to use is dependent on installation and training costs, one's existing hardware, software, and human resources, software performance, and the types of applications to be developed. Some languages and tools require mainframes, dedicated worksta-tions, or even supercomputers to operate and the software alone can cost anywhere from about US$ 1,000 to US$ 70,000 (Burlinson, 1989). Hardware designed specifically to run particular types of A l software is also available but it too is expensive (Sobkowski & Tischler, 1988, vol.3, 28 no.9, p. 67). LISP machines for example are designed solely to run the LISP language and the hardware/software comes as one integrated package which can be difficult to learn; see Graham, (1988, vol.3, no. 12, pp. 26-32) for a more detailed discussion of such machines. By contrast, there are numerous software tools available for the current range of personal computers: I B M PC's , X T ' s , A T ' s , and compatibles; 80386 machines; PS/2's; Apple Macintosh's; and there are even tools for 'home' computers such as the Atari S T and Apple II series. These software packages can cost anywhere from US$ 50for relatively simple tools to a few thousand dollars for very powerful development environments, though there are quite a few powerful and easy to use tools, such as Level 5, at around the US$ 600 mark. In terms of selecting software for any task, including expert systems applications, it should be pointed out that substantial thought needs be given to the availability and cost of support material and services in addition to the cost and performance of the system itself. Support services can include tutorial packages, user guides and manuals, consultation and trouble shooting assistance, and software updates, in addition to the system itself (Hildebrand, 1988, vol.3, no.3, p.68). Another important factor which should be considered and which emerged in the course of selecting the software for the demonstration project developed here is the availability of handbooks and reference material published by third party sources. Because of the vast and diverse range of tools available, it is impossible to cover all of them here and so the discussion will be limited to a generic description of two of the more popular classes of A I programming languages: LISP and Prolog; and to that class of tools known as Expert Systems and Expert System Shells. For a more in-depth analysis of these and a wide range of other tools see Tello (1988). 29 LISP The LISP, or LISt Processing, language was developed by John McCarthy in the mid 1950s and is thus second only to FORTRAN in terms of its age (Tello, 1988, p. 323). It is also the standard language of A l and Expert Systems research in the United States although it has been challenged more recently by Prolog. As its name implies LISP is designed to manipulate lists of information but the feature which differentiates it from other languages is that this information is symbolic not numeric. In fact LISP is notoriously poor at handling numbers and formulas because it has to treat them as symbols (Hasemer, 1984, p. 2). The building blocks of LISP are not numbers but atoms; these can be words, numbers, phrases, etc.. One or more atom(s) can be used to make up a list and variables can be 'bound' to these atoms for the purposes of evaluation, using several functions available for manipulating the lists. LISP has a few other distinguishing characteristics worth noting. Firstly, its interactive nature means that the com-puter responds each time the user inputs something (although this is only true of interpreted LISPs and not compiled LISPs). Secondly, like Pascal, LISP allows recursion, that is for functions to invoke themselves (Schnieder et al, 1982, p. 299; Hasemer, 1984, pp. 23-6) and thus allows lists to be manipulated by a function repeatedly until the desired result is achieved. And finally, functions and data are described using the same language structure and are thus indistinguishable from each other. An example of LISP code for defining a function called "do-something-with" is shown below to illustrate this point as well as the LISP language as a whole and is taken from Coffee (1988, vol.3, no.3, p. 39). In the example, anything to the right of a semicolon is a comment to clarify what the function does, and is ignored by the computer during execution. Note also that 30 "list-of-values" is a variable which represents a list of items and that the function names are user-defined surrogates of standard LISP functions (see Coffee, 1988): (define-a-function ;; called do- something- with ;; taking as input (list-of-values) ;; a list called list-of-values ;; and working as follows: (if (null list-of-values) ;; if list-of-values is empty nil ;; then return the result "nothing" ;; otherwise, return the result of (make-list-be ginning-with (some-function-of (first-of list-of-values)) ;; and ending with the result of (do-something-with (rest-of list-of-values))))) This code defines a function called "do-something-with" which has as its input a list of information called "list-of-values". If "list-of-values" has nothing in it (i.e. it is empty) the function returns the result "nil" which means that "do-something-with" can't do anything since there is no input for it - you can't do something with nothing. If, on the other hand, the list contains something then the function is told to construct a new list called "make-list-beginning-with" by applying the function "some-function-of to the first element of "list-of-values" and by applying "do-something-with" to the remaining elements in "list-of-values". This latter call to "do-something-with" occurs within the original definition of "do-something-with" and so invokes the whole "do-something-with" function again, this time to the remaining elements of the "list-of-values". Consequently, "do-something-with" applies the function "some-function-o f to every element of "list-of-values" until the list is empty and then stops; this is the principle of recursion. The example below illustrates recursion more clearly and is taken from Hasemer's introductory text on LISP (Hasemer, 1984, pp. 24-5). The pseudo-LISP code: 31 (defun shorten (L) (print L) (stop if the list L is empty) ;; i.e. return 'NIL' (shorten (cdr L))) defines a recursive function called 'shorten' which takes a list, prints it out and then deletes the first entry (the function of the (cdr L) term). The last line in the above code contains a call to 'shorten' (using the truncated list) which is within the limits of the original 'shorten' call (i.e. the function is recursive) and so 'shorten' starts all over again and keeps repeating the same steps until the list is empty. Thus given a list called animals and containing three atoms - ( C A T M O U S E D O G ) - the call "(shorten animals)" would result in the following output: These features mean that LISP is tremendously flexible and can modify and write itself as well as build complex functions from a standard set of simple functions. It is, therefore, useful for developing systems which can "learn" or need to add to their store of knowledge. However, LISP also has a reputation for being slow and for requiring large amounts of memory space in order to operate (hence the need for dedicated LISP machines). The author also found it difficult to interpret code listings. For a more in-depth introduction to the LISP language see Halsemer(1984). ( C A T M O U S E D O G ) ( M O U S E D O G ) (DOG) N I L - The original list - The list minus the 1st element - The list minus the 1st & 2nd elements - Stop since the list is now empty 32 Prolog Prolog stands for PROgramming in L O G i c and was developed by Alain Colmerauer's team at the Universite du Marseilles in 1972 (Tello, 1988, p. 364). It is much more popular in Europe than in the U.S. and has been selected by Japan as the basis for their "Fifth Generation Project" computer initiative. The standard syntax for Prolog is Edinburgh Prolog developed by Clocksin & Mellish and their text: Programming in Prolog (1987, 3rd edition) is the standard reference work. Prolog, like LISP, is a symbolic, declarative language but instead of being built around list manipulation it is based upon first order predicate logic (though both LISP and Prolog can handle TF—THEN rule structures) and this has built into it a basic inferencing mechanism which can be augmented by the user. The similarity between first order predicate logic and natural language constructions makes the concept of Prolog deceptively simple to understand at first but provides a powerful language which can become very complex. The easiest way to understand Prolog is to compare English sentences with their Prolog syntax equivalents. Suppose, for example, that we had the following land use information which we wanted to express using Prolog syntax: 1) . Council's policy is that land in D . L . 273 which is zoned for public use should not be developed. 2) . Lot 12, in District Lot 273, is zoned public use. These would look like this in Prolog: 1) . do_not_develop(X):- is_in(X, d 1273), is_zoned(X, public.use). 2) . is_in(lot_12, d.l 273). is_zoned(lot_12, public.use). 33 Notice that the Prolog statement in 1) represents an IF ~ T H E N rule and that the two statements in 2) represent facts. To clarify the more confusing elements of Prolog syntax: ":-" translates as "if"; a comma after a fact as the logical operator "AND". Like LISP, the same Prolog structures are used to describe both facts and rules and thus pieces of "data" are indistinguishable from the "guts" of the program even though they remain functionally distinct. It should be clear that we could add more facts to the above two, as in 3) below: 3). is_in(lot_ll,d_l_273). is_zoned(lot_ll, commercial). without having to alter rule 1) and that this rule would still be able to evaluate the additions. By the same token, we could add additional rules to operate on the facts available and it is in this manner that rule-based expert systems are built using the Prolog language. Notice that the facts and rules in such an expert system can only be true or false since Prolog's inferencing mechanism - predicate logic - and pattern matching capabilities can only determine absolute truth and absolute falsity. The way of solving this problem, as mentioned earlier, is to incorporate one of several uncertainty techniques for handling the inferencing process when information is missing or has some form of uncertainty associated with it. Among these techniques are: Zadeh's fuzzy logic or fuzzy sets (which allows truth values to range between 0 and 1 and includes rules for relating these to one another); Shortliffe's certainty factors (already mentioned); and non-monotonic logics (non-linear reasoning heuristics - "leaps of thinking" (Burlinson, 1989)). For a more in-depth discussion of what constitutes uncertainty and a description of the techniques which have been developed to handle it see the comprehensive paper by Mamdani et al in Merry (1985, pp. 181-194). 34 One of the strongest features of Prolog is the relative ease with which the programming code can be read and this should be readily apparent from the above example. In this respect, it is easier to read than LISP although trying to follow the way that predicate logic works in even relatively small knowledge bases can prove tricky, especially for those with knowledge of procedural languages. Prolog works by responding to questions (or goals) posed by the user. Prolog then uses the backward chaining technique, already mentioned, and searches the knowledge base trying to find information which verifies the goal. Forward chaining can also be programmed in Prolog but the majority of Prolog programs backward chain since this control strategy is an inherent component of the language. Thus if we asked, based on the knowledge expressed above: 4) . ?- do_not_develop(What). Prolog would respond: 5) . What=lot_12 N.B."?-" is a Prolog prompt and "What" is a variable since it starts with a capital "W". Thus constants start with lower case letters. The chief advantage of Prolog over LISP is that programs usually take up less memory space. During processing, however, it is sometimes difficult to prevent the backward chaining process from getting out of hand (Tello, 1988, p. 384). Consequently, the efficiency of Prolog depends upon the order of the rules and facts within the knowledge base and the way in which rules narrow the search space early on. Even so, as a language in which to develop demonstration systems, Prolog can yield results in less time than with other languages since it can be built up 35 in modules (Cooper, 1989, pp. 5-9) and because it is primarily a declarative language and describes a problem not how to solve it. Turbo Prolog 2.0 While most versions of Prolog follow the Clocksin & Mellish standard, a popular alternative dialect, is Borland International's Turbo Prolog, introduced in 1986 and now available as Version 2.0 (Horak, 1988, vol.3, no.6, p.77). There is great debate over whether or not Turbo Prolog is a true Prolog language since it does not contain some of the standard Clocksin & Mellish predicates and incorporates "strong typing" in order to run faster. The use of "strong typing" means that every predicate and argument type must be specified at the beginning of the program and in this respect Turbo Prolog is very similar to the Pascal language which also incorporates type checking (Rich & Robinson, 1988, pp. 62-6). Furthermore, Turbo Prolog is compiled rather than interpreted and again this is in the interest of speed. Compiled languages translate programs into machine code and evaluate them in one go whereas interpreted languages translate and evaluate programs line by line and are thus more flexible. These limitations mean that Turbo Prolog does not have the flexibility or sophistication of standard Prologs and thus cannot handle truly dynamic, flexible knowledge bases (Shammas, Sept. 1986, p. 295). Nevertheless, while Turbo Prolog is not really a fully functional Prolog language, it does . have several advantages and has been recommended as a suitable language for beginners because of its simplicity (Horak, 1988, vol.3, no.6, p. 77). Chief among these is that Turbo Prolog is quite a powerful and yet inexpensive (less than US$ 150) tool and has excellent documentation and user support. There are also a wide variety of third party texts describing the language 36 available. Turbo Prolog is able to handle external databases and quite complicated graphics and also has an editor and development environment which is very easy to use. These features mean that it is "... a robust tool for rule-based decision support, statistical analysis, and general graphics." (Horak, 1988, vol.3, no.6, p. 78) and as a result it has been chosen as the tool with which the demonstration system will be developed. For a more detailed discussion of Turbo Prolog's features see Rich & Robinson (1988) and Rodgers (1987). Expert Systems & Shells Another variety of software for developing expert systems are the purpose built tools that either provide a ready-made "off-the-shelf" expert system or an environment in which expert systems can be built. Ready-made systems contain a developed knowledge base and inference engine which can be put to immediate use in solving problems for a specific domain. More interesting, though, are those tools which allow users to develop their own applications. Many of the simpler development tools contain a pre-programmed inference engine and provide the user with tools for building their own knowledge bases. That is, they are expert systems with empty knowledge bases - these types of tools are known as expert system shells. To produce a functional expert system, all the user has to do is to supply the appropriate information for building a knowledge base in the desired domain. Some shells, such as VP-Expert, PC-Expert, and others (see the magazine AI Expert), provide the user with a spreadsheet-like workspace for organizing and structuring the knowledge to be used into record-type entries. VP Expert even provides routines for linking its expert systems with spreadsheet programs such as VP Planner or Lotus 1-2-3 (Tello, 1988, p. 132). These types of shells then automatically create the rule base using pre-defined routines. Thus, a knowledge base can be built from case-data or a 37 series of examples. The user then provides a series of questions which are linked to the rules in the knowledge base. These questions are used to "query-the-user" for answers to each question. The input provided is checked against the rule base to determine a result or to identify the next question which needs to be asked. This process is repeated until the system exhausts all the possibilities and/or arrives at a conclusion. This query-the-user process is used in most expert systems and it is important to note that the user is only asked questions and provided with responses which are of direct relevance to the user's needs. This is unlike the process used by most database and interactive systems which have to search their entire databases and ask irrelevant questions in order to provide results, some of which may themselves be irrelevant. In this sense then, Expert Systems search their knowledge bases in an almost intelligent manner. Advanced shells, such as Level 5, provide more flexible development tools but also they provide menu options with explanation facilities. For example, Level 5 allows the user to ask at any point in a consultation session what the system is trying to prove and why it is trying to prove it. These facilities mean that the user can assess the reasoning processes behind a result • and thus the system becomes more transparent to the user. At present though, such explanations amount to no more than a display of the current rule being evaluated and the goal being pursued, or a listing of the rules triggered and facts deduced up to the point of query. They are an improvement on A l language tools which require that the user program explanation facilities into the expert system in addition to having to program the system itself. As natural language interfaces improve, these facilities will no doubt improve and provide more dynamic interaction with the user. 38 Landmark Expert Systems: MYCIN & PROSPECTOR MYCIN MYCIN, one of the first expert systems, was the result of a research project at Stanford Medical Center to produce a computer tool which could assist doctors in the diagnosis and treatment of a range of infectious blood diseases (Van Horn, 1986, p.9). It operates in a very narrow and well structured domain and contains a knowledge base which relates symptoms to associated diseases. Users go through an interactive session by responding to questions about symptoms possibly exhibited by the patient and by supplying information in the form of test results. Throughout a session MYCIN interacts with the doctors in English. MYCIN led to the development of EMYCIN, one of the first expert system shells to be developed. EMYCIN, or "Empty MYCIN", contained MYCIN'S inference engine without its medical knowledge base and left the user to supply information for their domain of interest. While MYCIN is hailed as a landmark system, some have noted that its success rate is only about 70%. Consequendy, it will yield a mis-diagnosis in three out of every ten cases and while this may be better than the performance of a beginner it appears to be no match for a true expert with many years experience (Dreyfus & Dreyfus, 1984, p. 231). This raises some serious ethical questions about expert systems and it has been shown that in order to improve the success rate of any expert system the number of rules in the knowledge base has to be expanded substantially. Indeed, the law of diminishing returns means that each unit increase in the success rate requires an ever increasing number of additional rules. For more information on MYCIN see Tello (1988, pp. 101-5) and Van Horn (1986, pp. 5-10). 39 P R O S P E C T O R P R O S P E C T O R was developed at the Stanford Research Institute (now SRI Internation-al) during the mid to late 1970s with the help of the U.S. Geological Survey (Tello, 1988, p. 101). P R O S P E C T O R consists of several ore deposit models which take advantage of expert systems technology. These models are designed to assist geologists in evaluating field explora-tion data for a specific site and in determining where mineral deposits are likely to exist. P R O S P E C T O R is a rule-based mainframe expert system, written in INTERLISP (a dialect of the LISP language), and contains geological information which is represented in the knowledge base using a combination of taxonomies and semantic networks. Fuzzy set theory is used to handle uncertainty (Benson, 1986, p. 19-23). The ore models were built up from case data and were refined through a series of workshops and discussions with geological experts as well as through sensitivity analyses and performance tests using field data where the outcome was • already known (Benson, 1986, pp. 23-5). During a typical run session, P R O S P E C T O R requires that the user enter field observa-tions pertaining to the site in question and this information is then compared to the system's models concerning soils, rock structures, minerals, etc.. If the information input is insufficient for it to reach a firm conclusion, P R O S P E C T O R will ask for additional information and can provide a rationale as to why that information is needed. Once it has enough relevant information to reach a conclusion it summarizes the results (Benson, 1986, p. 18). P R O S P E C T O R can also explain how it reached its conclusion or what it is trying to do at any point in the interactive session. 40 P R O S P E C T O R is an important system because it is hailed as one of the greatest successes of the A l and expert systems industry to date. It is claimed by many to have been 'responsible' for the discovery of a molybdenum deposit valued in excess of US$ 100 million (Tello, 1988, p. 101; and Van Horn, 1986 p. 10). But Dreyfus and Dreyfus (1984, p. 230) paint a different picture: In reality, the P R O S P E C T O R program was given information concerning prior drilling on Mount Tolman where a field of Molybdenum had already been found. (authors' emphasis) Indeed Dreyfus and Dreyfus go on to point out that all P R O S P E C T O R did was to map out the undrilled portions of the site using the drilling data already gathered and to suggest the extent of the ore deposit. Furthermore, while the ore found was very valuable, the geologists decided that it was too deep to be retrieved economically (Dreyfus & Dreyfus, 1984, p. 230). The example of P R O S P E C T O R raises some very challenging questions and points the way towards a critical evaluation of the role of expert systems in real world environments, especially Planning. This is something which will be discussed in more detail in Chapter Six but it should be pointed out now that such unrealistic claims of expert system performance do not necessarily mean that planners should ignore the potential for expert systems applications in their sphere, merely that they should steel themselves against the kind of" A l Euphoria" which has been so prevalent in other fields: most notably the U.S. defense industry which has invested heavily in A l research (Dreyfus, 1987, p. 41; Dreyfus & Dreyfus, 1984, p. 221; and Rosenberg, 1986, pp. 168-172). 41 A Sample of Expert Systems in Planning Since the mid 1980s there have been several Planners and Planning related professionals, as well as academics, involved in developing Expert Systems for Urban Planning domains and other related fields. By far the majority of these have been developed as ongoing research projects in order to test .their performance and to see how planners react and adapt to them. U R B Y S U R B Y S , developed by Emile Tanic for the Municipality of Fort-de-France, Martinique, represents one of the first attempts in applying A I and Expert Systems research to a planning sphere (see Tanic, 1986). U R B Y S is a hybrid 'intelligent' urban information system comprising an expert system front end and a relational data base containing information and statistics on population, housing, land, infrastructure, etc.. The expert system's knowledge base contains production rules which are linked to the data base via an interface. These rules determine how the data base is searched and how conclusions are reached. However, whether a rule is triggered or not is dependent upon variables contained in the IF portion of the IF—THEN statements and the values of these variables are contained in the relational data base (Tanic, 1986, pp. 140-3). It is unclear from Tanic's article exactly how U R B Y S would be used in a Planning Department, for example. Tanic does argue, however, that Planners spend an excessive amount of time (he estimates approximately 60-80%) researching and organizing information concern-ing various planning issues and development proposals. Given this situation, it appears that the purpose of U R B Y S is to speed this handling and organization of information (Tanic, 1986, p. 42 135) and to make it easier to analyse and draw conclusions from the large amounts of, sometimes conflicting, information collected from censuses, surveys and the like (Tanic, 1986, pp. 139-40). A D A P T A D A P T (A Decision A i d Planning Tool) is a knowledge-based Decision Support System (DSS) which has been developed as a demonstration project for assisting Australian land-use planners in drawing up zoning schedules (Davis & Grant, 1987, pp. 60). Decision Support Systems have developed out of the Management Informations Systems (MIS) developed in the 1970s and: ... represent a point of view on the role of the computer in the management decision making process. Decision support implies the use of the computer to: 1) . Assist managers in their decision processes in semi-structured tasks. 2) . Support rather than replace, managerial judgement. 3) . Improve the effectiveness of decision making rather than its efficiency. (Keen & Morton, 1978, p. 13; quoted in Rosenberg, 1986, p. 86) As Davis and Grant point out "The major task faced by planners when drawing up any land-use plan is to assemble information from diverse sources (for example, special interest groups, political parties, scientific predictions, personal experience) and make decisions that best satisfy the multiple goals advocated by these sources." (Davis & Grant, 1987, p. 55). Algorithmic models of such decision-making processes have been built in the past, witness the whole field of Operations Research, as well as Systems Theory, but by and large these have met with little success because of their grounding in the positivist tradition. A D A P T is an attempt to apply the flexibility, uncertainty-handling, and explanatory facilities of expert systems to the 43 decision making processes that planners frequently employ. The system is centred on three premises about expert systems which I feel are essential to the long-term development of successful applications in the planning sphere: 1) . While the simpler parts of most decision making processes can be 'automated' using expert systems, planners will still have to resolve the more complex problems which arise. It is highly unlikely that expert systems will ever be able to replace human judgement on planning issues completely. 2) . Despite 1. above, the expert system should act to support the planner in evaluating these complex issues. 3) . The reasoning processes used by the expert system and the planner in making decisions should be transparent, i.e. visible, to other planners, professionals, community groups, and the public at large, (after Davis & Grant, 1987, p. 60) A D A P T is written in F O R T R A N - 7 7 and so its production rule structure is rather restricted at present. The rule base contains land use policies, in an IF—THEN format, which determine how land-use activities in specific planning areas are assigned to land-use control categories such as "permit as of right" or "permit with Council consent". In general, the rules take the following format: Assign or exclude (activity) to (control category) on all (planning units) where (criterion) is true. (Davis & Grant, 1987, p. 60) Like U R B Y S , A D A P T is linked to a database containing statistical, geographic, and land-use information which forms the criteria to be met in the IF portion of the production rules. Davis and Grant illustrate some typical rules in their English equivalents: Exclude pig keeping from 'as of right' category if distance to town is less than 5 km and effluent disposal capability is low. 44 Assign pig keeping to 'as of right' category if current zoning is rural 1(a). Assign rural residential allotments to 'permit with council consent' if agricultural capability is class 3 or 4. (Davis & Grant, 1987, p. 60) The knowledge base structure of A D A P T allows it to handle cases where information is missing or where conflicting alternatives arise and to inform the planner/user of these cases. A D A P T also keeps track of the decisions which are made at each stage of the zoning allocation process and the reasoning which underlies each decision. At present, however, the system cannot assess the reliability or uncertainty of the information which it uses, or of the results which it achieves. Furthermore, A D A P T cannot determine which of the various interest groups' needs are met, or to what degree they are met, by the zoning scheme produced (Davis & Grant, 1987, p. 64). Finally, A D A P T is in the process of being developed and refined, and will be re-written in LISP or Prolog so as to rectify some of these deficiencies and to improve the overall performance of the system as a DSS tool for Planners. For a more detailed discussion of A D A P T and the stages of the decision making process which it goes through see the rest of Davis & Grant's paper (1987, pp. 53-66). Other Systems of Interest There are a variety of other expert systems tools in both planning and planning-related • fields. T o discuss these in any kind of detail would require much more space than is available here and so only a brief, and thus incomplete, listing of other noteworthy systems (and the associated references) will be made. 45 E S M A N E S M A N stands for Expert System for Manufacturing Site Selection and has been developed as a simple demonstration system by Suh et al (1988) at the Department of Urban and Regional Planning, University of Illinois. E S M A N has been designed to assist state and local planners in assessing and selecting suitable sites when approached by foreign investors wishing to establish manufacturing plant(s) in the U.S.. E S M A N is written using Texas Instruments' LISP-based shell Personal Consultant Plus (see Tello, 1988, pp. 279-93 for a description of this software) and is a rule-based system similar in operation to URBYS and ADAPT. For more information on E S M A N see Suh et al (1988, pp. 239-52). GRANT ADVISOR GRANT ADVISOR is a very simple, rule-based, expert system designed to assist junior planners at the Tayside Regional Planning Department in giving out initial information to the public concerning the range of government grants available to local businesses. The system operates interactively and asks the user a series of questions to determine the specific needs of the person making the enquiry. The answers to these questions are then applied to the various rules contained in the system and the rules that are triggered determine which portions of the knowledge base are searched for grants relevant to the user's needs. In this way, only grants appropriate to the user's needs are selected, unlike a traditional database solution which would also present grants irrelevant to the user. For a more detailed discussion of G R A N T ADVISOR see File & Oldfield (1988, pp. 29-30). 46 O T H E R S Y S T E M S Other expert systems of interest are JESSE, which models aspects of the decision making and planning processes involved in Japanese national energy policy, in relation to national and international threats to Japan's energy security (see Goel et al, 1987, pp. 178-87); H E R M E S (Heuristic Emergency Response Management Expert System), which is an experimental rule-based system for assessing emergency situations (caused by hazardous materials such as liquid chlorine), estimating hazard levels, and suggesting plans of action for dealing with the emer-gency such as containing the material and ensuring the safety of those nearby (see Clark et al, 1988, pp. 18-21); an expert system (built using the L E O N A R D O expert system shell) designed to assist planners in evaluating various development applications (see Leary & Rodriguez-Bachiller, 1988, pp. 26-8); and, a rule-based system developed by Hammond (1986, pp. 107-16) for representing the regulations of the U . K . Department of Health and Social Services and used for determining benefit entitlements. This last system is similar in concept to, but is more advanced than G R A N T A D V I S O R and uses A P E S (Augmented Prolog for Expert Systems) as the development environment (for a discussion of A P E S see Tello, 1988, p. 115-7) Research into other expert system applications for planning and planning-related fields has also been carried out or is ongoing in other areas (see Barath & Futo, 1984, pp. 135-54; Davis & Clark, 1989, pp. 1-18; Leary & Rodriguez-Bachiller, 1987, pp. 198-210; Diamond & Wright, 1988, pp. 205-14; Dickey etal, 1986, pp. 251-71; and Leary, 1988a, pp. 383-98). While research into expert systems for urban planning seems to be most advanced in the United Kingdom (especially at Oxford Polytechnic) and in Australia (primarily at CSIRO), there has been some interest in Canada with some research being carried out in the Department of Urban 47 & Regional Planning at the University of Waterloo. Unfortunately, it has not been possible to obtain any information on this research. By far the majority of Canadian expert systems research to date has been led by Transport Canada which has organized several major seminars and workshops on the subject (see Transport Canada, 1985 & 1986). Under their direction, and the direction of the Ontario Ministry of Transportation and Communications, several expert systems have been built although these are aimed primarily at engineering problems and infrastructure maintenance. For a review of these see Gomi (1987, pp. 24-42). Application Areas in Urban Planning There are a number of areas within the planning process where expert systems applica-tions can be fruitfully developed. Davis et al base their discussion of application areas on a definition of planning as a "... rationality-seeking activity ..." but one in which "... problem solving and decisionmaking (sic)...[is]... a continuous process which takes into account our uncertainty about knowledge of the environment, of community values, and of decisions in related fields. Finally, we view the process of... planning as one of accommodating learning from consultation and public participation." (Davis et al, 1987, p. 241) Despite the provisos included above, the authors remain squarely within the traditional • planning paradigm and break the planning process down into six stages, each of which presents opportunities for expert systems applications: 1) Goal Identification; 2) Design of Strategies; 3) Evaluation and Selection; 4) Devising Tactics; 5) Implementation; and 6) Monitoring. I do not propose to defend the rational paradigm here since it merely provides an organizational tool around which a discussion of expert systems applications can take place. For discussions of traditional and alternative planning theories see Hudson (1979) and Friedmann (1987). Most of 48 the potential applications in these six categories require that much more refined expert systems techniques be developed in order to be able to deal more effectively with the open ended nature of planning in general (planning does not take place in a closed system). Nevertheless, rudimentary tools have been developed to assist experts in representing and organizing knowledge in the areas of natural language and story understanding, automated knowledge elicitation, as well as problem solving in simple environments (see Davis et al, 1986, pp. 244-7). As the authors point out, these techniques, if suitably modified, could be of assistance to planners and community groups in eliciting their goals. We have already seen an expert systems implementation (JESSE) which assists energy policy planners in developing, refining, and selecting plans of action. Systems like J E S S E , as well as Decision Support Expert Systems (see Dickey et al, 1986) and the others described above, illustrate that expert systems applications could be of significant assistance over a large portion of the planning process - namely plan formulation, evaluation, and selection. However, the existence of these systems means merely that rudimentary systems have been developed in domains which mirror elements of the planning process and thus in theory could be extended to planning. It does not, of course, mean that they should be so developed, and any attempts in this regard would require that planners address more critically what the role of the computer should be in planning, especially vis-a-vis contemporary planning theories and alternatives to the traditional planning paradigm. Expert systems aimed at goal elicitation, plan formulation, plan evaluation, and plan selection in an open-ended and complex field like planning (i.e. truly comprehensive decision support tools) are many years from being realized. Certainly, using current expert systems and 49 AI techniques, it appears unlikely that such systems will ever be achieved barring a fundamental shift in hardware performance and/or expert system development philosophy. Nevertheless, there are elements of the planning process where current expert systems techniques are sufficient for providing useful workable tools within the next five to ten years, possibly sooner depending on the complexity and subtlety of both the systems developed and the domain in which they are developed. While it appears unlikely that expert systems have a role to play at the implementation stage of the planning process, since implementation requires actions and not decisions (Davis et al, 1986, p. 249), the example of A D A P T as well as research undertaken at Oxford Polytechnic (see Leary, 1988a & 1988b; Leary & Rodriguez-Bachiller, 1987) illustrates that development control (what Davis et al call "Devising Tactics") is an area where useful expert systems tools can be developed quickly and effectively although, as yet there are no operational systems in place (nevertheless work is progressing on a number of fronts). The monitoring of plans and development control policies is another area where the rule-based/pattern matching methodology of current expert systems can be fruitfully applied in evaluating the expected consequences of policies or plans against those actually realized. Monitoring expert systems which monitor in real time (i.e. they collect information immediately from sensors, computer links, etc.) have already been developed in industry and elsewhere (see Davis et al, 1986, p. 250). Similar systems in planning would not require a real time component and thus would enjoy a considerable savings in terms of complexity, size, and expense, although the process for selecting the indices and criteria for comparing normative and real results would need to be thought out clearly. 50 A n alternative way of evaluating potential application areas is to look at the types of tasks which expert systems themselves can perform and see where these overlap the planning process. Ortolano and Perman (1987) assess expert systems from just such a perspective and have identified the following tasks: Interpretation; Diagnosis and Prescription; Design and Planning; Monitoring and Control; and Instruction. It should be clear immediately that some, if not all, of these categories mirror Davis et al's classification of the planning process. Diagnosis and Prescription - "inferring malfunctions from observable data and prescribing remedies" (Ortolano and Perman, 1987, p. 100) - are both involved in issue identification, goal formulation, and plan preparation. Design and Planning - designing "... the form or arrangement of objects and actions under given constraints." (Ortolano and Perman, 1987, p. 100) - is similar to site planning, urban design, and site selection. Monitoring and Control -" . . . comparing observations to expected outcomes and governing the behavior of the monitored system." (Ortolano and Perman, 1987, p. 100) - are both elements of plan reviews, planning analysis, forecasting, and development control. A n d finally, both Interpretation -" . . . inferring situation descriptions from data." (Ortolano and Perman, 1987,p. 99)-and Instruction- "...expert systems that help novices understand concepts or learn to perform tasks." (Ortolano and Perman, 1987, p. 101) - are involved at every level of the planning process and planning activity. Under each of these five headings, Ortolano & Perman identify specific tasks and areas of application where expert systems have been or could be developed to assist planners. These will be summarized briefly below: 51 Diagnosis & Prescription Expert systems have been developed in project management to identify problems and constraints. Expert systems have been built to assist in the operation and maintenance of infrastructure (roads, sewers, utilities, etc.) (see Hadden & Hadden, 1987, for a discussion of an advisory expert system designed to help the Austin/Travis County Health Department assess sewage facility permits.) Design & Planning Expert systems have been designed for site analysis, site selection, and habitat management, (recall E S M A N ) Expert systems have been used to help select, calibrate, and interpret the output from complex mathematical models, (i.e. they could be applied to the urban and regional models currendy used by planners.) Monitoring & Control Expert systems have been proposed for climate control within buildings. Several research projects are currently under development for the purposes of zoning administration and development control. Interpretation Expert systems are being linked with existing data base management systems ( D B M S - see Rosenberg, 1986, p. 83-6) to provide 'intelligent data base tools' for assisting professionals in interpreting data, (recall U R B Y S ) . Expert systems have been developed to assist in evaluating legal information and could be applied to land-use law in the same way. (see Berkowitz & Strzepek, 1987, for a description of a legal expert system designed to help administer provisions of the 1982 U.S. Reclamation Reform Act.) Expert systems are being built to assess if development proposals meet the necessary zoning and land-use regulations. Expert systems could be developed to determine the amount of property damage caused by natural disasters. 52 Instruction Expert systems have been built to tutor and train junior staff and novices for specific tasks such as equipment troubleshooting and maintenance. (N.B. for a more detailed discussion of these application areas and for informa-tion on the kind of research which has been carried out, see Ortolano & Perman, 1987, pp. 99-101). Cullen (1986, pp. 249-50) has also addressed the issue of expert systems applications within planning and identifies three domains in which such systems could be developed, namely: Spatial and locational analysis; Development control and planning law; and environmental impact assessment. Concerning the latter there has already been some work completed by a local consulting firm in Vancouver (Environmental & Social Systems Analysts Ltd. , Office tour, June, 1990) but for a more detailed review of research in this area see Page (1989). Although not present in Cullen's review, I would also include economic impact assessment on this list since current techniques fail to handle the qualitative values which invariably emerge and which are a central element in trying to determine the impact of a project upon quality of life. Characteristics of Tasks suited to Expert Systems Solutions Obviously, expert systems, like any other tool a planner uses, are useful for solving some problems or tasks and not so useful in addressing others. A n analysis of the literature reveals several common characteristics of tasks which are likely to benefit from and be suited to an expert systems solution. The key characteristics, in no particular order of importance, are: * The task has many ways of being solved. * The task cannot be solved using conventional algorithmic methods. 53 * Experts cannot always agree on how the task should be solved. * A n incorrect or late decision has significant consequences. * Knowledge about the task is incomplete, uncertain, and subjective. * Conclusions and recommendations about the task may be uncertain. (see Townsend, 1987, p. 112; Van Horn, 1986, p. 48; and Sandra Cook, referenced in Dreyfus & Dreyfus, 1986, p. 120-1) These characteristics describe features of the planning process in general as well as tasks within the planning process itself and so expert systems have significant possibilities with a range of planning domains. Within this range however, there are specific tasks which are more suitable than others as platforms from which initial demonstration expert systems can be developed. Choosing the correct domain for building a demonstration system depends upon achieving a balance between a complex 'meaty' problem and one which is manageable and relatively easily solved. Furthermore, knowledge about the chosen domain must be readily available, preferably in a structured short-hand form such as a procedures or regulations manual. The assistance of one or more knowledgeable experts can also be critical in developing the heuristics and rules of thumb necessary for the system to function effectively - this process of extracting the knowledge with the assistance of expert(s) - knowledge elicitation - was men-tioned earlier in the chapter. In general the demonstration system should be built around a domain which is compact and manageable. "Of overriding importance is the need to identify a small and well bounded field of expertise with as few open-ended questions as possible." (Leary, 1988b, p. 11). From these characteristics and the requirements of domains in which a demonstra-tion system may be built, Leary (1988a) has identified development control as the application 54 area in which initial demonstration systems are most likely to succeed since it is based upon clearly defined, structured, and codified, procedures and regulations (i.e. the Zoning By-law) as well as less structured information (i.e. design guidelines, etc.) and broader community and regional issues and policies. Furthermore, development control is something which most municipal planning depart-ments spend significant resources on. Irwin & Farrow's (1989) recent survey of sixteen planning departments in Southern Ontario revealed that on average anywhere from 51% to 68% of a department's resources are spent on development and project-related activities while only 13% are spent on planning studies, reviews, and other 'long-range' matters. Perhaps more interest-ingly, 81 % felt that their department was understaffed. Given these findings, albeit from a small sample size, development control expert systems could be invaluable in enabling planning departments to employ their resources more effectively and in helping planning staff deal more effectively with heavy workloads and more creatively with the control process itself. It is not surprising then that most of the initial planning interest in expert systems has been directed towards development control (recall A D A P T , the work of Leary, Rodriguez-Bachiller, Cullen, and to some extent Tanic). And for the purposes of demonstrating expert systems here, development control will also be the domain used. This is something which will be discussed more in Chapter Four but first an evaluative framework needs to be developed from which expert systems applications in planning can be objectively and rationally evaluated. 55 C H A P T E R T H R E E : A N E V A L U A T I V E F R A M E W O R K F O R A S S E S S I N G P L A N N I N G  T O O L S We have seen in the last chapter that expert systems are being successfully applied to limited spheres within urban planning - primarily in the area of development control - although much work has also been done in the ecological planning and natural resources management spheres (see Robertson et al, 1985; Davis & Clark, 1989; Page, 1989). As was hinted in Chapter Two, however, the advent of expert systems will require that the very nature of planning and the planning process itself be reevaluated in order to see how expert systems can help improve the way planning is conducted. Any new technology has a powerful impact upon those who use it and on the way they approach various problems or tasks: A n implemented technology carries with it a powerful vision of the society in which it is to be used.... and, sometimes an obligatory plan for the way people will have to arrange themselves to use it. (Pfaffenberger, 1988, p. 16) O n the other hand, new tools or technologies allow users to modify their work and behaviour. The motor car revolutionized personal transport but also altered the morphology of urban and rural areas in the same way that the computer has revolutionized work practices in nearly every sphere of human endeavour. Expert systems thus have revolutionary potential in the planning profession: The successful application of expert systems to social sciences problems may bring about fundamental changes in the ways in which the social sciences are conducted. It may lead to a reappraisal of the extent and scope of problems that can be tackled in the social sciences. (Brittain, 1986, p. 117) The advent of any new technology, though, requires that some thought be given to what we are trying to achieve as planners and to what kinds of tools are needed to support these tasks. Developing such tools without a clear normative framework upon which to base evaluations 56 could lead to an empirical "hit and miss" approach to research and to the development of tools which hinder rather than help the planning process. Contained within technology are powerful pre-understandings, social assumptions, cultural biases, value statements, and other prejudices. Technology is neither independent nor a deterministic manipulator of society. That is to say "technology is socially constructed" (Pfaffenberger, 1988, p. 16) and therefore to decide how and what aspects of technology are to be used requires an evaluation of social behaviour and social relationships. In the context of planning this equates to an evaluation of the role of the planner and the nature and form of the planning process itself. Robin Thompson, the 1990 President of the Royal Town Planning Institute has, in his Presidential statement, developed a normative framework for the planning profession as a whole and it is worth repeating briefly so that the overall goals of planning in general are not lost in the dazzle of expert systems technology. Thompson has argued that the role of planning should be to: 1) . Enable and regulate economic growth. 2) . Improve both the quality and equality of life. , 3) . Mediate conflict between economic growth and desires for a better and fairer quality of public life. (Thompson, 1990, vol.76, no.3, pp. 11-2) To achieve this, he has put forward six criteria by which the planning process and the planner's role should be evaluated: 57 1). S T R A T E G I C Planners should develop regional and strategic long range plans. 2). E F F I C I E N T Planning should be "cost effective and offer a good standard of customer care". It should also be able to demonstrate the value it adds to the development process (be the value economic, environmental, or social). 3). E N A B L I N G Planning must be entrepreneurial, flexible, cooperative and imaginative. It should enable the improvement of our society and the environment. 4). I N V O L V I N G Planning should be "open and consultative" and planners should seek input from all segments of society. Planning and decision-making should be decentralized. 5). N E E D S - B A S E D Planning should assist in reducing the rift between the haves and the have nots as well as the imbalances between regions and neighbourhoods. 6). G R E E N Concern for the overall quality of life and environment should pervade every element of the planning process. Development should be sustainable. (Thompson, 1990, vol.76, no.3, pp. 11-2) I do not propose to enter into a discussion on the theoretical or epistemological merits of these six goals, and elsewhere I have indicated references on the subject of planning theory and the role of the planner. Thompson's goals for planning are presented merely as an organizational tool indicating the overall objectives toward which support tools should be directed and to give an idea of the overall thrust and direction which the planning profession should take. On a general philosophical level, however, there can be little debate concerning the validity of these six aims since they attempt to balance pragmatic reality and normative idealism. They also point the way towards suitable criteria for evaluating new technologies and for ensuring that such new tools support the goals and aims of the planning profession as well as the role of the planner. 58 We should not forget the central aims of planning in striving for a fair, just, safe, sustainable, society and environment when developing technical tools for assisting the planning process. If planning is to achieve these fundamental goals then, from an epistemological point of view, problem solving and decision support tools in planning must also be broadly designed with the same fundamental ends in mind. As Keen & Morton (quoted in Rosenberg, 1986, p.86) have noted with regard to decision support systems: Decision support implies the use of the computer to: 1) . Assist managers in their decision processes in semi-structured tasks. 2) . Support rather than replace, managerial judgement. 3) . Improve the effectiveness of decision making rather than its efficiency. It thus follows that computers should be used in such a way as to allow planners to become more involved in the planning issues themselves rather than in the computer. In other words, the computer is a means to an end not an end in itself (after Pfaffenberger, 1988, p. 23). On a somewhat simplistic level, if the computer encourages this involvement then it can be seen as a positive influence otherwise, it is a hindrance. Thus, any evaluations of new technological tools must take place from the overriding point of view that tools should support planners and the planning process. This has not always been the case, as Cullen (1986, p.241-2) has noted and it can be argued that up until quite recently planners have been developing tools without any clear reference to a normative standard. As a result, planning theory, in borrowing ideas from operations research, cybernetics, systems theory, and others, has been molded to meet the requirements of these methodologies rather than the other way around (see Leary 1988a, p.383). Consequently, the traditional positivist tools which have dominated the social and regional 59 sciences to date have also infused planning. These tools include nearly all of the quantitative and procedural software as well as most of the generic software packages which are available today and which are in use in most planning departments (see Gar-On Yeh, 1988 and Bardon, 1988). Such tools and the techniques they use have been harshly criticized in recent years since it has been argued that they suffer from an "underlying technical malaise" on the grounds that: 1) . They yield at best partial models of social process and are therefore, when put together with other similar devices, likely to lead a programme of investigations towards global inconsistency; 2) . They are mechanical in form and function and so tend to build discre-tion-inhibiting inflexibility into any such programme; 3) . They are data intensive, and are thus often incapable of handling infor-mation gaps, varying levels of uncertainty, and the achievement of less than a ratio scale of measurement [i.e. they cannot handle qualitative distinctions]; 4) . They tend to be functionally myopic, oriented more or less exclusively towards predictive applications; 5) . They are operationally opaque, and so are hard not only to use but also to interpret and teach. (Cullen, 1986, p.241) (For an even lengthier indictment of positivist tools see Macgill, 1986, p. 1429-30) Cullen has also pointed out that such techniques were based upon mechanical models of causation directed towards addressing the question of "Why?" whereas planning should equally be concerned with questions of "How?" since"... planning analysis... [should]... explore the impacts of complex structural relationships upon social processes..." (Cullen, 1986, p. 242). Obviously, positivist methodologies are clearly not 'ideal problem solving or decision support tools'. Nevertheless, Cullen's critique hints at possible solutions to the problems he raises since an ideal tool would be diametrically opposite to the flaws outlined above. 60 Such epistemological and practical concerns would be irrelevant to planners in a Utopian . society since they would be faced either with perfect and plentiful information or, should the information be imperfect (i.e. incomplete, uncertain, unverifiable, etc.), with the ideal support tools necessary for supporting their needs in planning analysis and policy formulation. In the real world, however, such luxuries are impossible due to the complexity and interconnectedness of information itself and to the open nature of the planning process. However the concept of a "Utopian Planning Tool" is useful in guiding the development of real world support tools and in developing a normative framework which outlines an "ideal problem solving and decision support tool". Towards an Evaluative Tool Macgill (1986, p. 1430) has argued that"... different styles of model (and models of a given style)... [including expert systems]... have rather different qualities and should be judged in particular terms.... Nevertheless, standards can rightly be spelled out as an institutionalized heuristic or normative framework to guide and evaluate analytical practice". This is the intent of the framework presented here. Ideally, any model should be comprehensive and thus equally successful in a variety of areas. This is patently not the case, however, with the majority of models, including expert systems, since they are usually aimed at specific roles or domains. Macgill has developed seven questions for use in judging the quality of any model and these have been rephrased to form the . core of the evaluative framework presented here. This framework has also drawn upon Cullen (1986), as well as expert systems literature in general but specifically Bramer (1984), Dalenoort 61 (1986), Phillips (1986), Brittain (1986), Sloman (1985), Mamdani et al (1985), and Reighgelt & Van Harmelen (1985). The advent of expert systems has brought with it a variety of claims concerning the performance of computers and software tools which operate on artificial intelligence principles. There is much debate amongst A l theorists and researchers alike concerning the validity of these claims (see Chapter Six). While many of these have yet to be proven conclusively, it is nevertheless possible to use them as yardsticks by which the performance of expert systems themselves can be judged, particularly with regard to the representation of knowledge and the handling of uncertain or incomplete information. The Evaluative Framework The framework presented here has been designed to be applicable to a wide variety of computer models and tools but will be used specifically to evaluate the demonstration system developed and described in Chapter Four. Any problem solving and/or decision support tool should exhibit the following charac-teristics. Most of these are self explanatory but justifications for several of the criterion are given where necessary: 1) . The output of the tool should be A) Consistent, B) Suitable, and C) Relevant to a particular policy content or planning problem. (Macgill, 1986; Phillips, 1986) 2) . The accuracy of results, as well as the way results are achieved, should be recognizable. The tool must be able to substantiate and explain the results achieved and users must have confidence in both the tool's process as well as its output (Macgill, 1986). In other words, the tool's internal structure (i.e. the model's assumptions, policy statements, rules of thumb, 62 etc.) and method of functioning should be transparent to the user (Cullen, 1986). This criteria is designed to prevent the development of tools which appear to operate in some magical "black box" fashion. For a discussion of "black box" techniques, problem solving methods for planning in general, and the similarity between research efforts in both Planning and AI see Leary (1988a, p.383-8). 3) . Input must be A) Accurate, B) Valid, and C) Of good quality. (Macgill, 1986). This is another way of phrasing that standard computing adage: "Garbage in = Garbage out." 4) . The tool should have a solid epistemological grounding (Macgill, 1986; Brittain, 1986). It should be theoretically and methodologically valid. 5) . The tool should be highly interactive and act as a conduit for communica-tion between "expert" and user, as well as between users, regardless of the user's ability (Macgill, 1986; Collins et al, 1985). 6) . The tool should be easy to learn, use, understand, and interpret, for a range of users from novice to expert, i.e. it should not be operationally opaque (Macgill, 1986; Cullen, 1986; see Robertson et al, 1985 for an example of this). 7) . The tool should be rooted in both the context of the problem as well as the context of our"... cognitive heritage, biologically as well as cultural-ly." (Dalenoort, 1986, p.89; see also Sloman, 1985 and Macgill, 1986) This criteria is in complete contradiction to the traditional notions of systems analysis, rational planning, and other attempts to create general problem solving and decision support tools which were so prevalent in the 1960s (see Leary, 1988a). It is also a reaction to the attempts of the AI industry to create universal problem solvers, most of which failed. 63 To these we can also add criteria based upon the antitheses of Cullen's critique of positivist tools; that is to say, ideal problem solving and decision support tools should also exhibit the following: 8) . The tool should not be data intensive but must be able to handle a wide variety of information and expand upon what has already been included in the database. It must be easy to update and to modify. Planning issues and problems consist of a huge range of information types which can be decomposed into two primary categories: quantitative and qualitative. Numerous techniques have been developed for the former but there have been few truly useful methods devised for the latter. The problem of qualitative information is further compounded by problems associated with handling uncertainty as well as incomplete or missing information. Qualitative and uncertain information are frequent-ly elements of planning issues, so for any tool to be valuable and be able to push the bounds of planning analysis beyond the capabilities of current tools (and thus improve planning practice), it must be able to handle the whole spectrum of information types. 9) . The overall inferencing system should be independent of the repre-sentational schema used to express data, thus providing a consistent means by which several systems could be integrated. (Cullen, 1986, p.242) As noted earlier, the separation of the inferencing or processing system from the data (information) structures increases flexibility and can allow several databases, each focussing on a specific problem domain, to be 64 combined to produce an integrated support environment using the same inferencing system. 10). The tool should be highly flexible and allow the user discretionary freedom as well as freedom of purpose (i.e. the freedom to solve a range of problems). That is, the tool should not be technique-specific but should use a variety of problem solving methods and strategies so that should one approach fail there are alternatives to fall back on. Nor should the tool be function-ally-specific such that it can only perform one kind of task (e.g.: predic-tion or generation - see Macgill , 1986 for a breakdown of modeling tasks) Finally, given that these criteria have been developed from the expert systems literature as well as from reviews and critiques of positivist techniques, it should be no surprise that by and large the positivist, procedural tools currently in use will "fail" to meet most of the criteria when evaluated using this framework. If the claims of AI and Expert System proponents are borne out, then expert systems and other AI based tools should withstand an evaluation using this framework. This does not mean that all existing positivist tools in operation should be discarded in favour of Expert Systems based solutions since that would be sheer folly. It is highly unlikely that all of the claims about expert systems will come true, and therefore, the prudent planner should look to establishing a range of tools, both traditional and Al-based, as well as to augmenting existing tools with expert systems. The evolution of hybrid systems (i.e. systems which draw on a combination of both traditional as well as Al-based techniques) should also not be ignored since the emphasis should be on developing useful Decision Support Systems and not on the specific technology used, be it AI- or procedurally-based. 65 We will now turn to developing and describing a very rudimentary demonstration expert system in Chapter Four and in the following chapter (Chapter Five) will apply this framework to an evaluation of the system developed. 66 C H A P T E R F O U R : A D E S C R I P T I O N O F T H E D E M O N S T R A T I O N S Y S T E M - E U C L I D Most urban planning research into the feasibility of Expert Systems within the profession has, to date, been either highly preliminary in nature or, for the few embryonic systems which have been developed (largely in academic institutions), focussed around the domain of Develop-ment Control. The same cannot be said of regional and environmental planning where far more research has been carried out both in Canada and abroad, and where operational expert systems have already been developed [see Davis & Clark (1989), Page (1989) for concise summaries of the work that has been done]. Nevertheless, within the urban sphere Leary (1988a) has noted the potential for translating Design Guidelines into an expert system format, and has argued that design guidelines are in essence pre-structured knowledge bases in a written format. Leary & Bachiller's (1988) L E O N A R D O - b a s e d system, which assists in checking development applica-tions, and Davis & Grant's A D A P T system (1987) also demonstrate that feasibility studies are already being undertaken within the domain of urban planning. Yet curiously, despite all of this activity in the domain of development control, there appears to have been limited research in the use of expert systems for helping to administer Zoning By-laws; such a pervasive part of North American planning practice. This should not be surprising since most of the expert systems work to date has occurred elsewhere or in other fields. Indeed, North American planners seem to be just beginning to assess the overall possibilities although one or two studies dealing with zoning by-law administration do appear to have been conducted at the University of Waterloo. Unfortunately, it has not been possible to obtain any details on this research to date. 67 It seems curious that there has not been more research on translating Zoning By-laws into Expert Systems since such By-laws are well structured and organized, concise in nature, and, like design guidelines, are essentially written knowledge bases in that they contain a set of legal rules, regulations, and conditions. They thus conform with the types of domains that are recommended in the A I literature as being suitable for developing not too trivial and not too complex demonstration systems. Zoning By-laws also exhibit most of the characteristics of tasks suited to Expert Systems solutions: There are many ways a By-law can be interpreted. Zoning By-laws cannot be reduced to functions and algorithms since they require a substantial amount of judgement in evaluating the suitability of development proposals. Planners, developers, and the public are often in discord over how a proposal should be judged and whether or not a development application should be allowed. It is certainly true that an incorrect or late decision can have, or lead to, significant impacts upon both developers, planners, and others, not to mention communities and the viability of the municipality itself. Development proposals are presented in varying stages of completeness and may change as the application progresses. As a result, they may require scrutiny at various stages throughout the approval process and so there is a need for consistency between and within applications. Perhaps a more persuasive argument for developing expert systems to assist in the assessment of development proposals is the fact that most planning departments expend vast resources to fulfill their development control function and provide over-the-counter services. Furthermore, this emphasis on development control often occurs at the expense of the long range planning and community planning functions which provide the policy framework from which development proposals are evaluated, particularly in municipalities without a long range planning division. 68 From a contemporary point of view, this imbalance in municipal planning functions is exacerbated by the increasing pressures of heavy workloads due in part to staff shortages and, in periods of economic prosperity, to increasing numbers of development proposals from the development industry. The City of Vancouver, for example, estimates that, on average, the time it takes for a development application to be processed is anywhere from 2 weeks to 2 months, or even longer, depending on the complexity of the proposal, issues which arise, and any studies which have to be carried out (City of Vancouver, Development Permits for Major Developments, Brochure #3, Oct. 1987). Given what has been said in the preceding chapters and above, it should be clear that Development Control Expert Systems could provide planners with a significant weapon with which to combat these pressures. Such systems could assist both junior and senior staff members in administering Zoning By-laws and assessing development proposals more expeditiously and on a more consistent basis. As a consequence, they could ultimately free up staff and departmen-tal resources, thus providing greater freedom and flexibility to do more long range planning and to increase community involvement in the planning process itself. Nevertheless, it should be pointed out that there could be serious negative consequences in introducing Expert Systems to the planning office. These will be discussed in more detail in Chapter Six. At this stage, however, the suitability of using Expert Systems in the urban planning sphere and of creating systems, based upon A l techniques, which function as development control 'assistants' remains to be proven. Demonstration systems must therefore be developed in order to be able to evaluate more conclusively how the introduction of expert systems will affect municipal planning practice. 69 It is within the overall context of both this pragmatic, contemporary view of urban planning and the need to produce demonstration systems in the domain of development control that the system developed here - Euclid - is presented. Euclid Euclid is a simple backward chaining expert system built purely to test the feasibility of translating Zoning By-law schedules into a production rule schema as well as the practicability of providing planners with a tool to assist in the evaluation of development proposals. It has been conceived as a tool for assisting planning staff in their assessments of development applications. However, due to the limited programming experience of the author, and the limited time in which to do the research, Euclid, as an initial exploratory vehicle, represents only a portion of the features which would be necessary in a fully developed system. It also performs as a 'test case' for applying the criteria developed in Chapter Three. It has been developed using the Turbo Prolog 2.0 language and has been built around a portion of the City of Vancouver's current Zoning By-law. It is named, for obvious reasons, after the Village of Euclid, over which the U.S. Supreme Court upheld the concept of zoning in its landmark ruling of 1926 (see Babcock,1966, p.4). It should be clear that trying to translate an entire Zoning By-law in to a production rule knowledge base is a formidable task indeed. The City of Vancouver's Zoning By-law alone defines over 55 separate zoning districts, not counting the Comprehensive Development Zones (City of Vancouver, Zoning By-law, September, 1989). Even the City of North Vancouver's (a small municipality) Zoning By-law identifies 23 separate zones, again not including their Comprehensive Development schedules which, by 1986, numbered 85! (City of North Van-70 Figure 4.2 Zoning Bv-law Structure I N T E N T O U T R I G H T A P P R O V A L U S E S - accessory uses - dwelling uses C O N D I T I O N A L A P P R O V A L U S E S - accessory uses - dwelling uses - cultural & recreational uses - institutional uses - retail uses - service uses - utility and communication uses P H Y S I C A L R E G U L A T I O N S - site area - frontage - height - front yard - side yards - rear yard - floor space ratio - site coverage R E L A X A T I O N O F R E G U L A T I O N S Source: The City of Vancouver; Zoning and Development By-Law: September, 1989. 72 Figure 4.3 Euclid: Program Modules U S E R S Y S T E M / U S E R I N T E R F A C E EUCLID PROGRAM T U R B O P R O L O G I N F E R E N C E E N G I N E K N O W L E D G E B A S E Outright Use Rules Conditional Use Rules Zoning Regulation Rules I N T E R N A L D A T A B A S E S Zoneinfo Dimensions Answer Storage RT-2 D A T A B A S E RT-4 D A T A B A S E R T - 4 N D A T A B A S E RT-5 D A T A B A S E R T 5 N D A T A B A S E RT6 D A T A B A S E 73 couver, Zoning By-law 1967, May, 1985). In addition, a truly comprehensive development control tool would require the inclusion of the Parking By-law, the Health and Fire By-laws, as well as Development Permit regulations, and would need to be tied into a Geographic Informa-tion System or the administrative database system in order to keep track of development applications and their status. Therefore, in order to keep the workload within manageable limits, the scope of Euclid has been restricted to those Zoning schedules which govern Two-Family residential areas in Kitsilano, Grandview Woodlands, and Mount Pleasant - namely the RT-2, RT-4 , R T - 4 N , RT-5 , R T - 5 N , and RT-6 districts. Figure 4.1 delimits the geographical locations of these three local areas. The six Zoning schedules are all organized in a similar fashion and are split into various sections as oudined in Figure 4.2. The schedules list those uses which can be approved outright and those which may be approved conditionally. In addition, they describe regulations governing heights, setbacks, floor space ratios, etc., which both outright and conditional uses must meet in order to be approved. The schedules also contain a few regulations which apply only to those uses which may be approved conditionally, as well as the zoning relaxations which may apply to specific zones and proposed uses. Sections 10 & 11 of the By-law have consciously been left out so as to reduce the amount of programming required. Euclid draws on both this built-in organizational structure as well as the production-rule methodology to provide the framework around which the system is programmed. It should be noted that the production-rule formalism is not new to planning and resembles quite closely the ADDA (Analysis of Interconnected Decision Areas) technique which forms part of the Strategic Choice approach advocated by Hickling (1975,pp. 23-34) and others - particularly if A J D A is 74 Figure 4.4 The Planner/computer Interface U S E R 31 Main Menu Window - select action - read in zoning specifications - get lot dimensions - select use Select a Zone Window 1—. » - select a zone Checking a Zoning By-law Window - run query_the_user session Response Window - report results to the user - return to main menu window Error Message Window - report input errors to user 75 used to generate a solution or decision tree. There is, therefore, strong support from both the Decision Making and AI literature in adopting this approach. In its present form, Euclid is comprised of several modules, each of which has a specific function. Figure 4.3 illustrates the major program blocks and their relationship to one another. The planner/computer interface governs how the program interacts with those using the system and provides a vehicle for obtaining information from and returning results to the user. The knowledge base forms the bulk of the system and is built up from several program files which correspond roughly to the organizational structure of the Zoning Schedules, as shown in Figure 4.2 above. Thus, one file contains the rules governing outright uses, another the rules which evaluate conditional uses, and yet another which lists the relaxations permitted under various zone/use combinations. The rules which describe the specific zoning regulations are, by necessity, split into two files and the reason for this will be discussed later. Finally, six database files contain the numerical specifications for each of the six zoning schedules. With the exception of the database files, these modules are transparent to the user in the finished application since they are all contained in one big executable file or 'consultation shell' (Tello, 1988, p. 105). For those interested, the actual Turbo Prolog code for each of the modules is listed in Appendix 3 and the contents of each database file is listed in Appendix 1. Fairly detailed comments and predicate descriptions have been included in the code listings and it is not intended to duplicate those comments here. Readers should refer themselves to the Appendices since this may be beneficial in the discussion that follows. 76 The Planner/computer Interface The interface between the planner using Euclid and the program is represented diagram-matically by Figure 4.4 and the programming code which represents this module is contained in the E U C L J D . P R O file listed in Appendix 3. This interface determines what the user sees on the screen and how information is handled. The heart of the interface consists of several windows, one of which forms the main menu. Other windows are used for the query-the-user process and for displaying results. There are also several windows in which error messages or directions are displayed. While the concept of menus has several disadvantages in terms of user comfort (for example it can be very difficult to remember what level you're at within the system when there are several sub-menus nested within each other) Turbo Prolog provides several standard predicates which make defining windows and choices very easy and so this is the method used. Another important function of the interface is that it asks the user to select the zoning schedule which applies to the site in question. The user is also asked to select from a list of uses that use which matches the use proposed in the development application. Since Euclid can deal with six zoning schedules and over 25 uses, asking these two questions serves to narrow the system's focus to only those questions which are relevant to the case being assessed. Further-more, asking the user to select the appropriate zone precludes the need for Euclid to contain a geographic database or rules which link property addresses to zoning schedules (again purely in order to keep work levels within manageable limits), though these would be desirable features of a more sophisticated system. 77 The interface also contains predicates which gather information needed by the rules at various stages throughout the program. For example, information on the site and its dimensions, as well as specifications for the particular zone selected (e.g. floor space ratio values), need to be available to all rules which use them in their evaluations. Thus, the interface contains a predicate which asks the user to supply certain site dimensions and stores these dimensions in a database which can be called upon by any rule at any point in the program. There is also a predicate which, depending upon the zoning schedule selected, accesses the appropriate database file and loads its contents into another database which can also be accessed at any time. These two features remove the need to ask the user repetitive questions. Finally, the interface contains the predicates which determine how the rules are searched. In a sense, these predicates form part of the inference engine in that they guide how the rules governing outright use, conditional use, and the regulations are to be dealt with. Again, in order for the search space to be narrowed, outright uses are checked first and only if the use is not allowed outright are the conditional use rules checked. Only if a use is allowed either outright or conditionally are the zoning regulations checked since there is no point in checking regulations if the use itself is not allowed. The Inference Engine While the interface determines where Euclid starts its evaluation and the order in which rules are searched, the inference engine still needs to be told how rules are to be evaluated and outcomes decided. Even though it is possible to create custom made inference engines, Euclid, for the sake of simplicity, employs the standard pattern matching process (called 'unification') which is an integral part of the Turbo Prolog language. This unification mechanism operates in 78 a backward chaining manner. Recall that backward chaining operates on the "A is true IF B is true" principle and that, in its simplest form, backward chaining can only handle T R U E / F A L S E distinctions. As a consequence, Euclid contains no facility for handling uncertainty and determines the truth of a rule on the basis of answers supplied by the user in response to 'yes/no' questions or, in the case of questions asking for numerical input, on the basis of numerical values supplied by the user. The Knowledge Base Turbo Prolog's unification process relies heavily on the knowledge base in determining the results of rule queries since the rules are linked to each other in a tree type structure. In the Turbo Prolog language, each rule consists of a H E A D and a B O D Y and generally takes the format: (1) " H E A D " : - " B O D Y " (note that ":-" is read as "IF") Thus, using backward chaining, the H E A D of a rule is true if the elements forming the B O D Y of the rule are also true. Note that the B O D Y may contain more than one element and that in some cases the entire B O D Y of a rule must be satisfied in order for the H E A D to be true while in others there may be several options, only one of which needs to be true. The logical operator A N D (represented in Turbo Prolog by the comma ',') is used to represent elements of the former rule-type while those of the latter type will contain at least one O R operator (represented by a semi-colon ';'). Note also that the bodies of some rules in Euclid are hybrids and can contain both A N D and O R operators. In these cases, the O R operators act to delimit the various options which may be satisfied. A l l the elements which make up a particular option must prove true in order for that option to succeed. If the first option succeeds, the H E A D of 79 the rule succeeds, whereas if it fails, each alternative option is tried until the rule either succeeds or fails. For example the rule: (2) check_conditional_app(Zone,Use):- A , B ; C ; D , E , F . describes a rule which checks to see if a particular use is allowed conditionally in the zone selected. The rule contains three options, only one of which needs to be true in order for the use to be allowed. The first option is made up of two elements, A and B , both of which need to be true in order for option one to succeed and if it does so the rule succeeds. If it fails, Turbo Prolog tries the next option which has only one element, C , which is either true or false. If the first two options fail, option three is triggered and elements D , E , and F , are assessed. The rule structure described above is used quite extensively by Euclid in describing zoning regulations where there may be several alternative conditions. For example, the height of a building can be either so many feet or so many storeys high. Consequently, if a building fails the first it may comply with the second. Rules are linked to each other, and the search sequence is defined, by including in the B O D Y of the current rule the H E A D of the rule which follows it. Thus, any of the elements A - F in rule (2) may represent calls to additional rules. In such cases, Turbo Prolog has to go to that next rule and determine whether it is true before it can determine the outcome for the 'current' rule. In this way too, values can be passed from one rule to the next since variables can 'travel' with the H E A D of a rule. To illustrate this point, rule (2) above has associated with it two arguments. In the example shown, these arguments are two variables (in Turbo Prolog variables start with a capital letter) - Zone, and Use - the values of which are supplied by the 80 user at the beginning of a consultation session. Thus, if the user selects "RT-4" as the zone, '8' (Infill) as the use, Zone takes the value "RT-4" and Use becomes '8'. Once the values of Zone and Use have been determined they can be used, in conjunction with the rule itself, to transport the user's choices throughout the program. It should be clear that there may be several versions of a particular rule since there are many possible zone/use combinations and each rule can only describe the conditions for a particular situation. Under such circumstances, this ability for variables to be carried with the H E A D of a rule becomes very useful. It is used to advantage in Euclid since it allows the H E A D of each rule to be used as a filter so that only those rules which apply to the zone/use combination being evaluated are triggered. For example the rules: (3) check_outright.app("RT-6", 12):- B O D Y A . (4) check_outright_app("RT-4N"J :- B O D Y B. (5) check_outright_app(_,8):- B O D Y C. (6) check_outright_app(.J :- B O D Y D . represent four versions of the rule which checks to see if a given zone/use combination is allowed outright. Rule (3) defines the conditions which apply in a specific situation, namely when the zone in question is RT-6 and the use '12' (Two-Family residential). Only if the user has selected these two choices will the rule be triggered and the conditions contained in B O D Y A tested. Similarly, rule (4) describes the conditions to be met if the zone is R T - 4 N . In this rule it does not matter what the use is and as a result, if the zone is R T - 4 N , the conditions are tested regardles s of the use chosen. Rule (5) represents the opposite situation and describes the conditions that 81 are to be tested if, and only if, the use chosen is '8' (infill). Finally, rule (6) is the same as saying that the conditions listed in B O D Y D are to be tested regardless of the Zone or the Use selected. This last rule serves as a catchall clause and behaves in a similar fashion to the E L S E component of a Pascal L E - T H E N - E L S E statement. The description of rule structures above applies mainly to the rules that check for outright and conditional uses and, in some cases, zoning regulations which are tied to a specific zone and use. By and large, most of the zoning regulations are not dependent upon a specific zone and/or use and, as a result, the rules that describe them have a slightly different format. This different format is used because these zoning regulations apply universally within a zone regardless of the use proposed and because some of them are common to several of the zoning schedules. Each of these regulations is represented by a specific rule. Consequently, there are regulations which describe height requirements, side yard requirements, floor space ratio requirements, site coverage requirements, etc.. In most cases, each zone has its own specific regulations and, rather than identify each by a separate name, a standard term is used in association with a number; this improves the readability of the code. For example, there are three different regulations describing front yard requirements and these are translated into the following rules: (7) check_front_yardl :- conditions. checkfront_yard2:-conditions. check_front_yard3 :- conditions. The predicate 'check.rest.of regs(Zone)' is then used to identify which regulations apply to which zone by listing the requisite rules in the body of the appropriate 'check_rest_of regs(Zone)' rule. Thus the rule: 82 (8) check.rest_of_regs("RT-4") :-proposed_use(X), check_height2, check_front_yard3, check_side_yards 1, check rearj ard 1, check_fsr4, check_site_coverage(X). lists those regulations that apply, regardless of use, only to the RT-4 zoning district. Note that regulations which are shared among two or more zones are easily handled since each zone has its own 'check rest_of_regs' rule and thus the rule for a particular zoning regulation can appear in more than one 'check_rest_of_regs' clause without creating errors in the way the system works. In general, the regulation rules take the following format: (9) check regulation X :- condition 1; condition 2; condition 3; response message. Item 9 above contains three conditions and a response message. Each condition consists of three elements: 1) information supplied by the user; 2) a relational operator (<, <, =, ^ , >, >); and, 3) the zoning specification to be met. In addition, each condition needs to contain a question which elicits the correct input from the user as well as predicates which are able to access the databases and retrieve appropriate specifications. Some of the conditions require information which has already been obtained as a result of queries relating to previous regulations. Lot dimensions, for example, are frequently used in evaluating conditions and asking for this information repeatedly would lead to user frustration and confusion. Consequent-83 ly, where information supplied by the user is likely to be required by other regulations later on, it is stored in a special database so that the user does not have to be asked for it again. Note that the final condition in the rule above is in fact a response message which automatically succeeds. This message provides Euclid with a way of telling the user which regulation the development proposal fails to meet since it is only triggered if all of the conditions within that rule, and above it, fail. Thus if rule (9) above describes a rear yard regulation, the message would say that the development proposed failed to meet rear yard requirements for the zone that had been selected and would then lead to another message saying that the use was not allowed either outright or conditionally. The combination of the rules described above makes Euclid's knowledge base quite expressive and it is fairly easy to produce rules for a specific regulation or use. However, the production rule technique also produces a rule base which is memory intensive, cumbersome, and makes it rather difficult to follow the order in which the rules are evaluated. Furthermore, Euclid cannot communicate using the English language and, as a consequence, cannot interpret user input nor provide responses on its own accord. The language used in the Zoning By-laws is quite complex and involved, since many of the regulations contain subtle and not so subtle variations. Consequently, since Euclid uses the standard pattern-matching processes of Turbo Prolog, the questions that it asks have had to be 'hardwired' into the rules as write statements and text strings. In addition, the responses and results that it applies have also had to be treated in this way and thus a fair amount of flexibility has been lost. 84 The Development Process Initially, Euclid was built up as a single program containing rules only for the RT-6 schedule. This schedule was chosen as the early development case because it was the most complex of the six schedules and contained several regulations unique to the RT-6 zone. The first task involved translating the written statements into Turbo Prolog code. This process was complicated by the fact that the author was new to the Turbo Prolog language and had to learn how to program Euclid at the same time as trying to translate the zoning By-laws. As a result, a trial and error approach had to be employed and several weeks passed before an appropriate rule structure was developed. It soon became apparent during the development period that in some cases a direct translation of a regulation into its Prolog equivalent would lead to errors in logic or errors in the way the system responded since Turbo Prolog treats the logical operators (AND,OR,NOT) in very specific ways. Usually, the problem arose with a particular condition of a regulation and was the result of a rule failing when the logic of the program required that it should succeed. The solution in these situations was to program the condition in its opposite logical form. Thus, if one of the conditions to a rear yard regulation, say, required that the rear yard had to be less than or equal to (<) 35 feet and the rule failed when logically it should have succeeded, the rule was re-written so that the rear yard had to be greater than (>) 35 feet. Debugging these and other types of errors proved to be a time consuming task but once the rules for the RT-6 zone were operating more or less successfully, the user interface portion of the Euclid program was developed. As mentioned earlier, Turbo Prolog's built in window handling predicates made making the menu environment fairly straightforward. The difficult 85 portion of the interface consisted of developing the initial rules for governing how the knowledge base was to be searched and for eliciting key information from the user and storing it in several distinct databases. It is not intended here to discuss the intricacies of the way these rules work and for a more detailed discussion of the Euclid system reference should be made to the annotated Turbo Prolog code listings in Appendix 3. To reach the stage where the RT-6 rules and the user interface were working fairly successfully took about 120 person-hours of programming effort. The next phase of develop-ment involved adding the rules and specifications for the remaining five zoning by-laws. Since the basic operating processes and rule structure of Euclid had already been determined, adding these by-laws consisted mainly of expanding the rule base to cover all the possible combinations required. However, in some cases, the addition of these rules conflicted with some of the existing rules and produced errors in the way the system had been designed to operate. These conflicts required quite an extensive period of testing and debugging to bring the system back to its previous level of proficiency and one of the principal modifications during this process involved the modification of the RT-6 rules so that they would only apply in cases where the RT-6 zone had been selected. Nevertheless, the rules and database facts for the five remaining zones, as well as the modifications to the rules governing the search strategy, only required about 50 person-hours of additional programming effort to incorporate them into the system. The debugging of the program was complicated by the fact that the final program code approaches 60 K b in size and could not, unfortunately, be compiled, in its entirety, into the space remaining in the Turbo Prolog development environment. (A weakness of Turbo Prolog is that it can only handle compiled programs up to 64 Kb in size and the compiled size of a program 86 is always larger than the size of the actual code - the size of the final compiled version of Euclid, for example, is almost 180 Kb!). The solution around this problem was to debug the program modules a portion at a time. This in itself is a lengthy process since combinatorial explosion in concert with the numerous questions that the system asks leads to thousands of possible combinations; Euclid supports 162 zone/use combinations alone, not counting the variations in the user's responses. Consequently, while each of the zone/use combinations have been put through a basic test, it has been impossible to check the outcomes of every single variation in user input. While this 'debug a portion at a time' methodology allowed the essentials of the system to be tested and proven, it presented no solution to the problem of how to generate a stand alone executable file. Since the file could not be compiled in the Turbo Prolog environment, it had to be compiled externally. This necessitated breaking up the program into seven separate program files (these are the files listed in Appendix 3) and then Unking them all together into a file which could be accessed by the Operating System of a personal computer. Breaking up the program required that portions of it be modified to accommodate the new structure and so portions of the new program had to be debugged yet again. Modifying the program structure and creating the executable file also proved to be time consuming and took, approximately 85 person-hours of further programming and editing effort. The current version of Euclid is contained on one 360 K floppy disk and can be run from a standard I B M A T , or compatible computer. It consists of the main executable program, a Prolog error message file ( P R O L O G . E R R ) , and the 6 database files. Since the system relies on fairly straight forward and simple expert systems techniques, it runs very quickly and the user 87 is not left waiting for the next question to be asked or a result to appear. There is a noticeable pause, however, when loading the program from a floppy drive to the workspace and when the contents of the database file, corresponding to the zone selected by the user, is read into the system. These time lapses are reduced considerably if the system is installed, in its entirety onto a hard drive. A Sample Run Session In running Euclid the first thing the user sees is a message window stating that Euclid has been developed as part of the author's M . A . Thesis research. Pressing the space bar removes this window and reveals the main system window. This contains a welcome message, the main menu, and a copyright notice. The main menu has 5 choices and under the present version of Euclid only option 1 "Checking a Zoning By-Law" is operational. Options 2 and 3 have been included in the main menu to show how a moderately complete development control system would appear to the user and are at present 'cosmetic'. Option 2 "Find a zone for a Project" would allow planners to pose the question "I have a development project in mind, which zoning schedule is most appropriate?" while Option 3 "Modify or Add to the Database" would allow planners to up date or modify zoning specifications. Option 4 is operational and allows the planner to move to the operating system (in this case DOS) to carry out file maintenance etc. and then, by typing ' E X I T ' , return to the Euclid main menu - a useful feature in large programs which deal with numerous files and where information changes frequently. Finally, Option 5 ends the session and returns the user to D O S . 88 Figure 4.5 Euclid System Flow Chart (1) Display Main Menu (2) Check the Zoning on a Property - get zone schedule - load zoning database - get lot dimensions - get use (3) Is use allowed in zone selected? (5) Is use allowed outright (6) Does it meet outright zoning regulations for the zone? yes no (8) Report the use is is allowed outright. E N D (4) check regulations? no yes E N D . Goto (6) below Is it allowed conditionally? yes no Goto (15) Below (9) Does it meet conditional zoning regulations for the zone? continued on next page. 89 Figure 4,5 cont'd (10) Report the use is allowed conditionally. E N D (11) Are any relaxations possible? (12) Are any relaxations possible? no yes no (13) Report the relaxations that are available (14) Report that the use is not allowed outright but may be allowed conditionally, I (15) Report that the use is not allowed, either outright or conditionally Ask: "Do you want to check for conditional approval?" E N D yes no Goto (7) Above E N D 90 T o run Euclid, the user must select Option 1. Euclid then displays another window and gives an instruction to select, from the list presented, the Zoning By-law which applies to the site in question. The flow chart contained in Figure 4.5 illustrates the process which Euclid carries out as it evaluates a development proposal. Selecting a zone causes Euclid to read the contents of the appropriate zoning database into the internal database that stores this information for use later on. Once this has been done, a message appears asking the user to enter the dimensions of the lot. If the lot is rectangular Euclid calculates and displays the site area, otherwise it asks the user to enter the actual area. Once the lot dimensions have been entered they are stored in another internal database designated for this purpose, again so that lot dimensions can be accessed later on without having to keep asking the user for the same information repeatedly. Next, the user is asked to select the use which is closest to the use proposed, again from a list provided by the system. This list displays all of the uses which are allowed in the six zoning districts but the user can also select 'other use' if the use proposed does not appear. Euclid then takes the zone/use combination selected and begins to evaluate it, first by checking to see if the use is allowed outright in the zone selected. When Euclid needs input from the user to substantiate a rule (i.e. to prove that the use proposed meets a certain requirement) it will ask a question and indicate what type of response it expects. Every time it needs information that has not already been provided it will ask a question. If the response provided is not what Euclid expects it will, in some cases, catch the error and ask the user to try again. Providing this error trapping facility is made more complicated in Turbo Prolog since the predicates which read user input only work for certain data types, thus entering a letter when an 91 integer is expected can cause the system to behave in a peculiar manner. While it is virtually impossible, especially in a demonstration system like Euclid, to guard against all possible input errors, it is unlikely that such an input error will permanently damage the program and in such circumstances all the user has to do is restart the system. If the use itself is allowed outright, Euclid then begins to evaluate specific elements of the development proposal against the particular zoning regulations for outright uses. Regulations that pertain to the specific zone/use combination selected are checked first, followed by the more general regulations. Again Euclid asks the user for information, such as the number of dwelling units proposed, the width of the side yards, etc. if that information has not already been supplied. For uses which do not imply a building as part of the proposal (e.g. a park), Euclid establishes whether or not a building is proposed. If such a use does not contain a building and yet is allowed, either outright or conditionally for the given zone, it is permitted and a message to that effect appears in the window entitled "Response to a Zoning Query". If, on the other hand, a building forms part of such a use, Euclid proceeds to evaluate the use against the zoning regulations. For uses which imply a building (e.g. a multiple dwelling use), Euclid moves straight into applying the zoning regulations once the use itself has been checked for outright or conditional approval. If the development project meets all of the regulation requirements for outright uses in the zone selected, the use is permitted outright and a message to this effect appears in the response window. If the use fails any one of the regulations, Euclid assumes the development proposal fails to meet the necessary zoning regulations. The message it provides contains the reason why the proposal fails and it may, in some cases, also identify any relaxations which may be applied for and/or list any guidelines which should be followed. Whether a project is permitted outright 92 or conditionally depends upon which of the two categories the use proposed falls into. If the use proposed is not allowed outright, Euclid informs the user of this fact and asks if they wish to check for conditional approval. If the user wants to check for conditional approval (since the proposal may still be permitted provided it meets use requirements and the zoning regulations for conditional uses) Euclid will then check to see if these requirements are met, in the same way as for outright uses, and will carry out the same reporting procedures as described above. If the use itself is not allowed either outright or conditionally, the development proposal may still meet the physical zoning regulations and so may still be approved by Planning Department staff since the Zoning By-laws themselves and the uses they allow are not cast in stone. Thus a use not expressly allowed in the By-law may still meet the height, setback, site coverage requirements, etc. and be allowed at the discretion of the Director of Planning. Euclid, therefore, attempts to deal with these contingencies in its operating structure and search strategy, and reports to the user when such situations arise. In addition, the current search strategy occasionally results in a line of questioning which, in some instances, appears confusing. For example, if a use is allowed outright but fails to meet the zoning regulations for outright uses, Euclid will ask the user if they want to check for conditional approval since the use may still be allowed conditionally. In most instances though, if the user selects this option it is highly likely that, while the use may be allowed conditionally, the application will fail to meet the regulations it failed under outright uses. This problem arises because most of the zoning regulations apply both to conditional and outright uses. Furthermore, the structure of the zoning schedules themselves forces this search strategy to be used in Euclid. In these situations this second go round is therefore irrelevant. 93 Conclusions As an initial demonstration exercise, Euclid shows that Zoning By-laws can indeed be translated into a logical program and run on a computer. What Euclid does in effect is make it easier for the planner to evaluate a development proposal since one evaluation takes a couple of minutes at most and Euclid asks only those questions which are relevant to the site being studied. This feature distinguishes Euclid from traditional interactive database systems since Euclid's expert system-based structure means that it only searches the relevant portions of the knowledge base rather than undertaking a brute force search. In a sense, Euclid searches for information in a quasi-intelligent manner. Also, since Euclid evaluates development applica-tions in a formalized way, it should, in theory, lead to more consistent and appropriate development control judgements; however, it has not been possible to evaluate this hypothesis. In conclusion, Euclid has been developed with junior planing staff in mind and depends for its success upon the user/planners exercising their judgement and being intimately familiar with the Zoning By-laws and the development approval process. Many of the questions Euclid asks have very particular meanings and Euclid expects them to be interpreted correctly. Furthermore, Euclid assumes that the user understands the implications of the input they provide. Since Euclid cannot handle uncertainty and cannot explain what it is it's after, the onus is on the user to provide prudent responses and to evaluate Euclid's results in a critical manner (see Hammond's (1986) and Collins' (1987) comments on the role of the user in developing expert systems and the need to develop systems with the end-user in mind). Unfortunately, these two shortcomings mean that Euclid does appear, to the uninitiated, as a 'black box'. Uncertainty handling and explanation facilities have not been built into the current version of the system 94 due to the author's lack of experience in using Prolog and it should be recognized that the first few systems that planners build cannot be expected to meet all of the criteria developed in Chapter Three. 95 CHAPTER FIVE: A N E V A L U A T I O N OF T H E DEMONSTRATION S Y S T E M - EUCLID In Relation to the Evaluative Framework While Euclid illustrates that expert systems can be developed in the Urban Planning sphere, and in particular for the task of development control, it should be clear that it can in no way be considered a comprehensive state of the art tool. Consequently, any evaluation of the system from the stand point of the evaluative framework presented in Chapter Three should not lead towards any categorical conclusions in favour of or against Expert Systems in the planning work place. Nevertheless, the lessons learned from applying the framework to Euclid can help in the formulation of methodologies and expert system structures which may be suitable to planning domains, as well as indicating directions for future research. It is within this context that the framework is used to evaluate Euclid. A central underlying thrust of this thesis is that development control is not planning in its truest sense and that, in spending the lion's share of their limited resources to administer Zoning By-laws, Planning Departments are failing to deal adequately with the urban problems that cities face in the 1990s. The experience of Euclid shows that it may be possible to incorporate Expert Systems into the development control function and possibly reduce the resources expended in this regard while at the same time perhaps improving the consistency of the approval process. Obviously, systems such as Euclid would be most at home evaluating fairly ordinary small to medium scale development proposals. Mega-projects and other complex proposals such as Pacific Place or Coal Harbour would still require the traditional approach involving a team of planners. In this regard, an expert system which could screen out complex development proposals from the simple ones and evaluate only the latter would be highly valuable. Euclid 96 represents a very simple implementation of the evaluation component while there are already several expert systems operational which perform screening operations - S C R E E N E R for example (developed by Environmental & Social Systems Analysts Ltd. - a local Vancouver consulting firm specializing in environmental and resource planning) screens out business and development projects according to their compliance with the federal guidelines relating to Environmental Impact Assessment. By providing a consistent and user-friendly environment in which to assess development projects, Euclid also meets Keen & Morton's description of what decision support implies. By evaluating the project proposed Euclid assists managers to make decisions with regard to zoning approvals since it evaluates a project and makes a 'recommendation'. It is important to note that Euclid's recommendation is based both upon the user's judgement in the first place and on the assumption that the user will not accept Euclid's result as the absolute truth. However, the very fact that Euclid makes a recommendation in this regard could be considered to be dangerous and perhaps should be replaced by a check list informing the user of those regulations the project meets, those it fails, and the reasons why. Euclid could still make a 'recommendation' but with such a feature the User would be in a much better position to judge Euclid's performance. Nevertheless, Euclid has been conceived, in its present form, to support rather than replace the planner's decision making skills as well as to improve the efficiency and consistency (i.e. the effectiveness) of those decisions. With regard to the evaluative framework itself, Euclid can only be considered a partial success since it has not been possible to program in all of the features which set expert systems apart from traditional procedural programs and thus Euclid is more of a 'black box' than is 97 desirable. This is more a function of the software tool used and the limited programming knowledge of the author rather than any difficulties inherent in creating expert systems to meet a planning task. Taking each of the ten criteria in turn: 1). T H E O U T P U T O F T H E T O O L S H O U L D B E A) C O N S I S T E N T , B) S U I T A B L E , A N D C) R E L E V A N T T O A P A R T I C U L A R P O L I C Y C O N T E N T O R P L A N N I N G P R O B L E M . The structure of Euclid does mean that the output is consistent since Euclid's responses are built up from text strings. If, in testing a particular development proposal, the user provides the same set of answers, Euclid will respond in the same way again and again until a different set of answers is provided. Euclid's evaluation is also consistent since it only recognizes absolute truth and absolute falsity and thus a project either fails or succeeds. In reality, however, the project may meet some requirements and fail others and so may comply with all or only a portion of the zoning schedule. Thus, development projects do not conform to the zoning regulations in purely black and white terms. But Euclid errs on the side of caution. As soon as the project fails to meet one zoning . regulation, Euclid assumes the entire project fails, since a part of the regulations are contravened. Euclid then informs the user which regulation has been breached so that that specific issue can be addressed. O f course, Euclid's consistency depends, to a large extent, upon the input it receives (see criterion 3) but it will always be consistent in terms of the way it evaluates a project. As far as the development control domain is concerned, Euclid's results are both suitable and relevant to the task at hand. In providing a quick and consistent means of checking a development proposal, Euclid's response system allows planners to identify quickly those projects which meet zoning regulations and those which do not. It thus performs a crude 98 screening function. At present, Euclid suspends its evaluation as soon as the project under evaluation fails a regulation. A more useful variation in this regard would be for Euclid to evaluate the project against the entire By-law and then produce a report showing where the project complies with and contravenes the regulations. 2). T H E A C C U R A C Y O F R E S U L T S A S W E L L A S T H E W A Y R E S U L T S A R E A C H I E V E D S H O U L D B E R E C O G N I Z A B L E . T H E T O O L M U S T B E A B L E T O S U B S T A N T I A T E A N D E X P L A I N T H E R E S U L T S A C H I E V E D A N D U S E R S M U S T H A V E T H E C O N -F I D E N C E IN T H E T O O L ' S P R O C E S S A N D O U T P U T . The current version of Euclid fails to meet this criteria for several reasons, the most " significant of which is its inability to explain how it arrived at a particular result, or why it is asking a particular question. Since it cannot substantiate its line of reasoning nor provide a rationale for its results, users are left to judge these results for themselves. A further problem lies in the fact that Euclid cannot handle uncertainty, only recognizing T R U E or F A L S E results. The simple reporting system employed also implies absolute accuracy in Euclid's results and, to some extent, forces the user to accept these at face value since the magnitude of any failure to meet the regulations is not displayed. For example, a building may exceed the height allowance by one foot or by 20 feet yet in Euclid both instances lead to the same: "The use proposed fails to meet height requirements..." response. In this sense, Euclid is itself a black box. Furthermore, Euclid's current, simplistic operating structure cannot inspire great con-fidence on the part of the user in terms of relying upon its results. However, since Euclid is so closely based upon the structure of the Zoning By-laws it mimics, any lack of faith concerning the way it works implies a lack of faith in the way the Zoning By-laws themselves are structured 99 and interpreted. Greater confidence in Euclid would be to provide an expanded reporting structure which lists not only how a particular project stacks up against the regulations but also indicates the magnitude of the difference between the building's dimensions and the zoning specifications which apply to that site. 3) . I N P U T M U S T B E A) A C C U R A T E , B) V A L I D , A N D C) O F G O O D Q U A L I T Y . As mentioned under criterion 1, Euclid relies heavily on the user to provide accurate and valid input. In one or two instances, Euclid will flag suspect information and query the user to make sure the input provided is correct. For example the area of the ground floor cannot be greater than the floor area of the whole building and if such a situation occurs, Euclid asks the user to confirm the figures or provide new ones. Finally, provided the user operates the system in a responsible manner, the input supplied will usually meet the three conditions above since it will be based upon information submitted as part of the development application. 4) . T H E T O O L S H O U L D B E T H E O R E T I C A L L Y A N D M E T H O D O L O G I C A L L Y V A L I D . Since Euclid is based upon contemporary Canadian development control practice, it can only be based upon a solid epistemological foundation in so far as the concept of Zoning itself, as a method of controlling development, is theoretically valid. While the practice of zoning has its critics (see Goldberg & Horwood, 1980; Ronis & Rucker, 1971; and Ukeles, 1964, for example), it has nevertheless been firmly established in Canadian municipalities since the early days of planning and so has gained widespread support as a valid planning tool. Therefore, as an evolutionary development of zoning practice, Euclid is itself supported by this theoretical and methodological acceptance of zoning. 100 5) . T H E T O O L S H O U L D B E H I G H L Y I N T E R A C T I V E A N D A C T A S A C O N D U I T F O R C O M M U N I C A T I O N B E T W E E N ' E X P E R T ' A N D U S E R S , A S W E L L A S B E T W E E N U S E R S . The query-the-user process which is part and parcel of Euclid makes the system highly interactive - a result is not obtained simply at the stroke of a single key - rather, the user is led, by the series of questions they see, through Euclid's evaluation process. As a conduit for communication however, and hence as an educational tool for learning about zoning, Euclid is less successful since the flow of information tends to be primarily from the system to the user. It is the lack of an explanation facility which is the main reason why Euclid is not very successful in this regard, but then Euclid was explicitly targeted at planners who are familiar with the Zoning By-laws and with the development control review process. 6) . T H E T O O L S H O U L D B E E A S Y T O L E A R N , U S E , U N D E R S T A N D , A N D I N T E R P R E T , F O R A R A N G E O F U S E R S . The use of pre-defined text strings for asking questions and displaying results means that Euclid does not require a natural language interface. While this limits flexibility and tends to lead to the 'hardwiring' of information into the system, it means that Euclid operates in a way which the user can understand quickly. No programming knowledge is required to run the system and since Euclid directs the questioning, gives an indication of the answers it expects, and to a limited extent catches user input errors, the system has proven very easy to operate and learn. In addition, the various responses that Euclid provides in terms of results are also straightforward and thus the result of an evaluation is quite clear. 101 7) . T H E T O O L S H O U L D B E R O O T E D IN B O T H T H E C O N T E X T O F T H E P R O B L E M A N D IN O U R C U L T U R E A N D C O G N I T I V E H E R I T A G E . Since Euclid is based upon existing Zoning By-laws, it is firmly rooted in the Canadian planning tradition. In addition, as a response to the contemporary pressures facing development control planners in the 1990s, Euclid represents an attempt to deal with the problem of constrained resources and, at the same time, attempts to make the development control process more effective and efficient. Euclid also acknowledges, indirectly, the need for forward, or long-range, planning in light of changing expectations and planning pressures. 8) . T H E T O O L S H O U L D N O T B E D A T A I N T E N S I V E A N D M U S T B E E A S I L Y U P D A T E D A N D M O D I F I E D . The current version of Euclid does not require excessive data in order for it to work but like most Al-based tools is, unfortunately, fairly heavy in terms of its memory requirements. If more Zoning schedules were to be added, then Euclid would become extremely data intensive unless a completely different inferencing strategy and representational structure were to be employed. Euclid's appetite for memory as well as the difficulties which would be involved in increasing the scope and sophistication of the system suggest that its current structure is incorrect. Consequently, if Euclid were to be developed further it would be highly desirable to involve an experienced Prolog programmer in the development team and possibly use a more sophisticated Prolog language. In terms of updating the current version of Euclid, changes to the zoning specifications would be very easy to make since the database files could be accessed by the standard D O S editor. If the zoning by-laws were to change more dramatically in terms of altered rules and or new zoning requirements, the changes would be less easy to make. During development, it was 102 found that adding a new rule or altering an existing one could occasionally lead to the system behaving unexpectedly or producing errors. Again this is an indication that Euclid's repre-sentational and inferencing structures should be altered and improved. By and large however, additions or changes to the rules proved to be easier to make in Turbo Prolog than in procedural languages like Pascal. 9). T H E I N F E R E N C I N G S Y S T E M S H O U L D B E I N D E P E N D E N T F R O M T H E R E P R E S E N T A T I O N A L S C H E M A U S E D T O E X P R E S S D A T A . The use of Turbo Prolog's built in pattern matching capabilities for the inferencing system in Euclid means that the way the system evaluates the knowledge base is kept separate from the information contained within the knowledge base. While some of the rules in Euclid define the order in which Turbo Prolog should search the knowledge base, the results of the comparisons between stored zoning information and user supplied zoning information are determined purely by Turbo Prolog's Unification procedures. Consequently more rules, cover-ing new zones, could be added to Euclid and, provided they were consistent with the format of similar rules already in the knowledge base, the system would be able to evaluate them. However, the simplistic nature of Euclid's current inferencing system (it cannot handle uncertainty for example) and reporting system has, to some extent, necessitated that information be 'hardwired' into the knowledge base. For example, the relationships between the charac-teristics of the development proposal and the requirements of the Zoning By-law [e.g. (height of the project proposed) related to (height allowed under the zoning by-law); (number of dwelling units proposed) related to (number of dwelling units allowed)] are defined explicitly for each condition of each rule within the knowledge base. Thus, major changes to the zoning by-laws could require that the relationships for those conditions affected be re-written. Such 103 changes could have repercussions in the logic of the rules and in the way the system operates as a whole. In a production rule system like Euclid, tracing the logic of the rules and the way they are connected to each other becomes harder as the number of rules expands and, thus, changes to the by-laws could lead to the system being 'down' for a period while the revisions are incorporated. Note, however, that provided the relationship for a condition remains the same, changes to zoning specifications (i.e. changing the height limit from 35 feet to 40 feet) would require that only the database containing that specification be accessed and the height figures changed. In such situations the knowledge base itself would require no modifications. 10). T H E T O O L S H O U L D B E H I G H L Y F L E X I B L E A N D A L L O W T H E U S E R D I S C R E T I O N A R Y F R E E D O M A N D F R E E D O M O F PUR-P O S E . Euclid does not meet this criterion since in its current form it can only check to see whether or not a proposed development meets the regulations of the zoning schedule relevant to the site in question. In order for Euclid's results to have any worth, its evaluation process depends upon the development project being fairly well defined and the application being at a fairly advanced stage since details on the design of the project form a major part of the system's information requirements. Discretionary judgement and expertise could not be built into Euclid, as they have in some expert systems, for two reasons. First, incorporating such a capability into Euclid would have entailed significant increases in the scale of the programming effort required. A n d secondly, access to the relevant expertise was not possible; as noted in Chapter One. Conse-104 quently, it was not possible to undertake a knowledge elicitation exercise and thus Euclid has had to rely solely on the material contained within the written zoning schedules for its rules. In terms of giving the user more freedom, Euclid hints, in a crude way, towards using expert systems as a vehicle for evaluating the effectiveness of new, or proposed, zoning regulations and for asking "What if?" questions. Using expert systems in this way could possibly reveal any unintended consequences and provide planners with the means of developing and testing, in a structured manner, the regulations proposed. At the present time planners do not have this capability and so there may be a potential role here for expert systems in planning. The present structure of Euclid's query-the-user process, though, does not give the planner this kind of flexibility in terms of being able to ask 'What if?' questions or in evaluating the impact upon development applications of proposed regulation changes. While the planner can use Euclid to test variations of the project, to see how these affect the status of the development application, by running several evaluations - each time altering one or more of the answers during the question and answer session - the system cannot store an evaluation session in a file and reactivate it at a later date and this serves to limit Euclid's flexibility. Such a feature would be a desirable component in a fully functional system since it could be used to produce a report which could then form part of the official record and be included in the recommendations presented to Council. City Managers would also be able check the report and or run the system to gain a greater understanding of the project proposed. In addition, the ability to edit the responses of a session would allow project variations to be tested easily and the 'best' alternative identified. 105 Another beneficial capability would be to allow the evaluation session to be suspended part way through, say if information wasn't available, and then continued at a later date. This would allow the planner the freedom to see where a project failed the zoning by-laws and what would have to be done in order to rectify the situation. With such a flexible evaluation process, Euclid could expand its current evaluation/prediction capabilities to provide a tutorial environ-ment in which junior staff could gain experience in development control. Conclusions of Applying the Evaluative Framework From the analysis above, Euclid is clearly not an "Ideal Problem Solving and Decision Support Tool" since there are many areas where it fails to meet the kinds of flexibility and freedom required of a Planning Support Tool. The analysis does, however, illustrate areas where Euclid could be made a more useful tool. Yet, it should be noted that in order to incorporate the improvements mentioned above, Euclid's current knowledge base would have to be comprehen-sively altered and improved and Euclid's search strategy refined. Nevertheless, Euclid does demonstrate that there may be some potential for expert systems in the sphere of urban planning, and, in that sense, it is a success. The ease and speed with which users can interact with Euclid suggests that fully fledged expert systems may lead to time savings in the assessment of development applications. The fact that the zoning schedules are contained within a knowledge base, and that Euclid treats the zoning rules within the knowledge base in a consistent manner, may also mean that fewer human errors go undetected. At the very least the work done here suggests that tools developed from Euclid could perhaps be used to confirm and check human decisions. Finally, it appears that a more advanced version 106 of Euclid could perhaps be used in an interactive way to train new staff members in the nuances of development control. It should be appreciated, though, that fully fledged implementable systems cannot be created immediately, especially since planners themselves have limited programming expertise. Initial development systems such as Euclid are a good first step towards identifying the parameters necessary for creating operational systems since they help define the structure and methodology of the system, as well as the capabilities which should be incorporated into a professional tool. Euclid represents approximately two person-months of programming effort and, as a result of this expenditure, has produced a much clearer picture of the type of development control expert system which would be of use to planners. Turbo Prolog As A Development Tool Another area in which the development of Euclid has yielded results is in the types of . development tools used. If another attempt was made to develop Euclid, a comprehensive expert system shell, such as Level 5, would probably be used since beneficial use could be made of the built-in explanation facilities. Turbo Prolog has proven to be quite an easy tool to work with and allows a large degree of flexibility in tailoring the knowledge base to the specific needs of each regulation. It is, however, labour intensive and a lot of programming effort would have to be carried out if the kinds of facilities which come, as standard, with some expert system shells were to be included in the system (e.g. an explanation facility). 107 In building Euclid, problems were encountered with memory limitations as well as with Turbo Prolog's limited mathematical capabilities - especially when comparing two real num-bers. Furthermore, the code produced for Euclid is fairly lengthy - all the files together total in the region of 60 K b - and it was discovered that as the system expanded it became harder to follow the internal workings of the system when trying to debug errors. Refining the system and checking for, as well as editing, errors thus proved to be exceptionally time consuming tasks. The lesson here appears to be that if a language such as LISP or Prolog is to be used, then it is wise to involve a programmer, experienced in that language, in the development process, so that a comprehensive program can be developed quickly and efficiently. For planners who want to develop systems on their own, or to test the concept, the experience of Euclid suggests that a shell is probably the best environment in which to develop potential applications. Nevertheless, the fact that Euclid has been developed successfully using Turbo Prolog, and with only a basic understanding of the language, is in itself highly encouraging. Lessons Learned from the Zoning By-laws The experience of Euclid also exposes several lessons of which both planners and municipal lawyers should be made aware. The translation of the six zoning by-laws used in Euclid into a format which is readable by Turbo Prolog forced a logical rigour upon both the structure and content of these by-laws. Under the glare of such scrutiny the present methodology employed in writing zoning by-laws revealed several weaknesses. First of all, the entire Zoning By-law assumes that all its readers are fairly adept at interpreting the requirements contained therein and understand the concepts upon which the By-law is based. While planning staff may be familiar with the contents and implications of the 108 By-laws, the same may not be said for developers or members of the public at large and thus the development control review process may be lengthened unnecessarily while parts of the By-law are clarified, explained and the application revised. In addition, and beyond the problem of interpretation, it was discovered, in trying to produce logical equivalents for the zoning regulations and requirements, that legal constraints placed upon the way in which regulations could be expressed (such as not allowing mathematical formulas to be incorporated into a regulation, as well as the lack of diagrams) obscure the clarity and simplicity of the regulations. This made translation of the By-laws harder than necessary and resulted in making it very easy to create logical inconsistencies and errors in the content of the knowledge base. Indeed, in some cases (the regulations governing sunlight exposure in the RT-2 zone for example) the intent and meaning of a regulation were so obscured that it was impossible to produce a suitable logical rule. In such situations, the solution chosen was to make Euclid ask a simple question to the effect: "Does the proposal meet the requirements for sunlight exposure, as defined in section 4.10.1 of the RT-2 schedule? (y/n)". A more frequent, but less serious, problem emerged with regulations which were couched in 'whichever is the greater' or 'whichever is the lesser' terms and these proved somewhat confusing and hard to interpret logically. Another problem which emerged in handling the six By-laws was unintentional differences in wording. In many cases, several By-laws shared the same regulation and yet that regulation in each case was worded differently although the intent clearly remained the same. This lack of consistency between zoning schedules, in terms of the way regulations are expressed, added yet more complications during translation. 109 Conclusions Even with a domain (development control) which one would consider to be highly structured due to the legal nature of the By-laws, the experience of Euclid has shown that there exists quite a large amount of flexibility, discretionary freedom, and variation in the content of the By-laws and in the ways the By-laws themselves can be interpreted. Furthermore, much is left to the discretion of the Director of the Planning Department, and while a system such as Euclid may reach a negative judgement it may still be possible for the project to be approved. This freedom and variation added to the difficulties involved in developing Euclid. On top of these issues there are also serious legal ramifications involved in creating an expert system based upon a Zoning By-law since the Municipality, as well as the system developers, could be held potentially liable for any errors contained within the system, or any wrongful conclusions reached. Euclid's production rule structure exacerbates this problem by making debugging and testing of the system a time consuming and difficult task. For these reasons, the suitability of zoning by-laws as a basis for building development control expert systems may be suspect and perhaps future system development should focus more on the development control process itself rather than on the substance of the projects proposed. Indeed, this finding seems to be supported by Rodriguez-Bachiller's (1990) recent research at Oxford Polytechnic where such a process-based system has been under development. Nevertheless, the overall conclusions from the development of Euclid have to be positive ones since the system was developed in a short period of time and without any extensive knowledge or prior programming experience with the Turbo Prolog language. 110 As should be expected with any exploratory system, Euclid has several severe limita-tions. Despite these, though, the process of developing Euclid has been valuable in that it has identified many improvements and refinements, and has clarified the requirements of Expert Systems if they are to be used in a planning context. Assuming that such improvements and requirements can be incorporated successfully into Expert Systems, that the technology and software improves over the next several years, and that Planners and municipalities are perfectly clear about the role Expert Systems should play within planning, then there does appear to be some potential for Expert Systems as planning tools. I l l C H A P T E R SIX: A G E N E R A L C R I T I Q U E O F E X P E R T S Y S T E M S While the majority of the literature on expert systems is wholly uncritical or empirical in nature, there exists a small body of literature which has scrutinized extensively both the theoretical as well as the practical basis of expert systems. In order for planners to make informed decisions and to evaluate expert systems knowledgeably, it is essential that these critiques be discussed. We have already seen the problems associated with even a very simple expert system tool in terms of knowledge elicitation and representation, as well as the practical difficulties which arise in using inference techniques and logical languages. It is of paramount importance to realize that expert systems are in their infancy and will likely remain in such an embryonic state for several years to come despite the claims of the Japanese with their Fifth Generation Computer Project as well as the Americans: ... the science of Artificial Intelligence (AI) - is seen as a key source of innovation and impetus for facilitating the revolution in information technology. More specifically, there exists the dream of so-called "5th Generation" computing .... wherein the hope is that developments in A I will enable the construction of computing machines which, for the first time, will have serious intellectual abilities (i.e. real artificial intelligence). These computers will have access to powerful knowledge bases encapsulating many areas of expertise from which they will make complex inferences (both inductive and deductive) in order to aid decision-makers. (Bloomfield,1987) (author's emphasis) As mentioned earlier, such euphoric statements must be treated with a generous amount of skepticism since the concept of expert systems and A I itself can be attacked from a variety of perspectives. It will suffice here to divide the critique into three segments, namely: Theoreti-cal Limitations, Practical Limitations, Professional Planning Limitations. 112 Theoretical Limitations A central problem surrounding A l and expert systems is the very nature of knowledge and expertise themselves. What constitutes knowledge? What is expertise? Such questions are almost impossible to answer since both are flexible and dynamic and can change over time. Defining in advance the knowledge or expertise that will be required for a given situation is exceptionally difficult since how does one determine what is important and what isn't?, especially if that situation has not yet occurred. Collins (1987) as well as Gammack & Young (1985) have noted that there are varying kinds of knowledge ranging from facts, rules, and heuristics, through to cultural, manual, and perceptive skills and other 'common sense' elements. Some knowledge is consciously known or 'shallow knowledge' but there also exists subcon-scious knowledge - sometimes referred to as deep or tacit knowledge - which is not directly knowable by the expert and thus remains inaccessible to both the knowledge engineer and to the expert system. I do not intend to enter into a lengthy treatise concerning the validity of Artificial Intelligence as a field of study since much of the academic discussion is centred around the complex problem of trying to model human brain functions and is of little interest here. Needless to say, the whole question concerning A l and whether computers can actually reason in ways similar to human beings, or demonstrate any real intelligence at all, is currently a hot topic for debate and this should become apparent from the focussed critique presented here. For a critique of A l as a field of study and of computers as 'minds' in and of themselves see Searle (1987), Shanker (1987), and Born (1987). 113 In terms of expert systems applications in planning, the majority of real planning issues are exceptionally complex due to their open-ended nature and the involvement of numerous vested interest groups. Many of these issues are inherently qualitative in nature. Yet as Merry (1985) has noted: "Qualitative reasoning is concerned with .... all kinds of representation and manipulation of 'deep' knowledge and also 'common sense' reasoning". While expert systems researchers have made some inroads in this regard there is still no principled way .... [for expert systems to handle].... qualitative reasoning and many extremely hard problems remain to be solved". So, in precisely the area where expert systems are supposed to represent a significant advance over traditional approaches there has been little successful progress. Furthermore, as Shanker (1987) and Pfaffenberger (1988) have noted, expert systems are heavily imbued with powerful misconceptions, biases, and value statements which are difficult to grasp at first since they are an inherent part of the system's structure. Although, as Born (1987) notes, this is a common failing of the majority of the computer tools available today: "In many cases we do not realize that misconceived conceptions such as outdated ideas about economic growth, built into the computer programs via the theories underlying them, also seep into our world through these channels." (Born, 1987) Practical Limitations O f more immediate relevance in applying expert systems technology to the field of planning are the practical problems involved in trying to develop workable and useful systems. The major stumbling block which all expert systems face concerns the elicitation and repre-sentation of knowledge. As we have seen, knowledge, especially planning knowledge, is extremely complex, dynamic, and is nearly always dependent upon the current situation or 114 context. Thus, knowledge which is useful in one situation may not be so in another. Furthermore, knowledge can either be tacit (i.e. subconscious) or explicit (e.g. rules, facts, 'shallow' information). It is, therefore, impossible to try and gather the knowledge required to meet every eventuality and even harder to foresee what knowledge will be required for future situations. This is why expert systems have only been successful in domains where only limited amounts of knowledge are required, where the situational permutations are relatively small, and where such information is highly structured and narrowly focussed. Assuming that the required knowledge exists, it must then be elicited in order to be translated into an expert system. The success of an expert system depends upon how successfully knowledge can be extracted from the relevant expert(s). Some expert systems, including the simple demonstration system presented here, have been based largely upon the knowledge contained in books and manuals. Indeed, Leary (1988a) has argued that Design Guideline Manuals are in effect knowledge bases since they represent an abridged and codified culmination of 'real' planning and development control knowledge. However such 'book knowledge' represents the shallowest of shallow knowledge since it projects an idealized image of the task at hand and fails to take into account the messiness of reality (Collins et al, 1985). The meat of qualitative analysis, then, lies in deep, rather than shallow knowledge; in process rather than substance. Thus, the heart of an expert system lies in the heuristics and tacit knowledge which experts possess. But, and here's the rub, if the vast majority of this information is tacit or 'forgotten' knowledge (i.e. it's subconscious) how does one extract it from the expert? The process of knowledge engineering has been developed to try to deal with this problem and 115 involves workshop sessions between the knowledge engineer(s) and expert(s), at which the knowledge engineers use a variety of techniques in an attempt to draw knowledge from the experts and thus develop a model of the decision making or problem solving process(es) which the expert(s) use. For a discussion of knowledge elicitation techniques see Gammack & Young (1985) and for a description of the knowledge elicitation process at work see Berkowitz & Strzepek (1987). The success of this process not only hinges on the willingness of the experts to take part but more importantly on the ability of the knowledge engineer(s) to both extract and structure valuable knowledge as well as recognize when important heuristics have been uncovered. As one could expect, such knowledge elicitation sessions can produce vast amounts of unorganized information and separating the 'wheat from the chaff can be a time consuming undertaking. Indeed, even in a relatively simple domain, Berkowitz & Strzepek (1987) found that for every hour spent eliciting knowledge four hours were spent digesting the information gathered. Once knowledge has been gathered is has to be translated into a representational structure. As mentioned in Chapter Two, the most common representational structure is the production rule system. But as Sloman (1985) has noted, knowledge is so complex and dynamic that it requires a variety of formalisms in order to capture the full nuance of information. As humans, we are uniquely adept at understanding and coming to terms with a variety of representational systems: e.g. maps, models, diagrams, flowcharts, algorithms, etc., and we need to use such systems in order to analyze various problems and tasks successfully. As tools around which thinking and analysis can take place, such representational models are very useful. One possible role of expert systems could be as an additional representational structure in this regard. 116 While blackboard systems may allow the use of a variety of representational formalisms and so expand the heuristic models available, the overwhelming predominance of the production rule approach in the majority of current expert systems represents a severe weakness. No one representational structure can hope to capture the full force of knowledge nor deal with the varied types of information available. Thus, production rule systems tend to be biased towards 'shallow' knowledge since their structure forces information to be represented in fact and rule terms and as we have seen not all knowledge can be so represented. Perhaps a more important problem with the production rule representational schema is that it implies a model of human 'thought analysis' where human experts solve problems through a rational and logical assessment of rules and facts. In other words, the process of becoming an expert involves learning what the rules are and how to apply them. This view of 'experts as technicians' raises some serious questions but appears to be inherently flawed. Certainly, it does not correspond to the process by which planners gain experience and expertise. Dreyfus & Dreyfus (1984, 1986) have put forward a convincing model of the process by which expertise is gained. This model is opposite to that assumed by the production rule representation. In short it argues that beginners apply rules and facts only in trying to learn and understand a domain. As expertise is gained, we move away from applying rules towards recognizing exceptions to the rules and finally we learn to analyze tasks on a holistic rather than logical level [holistic here means superimposing the records of whole situations and measuring their similarity." Dreyfus & Dreyfus (1984)]. As an example of the mind functioning holistically rather than logically, Dreyfus & Dreyfus (1984) ask the question: How do we, as humans, recognize a face to be familiar? We do not, they argue, do so by decomposing it into its component parts (eyes, nose, hair, mouth, etc.) but react to it instinctively, intuitively, and as a whole. 117 At present, there exists no computational representation schema for mimicking such a holistic problem solving technique, hence the problems involved in trying to elicit facts, rules, and heuristics from experts who are thinking holistically: It seems that a beginner makes inferences using rules and facts just like a heuristically programmed computer, but that with talent and a great deal of involved experience, the beginner develops into an expert who intuitively sees what to do without applying rules The expert is simply not following any rules! He is.... recognizing thousands of special cases If one asks the experts for rules, one will, in effect, force the expert to regress to the level of a beginner and state the rules he still remembers, but no longer uses. (Dreyfus & Dreyfus, 1984, p. 226) Another problem which is prevalent for systems which attempt to operate within open ended domains (i.e. planning) is the problem of combinatorial explosion and diminishing returns. Combinatorial explosion stems from the way a group of objects can conceivably be arranged into varying combinations. As Brittain (1986) has noted, 10 objects (e.g. rules or facts) can be combined 1,024 ways while there are only 32 ways 5 objects can be combined. On the other hand, 15 objects have 32,768 combinations! Thus we have a geometric progression of the number of ways an expert system could consider a set of facts and rules. As Pfaffenberger (1988, p.68) has noted: "For every arithmetic increment in the system's breadth and expertise, there occurs an exponential increment in the number of situational contingencies that must be foreseen for the program to operate effectively." In other words in order to get a 10% improvement in performance the number of contingencies (i.e. rules and facts in the knowledge base) must be increased by a least 100% (i.e. a doubling of the knowledge base, see Barr & Feigenbaum, 1981) - this is the principle of diminishing returns since squeezing each extra ounce of performance out of the system requires more and more new knowledge. 118 This problem is a function of expert systems being situation and context dependent. Recall that the knowledge base is a repository of information about the problem and its context. Ideally, an expert system should be able to deal with and anticipate every conceivable situation and its interrelationships. This is, of course, impossible, since in an open ended domain like planning the number of situations and interrelationships would be infinite. B y necessity, the knowledge base has to be finite in order for the interactive user-expert system process to take place. But even for a finite knowledge base, the amount of information required to fully describe even fairly simple situations and limited interrelationships can be quite significant. In a production rule expert system such situations and interrelationships are described using facts and rules, and obviously each situation requires a variety of rules in order to express it. Expanding the scope of an expert system to take account of just one more situation thus requires that a whole host of new facts and rules be added to the knowledge base which describe not only that situation but also how it relates to all the other existing situations. Thus, for each increase in the expressive power of the knowledge base, the number of rules required explodes combinatorially. While the heuristic approach of expert systems and their use of a variety of control strategies should, theoretically, limit the size of the search space (i.e. that part of the knowledge base which is searched for information) relating to a given problem, expanding the size and performance of the expert system and developing the flexible control strategies necessary to handle all the information remains a fundamental problem in expert systems development. In production rule systems specifically, the order in which information in the knowledge base is assessed determines the effectiveness and efficiency of the system - the rules initially triggered 119 should reduce the search space dramatically so as to prevent lengthy search processes and user frustration over the time it takes for the system to respond. Another significant area where expert systems face severe difficulties is in their handling of uncertainty. As mentioned earlier, the majority of the techniques which have been developed in this regard are ad hoc at best (see Mamdani et al, 1985) and lack either a solid theoretical basis or substantial supporting empirical evidence, or both. Indeed, the hopes that expert systems can truly embrace uncertainty within their modus operandi remain bleak: Any attempt to deal with uncertainty within a strictly classical logic framework is itself an ad hoc method and does not constitute a sound theoretical framework. (Mamdani et al, 1985) Like knowledge, there are varying kinds of uncertainty since information can be uncertain in a variety of ways. Moreover, it is almost impossible to provide a comprehensive list of these dimensions of uncertainty since many exist across a seamless spectrum of quantitative and/or qualitative 'values' which themselves can be fuzzy and imprecise; consider the terms 'certain', 'probable', 'possible', 'uncertain', 'improbable', 'impossible', for example. While these give an idea of the extent to which uncertainty exists, its complex nature is best illustrated by listing the categories from which 'uncertainty' springs. The seven categories below reveal the nuances involved in uncertainty but are by no means an exhaustive list nor are the categories mutually exclusive. They do, however, serve to indicate the degree to which uncertainty is a central element of human life: Knowledge and information has associated with it one or more of these elements in varying proportions, and uncertainty can consist of: 120 B E L I E F One's belief in a given proposition or a piece of knowledge. L I K E L I H O O D The likelihood of a single, compound or conditional event. E X T E N T The extent of a proposition concerning a continuous variable. IMPRECISION The imprecision about any information. E X C E P T I O N Any exception to a general rule. M A N D A T E The mandate for performing some action. R E L E V A N C E The relevance of one piece of information to another. (see Mamdani et al,1985 - for a more comprehensive discussion of uncertain-ty) The over-riding lesson here is that, as with representational structures, no one way of handling uncertainty is sufficient, especially in a field like planning where uncertainty and varying values conflict with each other and imbue the planning process so completely. Professional Planning Limitations There exists almost no planning literature which evaluates the role of expert systems in planning from a critical perspective. The vast majority of planners currently researching expert systems are undertaking preliminary research into the potential application domains of expert systems and are doing so from within the firmly established rational planning philosophy. Consequently, the critique presented here is cursory in nature and merely represents an intuitive reaction to the possible adverse effects of expert systems upon various elements of contemporary planning practice. There is, thus, a need for expert systems to be evaluated from other planning perspectives but particularly in terms of how the infusion of expert systems might affect community development and the work of radical planners. 121 From a planning point of view there exists the danger that the introduction of expert systems may entrench the notion that top down rational planning is the preferred planning methodology. The whole process of developing expert systems implies the existence of a computer-literate elite which, in developing these tools, imbue them, whether consciously or not, with their beliefs, values, and biases. Furthermore, the very terminology of both A l and expert systems is imbued with such elitist tendencies; the phrase expert system implying a top-down process, for example. Furthermore, the possible creation of the notion that planning can be undertaken successfully through planners becoming users who interact with expert systems poses a significant danger and could lead to a dehumanization of the planning process: It is hard to believe that the company or government that has such systems dealing competently, but not expertly, with suitably selected problems will dominate all competition, as claimed by enthusiasts for Japan's fifth-generation project and for an expensive American response in kind. The most that can be expected is that expert systems may someday take their place alongside planning charts, management information systems, and professional training programs as useful tools for improving overall performance A genuine danger, however, faces the company or government going that route. To the extent that junior employees using expert systems come to see expertise as a function of large knowledge bases and masses of inferential rules, they will fail to progress beyond the competent level of their machines. With the leap beyond competence to proficiency and expertise thus inhibited, investors in expert systems may ul-timately discover that their wells of true human knowledge have gone dry. (Dreyfus and Dreyfus, 1986, p. 121) (Recall that one of the chief purposes of expert systems is to capture the knowledge of experts so as to have this information on tap once the expert has died or retired and so that it may be used to train junior staff) The possible dehumanizing effect of expert systems in planning has also been raised in connection with group process. Alan Hickling (personal correspondence, 1990), for example, 122 has argued that expert systems would have a damaging effect upon the success of group process since expert systems would foster user/expert system interaction in favour of group and community interaction. The planning process also involves numerous interest groups and parties with varying and conflicting values and objectives. The existence of these groups and their conflicting goals and beliefs complicates the processes of knowledge engineering and uncer-tainty handling still further, and thus could reduce the applicability and acceptance of expert systems technology in planning. On the other hand, Collins et al (1985) have argued that expert systems could serve to disseminate knowledge from experts to others. Planners could take advantage of this feature of expert systems in order to disseminate knowledge from 'expert' planners to members of various community groups and the public at large and thus inform people on the planning process. But Collins et al also argue, that in order for this "knowledge transfer" to take place, both the expert and the user must share the same tacit knowledge and a common culture. The experience in planning suggests that they must also share common beliefs, values, and desire similar goals in order for the content of an expert system's reasoning process and output to be understood and accepted: It becomes clear, that systems largely filled with information should be easy to build provided they are used by end users who know how to interpret the information. It is also clear, that the more expert the end user, the easier it will be to build a system that will be useful. Thus, the immediate value of expert systems, and of AI in general , is not to replace skilled persons - there is no immediate prospect of this - but to act as aids to increase the productivity of skilled persons and perhaps replace the relatively unskilled. (Collins et al, 1985) Expert systems could, in fact, be used to support group process since they could make portions of the planner's implicit knowledge explicit and thus open to scrutiny and debate. 123 Collins (1987) has argued that expert systems can be used to help render culture visible. Applying this notion to planning should mean that expert systems could be used to render both the planning process and the policies, values, and biases therein, visible. In other words, the processes of creating and using an expert system could be used to gain further insights into the planning process itself and to mediate between the various interest groups by developing workshop sessions in which groups interact with expert systems and then use that experience in group process workshops. Such programs would, of course, require planners highly sensitive to the limitations and co-optive dangers inherent in using expert systems. The point of using an expert system in qualitative research settings [e.g. Plan-ning] .... is not to create a computer program that is an end in itself; on the contrary, it is to harness microcomputer hardware and software so that it serves as a means to enhanced awareness, theoretical sensitivity, and humanistic understanding, [e.g. of the planning process] (Pfaffenberger,1988,p.77) In this way, expert systems, if carefully and sensitively used, could inform and reinforce group process. Thus, the expert system development process itself may be far more important in a planning sphere than the output it produces. This view is contrary to the belief of most expert systems developers who argue (as Burlinson, 1989, has argued) that everyone involved must abide by, accept, and agree with the output of any expert system. Furthermore, we have already seen that problems arise with the fixed set of rules contained within a knowledge base and, as Bloomfield (1987) has noted, such a fixed set of rules implies that consensus over their content is achieved (i.e. that everyone accepts the 'model' of planning which the knowledge base represents). Such a view follows traditional computer philosophy that system output is inherent-ly correct. These system developers though are not working within the planning field and such notions are, I would argue, highly counterproductive in a planning environment since they 124 reinforce the traditional top-down rational planning model and create a paternalistic view of group process and community participation. Conclusions It is clear from the above discussion, which is by no means an exhaustive one, that there exist serious and fundamental problems not only with expert systems but their use in the field of planning as well. However, any tool has its strengths and weaknesses. The current range of demographic, statistical, and economic/environmental impact models, for example, which are used quite extensively in the planning profession, are also infused with serious deficiencies and yet still make valuable contributions to the planner's efforts. Despite the full force and weight of the criticisms against expert systems and the difficult problems inherent in the expert systems development process, the majority of critics still feel that the field has value for qualitative researchers and hence for planners. Even Dreyfus (1987), perhaps one of the more vehement opponents of AI, while arguing that current A I and Expert Systems techniques are in effect moribund, still holds out hope in calling for alternative methodologies (such as neural nets) to replace the dominant production-rule paradigm. Dreyfus, thus, implicitly accepts the concept of expert systems as a valid one. The advantage of expert systems lies in their ability to make that which is implicit explicit and thus they have the potential to 'open up' the planning process (although at present this potential is quite limited due to the nature of the technology and the embryonic stage of expert systems research in planning). The process of generating a knowledge base and eliciting planning knowledge could lead to greater insights into the planning process itself and help in 125 developing consistent policy stances and regulation interpretations (see Hammond, 1986 for an example). In this role, expert systems can act as 'aide-memoires' and take advantage of the computer's capability to 'remember' and evaluate vast amounts of information. Expert systems can thus support the professional planner in their work and ease workloads by being able to • handle the numerous routine (e.g. zoning ) enquiries which planning staff receive daily (see Berkowitz & Strzepek, 1987). However, the responsibility for implementing and using expert systems successfully and conscientiously rests ultimately with the planner involved. It is essential that planners using expert systems understand their limitations and inherent pre-understandings so that the systems and their output are not abused or used abusively. As both Born and Pfaffenberger have noted: 'Clever' users of the programs will (after some mistakes and negative experien-ces) learn to take the results the programs generate with a grain of salt. They learn to relate results to reality with the help of their newly developed 'participative knowledge' which is needed for an adequate application of the programs. In this way, new 'user/experts' crop up who develop concepts about that part of reality they refer to. They re-invent the wheel, so to speak, and are guided by this wheel in their practice. (Born, 1987) .... the promise is bright so long as the software and its pre-understandings are clearly understood The utility of [an expert system] would lie not in any indefensible claim that it describes 'how people actually think', but that it would be easily manipulated in a way that could prove fruitful in sessions with informants As the [expert system] takes shape, its properties could be explored with informants, who can scrutinize the system's performance and point out when it performs at variance with native sensibilities Such tools can come into their own in qualitative research .... only when a thorough attempt is made to see them as they are. Like language, technology is our creation, and we imbue it with a symbolism whose potency we are only now beginning to guess. (Pfaffenberger, 1988,p.77). It should be clear from this last quote that expert systems have the capability to expand community participation and instill a greater public awareness concerning the intricacies of the 126 planning process. They may provide the planner with more suitable tools for presenting planning issues to communities and for establishing a basis from which discussions can take place. Given this role, the expert system becomes an element within the planning process rather than an end in itself. Finally expert systems may provide planning departments with a strategy for combating budgetary restraint and increased workloads by allowing time consuming, repetitive, and relatively simple tasks (e.g. giving out zoning information over the counter) to be handled by very junior and technical staff in consultation with an expert system (e.g. in terms of zoning matters, in consultation with a system similar to but more complex than the one developed here). Junior and middle planning staff could be employed more productively, and more often, in 'meatier' work such as policy formulation, long range plan preparation, community involve-ment, plan monitoring and analysis, etc., and thus, expert systems could perhaps help to redress the imbalance observed by Irwin & Farrow (1989). The danger here, though, is that Expert Systems could be seen by Municipal Administrations as a means of facilitating budgetary and staff reductions rather than as a vehicle for making planning potentially more effective and this is something of which all Planners interested in expert systems should be aware. 127 C H A P T E R S E V E N : C O N C L U S I O N S The research contained in this thesis set out to achieve two broad objectives. The first was to provide a synthesis of the existing literature on expert systems, and expert systems in planning, so as to provide a concise but moderately comprehensive basis from which profes-sional planners could assess expert systems technologies and identify potential areas of applica-tion within their own spheres of work. Indeed, a somewhat surprising finding of the literature review was the relative abundance of planning literature on the subject of expert systems even though the topic has only been under study for some five years. Since planning interest into expert systems to date has, to a large extent, been based upon a purely theoretical analysis of their potential, the second objective was to expand the boundaries of current planning research by actually developing a very simple expert system based upon the obvious, but so far relatively unpopular, domain of evaluating development applications. Indeed, the development of Euclid has shown that expert systems may have some potential in planning domains such as development control and that the notion of expert systems applications in urban planning is one which merits further research at the academic level. Euclid has proven to be a useful exercise since it has helped to provide a much clearer picture of the requirements that Expert Systems must meet if they are to be of use to Planners. In short, the results can be summarized as follows: • There does appear to be some potential for Expert Systems in Planning and Development Control. The use of fully developed expert systems, designed to assist in checking development applications, may result in time savings during the approvals process and may allow staff resources to be deployed on other tasks. • Expert S ystems may have a role in Planning in helping to detect costly human errors and train new members of staff. 128 • Expert Systems may have the potential to allow Planners to ask "What if?" questions and to develop new regulations and evaluate changes to the Zoning By-law in terms of their effectiveness for controlling development. • At the present time it is far too early to determine the potential, if any, of Expert Systems in Planning. Certainly, the technology is, at the present time, in its infancy and much more sophisticated software will have to be developed if Expert Systems are to be of real use to Planners in a variety of areas. A number of other findings also stand out as a result of conducting this research. Firstly, the process of developing Euclid has shown that expert systems, albeit crude in form, can be developed quite easily using a tool like Turbo Prolog, without the expenditure of significant resources and without the need for significant programming experience. Such a finding is good news for the future of expert systems in planning since the opportunity cost of exploring potential applications does not appear to be excessive. Secondly, development control has proved itself a good domain in which to target such expert systems research since it fulfills most of the criteria which are needed if an expert system is to be both viable and useful. However, even the relatively structured domain of assessing development applications has proven to be less structured and more open-ended than at first thought. This is due in large part to the discretionary freedom which is provided for in the Zoning Schedules. As a consequence Expert Systems may be even harder to build than first imagined. Nevertheless, it is still somewhat surprising that not more effort has been put into developing expert systems in this sphere since there does appear to be some potential for savings in time and in the consistency of the approvals process in so far as expert systems could detect and possibly prevent human errors. Such savings and improvements may be large since most planning departments spend an inordinate amount of time carrying out administrative and development control tasks. Furthermore, the limitations to departmental resources, and the large 129 number of development applications which are submitted annually, do appear to offer an incentive for building expert systems in the sphere of development control. Thirdly, while demonstration systems such as Euclid are not fully functional and/or ideal planning support tools, they do appear to provide an excellent way in which to learn about the domain, grapple with the problems which arise, and for identifying which capabilities a fully functional expert system must have if it is to be of everyday use to planners in the work place. Such an empirical approach is necessary at the present time since very few planning expert systems have been developed and we are at the stage where planners need to expand their expertise in this area if potentially useful tools are to be developed. Fourthly, the choice of software appears to play a critical role in the success and ease with which experimental expert systems are developed. While Euclid has proven to be a moderately successful exploratory tool, it lacks some of the refinements which average expert systems shells can provide. Turbo Prolog has proven to be quite adept at expressing the intricacies of Zoning By-laws but would require the expenditure of more programming effort if a highly flexible and comprehensive tool were to be created. The lesson here appears to be that planners may find it easier to explore the possibilities if they use expert system shells for the initial development work rather than one of the AI languages. Not only does Euclid point towards the usefulness and potential of expert systems in and of themselves, but it also suggests that the process of development may be just as valuable. Indeed, there appears to be some support for the notion that the process of developing expert systems is more important than the resultant system. The development of Euclid has lead to two 130 findings which, even if Euclid is extended or improved no further, still remain as valuable contributions to the planner's understanding of development control and Zoning By-laws. The first of these has been a greater understanding of how Zoning By-laws are supposed to control development. The development of Euclid forced a rigourous logical analysis of the zoning schedules and revealed that the Zoning By-laws implicitly define a process by which development proposals should be evaluated - Outright approval should be checked before Conditional approval, for example. In following this implicit process and in trying to translate the schedules into an equivalent logical form, Euclid provides the means by which the logical consistency of the By-laws themselves can be evaluated. Euclid thus suggests that expert systems may be useful as heuristic devices for evaluating those elements of the planning process which are taken for granted. The second finding in this regard, which is a by-product of the first, is the discovery of a couple of weaknesses and inconsistencies in the way Zoning By-laws are currently written. Euclid has revealed that Zoning By-laws can be unintentionally inconsistent and thus regulations which are, to all intents and purposes, identical in their intent may be written in slightly different styles depending upon who is tasked with drafting or amending the By-law and when. This finding suggests that greater thought and attention should be paid to the relationships between zoning schedules as well as to the overall consistency of the By-law itself. In addition, the legal constraints placed upon the contents of a By-law lead, in some cases, to regulations which, at their worst, are incomprehensible to the uninitiated or, at their best, confused. Such constraints, as well as the lack of any supporting graphics, also mean, in some cases, that the clarity of the 131 regulations is obscured and the resultant confusion may, in part, be responsible for making the approval process lengthier than need be. While there appears to be, on the basis of the work presented here, some future for expert • systems in planning, the strength of the arguments put forward by several authors critical of expert systems and the A I community as a whole (see Chapter Six) means that planners should be cautious in the way expert systems are developed and used. It should be stressed that expert systems are in their infancy and that the technology is still very limited. The failure of Euclid to meet all of the criteria, as discussed in Chapter Five, is due in part to the author's limited programming experience and to the use of a language rather than a expert system shell. However, it also suggests that Expert Systems techniques and software need to be improved and expanded before really useful and practical tools can be developed for the Planning profession; certainly, a simple production-rule system like Euclid appears to be insufficient. Such systems could also be a highly volatile force in redefining the role of the planner and the nature of the planning process. In unleashing expert systems upon the profession, planners must be very careful in making sure that the technology serves their needs and not the other way around. One way of addressing this issue is to develop these systems from within a strong theoretical and normative perspective. In other words, planners involved in the development of expert systems must have a solid grasp of contemporary planning practice so as not to develop systems in a theoretical vacuum. On a more practical level, planners should be aware that there are serious legal ramifications involved with systems such as Euclid. This is especially so where the use of such an expert system could possibly lead to a development application recommendation (either for . 132 or against) which later turns out to have been incorrect. Furthermore, the advent of expert systems in planning could lead to planners becoming dependent upon the technology and thus to a loss of professional skills in the planning workforce, especially if the expert systems introduced operate in a 'black box' fashion. Finally, it is possible that Expert Systems might be viewed by administrations as a means of cutting budgets and staff levels rather than as potentially liberating tools. So, where does this leave us? Clearly, there is some interest on the part of academic planners world wide in the potential for expert systems to be developed in planning and related fields. Equally clear, though, is that much more research needs to be done at the academic level, and more advanced pieces of software have to be developed, before truly competent systems can emerge and before systems can be installed with confidence in municipal planning departments and elsewhere. In this regard, the chapter in which Euclid is evaluated suggests numerous avenues for further research and these have arisen out of just one domain - that of development control. At this early juncture, planning departments should wait until it is absolutely clear that expert systems have a viable place in their day-to-day operation before approving the expendi-ture of any resources for the development of in-house systems. Thus, the impetus for system development has to come from outside the municipal sphere and yet, while commercial systems developed by Software Developers, and some Planning Consultants, are starting to appear, we are several years, perhaps decades, fromof-the-shelf 'intelligent' development control systems. The key to this impasse seems to be the development of more demonstration systems like Euclid but which push the bounds of current knowledge even further. Additionally, research into the 133 role and uses of Expert Systems within Planning should also help to define the extent to which they may be applied. In terms of the more distant future, the combination of Expert Systems with Computer Aided Design tools and Geographic Information Systems (G.I.S.) to produce comprehensive Computer Aided Planning systems, is a logical and desirable aim. However, Expert Systems should not be viewed as a panacea and it will be the planner who approaches expert systems (and other new technologies) with cautious optimism and with a healthy degree of skepticism who will most likely contribute the most to research in these areas. 134 Thesis Bibliography Aleliunas, Romas. (1989) Expert Systems and Shells: A Lab Introduction. Computer Science Programs Workshop, May 30-31st. Uninversity of British Columbia, Centre for Continuing Education. Alexander, Tom. (1985) "Artificial Intelligence: The Goal looms larger than life but researchers can't agree on how to build an intelligent machine." Popular Com- puting. Vo l . 4, No. 7, pp. 66-9 Amsterdam, Jonathan. (1985) "Expert Systems: Expert Systems on mainframes have proved their utility, and now they're entering the micro world in force.". Popular  Computing. Vo l . 4, No. 7, pp. 70-2,150,153. Antonisse, H . James, John W . Benoit, & Barry G . Silverman (Eds). (1987) Third Annual  Expert Systems in Government Conference: Proceedings. October 19-23rd, 1987., Washington, D . C . . Computer Society Press of the I E E E , 285 pp. + xiv. Armington, Stephen P. (1986) "Computer Applications to Land Planning." Urban Land. September, pp. 10-3. Armstrong, Jeff & Keith Weiskamp. (1988) "Building an Inference Engine with Turbo Prolog: Data, Data everywhere and not a thought to think.". Turbo Technix. Borland International. March/April, pp. 67-79. Babcock, Richard F . (1966) The Zoning Game: Municipal Practices and Policies. University of Wisconsin Press, Madison, Wisconsin. Barath, Etele & Ivan Futo. (1984) "A Regional Planning System Based on Artificial Intelligence Concepts". Papers of the Regional Science Association. Vol . 55, pp. 135-54. Bardon, Keith, David Grimshaw, Gi l l Mason, & Norman Strothers. (1985) Computers  in Planning. Royal Town Planning Institute. Bardon, K.S . (1988) "Microcomputers in British Local Authority Planning Depart-ments". Environment and Planning B: Planning & Design. Vo l . 15, No. 3, pp. 339-54. Barr, A . , & E . A . Feigenbaum. (1981) The Handbook of Artificial Intelligence. (Vol. 1). Heuristech Press, William Kaufman. Stanford/Los Altos, Calif.. Benson, Ian. (1986) "Prospector: A n Expert System for Mineral Exploration." in: G . Mitra, (Ed). Computer Assisted Decision Making: Expert Systems, Decision  Analysis. Mathematical Programming. Elsevier Science Publishers B . V . , The Netherlands, pp. 17-26. 135 Berkowitz, Linda, & Kenneth Strzepek. (1987) "An Expert System for the Administra-tion of the Acreage Limitation Provision of the Reclamation Reform Act of 1982." in: H.J . Antonisse, J.W. Benoit, & B . C . Silverman (Eds). Expert Systems  in Government: Proceedings of the Third Annual Conference on-. Computer Society Press of the I E E E , pp. 243-6. Bloomfield, Brian (Ed). (1987) The Question of Artificial Intelligence: Philosophical  and Sociological Perspectives. Croom Helm Ltd. , London. 286 pp. + xvi. Born, Rainer (Ed). (1987) Artificial Intelligence: The Case Against. Croom Helm Ltd. London, xxxv + 220 pp. Boyle, C . D . B . (1985) "Acquisition of Control and Domain Knowledge by Watching in a Blackboard Environment." in: Martin Merry (Ed). Expert Systems '85:  Proceedings of the Fifth Technical Conference of the British Computer Society  Specialist Group on Expert Systems. University of Warwick, December 17- 19th, 1985. Cambridge University Press, London, pp. 273-86. Brail, Richard K . (1987) Microcomputers in Urban Planning and Management. Center for Urban Policy Research. Rutgers, The State University of New Jersey, pp. 249-67. Bramer, M . A . (Ed). (1985) Research and Development in Expert Systems: Proceedings  of the Fourth Technical Conference of the British Computer Society Specialist  Group on Expert Systems. University of Warwick, December 18-20th, 1984. Cambridge University Press, Cambridge, pp. 1-11. Brehmer, Bemdt, Helmut Jungermann, Peter Lourens, & Guje Sevon (Eds). (1986) New  Directions in Research on Decision Making. Elsevier Science Publishers B .V . , Amsterdam, 443pp. + xii. Brittain, J. Michael. (1986) "The Challenge of Information Technologies to Knowledge Creation in the Social Sciences." in: B . C . Brookes (Ed). Intelligent Information  Systems for the Information Society: Proceedings of the Sixth International Research Forum in Information Science (IRFIS 6). Frascati, Italy. September 16-18th, 1985. Elsevier Science Publishers B . V . , The Netherlands, pp. 109-20. Brookes, B . C . (Ed). (1986) Intelligent Information Systems for the Information Society: Proceedings of the Sixth International Research Forum in Information Science (IRFIS 6). Frascati, Italy. September 16-18th, 1985. Elsevier Science Publishers B . V . , The Netherlands. 247 pp. + xii. Burlinson, Marie. (1989) Expert Systems and Shells: A Lab Introduction. Computer Science Programs Workshop, May 30-31st. Uninversity of British Columbia, Centre for Continuing Education. 136 Clark, Don, Ernest Chang, & Greg Sidebottom. (1988) "Hermes: A Prototype Expert System for Emergency Response Management". Emergency Preparedness  Digest. Vo l . 15, No. 2, pp. 18-21. Clocksin, W . F . & C.S. Mellish. (1987) Programming in Prolog. 3rd Edition. Springer Verlag, New York, 281 pp. + xiv. Cobb, Loren, & Robert M . Thrall (Eds). (1981) Mathematical Frontiers of the Social  and Policy Sciences ( A A A S Selected Symposium: 54), Westview Press, Inc..Colorado, & American Association for the Advancement of Science, xiv, 186 pp.. Coffee, Peter. (1988) "Why Lisp?". A I Expert. Vol . 3, No. 3, pp. 38-41. Cohn, Antony G . (1985) "Deep Knowledge Representation Techniques." in: Martin Merry (Ed). Expert Systems '85. Cambridge University Press, London, pp. 299-306. Collins, H . M . (1987) "Expert Systems, Artificial Intelligence and the Behavioural Co-Ordinates of Skill." in: Bloomfield, Brian (Ed). The Question of Artificial  Intelligence: Philosophical and Sociological Perspectives. Croom Helm Ltd., London, pp. 258-282. Collins, H . M . (1987) "Expert Systems and the Science of Knowledge", in: Wiebe E . Bijker, Thomas P. Hughes, and Trevor J. Pinch (Eds). The Social Construction  of Technological Systems: New Directions in the Sociology and History of  Technology. The M I T Press, Cambridge, Mass. x + 405 pp. Collins, H . M . , R . H . Green, & R . C . Draper. (1985) "Where's the Expertise?: Expert Systems as a Medium of Knowledge Transfer." in: Martin Merry (Ed). Expert  Systems '85. Cambridge University Press, London, pp. 323-34. Cooper, Glen. (1989) Practical Applications of Prolog. Glen Cooper & Associates Ltd. May, 26 pp.. Croft, D . (1985) "Choice Making in Planning Systems." in: Martin Merry (Ed). Expert  Systems '85. Cambridge University Press, London, pp. 125-41. Cullen, Ian. (1986) "Expert Systems in Planning Analysis". Town Planning Review. Vo l . 57, No. 3, pp. 239-51. Dalenoort, G.J. (1986) "Solving Problems with the help of Machines." in: B . C . Brookes (Ed). Intelligent Information Systems for the Information Society: Proceedings of the Sixth International Research Forum in Information Science (IRFIS 6). Frascati, Italy. September 16-18th, 1985. Elsevier Science Publishers B . V . , The Netherlands, pp. 83-90. 137 Davis, J.R. & J .L . Clark. (1989) "A Selective Bibliography of Expert Systems in Natural Resource Management." A l Applications. V o l . 3, No. 3, pp. 1-18. Davis, J.R., P.T. Compagnoni, & Nanninga. (1987) "Roles for knowledge-based systems in environmental planning.". Environment and Planning B: Planning & Design. Vol . 14, pp.239-54. Davis, J.R. & I.W. Grant. (1987) " A D A P T : A Knowledge-Based Decision Support System for Producing Zoning Schemes". Environment and Planning B: Planning  & Design. Vol . 14, No. 1, pp.53-66. Diamond, J.T. & J.R. Wright. (1988) "Design of an Integrated Spatial Information System for Multi-Objective Land-use Planning". Environment & Planning B:  Planning & Design. Vo l . 15, No. 2 pp. 205-14. Dickey, John W. , Elizabeth Mumby, Jeffrey Doughty. (1986) "Computer Consultant Systems: A n Application to Assessment of an Urban Housing Co-Operative.", in: Bruce Hutchinson, & Michael Batty (Eds). Advances in Urban Systems  Modelling: Studies in Regional Science and Urban Economics. Elsevier Science Publishers B . V . Vol.15, pp. 351-71. Dreyfus, Hubert L . (1987) "Misrepresenting Human Intelligence." in: Rainer Born (Ed). Artificial Intelligence: The Case Against. Croom Helm Ltd. , London, pp. 41-54. Dreyfus, Hubert L . & Stuart E . Dreyfus. (1984) "From Socrates to Expert Systems: The Limits of Calculative Rationality.". Technology in Society. Vo l . 6, No. 3, pp. 217-33. Dreyfus, Hubert L . & Stuart E . Dreyfus. (1986) Mind over Machine: The Power of  Human Intuition and Expertise in the Era of the Computer. The Free Press: A Division of Macmillan, Inc., New York, xviii + 231 pp. Efstathiou, J. , & E . H . Mamdani. (1986) "Expert Systems and how they are Applied to Industrial Decision Making." in: G . Mitra (Ed). Computer Assisted Decision  Making: Expert Systems, Decision Analysis. Mathematical Programming. E l -sevier Science Publishers B . V . , The Netherlands, pp. 3-16. Efstathiou, J . , V . Rajkovic, & M . Bohanec. (1986) "Expert Systems and Rule Based Decision Support Systems." in: G . Mitra (Ed). Computer Assisted Decision  Making: Expert Systems, Decision Analysis. Mathematical Programming. E l -sevier Science Publishers B . V . , The Netherlands, pp. 165-74. Ernst, Christian J. (Ed). (1988) Management Expert Systems. Addison-Wesley Publish-ing Co. , Reading, Mass., 210pp. + xx. 138 File, Portia E . & Paul Oldfield. (1988) "Advice on Available Grants from an Expert's Assistant". The Planner. October, pp. 29-30. Floyd, Michael. (1988) "Expert System design from a height: The next expert you consult may already be sitting on your desk!". Turbo Technix. Borland Interna-tional. March/April, pp. 64-66. Floyd, Michael. (1988) "Suitable for Framing: A n Object Oriented Approach using Frames can make an unruly knowledge base more managable". Turbo Technix. Borland International. March/April, pp. 80-88. Floyd, Michael. (1988) "Turbo Prolog 2.0: Intelligent Evolution: Turbo Prolog spreads its wings and the second generation is born". Turbo Technix. Borland Interna-tional. May/June, pp. 84-89. Friedmann, John. (1987) Planning in the Public Domain: From Knowledge to Action. Princeton University Press, Princeton, N.J. , 501pp. + xii. Friis, Siv, & S. Friis. (1986) "Tools for Prototyping." in: B . C . Brookes (Ed). Intelligent  Information Systems for the Information Society: Proceedings of the Sixth International Research Forum in Information Science (IRFIS 6). Frascati, Italy. September 16-18th, 1985. Elsevier Science Publishers B . V . , The Netherlands., pp. 71-82. Gammack, John G . , & Richard M . Young. (1985) "Psychological Techniques for Eliciting Expert Knowledge.", in: M . A . Bramer (Ed). Research and Develop- ment in Expert Systems: Proceedings of the Fourth Technical Conference of the  British Computer Society Specialist Group on Expert Systems. University of Warwick, December 18-20th, 1984. Cambridge University Press, Cambridge., pp. 105-112. Gellman, Harvey. (1989) "Competent or not, Expert Systems slow to find a place in industry." The Globe & Mai l . Report on Computers. Monday, March 13th, p. C12. Goel, Ashok, B . Chandrasekaran, & Donald Sylvan. (1987) "JESSE: A n Information Processing Model of Policy Decision Making." in: H.J . Antonisse, J.W. Benoit, & B . C . Silverman (Eds). Expert Systems in Government: Proceedings of the Third Annual Conference on-. Computer Society Press of the L E E E , pp. 178-87. Goldberg, Michael, & Peter Horwood. (1980) Zoning: Its Costs and Relevance for the  1980's. The Fraser Institute, Vancouver. Gomi, Takashi. (1987) "Survey of non-military applications of expert systems in Governments, in: H.J . Antonisse, J.W. Benoit, & B . C . Silverman (Eds). Expert 139 Systems in Government: Proceedings of the Third Annual Conference on-. Computer Society Press of the I E E E , pp. 224-42. Gottdiener, M . (1986) Cities in Stress: A New Look at the Urban Crisis. Urban Affairs Annual Reviews. Vol . 30, Sage Publications, London. Graham, Paul. (1988) "Anatomy of a Lisp Machine." A l Expert. Vo l . 3, No. 12, pp. 26-32. Hadden, W J . & S.G. Hadden. (1987) "An Intelligent Advisory System for Private Sewage Facility Permits: Two Years in the Trenches." in: H.J . Antonisse, J.W. Benoit, & B . C . Silverman (Eds). Expert Systems in Government: Proceedings of the Third Annual Conference on-. Computer Society Press of the I E E E , pp. 280-4. Hale, Jacques A . G . (1986) "Goal Oriented Decision Support." in: G . Mitra (Ed). Computer Assisted Decision Making: Expert Systems, Decision Analysis, Math- ematical Programming. Elsevier Science Publishers B . V . , The Netherlands, pp. 35-48. Ham, Michael. (1984) "Playing by the rules.". P .C . World. January, pp. 34-41. Hammond, Peter. (1986) "Representation of D H S S Regulations as a Logic Program.", in: G . Mitra (Ed). Computer Assisted Decision Making: Expert Systems.  Decision Analysis. Mathematical Programming. Elsevier Science Publishers B . V . , The Netherlands, pp. 107-16. Hasemer, Tony. (1984) Looking at Lisp: A Guide to Bringing the Power of the Leading  Artificial Intelligence Language to Microcomputers. Addison-Wesley Publ. Co.. Reading, Mass., 257 pp. Hashim, Safia H . (1988) "Metalogic and Expert Systems: The Golden Rule of Metalogic is:... Do unto thyself. Turbo Technix. Borland International. March/April, pp. 89-97. Hayward, Simon A . (1985) "Is a Decision Tree an Expert System?" in: M . A . Bramer (Ed). Research and Development in Expert Systems: Proceedings of the Fourth  Technical Conference of the British Computer Society Specialist Group on  Expert Systems. University of Warwick, December 18-20th, 1984. Cambridge University Press, Cambridge, pp. 185-92. Hickling, Allen. (1975) Aids to Strategic Choice. Centre for Continuing Education. The University of British Columbia. 63 pp. Hildebrand, J.D. (1988) "The Zen of C O N S : Choosing/Using a LISP." A l Expert. Vol . 3, No. 3, pp. 67-72. 140 Horak, Karl. (1988) "Borland International: Turbo Prolog 2.0." A I Expert. Vol.3 No. 6, pp. 77-9. Howard. Geoffry. (1984) Computer Anxiety and the use of Microcomputers in Manage- ment. Research for Business Decisions No. 92, U M I Research Press, Ann Arbor, Mich. , 137pp. + xii. Hudson, Barclay M . (1979) "Comparison of Current Planning Theories: Counterparts & Contradictions.". Journal of the American Planning Association. October, pp. 387-97. Irwin, Donald W . & John E . L . Farrow. (1989) "How do you evaluate your Planning Department?". Municipal World. October, pp. 270-2. Jerome, Marty. (1989) "Neural Nets: Back in Style." PC/Computing. Vo l . 2, No. 3, pp. 72-3. Keen, Michael J.R. (1985) "Expert System Shells come of Age." in: M . A . Bramer (Ed). Research and Development in Expert Systems: Proceedings of the Fourth  Technical Conference of the British Computer Society Specialist Group on  Expert Systems. University of Warwick, December 18-20th, 1984. Cambridge University Press, Cambridge, pp. 13-21. Keen, P . G . & M . S . Scott Morton. (1986) Decision Support Svstems:An Organizational  Perspective. Addison-Wesley, Reading, Mass.. 1978, p. 13. quoted in: Richard S. Rosenberg. Computers and the Information Society. John Wiley & Sons, Inc., New York. p. 86. Klosterman, R . E . & J.D. Landis. (1988) "Microcomputers in U.S. Planning: Past, Present, and Future.". Environment and Planning B: Planning & Design. Vol . 15, No. 3, pp. 355-367. Krutch, John. (1981) Experiments in Artifical Intelligence for Small Computers. Howard W . Sams & Co., Inc.. Indianapolis, Ind.. 110 pp. Leary, Michael. (1986) "Expert Systems: What Potential for Planning?". The Planner. December, Computers in Planning: A Special Advertising Supplement. Leary, Michael E . (1988a) "Knowledge and reasoning in development control and urban design: an expert systems approach". Environment and Planning B: Planning &  Design. Vo l . 15, No. 4, pp. 383-98. Leary, Michael. (1988b) "What are Expert Systems and how can they contribute to Planning?". Planning Outlook. Vo l . 31, No. 1, pp. 7-12. 141 Leary, Michael, & Augustin Rodriguez-Bachiller. (1987) "The Potential of Expert Systems for Development Control in British Town Planning" in: Research and  Development in Expert Systems IV. Proceedings of Expert Systems 1987  Seventh Annual Technical Conference of the British Computer Society  Specialist Group on Expert Systems. Brighton, U . K . , December 14-17th, pp. 198-210. Leary, Michael, & Augustin Rodriguez-Bachiller. (1988) "Expert Systems in Develop-ment Control: Progress so far and the Way Ahead". The Planner. October, pp. 26-8. Lundberg, C . Gustav & Vincent B . Robinson. (1988) "Computer Programs that Know: A Tutorial". Computers, Environment, and Urban Systems. V o l . 12, N o . l , pp. 49-71. Macgill , S . M . (1986) "Research Policy and Review 12: Evaluating a Heritage of Modelling Styles". Environment and Planning A . Vo l . 18, pp. 1423-46. M c G i l l , Penny. (1989) "Friendly Systems are catching Boss's Eye.". The Globe & Mail .  Report on Computers. Monday, March 13th, pp. C1-C2. Mamdani, Abe, Janet Efstathiou, & Dominic Pang. (1985) "Inference Under Uncertain-ty." in: Martin Merry (Ed). Expert Systems '85. Cambridge University Press, London, pp. 181-94. Marksjo, B . (1986) "Expert Systems for Local Government Planning" in: Newton, P.W. & M . A . P . Taylor (Eds). Microcomputers for Local Government Planning &  Management. Hargreen Publishing Co. , Melbourne, pp. 266-72. Merry, Martin (Ed). (1985) Expert Systems '85: Proceedings of the Fifth Technical  Conference of the British Computer Society Specialist Group on Expert Systems. University of Warwick, December 17-19th, 1985. Cambridge University Press, London. 334 pp.+ ix. Mitra, G . (Ed). (1986) Computer Assisted Decision Making: Expert Systems. Decision  Analysis. Mathematical Programming. Elsevier Science Publishers B . V . , The Netherlands. 282 pp. + xxii. Newquist, Harvey P. (1988) "In practice: Struggling to maintain.". A.I. Expert. Vol . 3, No. 8, pp. 69-71. Newton, P.W. (1988) "Microcomputer Applications for Urban Infrastructure Planning". Environment and Planning B: Planning & Design. Vo l . 15, No. 3, pp. 255-68. 142 Openshaw, S. (1989) Review of: I. Aleksander & P. Burnett. Thinking Machines: The Search for Artificial Intelligence.(1987) in: Environment and Planning B: Plan- ning & Design. Vo l . 16, No. 1, pp. 116. Openshaw, S. (1989) Review of: Richard K . Brail. Microcomputers in Urban Planning & Management.(1987) in: Environment and Planning B: Planning & Design. Vo l . 16, No. 2, pp. 244-5. Ortolano, Leonard & Catherine D . Perman. (1987) "A Planner's Introduction to Expert Systems". Journal of the American Planning Association. Winter, pp. 98-103. Page, Bernd. (1989) A n Analysis of Environmental Expert System Applications with  Special Emphasis on Canada and the Federal Republic of Germany. Alberta Research Council, Edmonton & Calgary, Canada. May-June, 40 pp. Pfaffenberger, Bryan. (1988) Microcomputer Applications in Qualitative Research. Sage University Paper Series on Qualitative Research Methods, Volume 14. Sage Publications, Inc., Newbury Park, Calif.., 87 pp. Phillips, Lawrence D . (1986) "Decision Analysis and its Application in Industry." in: G . Mitra (Ed). Computer Assisted Decision Making: Expert Systems. Decision  Analysis, Mathematical Programming. Elsevier Science Publishers B . V . , The Netherlands, pp. 189-97. Reighgelt, Han, & Frank Van Harmelen. (1985) "Relevant Criteria for Choosing an Inference Engine in Expert Systems." in: Martin Merry (Ed). Expert Systems  '85. Cambridge University Press, London, pp. 21-30. Repo, Aatto J. (1986) "On the Value of Information from the Information User's Point of View." in: B . C . Brookes (Ed). Intelligent Information Systems for the  Information Society: Proceedings of the Sixth International Research Forum in Information Science (IRFIS 6). Frascati, Italy. September 16-18th, 1985. E l -sevier Science Publishers B . V . , The Netherlands, pp. 1-10. Rich, Kelly M . & Phillip R. Robinson. (1988) Using Turbo Prolog. Second Edition. Borland-Osborne/McGraw Hil l , Inc.. Berkeley, Calif., xvi, 369 pp. Robertson, David, Robert Muetzelfeldt, Dave Plummer, Mike Uschold, & Alan Bundy. (1985) "The E C O Browser", in: Martin Merry (Ed). Expert Systems '85. Cambridge University Press, London, pp. 143-56. Rodriguez-Bachiller, Augustin. (1990) "Desktop Planning: Can Expert Systems help?". Paper presented at the Third U R S A-Net Advanced Seminar/Forum "Computers in Planning.". Patras, June, 1990. 143 Rogers, Jean B . (1987) A Turbo Prolog Primer. Addison-Wesley Publ.Co.. Reading, Mass.. 215 pp. + xii. Ronis, B . & W . Rucker. (1971) "Zoning: Tool or Tie-Up?". Urban Land. Vo l . 32, No. " 1, pp. 3-9. Rosenberg, Richard S. (1986) Computers and the Information Society. John Wiley & Sons, Inc., New York. 397 pp. + xxv. Schneider, G . Michael, Steven W . Wiengart, & David M . Perlman. (1982) A n Introduc- tion to Programming and Problem Solving with Pascal.. Second Edition. John Wiley & Sons, Inc.. New York, xii, 467 pp. Searle, John R. (1987) "Minds, Brains and Programs." in: Rainer Born (Ed). Artificial  Intelligence: The Case Against. Croom Helm Ltd., London, pp. 18-40. Shafer, Dan. (1988) "Finding a Prolog.". AI Expert. Vo l . 3, No. 6, pp. 71-5. Shammas, Namir Clement. (1986) "Turbo Prolog: A n easy-to-use nonstandard im-plementation of Prolog for the I B M P C " . Byte. September, pp. 293-5. Shanker, S .G. (1987) "The Decline and Fall of the Mechanist Metaphor." in: Rainer Born (Ed). Artificial Intelligence: The Case Against. Croom Helm Ltd., London, pp. 72-131. Shaw, Mildred L . G . & Brian Gaines. (1986) "Knowledge Engineering Tools for Expert Systems.", in: G . Mitra (Ed). Computer Assisted Decision Making: Expert  Systems. Decision Analysis. Mathematical Programming. Elsevier Science Pub-lishers B . V . , The Netherlands, pp. 147-63. Shipley, Chris. (1989) "Whatever happened to A.I.?: On the trail of Artificial Intelligence at the kickoff of a new decade. What is A.I. really? Where is it headed?". PC/Computing. Vol . 2, No. 3, pp. 64-74. Sloman, Aaron. (1985) "Why we need many Knowledge Representation Formalisms." in: M . A . Bramer (Ed). Research and Development in Expert Systems: Proceed- ings of the Fourth Technical Conference of the British Computer Society  Specialist Group on Expert Systems. University of Warwick, December 18-20th, 1984. Cambridge University Press, Cambridge, pp. 163-83. Sobkowski, Isidore, & Frances Tischler. (1988) "Software Review: Four Product Wrap-Up: Mainframe Expert Systems." A I Expert. September, V o l . 3, No. 9, pp. 67-77. 144 Suh, Sunduck, Moonja Park K i m , Tschangho John K i m . (1988) "Esman: A n Expert System for Manufacturing Site Selection". Computers. Environment, and Urban  Systems. Vo l . 12, No. 4, pp. 239-52. Tanic, Emile. (1986) "Urban Planning and Artificial Intelligence: The Urbys System". Computers. Environment, and Urban Systems. Vo l . 10, No. 3 & 4, pp. 135-46. Tate, Austin. (1985) "A Review of Knowledge-Based Planning Techniques." in: Martin Merry (Ed). Expert Systems '85. Cambridge University Press, London, pp. 89-111. Tello, Ernest R. (1988) Mastering A l Tools and Techniques. Howard W . Sams & Co., Inc.. Indianapolis, Ind. 543 pp. + x. The City of Vancouver. (1987) Rezoning Procedures in Vancouver. Brochure No. 3 June. The City of Vancouver. (1989) Zoning and Development By-law.. September. The Corporation of the City of North Vancouver. (1985) "Zoning By-law 1967.". By-law  # 3778. May 21st, 1985. Thompson, Robin. (1990) "Presidential Statement." The Planner. Vo l . 76, No. 3. pp. 11-2. Townsend, Carl. (1987) Mastering Expert Systems with Turbo Prolog. Howard W . Sams & Co. , Inc. Indianapolis, Ind.. 257 pp. + xiii. Transport Canada. (1985) Proceedings of the Workshop on the Application of Expert  Systems to Transportation. Montreal, September 12th, 1985. Research and Development Directorate, Transport Canada, December, (TP 7328E). Transport Canada. (1986) Expert Systems: Their Application in the Canadian Transport  Sector. January 1st, 1986. Applied A l Systems, Inc. & Cognos, Inc. prepared for: Director General, Research & Development Directorate, Transport Canada, 1986, (TP 7209E). Ukeles, Jacob, B . (1964) The Consequences of Municipal Zoning. Washington D . C . : Urban Land Institute, J .C. Nichols Foundation. Van Der Gaag, L . C . & P.J.F. Lucas. (1988) "HEPAR: A n Expert System in Prolog.". A.I. Expert. Vol.3, No. 6, pp. 34-43. Van Horn, Mike, and The Waite Group. (1986) Understanding Expert Systems: A n In-Depth Guide to the New Generation of "Smart" Computer Software. Bantam Books, New York. 233 pp. 145 Webster, C.J. (1989) Review of: W J . Black. Aspects of Information Technology. Intelligent Knowledge Based systems: A n Introduction.(1986) in: Environment  and Planning B: Planning & Design. Vol . 16, No. 2, pp. 246-7. Weiskamp, Keith. (1988) "What's in a list?: In list processing, a little bit of recursion goes a long way.". Turbo Technix. Borland International. May/June, pp. 90-3. Wielemaker, J, & A . Bundy. (1985) "Altering the Description Space for Focussing." in: Martin Merry (Ed). Expert Systems '85. Cambridge University Press, London, pp. 287-98. Wigan, M . . Review of : P.W. Newton, M . A . P . Taylor, & R. Sharpe (Eds). (1989) Desktop Planning: Microcomputer Applications for Infrastructure and Services Planning and Management.(1988) in: Environment and Planning B: Planning &  Design. Vo l . 16, No. 1, pp. 113-5. Wilkins, David E . (1988) Practical Planning: Extending the Classical A I Planning  Paradigm. Morgan Kaufmann Publishers, Inc.. San Mateo, Calif.., 205 pp. + xiii. Williams, Adrian J. (1986) "Decision Analysis for Computer Strategy Planning." in: G . Mitra (Ed). Computer Assisted Decision Making: Expert Systems. Decision  Analysis, Mathematical Programming. Elsevier Science Publishers B . V . , The Netherlands, pp. 207-23. Wodl, Gerald. (1987) "Expertensysteme: Ein Konzept und Seine Anwendungsmoglich-keiten in der Raumplanung" (Expert Systems: A Concept and Possibilities for its Application in Planning). MannheimerGeographische Arbeiten. Vo l . 22, pp. 119-24. Yazdani, Masoud & Ajit Narayanan (Eds). (1984) Artificial Intelligence: Human  Effects. Ellis Horwood Ltd., Chichester, 318pp. Yeh, A . Gar-On. (1988) "Microcomputers in Urban Planning: Applications, Constraints, & Impacts". Environment and Planning B: Planning & Design. Vo l . 15, No. 3, pp. 241-54. Anon. (1988) "Expert System Vendors and Features.". A I Expert. Vo l . 3, No. 9, pp. 71-7. Anon. (1989) "Management Brief: Decisions, Decisions.". The Economist. July 22nd, 1989, pp. 64-5. 146 A P P E N D I X 1 Z O N I N G D A T A B A S E SPECIFICATIONS RT-2 Zoning District zone_class("RT-2") p^rmittBd_uses([l,2,3A5,6J,9J041J2434445J6J74849,20,21,22,23,24,25,2 )^ . min_site_areal (4800,7200) ht(30,2,l) front_yd(24) side_yards(0.1,5) side_yds(7) rear_yard(35) fsr(0.6,0.75) site_coverage(0.45) site_cov(0.40,0.55) parking_coverage(0.3) number_of_buildings(3) accessory_buildings( 12,15,5,0.35,520,0.8) RT-4 Zoning District zone_class("RT-4") permitted_uses([l,2,3,4,5,6,7,8,9,ll, 12,13,14,15,16,17,18,19,20,21,22,24,25]) min_site_area(3300) height(35,2.5) front_yd(24) side_yards (0.1,5) rear_yard(35) fsr(0.6,0) site_coverage(0.45) parking_coverage(0.3) accessory_buildings(12,15,5,0.35,520,0.8) R T - 4 N Zoning District zone_class("RT-4N") pernritted_uses([l,2,3A5,6J3,94142J3,14,15,16,17,18,19,20,21,22,24^5]) min_site_area(3300) height(35,2.5) front_yd(24) side_yards(0.1,5) rear_yard(35) fsr(0.6,0) site_coverage(0.45) parking_coverage(0.3) accessory_buildings(12,15,5,0.35,520,0.8) noise_level(35,40,45,60) 147 A P P E N D I X 1 Z O N I N G D A T A B A S E S P E C M C A T I O N S (continued) RT-5 Zoning District zone_class("RT-5") pennitted_uses([l,23A5A7,8,9404142J3a4,15,16,17,18,19,20,21,22,23,24^5]) min_site_area(3300) max_frontage(105) height(35,2.5) front_yd(24) Aside_yards(0.1,5) rear_yard(35) fsr(0.6,0.75) site_coverage(0.45) parking_coverage(0.3) accessory_buildings(12,15,5,0.35,520,0.8) R T - 5 N Zoning District zone_class("RT-5N") perrmtted_uses([l,23A5A7,8,9aoaiJ2J3a445J6,17,18,19,20,21,22,23,24,25]) min_site_area(3300) max_frentage (105) height(35,2.5) front_yd(24) side_yards (0.1,5) rear_yard(35) fsr(0.6,0.75) site_coverage(0.45) parking_coverage(0.3) accessory_buildings(12,15,5,0.35,520,0.8) noise_level(35,40,45,60) 148 A P P E N D I X 1 Z O N I N G D A T A B A S E SPECIFICATIONS (continued) RT-6 Zoning District zone_class("RT-6") permitted_uses([ 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22]) min_site_area(3300) max_frontage(105) height(35,2.5) front_yard(0.2,5) side_yards(0.1,5) rear_yard(35) fsr(0.6,0.75) site_coverage(0.45) parking_coverage(0.3) dwelling_unit_density 1(30) dwelling_unit_density2(25) number_of_buildings (1) exterior_design(1.3,30,10,3,6.52) accessory_buildings(12,15,5,0.35,520,0.8) 149 Appendix 2 Index of Predicates contained within Euclid Predicate Definition access_os- defines the routine for accessing the operating system from within Euclid. ans_base() - this keeps track of whether or not the building proposed has a basement, i.e. it stores the user's answer regarding the existence of a basement so that the user does not have to be asked the same question more than once. ans_cell() - this keeps track of whether or not the building proposed has a cellar and functions in the same way as ans_base(). ans_ht() - this stores the height of the proposed/existing building to prevent having to ask the user redundant questions. ans_storeys() - in the same way as ans_ht(), this stores the number of storeys of the building proposed or in existence. ans_track() - keeps track of answers the user supplies while the system is checking for outright uses so that these can be used in checking for conditional approval, if need be, without having to ask the user for the same information again. check_acc-gfa() - checks to make sure that the gross floor area of any accessory building is within the limits prescribed by the zoning schedule concerned. check_acc_roof() - checks to make sure that the height of the roof for any accessory building is within prescribed limits. check_acousticsl() - checks to see if the development proposed conforms with acoustical requirements in zones where noise intrusion is deemed a problem. check_ansX() - checks answers supplied by the user to make sure they conform to the format required, i.e. this predicate traps input errors where yes/no responses are required. check_conditional_app() - this predicate takes the use selected by the user and tests to see if it is allowed conditionally in the zone in question. check_dwelling_unit_densityl() - checks to make sure that the number of dwelling units proposed are within the density requirements specified for the zone in question. check_external_designX - checks to make sure that the building(s) proposed meet basic design requirements in terms of their exterior appearance and that they fit in with surrounding buildings. 150 check_front_yardX - checks to make sure that the front yard proposed meets minimum depth requirements and thus that the buildings proposed are set back from the street in the same way as the surrounding buildings. check_fsrX() - checks to make sure that the total floor space area of the proposed building(s) is within the floor-space-ratio requirements for the zone in question. check_heightX - checks to make sure that the building(s) proposed are within the height envelope specified or that (in some cases) they are of a similar height to surrounding buildings if those buildings are above the height maximum, check_horizontal_sun_anglel() - checks to make sure that the units proposed have adequate exposure to sunlight. check_number_of_buiIdingsl - returns a message informing the user that more than one principal building per site can be allowed but that certain requirements must be met. It also ascertains whether or not a rear yard relaxation is required. check_outright_app() - this predicate checks to see if the use selected by the user is allowed outright for the zone in question. check_rear_yardX - checks to see if the development proposal meets minimum rear yard standards for the site/use/zone combination in question. check_regs() - this predicate lists those regulations which apply to specific zone/use combinations. Once the use as been established as being allowed either outright or conditionally then this predicate evaluates all those regulations which apply to the zone/use combination selected. check_rest_of_regs() - lists all the regulations which apply to a specific zoning schedule. This predicate is used to make sure that the development proposal meets regulations not covered by the check_regs() predicate - i.e. the non-use specific regulations. check_side_yardsX() - checks to make sure that the building(s) proposed are set back a sufficient distance from the sides of the lot. check_site_coverageX() - this predicate checks to make sure that the footprint of the building(s) proposed are less than or equal to the maximum site coverage area allowed. It also checks to see if the space proposed for surface parking is within the area allowed. check_use() - defines the procedure to be used in checking for zoning approval. This predicate determines that outright approval for the use will be checked first followed by the zoning regulations relating to outright uses. If these fail check_use() will go on to check for conditional approval for the use and will then 151 go on to check the zoning regulations governing conditional uses. check_use() also provides the mechanism for informing the user of the main outcome of an evaluation - i.e. whether the use is approved outright, conditionally, or not at all. do() - this predicate translates what the user selects from the main menu into a series of actions which Euclid can understand. end- defines the routine which brings the user back to the main_menu once the evaluation session has reached a conclusion. error_msg() - describes and defines messages which appear on screen in the event of a user input error. find_use- presents the user with a list of uses to choose from. If the use selected is not allowed in the zone selected, find_use will inform the user and ask them if they want to check to see if the use proposed conforms with the zoning regulations for the zone selected.(The Director of Planning may permit a use not expressly permitted under the zoning schedule providedit meets the necessary regulations). get_database() - takes the zone selected by the user and retrieves the corresponding database containing details of the zoning specifications. It then loads this information into an internal database within Euclid for use by other predicates within the system. get_dimensions - asks the user a series of questions about the dimensions of the site. It takes the figures supplied by the user and stores them in an internal database within Euclid designed for this purpose. In this way site dimensions can be referenced by accessing the internal database rather than asking the user for the figure(s). get_relaxation() - acts as a filter to ensure that (in the event of a development proposal failing to meet a zoning regulation for which a relaxation may be permitted) only those relaxations which pertain to the failed regulation, and to the particular zone/use combination selected, are reported to the user. main_menu- this predicate lists the action choices the user can select from the main menu window. memberO - this predicate is a recursive predicate which checks to see if the use selected by the user is allowed in the zone selected. The database for each zoning schedule contains a list of uses and member() checks to see if the use selected is a member of the list for the zone in question. modify_the_database - The predicate at the moment just creates a window from which the user would be able to modify information contained in the zoning databases. This predicate is cosmetic only at present. 152 proposed_use() - keeps track of the use selected by the user so that Euclid does not have to keep asking for the same information at every question. query_the_user - defines the actions Euclid carries out if the user selects the "Check the Zoning on a Property" option from the main menu. This predicate lists the zones which are contained within Euclid's knowledge base. The property in question has to be in one of the six two-family zoning districts in order for the system to work. The user is then asked to select the relevant zone - query_the_user then tells Euclid to get the relevant zoning database and starts the evaluation process rolling. quit- exits Euclid and returns the user to the Operating System - i.e. it returns control to D O S . relaxation() - defines the relaxations which apply for certain zone/use combinations in relation to specific zoning regulations. Each relaxation() predicate identifies a text string which Euclid reports to the user in the event that that relaxation applies. test() - acts as a filter to ensure that the check_external_designl predicate is only triggered if zone in question is RT-6 since the external design regulations only apply for this zone. testX() - this predicate checks to see what answers the user has provided to certain questions at an earlier stage in the interactive session. It acts as a filter within the check_site_coverage3() predicate since the answers which testX() checks deter-mine which portions of the check_site_coverage3() predicate are to be evaluated. 153 APPENDIX 3 - EUCLID PROGRAMMING CODE /*• EUCLID,, PRO #/ / # # * # * # * * # # # # # # # # # # * * * # # # # * -s- # # * # # # # # # -K- # # * * * * # # * # * • » * * # # # # # * * * • » * * * * # # * # # •«• # # * # # * # -x- # # # # # * # # * * # # # # * # * * # * # # * # * # * # # * # * # # # » * # # * -x- * / /# #/ /* E U C L I D */ /# #/ /* A SIMPLE DEMONSTRATION EXPERT SYSTEM FOR ASSISTING PLANNERS IN THE F I E L D OF DEVELOPMENT CONTROL #/ / # * * * # * •«• * * * * # # # * # # * * * # * # * # * * • » * * * * * * # * # # -X- • * # # « # -55- # # # -Si- • * * * -X- * * * # # * # # * # * * # # # # # -X- # # # # * # * # # # # # * # * * * * # * * # * * # # * # * # # # * # X- * # # * # -ft- # * # # # # # # / /* PROGRAM DOMAINS */ / # # # # # # # # # # # # # # # # # # # # # # * # # # # # # # # # # # # # # # / % % The P R O G R A M DOMAINS! s e c t i o n s p e c i f i e s t h e k i n d o f i n f o r m a t i o n w h i c h e a c h p r e d i c a t e c an h a n d l e . The s t a n d a r d t y p e s % ( o r DOMAINS) a r e s i n t e g e r s , r e a l s , s t r i n g s , c h a r a c t e r s , & s y m b o l s . S p e c i a l k i n d s of i n f o r m a t i o n (eg,, z o n e , u s e , % h e i g h t ) c a n a l s o be d e f i n e d i n t e r m s of t h e 5 s t a n d a r d d o m a i n s . T h i s makes t h e p r o g r a m more r e a d a b l e . % % 'code = 1250' i n d i c a t e s t h a t t h e c o d e array memory must be s e t a t 1250 p a r a g r a p h s i n o r d e r t o be a b l e t o c o m p i l e % EUCLID t o an e x e c u t a b l e f i l e . N.B. a n y t h i n g between /# and */ o r a f t e r a '%' i s t r e a t e d a s a comment and i s n o t c o m p i l e d . % % ' p r o j e c t "EUCLID"' i n d i c a t e s t h a t t h i s f i l e f o r m s a p a r t of a l a r g e r p r o g r a m c a l l e d EUCLID. % % ' i n c l u d e ...' means t h a t t h e f i l e GLOBALS„PRO i s t o be i n c o r p o r a t e d i n t o EUCLID.PRO. In t h i s c a s e G L O B A L S . P R O % d e f i n e s t h e g l o b a l d o m a i n s , p r e d i c a t e s , and d a t a b a s e s w h i c h a r e s h a r e d by a l l t h e f i l e s w h i c h make up EUCLID.PRO /* c o d e = 1250 */ p r o j e c t "EUCLID" i n c l u d e " c : W p r o g r a m s W t p r o l o g W g l o b a l s. p r o " / # * * * # * » # # # # ii- # * # -it # # * # # # -X- # * * V- # -X- # # /* PROGRAM PREDICATES */ /II % PROGRAM PREDICATES % The PROGRAM PREDICATES s e c t i o n l i s t s a l l t h e u s e r d e f i n e d p r e d i c a t e s w h i c h d e s c r i b e t h e f a c t s , r u l e s , and % i n f e r e n c i n g r o u t i n e s u s e d i n t h e p r o g r a m . The p r e d i c a t e s l i s t e d b e l o w a r e l o c a l and a r e u s e d p r i m a r i l y t o % c o n t r o 1 t h e mai n menu , s t a r t t h e e v a 1 u a t i on o f deve 1 opmerit p r o p o s a l s , and d i s p l a y t h e r e s u l t s „ p r e d i c a t e s mai n._menu q u e r y __t h e _u s e r find _ _ . 2:one m o d i f y _d a t a b a s e' a c c e s s _ o s d o ( i n t e g e r ) q u i t , end e r r o r _ m s g ( i n t e g e r ) g e t _ d a t a b a s e (:i. n t e g e r ) f i n d j j s e g e t _ d i m e n s i o n s c h e c k _ s i te__shape (f r o n t , 1 e f t , r e a r , r i g h t , l o t a r e a ) t e s t _ _ f 1 o o r a r e a (-f 1 o o r a r e a , -f I o o r s p a c e , f 1 o o r a r e a , f 1 o o r s p a c e ) member < i n t e g e r , u s e s l i s t ) t e s t Czone) / # * * * * ¥r # * # # * # # •* # # * # # # # # »a- * # •» # •* •* # # / /# PROGRAM CLAUSES #/ / # * # # # # * # # * * # # * * # # # * # # # # * # # # # # # * # # -x- # * # / % The PROGRAM CLAUSES s e c t i o n d e s c r i b e s p r e c i s e l y how ?ach of t h e p r e d i c a t e f u n c t i on? PRINCIPAL. CLAUSES 'mai n-menu' ' d o ( i n t e g e r ) ' •' q u e r y _ t h e _ u s e r ' ' g e t _ d a t a b a s e ( i n t e g c ' Q e t _d i mensi o n s ' ' f i n d _ u s e ' 'check u s e ' - d i s p 1 a y s t h e rn a i n __rn e n u o n s c r e e n and r e a d s t h e u s e r ' s s e 1 e c t i o n . ••- s t a r t s t o c a r r y o u t t h e u s e r ' s c h o i c e . - a s k s t h e u s e r t o s e l e c t t h e a p p r o p r i a t e z o n e . 1 r ) ' — 1 o a d s t h e r e q u i r e d d a t a b a s e f i 1 e i n t o t h e d a t a b a s e 'so n i n g i n f o ' « ~ a s k s t h e u s e r t o e n t e r i n l o t d i m e n s i o n s and s t o r e s r e s p o n s e s i n - a s k s t h e u s e r t o s e l e c t t h e use p r o p o s e d f r o m a l i s t o-f u s e s and s e l e c t e d i s v a l i d by c a l l i n g ' m ember<integer, useslist>'„ e 1 e c t. e d z o n e a n d u s e a g a i n s t a p p r o v e d o u t r i g h t a n d c o n d i t i o n a 1 t h e ' d i m e n s i o n s ' d a t a b t e s t s t o s e e i f t h e us c h e c k s t h e 2 o n e . I f t h e u s e i ; ' c h e c k _ r e s t __o f _ r e g < t h e v a r i o u s r e s u 1 1 s us a p p r o v e d i t g o e ' . Depend i ng on w h i c h c a n be rt: •s on t o c h e c k t h e r e g u l a t i o n s v i a ' c h e c k j - e g -t h e outcome o f t h e e v a l u a t i o n ' c h e c k _ u s e ' a l •turned t o t h e u s e r . f o r t h a t and »o d e f i n e ; SECONDARY CLAUSES ' member < :i. n t e g e r , use' ' e r r o r __m s g ( i n t e g e r ) ' c h e c k __a n s ( i n t e g e r ) ' t e s t ( z o n e ) ' NOTES .1 i s t ) c o m p a r e s t h e use s e l e c t e d a g a i n s t t h e ha r i d1es i n a 1im i t ed way i n p u t e r r o r s p r o v i d e s un i v e r s a l a n s w e r t e s t : i . ng and e n s u !"• e s t h a t o n 1 y c o n d i t i o n a 1 u s e s i n l i s t o f u s e s a11owed f o r t h e z o n e i n q u e s t i o n . by t h e user,, e r r o r c h e c k :i. ng. t h e RT--6 z o n e have t o meet e x t e r n a l d e s i g n r e q u i r e m e n t ? Commas The ' a-BODY i a r e t r e a t e d a s l o g i c a l AMD s t a t e m e n t s and S e m i - C o l o n * l o g i c a l OR s t a t e m e n t ? s y m b o l TRUE thv means > HEAD IF i s and t r u e sparats t h e HEAD of a r u l e f r o m i t s BODY „ The r u l e t a k e s t h e f o r m 'HEAD IF BODY' ••• i i f the The p e r i o d '••- i n d i c a t s ;nd of a r u l e o r f a c t . % % % % % % % % % % % % % % % % % % % % 7a % % % % % % % % % % The a l t s a r e The t h e t h e '••fai 1 ' i r n a t i ve s u i t . p r e d i c a t e 1 s o l u t i o n * f a !"• c e s b a c k t. r a c k i n g b y \« In most c a s e s w i t h i n a u t o m a t i c a l l y - f a i l i n g . The s y s t e EUCLID t h o u g h ' f a i l ' i s u s e d t o n\ t h e n goes d i r e c t t h e on t o s y s t e m l o o k f o r t o p r o d u c e '!' s y m b o l ( o r CUT) i s t h e a p p o s i t e e v a l u a t i on of a 11. e r n a t i v e s i n r a l e s c: u r r e n t r u 1 e f a i 1 „ of ' f a i l ' and p r e v e n t s b; w i t h OR s t a t e m e n t s o r t o c: k t r a c k i n g . T h e c u t i < p r e v e n t r u 1 e s w i t h t h ( e x t e n s i v e l y u s e d i n E U C L I D t o p r e v e n t s a m e H E A D f r o m b e i n g c a 11 e d s h o u 1 d I f t h e head o f any o t h e r r u l e a p p e a r ; i s t r u e b e f o r e g o i n g on t o c h e c k t h e ; i n t h e body of the r e m a i n d i n g element? c u r r e n t r u l s i n t h e body •, T u r b o P r o 1 o g c a 11 • of t h e c u r r e n t r u l e t h a t r u l : ind c h e c k s t o of i t s body Where an u n d e r s c o r e - '__' - t a k e s t h e p l a c e of an argument ( e . g . ' chec: k__use (_,_) ' o r ' c h e c k _ _ o u t r i g h t (__, 12) ' ) i t i s l i k e a wi 1 dc a r d . The u.nder s c o r e wi 11 a u t omat. i c a 3.1 y mat ch t.h e v a 1 ue of t he c a r r esp on d i ng a r gu.men t i n t he c a l l i n g c l a u s e , , Thus ' c h e c k _ o u t r i ght__app (_, 12) BODY' i s t h e same a s s a y i n g ' i f t h e u s e p r o p o s e d i s 12 c h e c k t h e BODY of t h e c l a u s e , r e g a r d l e s s of what t h e z o n i n g d i s t r i c t i s ' . From t h i s i t s h o u l d be c l e a r t h a t t h e '_' symbo1 h e 1 p s i n c r e a t i ng r u 1 e s whi ch c a n be u s e d i n more t h a n one s i t u a t i on„ Argument! t h e u s e r a t l a t e r -c a n t a k e . t h a t a r e v a r i a b l e s a r e i n d i c a t e d by a s u p p l i e s when a s k e d by ' g e t _ d i m e n s i o n s s t a g e s of t h e p r o g r a m i t i s t r e a t e d a s o n t h e v a 1 u. e o f b o u n d v a r i a b I e s o r o f < a v a r i ab1e whi c h i S u b s e q u e n 11 y , w h e n S i m i 1 a r 1 y u n b o u n d (o r bound t o t h e v a l u e v e r L o t. A r e a a p p e a r • •; v a r i a b 1 e s f r i •) C a p t i a l f i r s t l e t t e r , t h u s ' L o t A r e a ' i c l a u s e t o p r o v i d e t h e a r e a of t h e l o t . h a v i n g t h a t v a l u e s u p p l i e d by t h e u s e r i t a t i c o b j e c t s ( a r g u m e n t s t h a t a r e numbers o r s t a r t w i t h a l o w e r c a s e l e t t e r ) . Mote t h a t t h e r e a r e few t r u e o b j e c t s o r f a c t s i n t h e EUCLID s y s t e m s i n c e most of t h e i n f o r m a t i o n i s h a n d l e d by v a r i a b l e s and supp 1 i ed by t h e user• i nt.er ac t i ve 1 y o r r e a d i I Tto t h e dynami c d a t a b a s e s f r am d a t a b a s e f i 1 e s „ The two 'get _ r e 1 ax a t i o n s ' r u l e s a r i n e s s e n c e f a c t s and e a c h has two o b j e c t a r g u m e n t s c o r r e s p o n d i n g t o an i d e n t i t y number i d e n t i t y and u s e s p e c i f y i n g t h e p a r t. i c u 1 a r r e 1 a ;•; a t i o n „ E-i 1 a. n k s p a c e s i n In a d d i t i o n , wh m a t c h e s t h e c: 1 a u s e t r y i n g t o f i n d a m T u r b o P r o l o g ?n t r y i n g t o a r e i g n o r e d by p r o v e ' a c l a u s f t h e c o m p i l e r t h u s a l l o w i n g t h e c o d e t o be a r r a n g e d f o r ? T u r b o P r o I o g w o r • k s f r o m t a p t o b o 11 a m l o o k i n g for- t h e l e g i b i 1 i t y . head o f a r u l e t h a t Where t h e r e i s mart i t c h . I f t h e head of t h a n one c l a u s e w i t h t h e a r u l e m a t c h e s t h e c l a u s e s a m e h e a d , T u r b o P r o 1 o g w o r k s f r o m Tur b o P r o 3. og t r i e s t o s a t i s f y t h e t o p t o b o t t o m b o d y o f t h a t r u 1< sui; rnai n menu s -- i h i f t w i n d o w (5) , c 1 e a r w i n d o w , n 1 ( " VtCHECK THE ZONING ON A PROPERTY Vt ( l ) " ) , n l , n ; w r i t w r i t e ( " \ t F I N D A ZONE FOR A PROJECTXt ( 2 ) " ) , n l , n l , w r i t e ( " \ t M O D I F Y OR ADD TO THE DATABASE\t ( 3 ) " ) , n l , n l wr i t e ( " \ t A C C E S S THE OPERATINO SYSTEM\t ( 4 ) " ) , n1 , n1 , wr i t e ( "\tEND THIS S E S S I O N \ t \ t ( 5 ) " ) , n l wr i t e ( " \tENTER YOUR C H O I C E : \ t \ t " ) , r e a d i nt. ( C h o i ce) , "5 , n l , d o ( C h o i ce) q u e r y__t h e _ u s e r „ f i n d _ 2 o n e . m o d i f y _d a t a b a s e a c c e s s e s „ makewi ndow(11,7 do (1) do (2) do (3) do (4) do (5) d o (_) 5 •-- s h i f t w i n d o w (7) , c: 1 e a r w :i. n d o w , e r r o r _m s g (3) O " " , 0 ,0,25, 80) , c 3. e a r w i n dow , q u i t , i d i n t ( C h o i c e ) d o ( C h o i ce) qu.ery_.the_user s - s h i f t w i ndaw ! 2) , c3. e a r w i ndow , s h i f t w i ndow (8) , c:3. e a r w i ridow ,, n 1 , wr :i. t e ( " P l e a s e s e 1 e c t t h e Zon:i. ng 8 c h e d u l e w h : i . ch app 1 :i. e s t o t h e proper• t y \ n i n q u e s t i on : " ) , cu.rsor (R , C) , n 1 , n 1 , w r i t e (" (1) RT--2\t(2) R T - 4 \ t (3) RT--4N\t (4) RT - 5\n\n (5) R T - 5 N \ t (6) RT-6\n " ) , c u r s o r (R , C) , r e t r a c t a l l (_, 2 on i ng i n f o ) , r e a d i n t ( X > , get__datai:iase ( X ) , s h i f t w i ndow(2) , n 1 , g e t _ d i inensi ons , f i n d _ u s e . f i n d _ _ z o n e makewi ndow ( 1 2 , 7 , 15, "FINDING A ZONE FOR A PROJECT " , 0, 0 , 25 , 80 , 1 ,-1 , "\201 \ 187\200\ 188\205\ 186 ") , c 1 e a r w i n dow , n 3. , n 3. , w r i t e ( " The c u r r e n t v e r s i o n o f EUCLID does n o t s u p p o r t t h i s f a c i l i t y . I f you h a v e \ n " ) , w r i t e ! " a d e v e 1 o p m e n t p r o j e c: t. i n m i n d a n d w a n t t o f i n d w h i c h z o n e s s u p p o r t i t y o u. \ n " ) , ' w r i t e (" must s e l e c t c h o i c e 1 f r o m t h e MAIN MENU and t r y e a c h o f t h e z o n e s l i s t e d i n \ n " ) , w r i t e ! " t u r n t o s e e how t h e y f i t t h e p r o p o s e d project."),end„ m o d i f y _ d a t a b a s e s- makewindow(6,7,15,"MODIFY/ UPDATE THE DATABASES",0,0,25,80,1,-1,"\201\187\200\188\205\186"), c 1 earw:i. ndow , n 1 ,, n 1 , w r i t e ! " The c u r r e n t v e r s i o n o f EUCLID does n o t s u p p o r t t h i s f a c i l i t y . I f you w i s h \ n " ) , w r i t e ( " t o s e e t h e c o n t e n t s o f t h e d a t a b a s e a n d / o r e d i t / u p d a t e them y o u must s e l e c t X n " ) , w r i t e ! " c h o i c e 4 f r o m t h e MAIN MENU w h i c h w i l l a c c e s s t h e o p e r a t i n g s y s t e m !D0S).\n " ) , w r i t e ( " You may t h e n u. s e s t a n d a r d DOS c o m m a n d s and t h e b u l i t - i n ed i t o r EDLI N\n " ) , w r i t e ! " ( o r a n o t h e r s u i t a b l e e d i t o r ) t o m o d i f y t h e f i l e s . \ n \ n " > , w r i t e ! " NOTE; WHILE THE DATABASE F I L E S ARE BACKED UP, CHANGING THEM MAY PRODUCE\N"5, WRITE!" FATAL. ERRORS AND PREVENT THE SYSTEM FROM WORK ING. " ) , end. a c : c e s s _ o s s- s y s t e m ! " " ) , main__menu. q u i t 5 - ex i t . end !, s h i f t w i ndow ! ? ) , c l e a r w i ndow , n l , w r i t e ! " P r e s s t h e SPACE b a r " ) , r e a d c h a r (Y) , c:hec k _ a n s 3 ! Y) , sh i f tw:i. ndow ! 1) , c 1 e a r w i ndow , sh i f t w i n dow ! 3) , ma i n __men u. g e t _ _ d a t a b a s e ! 1) g e t _ d a t a b a s e ( 2 ) g e t _ _ d a t a b a s e !3) get__d a t a b a s e !4) g e t _ d a t a b a s e ! 5 ) g e t _ d a t a b a s e ( 6 ) get_database<__) c o n s u l t ! "RT2.dba" c o n s u l t ! "RT4.dba" c o n s u l t ! " R T 4 N . d b a c o n s u l t ! " R T 5 . d b a " c o n s u l t ! "RT5N., dba c o n s u l t ! "RT6„dba" , z o n i n g i nf a). , zon i ng i nf o) „ " , z o n i n g i n f o ) . , z o n i n g i nfo)„ " , z o n i n g i nf o) . , z on i ng i n f o ) . - e r • r o r _m s g ! 3) , r e a d i n t ! X ) , g e t __d a t a b a s e ! X ) e i"- r o r _m s g ! 1 ) :: - s h i f t w i n d o w ! 7) ,c:learw i n d o w, n 1 , w r i t e ! " Y o u r C h o i c e i s n o t v a I i d , \ n " ) w r i t e ! " p l e a s e p r e s s t h e SPACE b a r s V t " ) , r e a d c h a r ( X ) , check__ans3 ! X ) , I , s h i f t w i ndow !2) , wr i t e ! " '? " ) . e r r o r j n s g ( 2 ) s- s h i f t w i n d o w ! 7 ) , c 1 e a r w i n d o w , n I , n l , w r i t e ! " Your i n p u t i s n o t v a l i d , \ n " ) , w r i t e ! " p l e a s e p r e s s t h e SPACE b a r s \ t " ) , r e a d c h a r ! X ) , c h e c k _ a n s 3 ( X) , ! , s h i f t w i n d o w ! 2) , c 1 e a r w i n d o w , n 3. , g e t _d i m e n s i o n s. e r r o r __m s g < 3) s s h i -f: t. w i n d o w (7) , c: 1 e a r • w i n d o w , n 1 , w r i t s ! " You r C h o i c: e i s n o t v a 1 :i. d , p l e a s e t r y a g a i n ;; \ t " ) . c h e c k _ a n s i Cy') s - !„ c h e c : k _ a n s l ( 'n ' ) s -- ! , f a i 1 „ c h e c k _ a n s l { _ ) s- e r r o r _msg C1 ) , r e a d c h a r (Y) , w r i t.e (Y) , n l , n l , c:hec::k__ansl (Y) , ! » check., an s 2 ( ' n •' ) : I . c h e c k _ a n s 2 ( ' y ' ) :- ! , f a x 1. c h e c k _ a n s 2 (_) s- e r r o r _ m s g ( 1 ) , r e a d c h a r (Y) , w r i t e (Y) , n l , n l ,, c h e c k__ans2 (Y) , ! . c h e c k _ a n s 3 ( ' ' ) ,i - !,. c h e c k__ans3 ('_' > : - e r r o r __msg (1) ., r e a d c h a r !V) , w r i t e (Y) , n l , n l , c h e c k _ a n s 3 < Y) , ! . g e t i mensi o n s s •-- w r i t e ! " Please en t e r t h e f o 11 o w i n g i nf o r mat i on a b o u t t h e p r o p e r t y i n q u e s t i o n s "5 , n 1 , w r i t e ! " E n t e r F r o n t L o t W i d t h i n f t s \ t \ t " ) , r e a d r e a l ( F r o n t ) , w r i t e ! " E n t e r L e f t L o t L e n g t h i n f t s \ t \ t " ) , r e a d r e a l ! L e f t ) , wr i t e ( " E n t e r R e a r L o t Wi d t h i n f t \ t \ t " ) , r e a d r e a l ! Rear-) , w r i t e ! " E n t e r R i g h t L o t L e n g t h i n f t s \ t \ t " ) , r e a d r e a l ( R i g h t ) ,, e h e c k __s i t e __s h a p e (F r o n t , L e f t , R e a r , R i g h t , L o t a r• e a) , w r i t e ( " En t e r A r e a o f G r o u n d F1 o o r i n s q f t:; \ t " ) , r e a d r e a I (F1 r A r e a 1 ) , wr- i t e ( " En t e r T o t a 1 F1 o o r sp ac e i n s q f t : \ t " ) , r e a d r e a l (F1 r sp 1 ) , t e s t . _ f 1 o o r a r e a (F1 r A r e a 1 , F1 r s p 1 , F 1 o o r A r e a , F1 o o r s p a c e ) , w r i t e ! " E n t e r D e p t h of F r o n t Y a r d i n f t : \ t " ) , r e a d r e a l . ( F r o n t d e p t h ) , w r i t e ! " E n t e r D e p t h of Rear Y a r d i n f t s \ t " ) , r e a d r e a l ( R e a r d e p t h ) , ! , r e t r a c t a l l (_,d i m e n s i ons) , a s s e r t a ( d i m e n s i o n s ( F r o n t , L e f t , R e a r , R i g h t , L o t A r e a , F l o o r A r e a , F l o o r s p a c e , F r o n t d e p t h , R e a r d e p t h ) , d i m e n s i o n s ) ; e r r o r _ m s g ( 2 ) . c h e c k_s i t e _ s h a p e ( F r o n t , L e f t , R e a r , R i g h t , L o t a r e a) s - F r o n t = R e a r , !..  e f t = R i g h t , ! , L o t a r e a = ( ( F r o n t + R e a r ) /2) * ( ( L e f t + R i g h t ) /2) , n l , w r i t e ! " Th e T o t a l A r e a of t h e L o t i s s \ t \ t " , L o t a r ea) , n 1 , n1. c h e c k _ s i t e _ s h a p e ( _ , _ , _ , _ , L o t a r e a ) s - n l , w r i t e ( " THE S I T E IS MOT RECTANGULAR IN SHAPE„\n\n"), w r i t s ! " P l e a s e E n t e r T o t a l L o t A r e a i n s q f t u X t " ) , r e a d r e a l ( L o t a r e a ) , n l . t e s t _ f 1 o o r a r e a ( F l r A r e a 1 , F l r s p 1 , X , Y) s • - F l r s p l >= F l r A r e a 1 , ! , X = F l r A r e a l , Y » F l r s p l s n I , w r i t e ! " I t i s unus u a 3. f a r T a t a 3. F1 o o r s p a c e t o be 1 e s s t h a n t h e a r e a o f \ n " ) , w r i t s ! " t h e g r o u n d fIoor„ Have y o u a n t e r e d e a c h f i g u r e c o r r e c 1 1 y ? (y/n) " ) , r e a d c h a r ! Z ) , w r i t s ! Z ) , n l , n l , c : h e c k _ a n s i ! Z ) , ! , X - F l r A r e a ! , Y = F l r s p 15 w r i t e ! " P l e a s e R e - E n t e r Ground F l o o r A r e a i n s q f t s X t " ) , r e a d r e a l (X) , w r i t e ! " P l e a s e R e - E n t e r T o t a l F l o o r s p a c e i n s q f t s V t " ) , readreal(Y),nl» f i n d __u s e ; -•- c l e a r w i n d o w , n I , wr i t e ! " What k i nd of use i s p r o p o s e d ? \ n \n (1) Ac:cessory B l dg / Use (2) Community C e n t r e X t (3) N e i g h b o u r h o o d House\n " ) , w r i t e ! " (4) P a r k V t V t (5) P1 ay g r oun d \ t \ t (6) M a t e r i a l D e p o s i t i o n \ n (7) M a t e r i a l E x t r a c t i o n (8) I n f i 1 1 X t " ) , w r i t e ! " (9) Mu 11 i p 3. e Conv. Dwl ng\n (10) Mu 11 i p 1 e Dwe 1 1 i ng ( 1 1 ) One-Fami 3. y Dw 1 ng (12) Two--Fami 3. y Dw 1 ng\n " ) , w r i t e ( " ( 1 3 ) Day C a r e F a c i l i t y ( 1 4 ) C h u r c h Y t \ t (15) P u b l i c A u t h o r i t y U s e \ n ( 1 6 ) E l e m e n t a r y S c h o o l (175 S e c o n d a r y S c h o o l w r i t e ! " (18) S o c i a l S e r v i c e C e n t r e X n (19) S p e c i a l Needs Res,, (20) Nbrhd G r o c e r y S t o r e (21) Bed B r e a k f a s t Ac com,, ") , w r i t e ! " \ n ( 2 2 ) P u b l i c U t i 1 i t y V t (23) C l u b x t V t (24) A m b u l a n c e S t a t i o n \ n ( 2 5 ) H o s p i t a l \ t \ t ( 2 6 ) P a r k i n g A r e a X t (27) O t h e r " ) , c u r s o r ( 1 , 3 2 ) , r e t r a c t a l l (__, s t o r a g e ) , r e a d i n t ( X ) , ' a s s e r t a ( p r o p o s e d j j s e ( X ) , s t o r a g e ) , p e r m i 11 e d __u s e s (U s e) , m e m b e r • ( X , U s e) , z o ne__c1 a s s ( Z one) , check__u.se ( Zone , X) , ! . •f i nd__u.se s s h i -f t w i ndow ( 1) , c 1 e a r w i ndow , n 1 , zone_c 1 a s s ( Zone! , w r i t e ( " The u s e p r o p o s e d i s n o t e x p r e s s l y p e r m i t t e d , e i t h e r o u t r i g h t o r \ n " ) , w r i t e < " c o n d i t i o n a 11 y ., u n d e r t h e " , Z o n e , '' s c: h e d u 1 e b u t m a y s t i l l b e a 11 o w e d \ n b y t. h e D i r e c t o r o f P1 a n n i n g . \ n \ n " ) , w r i t e ( " Do y o u want t o c h e c k t h e r e g u l a t i o n s t o s e e i f t h e \ n u s e may c o m p l y ? ( y / n ) \ t " ) , r ead c h a r ( X ) ., wr• i t e ( X ) , n 1 , n I , c h ec k _an s 2 ( X ) , wr• i t e ( " T h i s en ds t he c u.r r en t s e s s i on ,. \ n \ n " ) , ! , en d 5 c 1 e a r w i n cl o w , p r o p o s e d __u s e (U s e) , s h i f t w i n d o w (2) , c 1 e a r w :i. n d o w , n 1 , z o n e; __c I a s s ( Z o n e) , w r i t e ! " CHECKING REGULATIONS FOR P R I N C I P A L BUILDINGS & S I T E ; „ . . • \n") , w r i t e ( " - - ~ -— - - - -• - - - • - - - \ n " ) , n 1 , c h e c k ... r eg s (Zone, U s e ) , c h e c k _ _ r e s t _ p f __regs ( Zone) , s h i f t w i ndow (1) , c l e a r w i ndow , n 1 , wr i t e ( " On t h e h a s i s o f t h e r egu1 a t i o n s a l o n e , t h e u s e p r o p o s e d \ n " ) , wr i t e ( " may b e per- m i s s i b 1 e i n t h e " , Zone, " D:i. s t r i c t., \ n \ n " ) , w r i t e ! " P l e a s e c h e c k w i t h t h e P l a n n i n g D e p a r t m e n t f o r c o n f i r m a t i o n , " ! , ! ,end; s h i f t w i nclcw (1 ) , n 1 , z one_c 1 a s s ! Zone) , w r i t e ! " The u s e p r o p o s e d i s n o t p e r m i t t e d , e i t h e r o u t r i g h t o r \ n " ) , w r i t e ! " c o n d i t i o n a l l y , u n d e r t h e ",Zone," s c h e d u l e b u t may s t i l l be\n a l l o w e d by t h e D i r e c t o r o f PI arm i n g - \ n " ) ,n1 , w r i t e ! " T h i s e n d s t h e c u r r e n t s e s s i on.\n") , e n d . member ( X , C X ! __'J ) « member ! X ,. II ! T a i 11) s member ! X , T a i 1 ) . c h e c k j i s e ( Z o n e , X) c 1 e a r w i ndow , n 1 , w r i t e ! " CHECKING PROPOSED USE s „„.., \ n " ) , w r i t e ! " ••- - \ n " ) , n 1 , c h e c k __o u t r i g h t __a p p ! Z o ne, X ) , c l e a r w i n d o w , n 1 , wr i t e ( " CHECK I NG REGULAT IONS FOR PR INCI PAL B U I L..D INGS Z< S I T E ; . „ . „ \ n " ) , w r i t e ! " - - • •• - ~-\n " > , n l , c h e c k _ . r e g s ( Zone , X ) , c h e c k _ r e s t _ _ o f _ r e g s ( Zone) , ! , s h i f t w i ndow ! 1 ) , c l e a r w i ndow , n l , w r i t e ! " The 11 s e p r o p o s e d i s p e r m i 11 e d o u t r i g h t b u t m u s t s t i l l b e \ n " ) , w r i t e ! " p r e s e n t e d t o The D i r e c t i o n o f P l a n n i n g f o r c o n f i r m a t i o n . " ) , n l , n l , w r i t e ! " T h i s e n d s t h e c u r r e n t s e s s i o n . " ) , e n d ; s h i f t w i n d ow ! 1) , n 1 , z o n e _ c 1 a s s ! Zone) , w r i t e ! " The u s e p r o p o s e d i s n o t p e r m i t t e d o u t r i g h t u n d e r t h e \ n " ) , wr i t e ! Z on e , " Sc h ecl u 1 e b u t may be a l l owecl c ond i t i a n a 11 y „ \ n \ n " ) , wr- i t e ! " Do y o u w i s h t o c hec k f or- c o n d i t i on a 1 ap p r o v a l ? ! y / n ) \ t " ) , r e a d c h a r ! Y ) , w r i t e ! Y) , n I , n 1 , c 1 e a r w i n d o w , c h e c k a n 3 2 ! Y) , ! , n 1 , w r i t e ! " T h i s e n d s t h e c u r r e n t s e s s i o n . " ) , e n d . c h e c k_ u s e ( Zone , X ) s - s h i f t w i ndow ! 2) , c 1 e a r w i ndow , n 1 , wr i t s ! " CHECK I NG PROPOSED USE s \n " > , wr i t e ! " - - - \n " ) , n 1 , c h i e c k _ c o n d i t i o na 1 _app ! Zone, X ) , c 1 e a r w i n d o w , n 1 , w r i t e ! " CHECKING REGULATIONS FOR P R I N C I P A L BUILDINGS™"*--: S I T E s „ „ . . \ n " ) , w r i t e ! " -- - — - - - -• - \n") , n l , c h e c k__regs ! Zone , X ) , c h e c k _ r e s t _ o f _ r e g s ! Z o n e ) , t e s t ! Zone) , ! , s h i f t w i ndow ! 1) , n l , w r i t e ! " The u s e p r o p o s e d i s D e r m i c t e d c o n d i t i o n a l 1 v hut miwt =;ti U A n " ) .. w r i t e ! " be p r e s e n t e d t o The D i r e c t i o n of P l a n n i n g -for con-f i rmat i on . " ) , n l , n l , w r i t e ! " T h i s e n d s t h e c u r r e n t s e s s i o n . " ! , e n d . c h i e c k _ u s e (_,_> s ~ s h i f t w i ndow (1 ) , n 1 , z o n e _ c l a s s ! Z o n e ) , wr i t e ! " The use p r o p o s e d i s n o t perrni 11ed , e i t h e r o u t r i g h t o r \n " ) , w r i t e ( " c o n d i t i o n a l l y , u n <: J e r t h e " , Z o ne," s c h e d u 1 e b u t IT j a y s t i 11 b e \ n a 1 1 o w e d b y t he D i r e c t o r o-f P1 a n n i n g . \ n " ) , n 1 , w r i t e ! " Th i s en d s t he c u r r en t s e s s i on . \ n " ) , en d . t e s t ! " RT-6 " ) s -- ! , c h e c k_ex t e r n a l __desi gn 1., t e s t !__) s - t r u e . / « # -x- -x- * # # » - X - -x- -x- # ¥.- # » # * # -x- # -x- -x- # # # -X- * # * / /* INITIAL. GOAL STATEMENT s */ / -X- # ft * # # -X- # # # # # # * # * « • » # * -X- * # # -X- -X- -X- # -K- / % % The GOAL, s e c t i o n d e s c r i b e s t h e p r e d i c a t e s w h i c h a r e a u t o m a t i c a l l y s t a r - t e d when t h e command EUCLID i s g i v e n a t % t h e DOS p r o m p t , o n c e t h e EUCLID p r o g r a m h a s been r e a d i n t o t h e w o r k s p a c e . The p r o g r a m s t a r t s w i t h t h e g o a l % l i s t e d b e l o w and i m m e d i a t e l y makes a l l t h e windows w h i c h w i l l be u s e d w h i l e t h e p r o g r a m i s r u n n i n g . % % 'main__menu' s t a r t s t h e p r o g r a m by c a l l i n g t h e 'main_menu' p r e d i c a t e l i s t e d a b o v e . % g o a l m a k e w i n d o w ! 9 , 1 5 , 4 , " " , 2 1 , 2 6 , 3 , 2 5 ) , makewindow(5,7,7,"MAIN M E N U " , 5 , 1 4 , 1 6 , 5 0 , 0 , - 1 , " \ 2 0 1 \ 1 8 7 \ 2 0 0 \ 1 8 8 \ 2 0 5 \ 1 8 6 " ) , n l , makewindow ! 1 ,7, 15, "RESPONSE TO ZONING QUERY" ,2,5,20,70, 1 ,--:!. , "\201 \ 187X200X 188\205\ 186" ) , makewindow!3,7,48," EUCLID !1.0) s A ZONING ASSISTANT ",0,0,25,80,1,-1,"\201\187\200\188X205\186") , n l , n1 , n1 , w r i t e ! " PREFACE TO THE SYSTEMXn") , n l , w r i t e ! " T h i s s y s t e m h a s been d e v e l o p e d as p a r t of t h e a u t h o r ' s M.A. T h e s i s X n " ) , w r i t e ! " r e s e a r c h i n g t h e t e c h n i c a l f e a s i b i l i t y o f b u i l d i n g E x p e r t S y s t e m s X n " ) , w r i t e ! " an d t h e i r p o t e n t i a1 u t i 1 i t y f o r han d 1 i n g Ur b an P l a n n i n g t a s ks„X n X n") , wr i t e ! " The s y s t e m was deve.1 oped a t t h e Sc:hoo 1 of Commun i t y ancJ Reg i ona 1 \ n " ) , w r i t e ! " P l a n n i n g , a t t h e U n i v e r s i t y o f B r i t i s h C o l u m b i a , d u r i n g t h e s p r i n g \ n " ) , w i-- i t. e ! " a n d s u m rn e r o f 1990, i n p a r t. i a 1 f u 1 f i l m e n t. o f t h e r e q u i r e m e n t s o f X n " ) , w r i t e ! " PLANNING 549 and t o w a r d s t h e Degree of M a s t e r of A r t s ( P l a n n i n g ) . X n " ) , n l , w r i t e ! " J u l i a n A t k i n s , X n J u l y , 1 9 9 0 X n X n " ) , s h i f t w i n d o w ( 9 ) , n l , w r i t e ! " P r e s s t h e SPACE b a r " ) , r e ad c h a r ( Y ) , c heck _an s 3 ( Y ) ,e1e a r window, sh i f t w i n d ow(3) , c 1 e a r • w i n dow, makewi ndow ( 2 , 7, 15,''CHECKING A ZONING BY-LAW ", 0 , 0 ,25 , 80 , 1 ,--1 ," X201 X 187X200 X 188X205 X 186 " ) , n l , makewindow(8,7,15,"SELECT A ZONE",2,5,20,70,1,-i,"X201X187X200X18SX205X186"),makewindow(7,7,15,"ERROR MESSAGE",15,12,5,54), s h i f t w i n d o w ( 3 ) , m a k e w i n d o w ( 4 , 7 , 1 5 , " " , 1 , 3 , 4 , 7 4 ) , w r i t e C " W E L C 0 M E T 0 E LI C L. ID s X n P1 e a. s e s e 1 e c t w h a t yp u w a n t t a d o b y e n t e r i n g t h e a p p r o p r- i a t e n u m b e r s makewi ndow(10,7,15,"",21,14,3,50) , w r i t e ! " . C o p y r i g h t (c) 1990 by J u l i a n F., A t k i n s , , " ) , main menu. /* OUTRIGHT.PRO #/ % % OUTRIGHT.PRO c o n t a i n s t h e r u l e s w h i c h a r e u s e d t o c h e c k w h e t h e r o r n o t t h e u s e p r o p o s e d c a n be a p p r o v e d % o u t r i g h t . The ' c h e c k _ o u t r i g h t _ a p p ' c l a u s e s a r e c a l l e d f r o m t h e ' c h e c k.__use' c l a u s e i n E U C L I D . PRO. % T h e r u l e ' c h e c k _o u t r i g h t _ a p p (_, __) s -•• c: o v e r s u s e s w h i c h a r e n o t a l l o w e d o u t r i g h t a n d f a i 1 s t h u s f o r c i n g % ' check__use' t o t r y and f i n d an a l t e r n a t i v e s o l u t i o n i n t h i s c a s e 'check_u.se' g o e s t o c h e c k f o r % c o n d i t i o n a l a p p r o v a l . % % ' c h e c k__acc__r o o f ' and ' c h e c k__ac::c__gf a' t e s t t o s e e w h e t h e r o r n o t an a c c e s s o r y u s e c o m p l y s w i t h t h e h e i g h t % a n d / o r g r o s s f l o o r a r e a ! g f a ) r e q u i r e m e n t s a s s p e c i f i e d i n t h e z o n i n g b y - l a w s . < t h e s e r e q u i r e m e n t s ; a r e % same f o r a l l 6 z o n e s . % % N o t e t h a t t h e q u e r y t h e u s e r f a c i l i t y i s b u i l t i n t o e a c h r u l e t h u s e n s u r i n g t h a t no s u p e r f l u o u s q u e s t i o n s % a r e a s k e d . % p r o j e c t "EUCLID" i n c 1 u. d e '' c s \ \ p r o g r a m s \ \ t p r o 1 o g \ \ g 1 o b a 1 s . p r o " p r e d i c a t e s c h e c k _ a c c : _ r o o f ( a c c _ _ r o o f ) check__acc__gf a ( r e a l ) c l a u s e s c h e c k _ o u t r i g h t _ a p p ( "RT--5N" , X) check_outright_app("RT-5",X)„ c h e c k . _ o u t r i g h t _ a p p ( "RT-4N" , X) i- c h e c k _ _ o u t r i g h t _ a p p ( "RT-4" , X) „ c h e c k _o u t r i g h t _ a p p !.__, 1) ••• w r i t e (" What t y p e of r o o f d o e s / w i 11 t h e ACCESSORY b u i l d i n g h a v e ? \ n " ) , w r i t e ( " C hoose one of t h e f o l l o w i n g : (1) F l a t , (2) M a n s a r d , (3) G a b l e X n " ) , w r i t e ! " ( N o t e t h a t G a b l e i n c l u d e s H i p and Cambrel t y p e r o o f s ) . " ) , c u r s o r ( 4 , 5 8 ) , r e a d i n t ( R o o f 5 , c u r s o r ( 8 , 0 ) , a c c e s s o r y __b u i I d i n g s (__, M a H t , S e t b a c k ,.._, _, R a t i o) , w r i t e ! " I s any p a r t o f t h e r o o f h i g h e r t h a n ",Ma>;Ht," f t ? (y/n) Vt.") , r e a d c h a r (X) , w r i t e ( X ) , n l , n 1 , c h e c k _ a n s 2 ( X ) , c h e c k _ a c c _ r o o f (R o o f ) , w r i t e ! " I s t h e a c c e s s o r y b u i l d i n g l o c a t e d i n t h e r e a r y a r d ? ( y / n ) V t " ) , r e a d c h a r (Y) , w r i t e (Y) , n l , n l , c h e c k _ _ a n s l (Y) , w r i t e ! " What i s t h e s e t back o f t h e a c c e s s o r y b u i l d i n g i n f t ? \ t " ) , r e a d r e a l (Z) ,n 1 , Z >= S e t b a c k , wr i t e ( " What i s t h e g r o s s f 1 o o r a r e a of t h e ac c e s s o r y b u i 1 d i n g i n s q f t ? " ) , reacl r ea 1 (GFA) , n 1 , ch e c k _ a c c _g f a(GFA) , w r i t e ! " How w i d e i s t h e a c c e s s a r y b u i l d i n g i n f t ? \ t " ) , r e a d r e a l ( W i d t h ) , n l , d i m e nsi oris (__, _, Rear , __, _, __, _) , W i d t h / R e a r <=•• Ratio,™",," c h e c k __o u. t r i g h t. _ a p p (_, 1) a — s h i f t wi ndow!1) ,c1 e a r w i ndaw,n1,f a i 1 . c h e c : k . _ _ Q U t r i ght__app ( " R T - 6 " ,9) s - w r i t e < " Does t h e c o n v e r s i o n i n c l u d e any a d d i t i o n s ? < y / n ) \ t " ) , r e a d c h a r ( X ) , a s s e r t z ( a n s _ t r a c k ( X , ' _ ' > , s t o r a g e ) , w r i t e ( X ) , n l , n l , c h e c k _ a n s 2 ( X ) , wr i t. e ( " W i l l a n y h o u s e k e e p i n g or- s 1 eep i n g u n i t s b e c r e a t e d ? (y / n ) \ t " ) , r e a d c h a r (Y ) ,, ; r t z (a n s _ t r a c k ( X , Y) , s t o r a g e ) , w r i t e (Y) , n 1 ,, n 1 , c h e c k _ a n s 2 ( Y ) , ! . c h e c k _ o u t r i g h t _ a p p ( " R T ••• 6'' , 9 ) s - ! , s h i f t w i n d o w ( 1 ) , c l e a r w i n d o w , n 1 , f a i 1 . check..._outr ight...app < "RT 6",11) : I , f a i l . c h e c k _p u t r i g h t __a p p (_, 11 ) s - I , t r u e. c h e c k j i i u t r i ght__app ( "RT-6" , 12) :; ! , f a i 1 . c hec k __o u t r i g h t _ a p p (_ ,12) s - ! , t r u e. c h e c k _o u t r i g h t _ a p p (_, _) : - s h :i. f t w i n d o w (1) , c 1 e a r w i n d o w , n 1 , f a i 1 . c h e c k__acc_r oof ( 1 ) - ! , w r i t e (" How h i g h i s t h e r o o f of t h e a c c e s s o r y b u i l d i n g a t i t s \ n " ) , w r i t e ( " h i g h e s t p o i n t i n f e e t ? \ t " ) , r e a d r e a l (X) ,n1, a c c e s s o r y _ b u i 1 d i ngs (Hei g h t , __, __, __, __, __) , X < = H e i g h t . c h e c k _ a c c _ r o o ' f ( 2 ! s - ! , w r i t e <" How h i g h i s t h e r o o f of t h e a c c e s s o r y b u i l d i n g a t i t s deck l i n e ? \ t . " ) , r e a d r e a l ( X ) , n l , a c c e s s o r y _ b u i 1 d i n g s ( H e i g h t _ , _ , _ ) , X <= H e i g h t . c:h e c k__ac c _ r o o f ( 3 ) s -• ! , wr i t e ( " Wha.t i s t he mean he i gh t of t he accessor y b u.i I d i n g ' s r o o f , \n " w r i t e ( " f r o m e a v e s t o r i d g e ? \ t " ) , r e a d r e a 1 ( X ) , n 1 , a c c e s s o r y _ b u i 1 d i n g s (H e i g h t , _ , _ , _ , _ , _ ) , X < = H e i g h t . c h e c k _ a c c _g f a. (G F A) s - d i m e n s i o n s (_,__, R e a r W i d t h , _ , _ , _ , _ , _ , R e a r D e p t h ) , a c c e s s o r y _ b u i 1 d i n g s (__,__, __, P e r c e n t , S q f t , __) , GFA / ( R e a r Dep t h * Rear W i d t h ) < = P e r c e n t , ! ;; a c c e s; s o r y _ b u i I cl i n g s (_,__,__,_, S q f t , _) , GFA < = S q f t . i /* CQMD ITML.PRO * / % % C O N D I T N L . P R O c o n t a i n s t h e r u l e s f o r t e s t i n g t o s e e w h e t h e r of a not a u s e meets t h e r e q u i r e m e n t s f o r % c o n d i t i o n a 1 a p p r o v a 1 „ ' c h e c k _u s e ' c a l l s ' c h e c k _ c o n d i t i o n a 1 _a p p ' i f i t s c a l l t o ' c h e c k _ o u t r i g h t ' f a i 1 < % p r o j e c t "EUCLID" i n c 1 u d e " c : \ \ p r o g r a. m s \ \ t p r o 1 o g \ \ g 1 o b 1 s • p r o'' c 1 d i i ; c: hec: k _c on d i t i on a 1 _ap p ( "RT-5N" , X) s ! , c h e c k__condi t i o n a l _app ! "RT 5" , X) . c:hec:k.._condi t i o n a l _app ( "RT-4N" , X ) s ! , check_c:ond:i t i o n a l ......app ( "RT--4" , X ) „ c h e c k . _ c o n d i t i o n a I _ _ a p p ( "RT-2" ,8) s --• ! , f a i 1 , c h e c k _ _ c o n d i t i o n a l __app (_, 8) s - wr:i.te(" A r e t h e d w e l l i n g u n i t s p r o p o s e d i n c o n j u n c t i o n w i t h a\n n e i g h b o u r h o o d g r o c e r y s t o r e ? (y/n) \ t " ) r e a d c h a r ( Y ) , w r i t e ( Y ) , n l , n l , c h e c k _ a n s l ( Y ) , I , w r i t e ! " I-! o w many u n i t s a r e p r o p o s e d ? \ t " ) , r e a d i n t ( N ) ,n1, N < = 2, w r i t e ! " D o t h e y c: o n f o r m t a s e c t i o n 11 „ 16 o f t h e Z o n i n g B y - 3. a w'? !y / n ) \ t " ) , r e a d c h a r ( Z ) , w r i t e ( Z ) , n l , n l , c h e c k _ a n s i ! Z ) , c h e c k __c o n d i t i o n a 3. __a p p (_, 2 0) . c h ec k _c on d i t i on a 1 _ap p C " RT--6 " , 9) s ! , an s _ t r ac k (A1 , A2) , c h e c k _an s 1 (A1) , wr i t e ( " Ar e t. h e ad d i t i on s i n c: I u d ed i n t. h e p r op o s e d c on v e r s i o n i n k eep i n g w i t h t h e \ n " ) , wr i t e ( " c h a r a c t e r o f t h e e x i s t i ng b u i 1 d i ng? ( y / n ) \ t " ) , r e a d c h a r ( X ) , wr i t e ( X ) ,n1 , n 1 , c h e c k _ a n s l ( X ) , ! , A2 < > 'y', w r i t e ! " W i l l any h o u s e k e e p i n g o r s l e e p i n g u n i t s be c r e a t e d ? ! y / n ) \ t " > , readchar (Y) , w r i t e (Y) , n l , n l , c h e c: k _ a n s 2 ! Y) , c h e c k_cond i t i o n a l _app < "RT-6" , 8) „ check_j:::ond:i. t i o n a l _app ! "RT-5" , 9) : !, w r i t e ! " B e f o r e m aking a d e c i s i o n on a M u l t i p l e C o n v e r s i o n Use, t h e D e v e l opment\n " ) , w r i t e ! " P e r m i t B o a r d s h a l l c o n s i d e r t h e q u a l i t y and l i v a b i l i t y o f t h e r e s u l t i n g \ n " ) , w r i t e ! " u n i t s , t h e s u i t a b i I i t y o f t h e b u i 1 d i n g for- c o n v e r s i o n i n t e r • m s o f age a n d \ n " ) , w r i t e ! " s i z e , and t h e e f f e c t o f t h e c o n v e r s i o n on a d j a c e n t p r o p e r t i e s and t h e \ n " ) , w r i t e ! " c h a r a c t e r of t h e a r e a . \ n \ n " ! , w r i t e ! " D i d t h e b u i 1 d i n g b e i n g con v e r t e d e x i s t p r i cn r t o \ n D e c e m b e r 61 h , 1977? ! y / n ) \ t " ) , r e a d c h a r (X) , w r i t e ! X ) , n l , n l , c h e c k _ _ a n s l (X) , w r i t e ! " A r e any a d d i t. i ons p r o p o s e d i n keep i ng wi. t h t h e c h a r a c t e r of t h e \ n " ) , wr i t e ! " ex i s t i n g b u i 1 d i n g ? ! y / n ) \ t " ) , r e a d c: h a r (Y) , wr i t e ! Y) , n I , n 1 , c hec:: k _an s i !Y) , w r i t e ! " Wi 11 any h o u s e k e e p i ng o r s3. eep i ng un i t s be c r e a t e d ? ! y/n ) \ t " ) , r e a d c h a r ! Z ) , wr i t e ! Z ) , n 1 , n 1 ,check__ans2 ! Z ) , c h e c k _ _ c o n d i t i ona 1 __app !''RT5" ,8) . check__c::ondi t . i o n a l _ a p p ! "RT-4" ,9) s -- ! , check__condi t i o n a l _app ! "RT-5" ,9) . c h e c k __«::: on cl:i. t i o n a l _app ! "RT 2",9) s •- w r i t e t " Be-fore making a d e c i s i o n on a M u l t i p l e C o n v e r s i o n U se, t h e D e v e l opment\n " ) , wr i t e ( " P e r mi t B o a r d s h a 11 c o n s i tier t h e qua 1 i t y and 1 i vab i 1 i t y o f t he r e s u 11 i ng \n " ) , w r i t. e ( " u n i t. s , t h e s u. i t a. b i 1 i t y o f t h e b u i I d i n g f o r c o n v e r s i o n i n t e r m s o f a g e \ n " ) , 4} wr i t e ! " and s i z e , and t h e e f f e c t of t h e con v e r s i on on ad j -acent p r o p e r t. i e s and\n " ) , w r i t e ! " t h e c h a r a c t e r of t h e a r e a . \ n \ n " ) , w r i t e ! " D i d t h e b u i l d i n g b e i n g c o n v e r t e d e x i s t p r i o r t o J u n e 1 8 t h , 1956? ! y / n ) \ t " ) , # r e a d c h a r ( X ) , w r i t e ( X ) , n l , n l , c h e c k _ a n s 2 ( X ) , I ; wr i t. e ( " How man y cl we 11 i n g un :i. t s a r e p r op o s e d ? \ t " ) , r ead i n t. (Y) , n 1 , Y > 2 , w r i t e ! " B u i l d i n g a d d i t i o n s a r e n o t p e r m i t t e d . \ n \ n " ) , ! , # w r i t e ( " SEE MORE? (y/n) \ t " ) , r e a d c h a r (Z) , w r i t e (Z) , n 1 , n 1 , c h e c k _ _ a n s l ( Z ) ; ! , t r u e . check__concl i t i ona 1 _app ( " RT-5 " , 10) x - w r i t e ! " A r e t h e d w e l l i ng un i t s d e s i gned spec:i f i c a l l y f o r s e n i o r C i t i z e n s h o u s i ng\n " ) , & w r i t e ! " o r a s i m i l a r u s e ? ! y / n ) \ t " ) , r e a d c h a r !X) , w r i t e (X) , n 1 , n l , c h e c k . _ a n s l !X) , ! p. w r i t e ! " Do a t l e a s t 5 0 % of t h e d w e l l i n g u n i t s i n e a c h b u i l d i n g h ave two o r \ n " ) , ^1 w r i t e ! " m o r e b ed rooms? ! y / n ) \ t " ) , r e a d c h a r ( X ) , w r i t e ( X ) , n l , n l , c h e c k _ a n s l ! X ) , c h e c k _ c o n d i t i o n a l _ a p p ( " R T - 5 " , 8 ) , !; ! , f a i l . c h e c k _ c o n d i t i o n a l _ a p p ! " R T - 4 " , 1 0 5 !- I , f a i 1 . c h e c k __c o n d i t i o n a. 1 _ a p p ! __, 10) s - w r i t e ! " A r e t h e d w e 11 i n g u n i t s p r o p o s e ci. i n c o n j u n c t i o n w i t. h a \ n n e i g h b o u r h o o d g r o c e r y s t o r e ? ! y / n ) \ t 1 ' ^ r e a d c h a r !Z) , w r i t e !Z) , n l , n l , c h e c k _ _ a n s l (2) , ! , w r i t e ! " How many u n i t s a r e p r o p o s e d ? \ t " ) , r e a d i n t !M) , n 1 , N <= 2 , • w r i t e ! " Do t h e y c o n f orm t o s e c t i on 11 „ 16 of t h e Zon i n g B y I aw? ( y / n ) \ t " ) , r e a d c h a r !Y) ,, wr i t e C Y ) , n l , n 1 , c h e c k _ a n s 1 !Y> , c h e c k _ c o n d i t i o r i a l __app ( , 20) „ €1 c h e c k _c o n d i t i o n a I __a p p ( " R T - 6 " , 11) s - w r i t e ( " A r e t h e d w e 11 i n g u n i t s p r o p o s e cl i n c o n j u. n c t i o n w i t h a \ n " ) , w r- i t e ( " n e i g hi b o u r h o o d g r o c e r y s t o r e ? (y / n ) \ t " > , Q rea.dc.har (Y) , w r i t e (Y) , n l , n l , c h e c k _ a n s l (Y) , I , w r i t. e ! " H o w m any u n i t. s a r e p r o p o s e d ? \ t " ) , r e a d i n t !M) , n l , N < = 2, • w r i t e ! " Do t h e y c o n f o r m t o s e c t i o n 11.16 of t h e Z o n i n g B y - l a w ? ! y / n ) \ t " ) , i-eadchar (Z) , wr i t e ! Z ) , n 1 , n 1 , c h e c k _ a n s 1 ! Z ) , c h e c k _ c o n d i t i o n a l _app ! "RT-6" , 20) „ # c h e c k c o n d i t i o n a l app ! "RT-6" ,12) s ! , c h e c k j : o n d i t i o n a l app ! "RT-6" , 1 1 ) . # c h e c k _ c o n d i t i o n a l _app (_, 14) s- !, w r i t e ! " Does t h e p r o p o s e d C h u r c h c o m p l y w i t h s e c t i o n 11,. 7 o f t h e \ n Z o n i n g B y - l a w ? ( y / n ) \ t " ) , r e a d c h a r ! X) , w r i t e ! X) , n l , n l , e h e c k _ a n s l ! X ) . c h e c k _ c o n d i t : i . o n a l _ a p p !_, 15) s- !, w r i t e ! " I s t h e P u b l i c A u t h o r i t y Use p r o p o s e d e s s e n t i a l t o t h e D i s t r i c t ? ! y / n ) \ t " ) , r e a d c h a r ( X ) , w r i t e ( X ) , n l , n l , c h e c k _ a n s l ( X ) . c h e c k _ c o n d i t i ona 1 __app (__, 16) s - ! , wr i t e ( " Does t h e p r o p o s e d E1 e m e n t a r y Schoo 1 comp 1 y wi t h s e c t i o n 11. 8\n " ) ,, w r i t e ! " of t h e Z o n i n g B y - l a w ? ! y / n ) \ t " ) , ' r e a d c h a r ( X ) , w r i t e ! X ) ,n1,n1, c h e c k _ a n s 1 ! X ) „ W # chec:k__c:oncli t i a n a 1 __app (_, 17) i •-- ! , w r i t e ! " Does t h e p r o p o s e d S e c o n d a r y Sc:hoo 1 comp 1 y w i t h s a c t i o n 11 „ 8\n " ) , w r i t e ! " o-f t h e Z on i n g B y - l a w ? ! y / n ) \ t " ) , readc:har ! X ) ,, wr i t e ! X ) , n 1 , n 1 , c h e c k _ a n s 1 ! X ) . W check__coric:li t i o n a l __app ! "RT-6" , 19) s - !, w r i t e ! " Does t h e p r o p o s e d S p e c i a l Needs R e s i d e n t i a l F a c i l i t y camp 1 y\n " ) , w r i t e ! " w i t h s e c t i o n 11.17 of t h e Z o n i n g B y - l a w ? ! y / n ) \ t " 5 , • r e a d c h a r ! X ) , wr i t e ! X ) , n 1 , n 1 , chec:k_ans 1 ! X ) „ c h e c k _ . c o n d i t i o n a l . _ a p p ("RT-4" , 19) : - ! , c h e c k _ c o n d i t i o n a l _app ( "RT-6" , 19) . • c h e c k _ c o n d i t i o n a 1 _ _ a p p ( " R T - 5 " , 1 9 ) s - ! , w r:!. t e ! " Do e s t. h e p r o p o s e d S p e c i a 1 N e e d s R e s i d e n t i a 1 F a c i 1 i t y c o m p 1 y \ n w i t h s e c t i o n 1 1 . 7 " ) , w r i t e ! " of t h e Z o n i n g B y - l a w ? ! y / n ) \ t " ) , • r e a d c h a r !X) , w r i t e ! X ) , n l , n l , chec:k._ansl ( X ) . c hec k __c on d i t i on a 1 _ap p ! " RT-2 ",19) 5 - ! , c h ec k __c on d i t i on a 1 _ap p ( " RT-5 " , 1 9 ) . c h e c k . . . . c o n d i t i o n a l _app !_..., 20) s- !, w r i t e ! " D i d t h e g r o c e r y s t o r e e x i s t p r i o r t o J u l y 2 9 t h , 1980? ! y / n ) \ t " ) , r e ad c h a r ( Z ) , wr i t e ! Z ) , n 1 , n 1 , c h e c k __an s 1 ! Z ) , w r i t e ! " Does t h e g r o c e r y s t o r e c o m p l y w i t h s e c t i o n 11.16 o f t h e \ n Z o n i n g B y - l a w ? ! y / n ) \ t " ) , r e a cl c h a r ! W) , w r i t. e ! W) , n 1 , n 1 , c. h e c k __a n s 1 ! W) « chec::k__conc:li t i o n a l _app !_, 21) : - !, w r i t e ! " Does t h e p r o p o s e d Bed and B r e a k f a s t A c c o m m o d a t i o n c o m p l y w i t h s e c t i o n X n " > , w r i t e ! " 11.4 of t h e Z o n i n g B y - l a w ? < y / n ) \ t " ) , r e a d c h a r ! X ) , w r i t e ! X ) , n 1 , n 1 , c: h e c k _a. n s 1 ! X ) . c: h e c k __c o n d i t i o n a 1 __a p p ! " R T - 2 " , 2 3) s - I , w r i t e ! " Does t h e p r o p o s e d C1 u b i n v o 1 v e a n y c o m m e r c i a 1 a c t i v i t. i e s ? ! y / n ) " ) , r ead c h a r ! X ) , w r i t e !X) , n l , n 1 , c hec k ...an s 2 ! X ) , w r i t e ! " A r e o r w i l l a d j a c e n t p r e m i s e s be a d v e r s e l y a f f e c t e d ? (y/n) " ) , r e a d c h a r ! Y ) , w r i t e !Y) , n l , n l , check_ans2!Y)„ c hec k ..j::: on cl i t i on a 1 _ap p ! "RT-5" ,23) s - ! , c h e c k..cond i t i o n a l _app ! "RT-2" ,23) „ c h e c k _ c o n d i t : i . o n a l . _app C R T 6",24) - !, f a i l . c h e c k _ c o n d i t i o n a 1 _ a p p !.... ,245 s - ! , t r u e . check.._cond:i. t i o n a l . _ a p p ! "RT-6" ,25) :: - ! , f a i 1 ., check_j:::ondi t i o n a l _app (_, 25) s I , w r i t e ! " Does t h e p r o p o s e d H o s p i t a l c o m p l y w i t h S e c t i o n 11.9\n of t h e Z o n i n g B y - l a w ? ! y / n ) \ t " ) , r e a d c h a r ( Y ) , w r i t e ( Y ) , n l , n l , c h e c k _ a n s 1 ! Y ) . c h e c k j r o n d i t i o n a l _ a p p ! " R T - 2 " , 2 6 ) : - !, w r i t e ! " I s t h e p r o p o s e d P a r k i n g A r e a a n c i l l a r y t o a p r i n c i p a l u s e \ n " ) , w r i t e ! " on an a d j a c e n t s i t e ? ( y / n ) \ t " 5 , r e a cl c h a r (X ) , w r i t e ! X ) , n 1 , n 1 , c h e c: k _a n s 1 ! X 5 „ c : h e c k _ _ c o n d i t i o n a 1 _app (_, _) s - t r u e . m /* REGSI ,. PRO */ % % RE6S1,, PR0 and REBS2. PR0 <:::ontai n t h e r u 1 es whi ch desc:r i be the zoni. ng regulations„ REGS 1 „ PRO c o n t a i n s % a l l of t h e ' c h e c k _ r e g s ' c l a u s e s and t h e s e d e s c r i b e t h e r u l e s f o r c h e c k i n g s i t e a r e a r e q u i r e m e n t s f o r % t h e s p e c i f i c zones., REGS 1 „ PRO a l s o c o n t a i n s t h e ' c h e c k _ r e s t _ o f _ r e g s ' r u l e s w h i c h d e t e r m i n e w h i c h % p a r t i c u l a r r e g u l a t i o n s a p p l y f o r w h i c h z o n e . The r e m a i n d e r of REGS1.PR0 c o n s i s t s of r u l e s d e s c r i b i n g % e a c h o f t h e z o n i n g r e g u l a t i o n r e q u i r e m e n t s . E a c h r u 1 e c o n s i s t. s o f a s e r :i. e s o f c o n d i t i o n s , u s u a 11 y % s e p a r a t e d by a s e m i - c o l o n , and a r e s p o n s e t o be g i v e n s h o u l d t h e u s e / s i t e c o m b i n a t i o n f a i l t h a t z o n i n g % r e g u l a t i o n . % % N o t i c e t h a t o n l y t h e r e g u l a t i o n s r e l e v a n t t o t h e zon e i n q u e s t i o n a r e t r i g g e r e d d u r i n g a s e s s i o n and t h a t % most o f t h e c o n d i t i o n s r e q u i r e t h e u s e r t o r e s p o n d t o one o r more q u e s t i o n s , , % p r o j e c t "EUCLID" i n c l u d e "cs\\programs\\tprolog\\g1obals„pro" p r e d i c a t e s cine c k __s i d e __y a r d s 2 ( i n t e g e r ) c h e c k _ f s r 1 ( i n t e g e r ) ch e c k _ f s r 2 ( i n t e g e r ) check__\-sr3 ( i n t e g e r ) c h e c k __s i t. e __c o v e r a g e 2 ( i n t e g e r ) c h e c k _ s i t e _ c o v e r a g e 3 ( i n t e g e r ) t e s t 1 ( r e a l , c h a r , c h a r , i n t e g e r ) t e s t 2 ( r e a l , c h a r , c h a r , i n t e g e r ) c h e c k __d w e l l i n g u n i t _ d e n s i t y l ( i n t e g e r ? chec::k_hor i z o n t a i _sun__ang 1 e 1 ( i n t e g e r ) c h e c k _ac; o u s t i c s 1 ( i n t eg e r ) t e s t _ u s e (use) c 1 a u s e s c h e c k . / e g s ( "RT-4N" , X ) s •- ! , c h e c k _ r e g s ( "RT-6" , X) . c h e c k _ r e g s ( " R T - 5 N " , X ) s ••• I , c h e c k e r egs ( "RT--6" , X) „ c h e c k _ r e g s ( " R T - 2 " , 10) s - d i m e n s i o n s (_,_,_.,.._,!.... o t A r e a , _ , _ , _ , _ . ) , mi n _ s i t e _ a r e a l ( , S q f t ) , !.. o t a r e a > = S q f t , i 5 s h i f t w i n d o w (1) ,, c 1 e a r w i n d o w , z one_c 1 a s s ( Zone) ,• n 1 , w r i t e ! " The u s e p r o p o s e d f a i l s t o meet s i t e a r e a r e q u i r e m e n t s N n " ) , w r i t e ( " f o r t h e " , Zone , " s c h e d u 1 e. \n \n " ) , n I , ! , f a i 1 ., c h e c k _ r e g s ( " R T - 6 " , 1 0 ) s- w r i t e ! " How many a d j o i n i n g p a r c e l s o f l a n d make up t h e p r o p e r t y i n q u e s t i o n ? \ t " ) , r e a d i n t ! X) ,n1 , w r i t e ! " Were t h e c u r r e n t p a r c e l !s) on r e c o r d i n t h e Land T i 11es 0f f i c e \ n " ) , w r i t e ! " b e f o r e December 6 t h , 1977? ! y / n ) \ t " ) , r e a d c h a r ! Y) , w r i t e ! Y) , n 1 , n 1 , c h e c:: k _ a n s 1 ! Y) , d i mensi o n s ! F r o n t _ ) , max__f r e n t a g e ! Z ) , F r o n t <= Z , ! 5 s h i f t w i n cl o w (1) , c: l e a r w :i. n d o w , z o n e _c 1 a s s ( Z o n e) , n 1 , w r i t e ( " The u s e p r o p o s e d f a i l s t o meet s i t e a r e a r e q u i r e m e n t s X n " ) , wr- i t e ( " f or- t h e " , Zone, " sc:hed u 1 e „ \n \ n " ) , n 1 , 1 , f a i 1 . ch e c k e r - e g s ( "RT-5" , 10) : - ! , c h e c k _ r e g s ( "RT-6" , 10) . c: hec k__r e g s ( "R1"-2 " , 1 1) :; ! , t r ue „ c h e c k _ r e g s ( " R T - 6 " , 1 1 ) s- d i m e n s i o n s ( _ , _ , „ , _ , L o t a r e a , _ , _ , _ , _ ) , mi n _ s i t e _ _ a r e a (Sqf t ) , L o t a r e a >= S q - f t , ! $ s h i f t w i n d o w ( 1) , c l e a r w i n d ow, z o n e „__c: 1 a s s ( Z o n e) , n 1 , w r i t e ! " The u s e p r o p o s e d f a i l s t o meet s i t e a r e a r e q u i r-e,ments\n") , wr i t e ! " f o r t h e " , Z on e ,, " s c h ed u 1 e., \ n \ n " ) , r e l a x a t i o n ( Z o n e , 5 . 1 , 1 1 ) , n l , ! , fail„ c h e c k _ . r e g s < "RT-4" , 11) s - ! , c h e c k j - e g s ( "RT-6" , 11) . c h e c k j r e g s ! " R T - 5 " , 1 1 ) 2- !,eheck_regs!"RT-6",11)„ c h e c k _ _ r e g s ! "RT-2" , 125 ; - d i m e n s i o n s < _ , _ , _ » _ , L o t A r e a _ ) , mi n _ s i t e _ a r e a 1 (Sqf t , ._.) , L o t a r e a >- S q - f t , ! ; s h i f t w i n d o w (15 , c l e a r w i n d o w , z o n e _ c 1 a s s ( Z o n e) , n 1 , wr i t e ( " T h e u s e pr• o p o s e c l f -ai 1 s t o meet s i t e a r e a r e q u i r e m e n t s \ n " ) , w r i t e ( " f or- t h e " , Zone, " s c heel u 1 e „ \n \ n " 5 , r e l a x a t i o n ( Z o n e , 5 . 1 , 1 2 ) , n l , ! , f a i 1 . c h e c k j - e g s ( X , 12) s -- i , c h e c k _ _ r e g s ( X , 115 „ c h e c k __r e g s (_,_._) s -• t r u e „ c h e c: k __r e s t _o -f.... r • egs ( "RT-2" ) 5 - - p r o p o s e d j i s e ( X 5 , t e s t ...use ( X 5 , !; p r o p o s e cl __u s e ( X ) , c h e c k _.h e i g h 13 , c h e c k __f r o n t ...y a r- d 2 , c h e c: k _ s i d e _y a r cl s 2 ( X ) , c h ec k _ r e a r _ y & r d 2 , check._.f sr-3(X) , c h e c: I-:: _ s i t e _c o v e r- a g e 3 ( X ) , c h e c k _h o r i z o n t a 3. _ s u n __a n g 1 e 1 ( X 5 „ cI" 1 ec. k_rest_pf ...regs ( " RT 4 " ) :i proposed_.use ( X ) , test.....u.se ( X ) , ! 5 proposed_u.se ( X ) , c h e c k _ h e i g h t 2 , c h e c k _..f r o n t __y a r d 3 , c h e c k _ s i d e _ y a r cl s 1 , c h e c: k _ r e a i-- _ y a 1 - d 1 , check__f sr -4, c: h e c k _ s i t e _c a v e r- a g e 2 ( X ) „ chec: k _ r e s t _ o f __regs < " R T - 4 N " ) s - p r a p a s e d _ u s e < X ) , t e s t . _ u s e ( X ) , Is. p r a p o s e d __u s e < X ) , c h e c k _ h e i ght.2, e h e c: k _ f r o n t _y a r • d 3 , c h ec k __s i d e _ y a r d s 1 , c h e c k __r e a r _y a r • d 1 , c h e c k _ f sr-4, c h e c k _ s i t e _ c o v e r - a g e 2 ( X ) , c h e c k _ a c o u s t i c s i ( X ) . c h e c k _ r e s t _ o f _ r s g s ( " R T - 5 " ) ! - proposed__u.se (X) , test__u.se (X )f, ! 5 p r o p o s e d _ u. s e ( X ) , c h e c k _ h e i g h t 2 , c h e c k __-F r o n t __y a r d 3 , c h e c k _ s i d e __y a r d s 1 , c h e c k _ r e a r __y a r d 1 , c h e c k ~ f s r 2 (X) , c h e c k__si t e _ _ c o v e r a g e 2 ( X ) . c h e c k _ r e s t __p -F __ r e g s ('' R T - 5 N " ) : - p r o p o s e d __u s e ( X ) , t e s t __u s e ( X ) , ! ; proposed_u.se ( X ) , c h e c k _ h e i g h t 2 , c h e c k _ f r o n t __y a r cl 3 , c h e c k _ s i d e __y a r d s 1 , c h e c k _ r e a r __y a r d 1 , c h e c k ~ f sr-2 (X) , c h e c k _ s i t e __c o v e r a g e 2 ( X ) , c : h e c k _ a c o u s t i c s l (X) „ c h e c k _ e s t _o4'• __r e g s ( " RT-6 " ) s - p r o p o s e d _ u s e ( X ) , t e s t _ u s e ( X 5 , I ; proposed__u.se ( X ) , c h e c k . _ h e i g h t i , c h e c k _ _ - f r o n t ___y a r d 1 , c h e c k _ s i d e _ y a r d s l , c h e c k __r • e a r __y a r d 1 , c h e c k j s r l (X) , c h e c k __s i t e __c o v e r a g e 1 , ci ' lec k_d w e l l i ng__un i t__denisi t y 1 ( X ) . t e s t _ _ u s e (4) s - ! , wr i t e ( " A r e any b u i 1 d i ngs p r o p o s e d f o r t h e s i t e r ead c h a r (Z) , w r i t e ( Z ) , n 1 ., n 1 , c hec: k _ a n s 2 < Z ) ., t e s t _ u . s e (5) s -t e s t _ u s e ( 6 ) s-t e s t _ u s e ( 7 ) : -t e s t _ u . s e (15) s -t e s t _ u s e (22) -t e s t "use (26) •-, testj«se!4), , t e s t _ _ u s e (4) ., , t e s t _ u s e ( 4 ) . I , t e s t _ u s e ( 4 ) „ ! t e s t _ u s e (4) .. ! , t e s t _ u s e (4) ., ( y / n ) V t " test.....u.me (27) •-- ! ,, t e s t _ _ u s e ! 4) t e s t u s e ( ) s- taiI„ «:: h e c k _. s i d e __y a r d s 2 (10) 5 -s i d e __y d s ( F e e t ) , w r i t e ! " How w i d e a r e t h e s i d e y a r d s i n f e e t ? \ t " ) , r e a d r e a l (X).,nl , X zone__c 1 a s s ( Zone) , w r i t e ! " A r e a l l t h e o u t e r w a l l s w r i t e ! " r e q u i r e d , as d e - f i n e d by o-f t h e p r i n c i p a l s e c t i on 4.5„3 of b u i I d i n g ( s ) t h e Zone w i t h i n t h e S c h e d u l e ? F e e t , s p a c e \ n " ) ! y / n ) \ t " ) r e a d c h a r ( Y ) , w r i t e !Y) , n1 , n l , c h e c k _ a n s i !Y) sh i f t w i n d o w ! 1) , c 1 e a r w i ndow, z one_.cI a s s ! Zone) ,n1, w r i t e ! " The u s e p r o p o s e d d o es 5 w r i t e ! Zone S c h e d u l i Tl-n n o t me ?r e f a r t t s i d e ") , n l , y a r d r e q u i r I , f a i 1 „ ? i ri e n t s f o r t h e \ n '') # c h e c k__si de__yards2 !_) s ••• c h e c k _ s i d e _ y a r d s l , c h e c k f s r 1 ! 8 ) • d i m e n s i o n s (__,_,_,.._, L o t A r e a , _ , F l o o r s p a c e , _, F l o o r s p a c e / L o t A r e a >= R a t i o l , ! , u-wi ndow , n 1 , >hi f t w i ndow (1) , c I > w r i t e ! w r i t e ! ' w r i t e ! w r i t e ( ' w r i t e ! w r i t e ! ' w r i t e ! w r i t e !' w r i t e ! w r i t e !' w r i t e ! w r i t e ( ' w r i t e ! w r i t e !' w r i t e ! The u s e p r o p o s e d r e q u i r e s an i n c r e a s e i n f 1 o o r s p a c e r a t i o. Wh i I e i t i s w i t h i n t h e a l l o w e d i t must s t i l l be a p p r o v e d by t h e >r ! R a t i o l , R a t i o 2 ) t h e a l l o w a b l e \ n " ) maximam i n c r e a s e F l o o r s p a c e / L . o t a r e a < =: R a t i o2 , i \n' ) who must f i r s - The i n t e n t and g u i d e •t c o n s i d e r s ") , n l , n l , of t h i s s c h e d u l e and w e l l •1 i n e s . \n" ) ,, D i r e c t o r o f P1 a n n i n g \ n " ) , . any a p p l i c a b l e p o l i c i e s \ n " ) - Th i n d Thi h e i g h t , b u 1 k , 1 o c a t i o n and t h e i r ef f e c t on t he <• a n d e ;•; i s t i n g v i e w s „ \ n " ) , The amount of open s p a c e and t h t g e n e r a l a m e n i t i e s o f t h e a r e a T h e p r e s e r v a t i o n o f a r c h i t e c t u r<• a m e n t i e s d e s i r e d f o r t h e a r e a SEE MORE? ; r e f o r e . A t ov e r a11 d e s i gn o f t ht s u r r o u n d i n g b u i 1 d i ng<j p r o p o s a l \ n " ) ; t r \ n" ) • e f f e c t \n" ) , .1 c h a r a c t e r \n") , n l o f t h e p r o p o s a 1 o n t h e \ n " ) ! y / n ) \ t " ) , r e a d c h a r ! B ) V 5 w r i t e !B) and t h e g e n e r a l \ n " ) , , check...ansi !B) , c l e a r w i ndow , n 1 , P r i ;nts \n") ,f a i I c h e c k _ f s r l !9) --check__f s r 1 ! 10) : --c h e c k _ f s r l ! 11 ) s ••-c h e c k • f s r l ! 1 2 ) s-c h e c k_ c h e c k c h e c k , c h e c k f s r l ! 8 ) f s r 1 ! S ) f s r 1 ( 8 ) f s r 1 ( 8 ) c l-i e c: k f s r 1 ! X ) : •-• c h e c k f s r 2 ( X ) c h e c k f sr-2 !8) ; - d i m e n s i o n s ? _ _ L o t A r e a ,..., F1 o a r S p a c e , _, _) , f s r !.., R a t i o 2) , !F1 a o r S p a c e / L o t A r e a ) <•-- R a t i o 2 , ! : ; s h i f t w i n d o w ! 1 ) , c l e a r w i n d o w , z o n e _ c I a s s ! Z o n e ) , p r o p o s e d _ u s e ! U s e ) , n I , w r i t e ! " The u s e p r o p o s e d f a i l s t o meet t h e f l o o r s p a c e r a t i o x n " ) , w r i t e ! " r e q u i r e m e n t s f o r t h e ",Zone," S c h e d u l e , \ n " ) , ! , r e l a x a t i o n ! Z o n e , 5 . 5 , U s e ) , n l , f< i i 1. z o n e _ c l a s s ( Z o n e ) , n l , w r i t e ( " The u s e p r o p o s e d f a i l s t o meet a n g l e o f d a y l i g h t r e q u i r e m e n t s X n " 5 , w r i t e C" f o r t h e " , Zone, " S c h e d u l e , ") , n l , ! , f a i 1 , c:heck__hor i z o n t a 1 __sun_ang 1 e 1 (9) s --c h e c k __h o r i z o n t a 1 _ s u n _ a n g 1 e 1 (10) s c h e c k _h o r i z a n t a 1 __s u n _ a n g 3. e 1 (11) ; -c h e c k_hor i z on t a 1 _ s u n __ang 1 e 1 < 12) : -c h e c k _ _ h o r i z o n t a l _ s u n _ a n g 1 e 1 (19 5 s -c h e c k _ _ h o r i z o n t a 1 _ _ s u n _ a n g l e l (8) « c h e c k __h o r i z o n t a 1 _ s u n .__a n g l e l (8) „ check__ h o r i z o n t a 1 __sun__anglel (E!) . c h e c k_hor i z o n t a l _sun__ang 1 e 1 ( 8 > „ c h e c k _h o r i z o n t a 1 __s u n __a n g l e l (E)) . c h e c k __h o r i z o n t a 1 __s u n _ a n g 1 e 1 (_) s -- t r u e. check___aeoust i c s 1 (8) s z one_c 1 a s s ( Zone! , w r i t e ( " A l l D e v e l o p m e n t P e r m i t a p p l i c a t i o n s f a r d w e l l i n g u s e s i n t h e ",Zone,"\n") , w r i t e ! " D i s t r i c t r e q u i r e t h a t an a c o u s t i c a l s u r v e y o f t h e d w e l l i n g s b e \ n " ) , w r i t e ! " u n d e r t a k e n and a r e p o r t p r e p a r e d . X n X n " ) , w r i t e ! " Has sueh a r e p a r t been s u b m i 11ed and do you have a c c u r a t e i nf ormat i on,\n") , w r i t e ! " c e r t i f i e d by an a c o u s t i c s s p e c i a l i s t , on n o i s e l e v e l s f o r t h e f o l l o w ! n g \ n " > , w r i t e ! " p or-1 i on s o-f t h e d w e l l i n g un i t ! s) ? ! y /n ) " ) , c u r s o r ! R , C) , R1 = R--5 , n 1 , n 1 , w r i t e ( " \ t B e d r o o m s , L i v i n g R o o m s , D i n i n g R o o m s , R e c r e a t i o n R o o m s , \ n " ) , w r i t e ! " V t K i t c h e n , B a t h r o o m s , H a l l w a y s , T e r r a c e s , \ n " ) , w r i t e ! " \ t P a t i o s , B a l c o n i e s . \ n " ) , c u r s o r ! R 1 , C ) , r e a d c h a r ! V ) , wr i t e ! V ) , n I , n 1 , chec k_ans2!V) , I , s h i -f t w i n d o w ! 1) , c 1 e a r w i n d o w , n I , w r i t e ! " Z o n i n g a p p r o v a l c a n n o t be made u n t i l a p r o p e r a c o u s t i c a l s u r v e y \ n " ) , w r i t e ! " and r e p o r t h a s been made. At p r e s e n t s " ) , n 1 , f a i l ? c u r s o r - !R , C) , R2 - R+3 , n o i s e _ l e v e l ! Lev 1 , L e v 2 , L..ev3 , L e v 4 ) , c u r s o r ! R2 , C) , n 3. , w r i t e ! " Do n o i s e l e v e l s i n any of t h e Bedrooms e x c e e d \ n " , L e v l , " db !A w e i g h t e d L e q ) ? ( y / n ) \ t " ) , r e a d c h a r ( W ) , w r i t e ( W ) , n l , n l , c h e c k _ a n s 2 ( W ) , w r i t e ! " Do n o i s e l e v e l s i n t h e L i v i n g Room, D i n i n g Room, o r R e c r e a t i o n RoomXn"), w r i t e ! " e x c e e d ",L.ev2," db (A w e i g h t e d L e q ) ? ! y / n ) \ t " ) , r e a d c h a r ! X ) , wr i t e ( X ) , n3. , n 1 , c h e c k__ans2 ! X ) , w r i t e ! " Do n o i s e l e v e l s i n t h e K i t c h e n , B a t h r o o m ! s ) , o r H a l 1ways\n") , w r i t e ! " e x c e e d " , L e v 3 , " db !A w e i g h t e d L e q ) ? ( y / n ) \ t " ) , r e a d c har- (Y) , wr- i t e (Y 5 , n 1 , n 1 , c hec k .an s 2 (Y 5 , w r i t e ! " Do n o i s e l e v e l s on t h e T e r r a c e ( s ) , P a t i o ( s ) , o r B a l c o n i e s \ n " ) , w r i t e ! " e x c e e d " , L e v 4 , " db (A w e i g h t e d L e g ) ? ( y / n ) \ t " ) , r e a d c h a r (Z) , w r i t e (Z) , n l , n l , chec:k_ans2 (Z) , ! ; s h i f t w i n d o w (1) , c 3. e a r w i n d o w , z one_c 1 a s s ( Zone) , n 3. , w r i t e ! " The u s e p r o p o s e d f a i l s t o meet a c o u s t i c s r e q u i r e m e n t s X n " ) , wr- i t e ( " f o r t h e " , Z on e , " Sc h ed u 1 e „ " ) , n 1 , ! , f a i ]. . c h e c k _ a c o u s t i c s l ( 9 ) s -c: h e c: k _a c o i ..t s t i c s 1 (10) c: h e c k __a c: o u s t i c s 1 (11) --e h e c k _ _ a c o u s t i c s l (12) s --c h e c k a c o u s t i c s 1 (19) :i — c h e c k _ _ a c o u s t i c s 1 (8) „ c h e c k _a c o u s t i c s 1 (8) „ c h e c k _ _ a c o u s t i c s l (8) „ c h e c k _ _ a c o u s t i c s l (85 „ c h e c k acoustics!(85„ c h e c k _ f s r 2 < 9) ; - ! ,, c h e c k _ f s r 2 (8) ., c h s c k j sr-2 < 10) s- !, c h e c k j sr-2 (8) . c h e c k_f s r 2 (_) s- d i mensi o n s (_,_,_,_, L o t A r e a ,_, F l o o r s p a c e ,_,__) , f s r ( R a t i o l , __) , F l o o r s p a c e / L o t a r e a <= R a t i o l , I i; s h i f t w i n d o w ( 1 ) , c 1 e a r w i n d o w , z o n e _ c 1 a s s ( Z o n e ) , p r o p o s e d _ u s e ( U s e ) ,nI , w r i t e ! " The u s e p r o p o s e d f a i l s t o meet t h e f 1 o o r s p a c e ra.t. i o \ n " ) , w r i t e ! " r e q u i r e m e n t s f o r t h e ",Zone," S c h e d u l e . \ n " ) , ! , r e l a>; a t i on ( Zone , 5. 5 , Use) , n l , f a i l . c ii e c k _ f s r- 3 ( 1 0 ) s ••• ! , c h e c k _ f s i- 2 ( 1 0 ) . c h e c k _ f s r 3 (__) s — c h e c k _ f s r 4 „ c h e c k _ s i t . e_c:overage2 (26) s — !, sh i f t w i ndow (1) , c l e a r w i ndow , n l , z one _ _c 1 a s s ( Zone) , w r i t e ! " S i t e c o v e r a g e r e q u i r e m e n t s f o r t h e p a r k :i. ng u s e p r o p o s e d c a n n o t \n " ) , w r i t s ! " b e d e t e r m i n e d f r o m t h e " , Z o n e , " S c h e c:! u le« C h e c k t h e c u r r e n t P a r k i n g \ n " ) , w r i t e ! " B y - l a w f o r t h e s i t e c o v e r a g e r e q u i r e d . " ) , n l , r e l a x a t i o n ! Z o n e , 5 . 2 , 2 6 ) , n l , f a i 1 . c h e c k _ s i t e _ c o v e r a g e 2 ( _ ) s - c h e c k __s i t e _ _ c o v e r a g e 1 „ c h e c k _ s i t e _ c o v e r a g e 3 ! 1 0 ) s- w r i t e ! " What i s t h e t o t a l a r e a o f t h e s i t e c o v e r e d bys s u r f a c e p a r k i n g \ n " ) , w r i t e ! " a c c e s s o r y b u i l d i n g s , m a n o e u v e r i n g a i s l e s , d r i v e w a y s , l o a d i n g a r e a s N n " ) , w r i t e ! " o t h e r v e h i c l u l a r f a c i l i t i e s , AND p r i n c i p a l b u i I d i n g (s) , i n s q f t ? " ) , r e a d r e a l !A) , a s s e r t a ! answer _J"iei g h t (A) , s t o r a g e ) , a n s _ h t ( H e i g h t ) , a n s _ c e l l ( A n swer!) , ans__base ( A n s w e r - 2 ) , a n s _ s t o r e y s ! S t o r e y s ) , t e s t 1 ( H e i g h t , A n s w e r 1 , A n s w e r 2 , S t o r e y s ) , d i m e n s i o n s < _ , _ , _ , L o t A r e a , _ , __, _ , _ ) , s i t e _ c o v ( P e r c e n t 2 , _ ) , ! A / L o t A r e a ) <> P e r c e n t 2 , 1 5 an s wer _h e i g h t ! A) , a n s _ h t ( H e i g h t ) , a n s _ c e l 1 ( A n s w e r ! > , a n s _ b a s e (Answer2) , a n s _ _ s t o r e y s ( S t o r e y s ) , t e s 12 (H e i g h t , A n s w e r 1 , A n s w e r 2 , S t. o r e y s) , d i m e n s i o n s ! , L o t A r e a , _ , _ , _ _ , _ ) , s i t e _ c o v ! , P e r c e n 13) , ( A / L o t A r e a ) <= P e r c e n t 3 , ! 5 s h i f t w i n d o w ! 1) , c 1 e a r w i n d o w , z on e _ _ c 1 a s s ! Z on e) , n 1 , w r i t e ! " The use p r o p o s e d f a i l s t o meet s i t e c o v e r a g e r e q u i r e m e n t s X n " ) , w r i t e ! " f o r t h e " , Z o n e , " Schadu.3. e „ " ) , n 1 , ! , f a i 1 „ c h e c k _ s i t e _ _ c o v e r a g e 3 ( X ) : ~ ! , c h e c k _ s i t e _c o v e r a g e 2 ( X ) . t e s t 1 ( H e i g h t , A n s w e r 1 , A n s w e r 2 , S t o r e y s ) s H e i g h t <- 3 0 ; Answer 1 - ' y ' , S t o r e y s <- 2;; A n s w e r 2 = ' y ' , S t o r e y s <- 1. t e s t 2 ( H e i g h t , A n s w e r 1 , _ , S t o r e y s ) s- H e i g h t <- 20; A n s w e r ! = 'y', S t o r e y s <•-- 1. c h e c k _ h o r i z o n t a l __sun__angl e 1 (8) s- w r i t e ! " How many d w e l l i n g u n i t s a r e p r o p o s e d ? \ t " ) , r e a d r e a l ( X ) , n l , X < 3 , i ; z one_c1 a s s ! Zone) , w r i t e ! " I s t h e p l a n e d e f i n e d by s e c t i o n 4.10.1 of t h e ",Zone," S c h e d u l e u n o b s t r u c t e d X n " ) , w r i t e ! " o v e r a d i s t a n c e o f 80 f e e t f r o m a l l e n t e r i o r w a l l s ' ? !y/n) " ) , c u r s o r !R,C), R l - R - 2 , n l , w r i t e ! " !See s e c t i o n s 4.10.2 and 4.10.3 f o r i n f o r m a t i o n on\n what c o n s t i t u t e s an o b s t r u c t i o n ) , , " ) , c ur- soi- ! R1 , C) , r e a d c har- (Y) , w r i t e ! Y) , c u r s o r ! R , C) , n 3. , c h ec k _an s 1 ! Y) , ! ; s h i f t w i n d o w ! 1) ,, c 1 e a r w i n d o w , c hec k .__a c o LA S t :i. c s:!. (_) s -- t r- u e. c: h e c k _d w e 11 i n g __u n i t _d e n s i t y 1 (&) c h e c k__d we 11 i ng_un :i. t _ _ d e n s i t y 1 (9) c: h ec !•:  _d w e l l i n g _un :i. t J e n s i t y 1 (10) c h e c k _d we 11 i ng_un i t _den s i t y 1 ( ) ! , w r i t e ( " How many d w e l l i n g u n i t s a r e p r o p o s e d ? X t " ) , r e a d i n t ( X 5 , n l , d i m e n s i o n s (__,__,__ ,...., L o t Area,_,__,_,_) , d w e 11 i n g _u n i t _d e n s i t y 1 (U p a c ) , L.o t A r e a / f t__per_..aere = L.ot A c r e a g e , roLAnd ( X / L o t f t c r e a g e ) < ~- Upac . ! , c h e c: k _d w e l l i n g _u n i t __d e n s i t y 1 (8) ,. w r i t e ( " How many d w e l l i n g u n i t s a r e p r oposed'?\t " 5 , r e a d i n t ( X 5 , n 1 , d i mensi ons (_, _, _, __, L o t A r e a ,__,__,_,_) , dwel 1 i ng_un i t _ d e n s i t y 2 (Upac ) , L o t A r e a / f t _ p e r _ a c r e = L o t A c r e a g e , r o u n d ( X / L o t A c r e a g e ) > Upac, sh i f t w i ndow(1) ,c1 e a r window, z one.__c 1 a s s ( Z one) , n 3. , w r i t e (" The u s e p r o p o s e d - f a i l s t o meet d w e l l i n g u n i t d e n s i t y X n " ) , wr i t e ( " r e q u i r e r n e n t s f o r t h e " , Zone , " S c h e d u l e „ " ) , n 1 , ! , f a i l ; w r i t e ! " I s more t h a n one p r i n c i p a l b u i l d i n g p r o p o s e d ? ( y / n ) \ t " ) , r e a d c h a r ( X ) , wr i t e ( X) ,n 1 ,n1,chec k _ a n s 2 ( X ) , I ; I , c h e c k_number _ o f _b u i 1 d i ngs 1« w r i t e ! " A r e any d w e l l i n g u n i t s a r e p r o p o s e d ? ( y / n ) \ t " ) , r e a d c h a r ( Z ) , wr i t e ( Z ) , n I , n I , c h e c k__ans2 ( Z wr- i t e ( " How many? \ t " ) , r ead i n t ( X ) , n 1 , d imen s i ons ( _ , _ , _ _ , _ , L.ot Ar e a ) , d we 11 i ng _ _ u n i t _.dens i t y2 (Upac ) , L a t Ar ea / f t _p e r __a.ere = !....ot Ac:r eag e , r o u n d ( X / L o t Ac r- eag e) > Upac, sh i f t wi nd ow(1) ,c1 e a r w i n daw, z an e_c1 a s s ( Z on e) ,n1 , w r i t e ! " The u s e p r o p o s e d f a i l s t o meet d w e l l i n g u n i t d e n s i t y X n " ) , w r i t e ! " r e q u i r e r n e n t s f o r t h e ",Zone," S c h e d u l e . " ) , n l ,! , f a i l ; w r i t e ! " I s more t h a n one pr- i nc i pa3. b u i I d i n g pr-oposed? ( y / n ) Xt " ) , r e a d c h a r ( X ) , wr i t e ( X ) , n 3. , n 1 , c hec:: k._ an s 2 ( X ) , ! ; ! , c h e c k _n u m b e r- _o f __b u i 1 c:l i n g s 1. % % % % % % % % % /* REGS2,, PRO */ RE6S2, PR0 c: ori t a :i. n s t h e r emai n i n g r u 1 e s f o r cle ar- e c a l 1 ed f r- om t he ' c:hec: k _ r e s t _p f __r e g s ' c: 3. au<; : r i b i n g t h e z o n i n g r e g u l a t i o n s , , Mote t h a t s i n c e t h e s e r u l e s s si i n R E 6 S1 „ P R 0 t h e y h a v e t o be d e <:: 1 a r e d a s g 3. o b a 1 p r e d i c a t< T h e c 1 a u s e ' g e t _ r e 1 a ;•: a t i o n ' i n t h e b o d y o f c: h e c k. __s i d e __y a r d : r e l a x a t i o n c: 1 a u s e c: o n t a i n e d i n R E L. AX MS „ P R 0 i s c: a l i o cl -f o r c: (I n f i l l ) ar '10' (Mu 11 i p 1 e Dwe3. l i n g ) ' g e t _ r e 1 a;•: a t i on ' f a i 1 •; p e r m i 11 e d ' r e s u 11 „ ; 1 a n d c: h e c: k __r e a r _y a r d .1. ;r-ta:i. n uses; and n o t a t he > and l e a cl s t o ' c: heck u« e n s u r e s t h a t ?rs„ I f t h e us ;e ' produce i n g t h e c o r r e c t •e i s n o t '8' a 'use i s n o t p r o j e c t i n c l u d e "EUCLID" "c s NNprogr; [ins \ \ t p r o 1 og \ \g I ob a3. s „ p r o' c 1 aus c h e c k J i e i g h t 1 s- h e i g h t ( F e e t , S t o r e y s ) , w r i t e ( " A r e t h i wr i t e ( " " , F e e t , " f s e t o r " , S t o r e y r e a c J c h a r ( Z ) w r i t e ( " How w r i t e ( " How w r i t e ( " How w r i t e ( " How ) b u i l d i n g s ; a d j a c e n t on b o t h s i d e s of the storeys'"' (y/n) \ t " ) , ;.i.te h i g h e r t h a n \ n " ) wr- i t e ( Z ) , n I , n 3. , c h e c k__ans 1 (Z ) , h i g h i s t h e f i r- s t i n f t ? \ t " ) , r e a d r- e, h i g h i s t h e PRINCIPAL b u i l d i n g ( s ) i n h i gh i s t he PR IMCIPAL. b u i 1 d i ng (s) i n many s t o r e y s denes i t ( t h e y ) h a v e ? \ t " ) cursor- ( R l , C l ) , R2 13. (A) , c u r s o r (R: = R l C l f t ? \ t " ) f t'?Nt" ) r e a d r e , r e a d r e a , r e a d r e a a l (Y) ,n1 , ,C2) , l (X) l (X) C2 w r i t e ( " N t A n d the , A v e r a g e H e i g h t -second"? " ) , (A+EO/2, X < = : <= F e e t , ! h e i g h t (.._, S t o r e y s ) , Y < = S t o r e y s , ! ; r e a d r e a l ( B ) , n l A v e r a g e H e i g h t , , n l , h e i g h t ( F e e t , __) s h i f tw i n dow (1) , c 1 e a r w i n d o w , z one__c 1 a s s ( Zone) , n I , wr- i t e ( " The u s e p r op o s e d d oes wr i t e ( " "„Zone„" S c h e d u l e . The n o t meet he i ghi t r equ i r e m e n t i •ref o r e s " ) ,, n 1 ~ ! , f a i 1 . f o r t h e X n " ) c h e c k_he i g h 12 s ~- h e i g h t ( F e e t , __) , w r i t e (" How h i g h i s t h e PRINCIPAL, b u i 3. d i n g (s) i n f t ' ? N t " ) , r e a d r e a l (X) , n l , X < = Ft h e i g h t (__, S t o r e y s ) , w r i t e ! " How many s t o r e y s d o e s i t ( t h e y ) h a v e ' ? X t " ) , r e a d r e a l ( Y ) , n 1 , Y <> S t o r e y s , ! : s h i f t w i n d o w (1) , c: 1 e a r- w i n cl o w ,, zone_c3. a s s ( Zone) , n 1 , w r i t e ! " The u s e p r o p o s e d d oes n o t meet h e i g h t r e q u i r e r n e n t s for- t h e N n " ) , w r i t e ! " " , Zone S c h e d u l i T h e r e f o r e ; " ) , n 1 , ! , f a i 3. c h e c k _ h e i g h t 3 s - w r i t e ! " How h i g h i s t h e PRINCIPAL b u i l d i n g ( s ) i n f t ' ? X t " ) , r s a d r e a l ( X ) , n 1 , sr-ta ( a n s J i t ( X ) , s t o r a g e ) , l i t (Feet,__,__) , X < = F e e t , ! ;; w r i t e ! " Does t h e b u i I d i n g (s) hi a v s a e e l 1 ar- ? (y / n ) N t a s s e r t a ( a n s _ _ c e l I (Y) , s t o r a g e ) , n l , n l , c h e c k _ a n s 2 (Y) , ! ) readchar(Y)„ w r i t e ( Y ) c h e c k__hei gh14; w r- i t e ( " L x c 1 u cl i n g t hi e c e l l a r - , h o w many s t o r- e y s cl o e s t h e b u i 1 ci i n g (s) h a v e'? Nt" ) r i id r e a l (Z) s h i f t w i n d o w ( 1 ) z o n e __c 1 a s s ( Z o n w r i t e ! " The u s s e r-1 a (a n s _s; t o r-1 , c 3. e a r wi ndow , e) , n 1 , e p r o p o s e d doe? >ys ! Z ) , s t o r a g e ) , n l , h t !_, S t o r e y 1 ,__) , Z S t o r e y 1, !; n o t meet h e i g h t r e q u i r e m e n t s f o r t h e N n " ) w r i t e ! " " , Zone, " S c h e d u l e . There-fores " ) , n l , ! , f a i l rl, ! 5 ...ght 4 s w r i t e ! " Does t h e taui 1 d i ng (s) h a v e a b a s e m e n t ? (y/n) " ) , r e a d c h a r CW5 , w r i t s (W) , a s s e r t a ( a n s _ b a s e < W) , s t o r age) , n 1 , n I , ( < c h e c k _ a n s l !W) , w r i t e ! " Exc 1 ud :l. ng t h e b a s e m e n t , how many s t o r e y s d o e s t h e taui 1 d i ng !s) h a v e ? " ) , r e a d r e a l ! Z ) , a s s e r t a (a n s ._ s t o r e y s ! Z ) , s t o r a g e ) , n i , h t ! , , 3 t o r e y 2) , Z < S t o r e y 2 , ! ; sh i f t w i ndow ! 1) , c 1 ear- w i ndow , (_ ) z on e,._c 1 a s s CZ on e) , n 1 , w r i t e ! " The u s e p r o p o s e d d o e s n o t meet h e i g h t r e q u i r e m e n t s -for t h e \ n " ) , ( ) wr i t e ! " " , Zone , " S c h e d u l e „ There-f o r e " ) , n 1,1, -f a i 1 . (..') c h e c k _ _ - f r o n t _y a r d 1 -- z o n e ... c I a s s ! Z o n e) , ( w r i t e ! " What i s t h e d e p t h o f t h e f r o n t y a r d , i n f t , f o r t h e a d j a c e n t s i t e s ? \ n " ) , < • w r i t e ! " ! Refer- t o s e c t i o n 4.4.1 of t h e " , Z o n e , " S c h e d u l e f o r g u i d a n c e i n \ n d e t e r m i n i n g t h e s e d e p t h s . ) \n\n") , c u r s o r !R1 ,C1) , R2 = RI , C2 = Cl-i-30, w r i t e ! " \ t T h e f i r s t ? \ t " ) , r e a d r e a l !X) , ' . {' c u r s o r !R2,C2 5 , w r i t e ( " \ t And t h e s e c o n d ? \ t " ) ,, r e a d r e a l ! Y) , n 1 , !X + Y ) / 2 = A v e D e p t h , d i m e n s i o n s !...„, L e f t R i g h t F Y - o r t t D e p t h ,.....) , f r o n t _ y a r d ( R a t i o , F e e t ) , ( ( ( L e f t + R i g h t ) /2) * R a t i o ) = D e p t h , rou.nd !abs ! A v e D e p t h Depth 5 ) > F s e t , F r o n t D e p t h A v e D e p t h , ! s ( d i mensi o n s (_, L e f t R i g h t , „,_,_,FrontDepth, _ J , -fr o n t ...yard ( R a t i o , F e e t ) , ! F r o n t D e p t h / ! ! L e f t + R i g h t ) / 2 ) ) >•-•= R a t i o , . ; s h i f t w i n d ow ! 1) , c: I e a r w i nd ow , z o n e.... c 1 a s s ! Z o n e) , n I , V w r i t e ! " The u s e ' p r o p o s e d d o e s n o t meet f r o n t y a r d r e q u i r e m e n t s f o r t h e \ n " ) , '.. wr- :i. t e ! " " , Z on e , " Sc h ed LA I e „ T h e r e f o r e s " 5 , n 1 , i , f a i l . ! - c h e c k _ f r o n t _;•/ a r cl 2 s •-• d i m e n s i o n s !...,!.... e f t , _._, R i g h t,._.,..., _._,..., _.) , ! L e f t + R i g h t ) / 2 < 12 0 , ! , (. .. w r i t e ( " S i n c e t r i e s i t e has; an a v e r a g e d e p t h o f 1 e s s t h a n 120 f e e t , t h e d e p t h \ n " ) , write-,!" r e q u i r e d f o r t h e f r o n t y a r d may be d e c r e a s e d i n aizc.ar-da.nce w i t h s e c t i o n \ n " ) , w r i t e ! " 11 „ 2 o f t h e Z on i n g By law,, \ n " ) , n 1 v . d i mensi o n s !_,...,......., Fr• ont.Dept.h , _) , f r o n t _ y d ! F e e t ) , F r o n t D e p t h >-:: F e e t , i ; s h i f t w i n d o w ! 1) , c I ear- w i n d o w , ! z one...c I a s s ! Zone) , n I , ;.. w r i t e ! " The u s e p r o p o s e d d o e s n o t meet f r o n t y a r d r e q u i r e m e n t s f o r t h e \ n " ) , w r i t e ! " " , Zone, " Schedule,, T h e r e f o r e s " ) , n 3. , i , f a i l . ( c h e c k . . . f r c n t ......y a r d3 s- d i men s i on s (....., L e t t v , R i g h t,...,.._, _..,__,.....) , ( L e f t + R i g h t ) / 2 < 120,!, w r i t e ! " S i n c e t h e s i t e h a s an a v e r a g e d e p t h o f l e s s t h a n 120 f e e t , t h e d e p t h \ n " ) , I w r i t e ! " r e q u i r e d f o r t h e f r o n t y a r d may be d e c r e a s e d i n a c c o r d a n c e w i t h s e c t i o n \ n " ) , wr i t e ! " 11 „ 2 o f t h e Zon i ng By--1 aw. \n " ) , n 1 5 cl i mensi ons ! . . . . , . . . . F r o n t D e p t h , _) , f r o n t _ y c l ( F e e t ) , F r o n t D e p t h >= F r s e t , ! C • s h i f t w i n d o w ! 1) , c 1 e a r w i n d o w , I z one....c 1 a s s ! Z on e) , n 1", w r i t e ! " The u s e p r o p o s e d d o e s n o t meet f r o n t y a r d r e q u i r e m e n t s f o r t h e \ n " ) , ( w r i t e ! " " , Zone, " Schedule,, \n\n") , ( w r i t e ! " The Di r e c t o r o f P l a n n i n g o r t h e Deve1opment P e r m i t B o a r d , a s \ n " ) , w r i t e ! " t h e c a s e may be, may r e l a x t h e minimum f r o n t y a r d d e p t h \ n " 5 , ( w r i t e ! " r e q u i r e d p r o v i d e d h e f i r s t. c o n s i d e r s the d e p t h s o f t he a cl j a c e n t \ n " ) , I w r i t e ! " f r o n t yards; and a l l a p p l i c a b l e p o l i c i e s and g u i d e l i n e s a d o p t e d \n by C o u n c i 1 . " ) , n l , ! , f a i l . ( check__.side__.yard s i s - w r i t e ! " I s t h e p r o p e r t y a c o r n e r s i t e ? (y/n) \ t " > , readchar ( X ) , w r i t e (X) , n l , n l , c h e c k...ans; 1 ! X ) , ! , L w r i t e ! " Does i t c o m p l y w i t h s e c t i on 11„1 of t h e Z on i ng By-1 aw? ! y / n ) \ t " ) , r e a d c h a r ! Y ) , w r i t e ( Y ) , n l , n l , c h e c k _ a n s 1 ! Y ) s . ( w r i t e ! " How w i d e a r e t h e e x i s t i n g / p r o p o s e d s i d e yards; i n f e e t ? \ t " ) , readreal !X) , •• a s s e r t , a ( s i cles ( X ) , s t o r a g e ) , d i m e n s i o n s ( F r o n t , _ , R e a r ,_, _,„,_,_,_) , s i de__yards (Rat i o , F e e t ) , ( F r o n t + R e a r ) /2 * R a t i o = S i d e W i d t h , F e e t >= S i d e w i d t h , X < S i d e W i d t h , I , - f a i 1 ; s i d e s (X) , s i d e y a r d s (....., F e e t ) , X < F e e t , - f a i l ? s i d e s ( X ) , s i d e._y a r d s (_, F e e t ) , X = F e e t , I , n 3. i; s i d e s ( X ) , s i d e _ y a r d s (_., F e e t ) , X > F e e t , n 3. , w r i t e ! " E a c h s i d e y a r d need n o t e x c e e d " , F e e t , " -feet i n wi d t h \ n " ) , n 3. , s h i f t w i n d ow ( 1 ) , c: 3. e a r w i n c:low , z ane__<:::.3. a s s ( Zone) , p r o p o s e d _ u s e (Use) , n 3. , w r i t e ! " The u s e p r o p o s e d d o e s n o t meet s i d e y a r d r e q u i r e m e n t s f o r t h e \ n " ) , wr i t e ( " " , Zone , " S c h e d u l e „ " ) , n l , ! , g e t _ r e l a x a t i on ! X , Use) , r e l a x a t i on ! Zone , X , Use) , n l , - f a i 1 . L h e c k _ r e a r . _ y a r d i s -- d i mens i or i s !_, L e f t , _, R i g h t ,„»„»._»_, __) , ( L e f t •+• R i g h t ) / 2 < 120, w r i t e ! " S i n c e t h e a v e r a g e d e p t h o f t h e s i t e i s l e s s t h a n 120 f e e t t h e d e p t h X n " ) , w r - i t e ( " r e q u i r e d f o r t h e r e a r y a r d may be d e c r e a s e d i n a c c o r d a n c e w i t h s e c t i o n \ n " ) , wr i t e ( " 11 „ 2 o f t h e Zon i ng By--1 aw „ \n " ) , n 1 , ! w r i t e ! " Doe s t h e rear- o f p r o p e r t y a b u t a l a n e ? ! y / n 5 \ t. " ) , r e a d c h a r (X) , w r - i t e ! X ) , n 1 , n 1 , c h e c k __a n s 1 ( X 5 , w r i t e ! " What i s t h e d i s t a n c e b e t w e e n t h e r e a r p r o p e r t y l i n e and t h e c e n t r e X n of t h e l a n e i n f t ? V t " ) , r e a d r e a l ( Y ) , d i m e n s i o n s ( _ , _ , _ , _ ) _ _ , _ , _ , _ , R e a r D e p t h ) , r e a r _ y a r d ( F e e t ) , Rear-Depth >~ F e e t ' Y , n l , ! s d i m ensi o n s (_,_,„,_,_,_,_,_, Rear-Depth) , r e a r .....yard ( F e e t ) , R e a r D e p t h > = F e e t , ! g s h i f t.w i. n dow ! 1 ) , c 1 ear- w i nd o w , z on e ._.<:: 3. a s s ! Z on e) , p r-op o s e d __use!Use) , n 3. , w r i t e ! " The u s e p r o p o s e d d o e s n o t meet r e a r y a r d r e q u i r e r n e n t s f o r t h e \ n " ) , w r i t e ! " " , Zone, " S c h e d u l e , , ") , n l , I , g e t _ r e l ax a t i on ! X , Use) , r e l a x a t i o n ! Zone , X , Use) , n l , - f a i l „ checker-ear-.....yard 2 s-• w r i t e ! " I s t h e s i t e a r i p a r i a n s i t e ? ! y / n ) \ t " ) , r e a d c h a r - ( X ) , wr- i t e ( X ) , n I , n I , chec: k_ans2 ( X ) , c h e c k _ r e a r- ...y a r- d 1 , ! ; d i m e n is :i. o n s (._, L. e f t , ...., R i g h t ,...,....., __.,......,.....) , (L e f t + R i g h t ) / 2 < 12 0 , wr i t e ! " S i n c e t h e a v e r age d e p t h o f t h e s i t. e i s 1 e s s t h a n 12 0 f e e t t h e d e p t h \ n " ) , w r i t e ! " r e q u i r e d for- t h e r e a r y a r d may be d e c r e a s e d i n a c c o r d a n c e w i t h s e c t i o n \ n " ) , wr- i t e ! " 1.1. „ 2 o f t h e Zon i ng By--1 aw „ \n " ) , n 1 , wr i t e ! " Has a ta u i 3. d i n g I i n e fa een e s t ab 1 :i. s h ed p ur- s u a n t t a t. h e p r o v i s i on s \ n " ) , w r i t e ! " o f s e c t i o n 14 „ 2 o f t h e Z o n i n g By l a w ? ! y / n ) \ t " ) , r e a d c h a r ! X ) , wr- i t e ! X ) , n I , n I , c hec k .an s 1 ! X ) , wr- i t e ! " Wh a t i s t h e d i s t an c e b e t w e e n t h e b ac k o f t he near- e s t p r-1 n c i p a 1 \n " ) , w r- i t e ! " b u i 3. d i n g a n cl t h i s b u i 1 d i n g I :i. n e , i n f t ? \ t " ) , r e a d r e a l !Y) , n l , r- e a r .._y arc! ( F e e t ) , X > = F e e t , ! w i- :i. t e ! " H a s a b u i I d i n g 1 i n e bee n e s t a b 1 :i. s h e cl p u r- s u a n t t a t h e p r- o v i s i o n s \ n " ) , w r i t e ! " o f s e c t i o n 14., 2 o f t h e Z o n i n g B y - l a w ? ( y / n ) Vt " ) , r e a d c h a r (X) , w r i t e (X) , n l , n l , c h e c k __a n s l (X) , w r i t e ! " W h a t i s t h e cl i s t a n c: e b e t w e e n t h e bar:: k o f t h e n e a r- e s t p r- i n c i p a 1 \ n " ) , w!- i. t e ! " b Li i 1 d :i. n g a n d t h i s b u :i. 1 d i n g 3. i n e , i n f t ? \ t " ) , r- e a d r e a l (Y) , n 3. , r- e a i-_y a r- d ( F e e t ) , X >= F e e t , ! :; s h i f t w :i. n d o w (1 ) , c: 1 e a r w i n d o w , z one...c 3. a s s ( 2one) , n 1 , w r i t e ! " The u s e p r o p o s e d d o e s n o t meet r e a r y a r d r e q u i r e r n e n t s f o r t h e \ n " ) , wr i t e ( " " , Zone , " S c h e d u l e „ Ther-ef o r e s " ) , n I , ! , f a x 1 „ c h e c k _ f sr- 4 s -- d i men s i on s ( , __,..., , L.ot A r e a , __., F l o o r - S p a c e , _, __) , f sr- ! R a t :i. o , _) , (F1 oar-Spac:e/!....ot A r e a ) < ™: R a t i o , I s. s h i f t w i n d o w ( i ) , c l e a r w i n cl o w , zone_c1 a s s ( Z o n e ) ,n1, w r i t e ( " 1"he u s e p r o p a s e c l f a i 1 s t o meet t h e - f l o o r s p a c e r a t i o\n " ) , w r i t e ! " r e q u i r e m e n t s f o r t h e " , Z o n e , " S c h e d u l e . T h e r e f o r e ; \ n " ) , ! , f a i l . c h e c k _ s i t e _ c o v e r a g e 1 s •-• d i mensi ons !_,__,__,_, L o t Ar• ea , f"'3. oar A r e a , _, , _) , s i t e _ c o v e r a g e ! P e r c e n 1 1 ) , F:'I o o r a r e a / L o t A r e a < ;= P e r - c e n 1 1 , w r i t e ! " What i s t h e s i z e , i n s q f t , o f t h e a r e a u s e d f o r p a r k i ng'?\t") , r e a d r e a l (X) , p a r k i n g __<:::average! P e r cen 12) , X /!....ot a r ea < ~ P e r cen 1 2 , n 1 , ! 5 s h i f t w :i. n dow ! 1) , c. 3. ear- w i nd ow , z a n e 3 . a s s ! Z a n e) , p r o p o s e d __u s e ! LJ s e) , n 3. , w r i t e ! " The u s e p r o p o s e d f a :i. 1 s t o meet s i t e c o v e r a g e r e q u i r e m e n t s \ n " ) , w r i t e ! " f o r t h e " , Zone, " S c h e d u l e . " ) , n 3. , ! , r e l a:: a t i on ! Zone , 5. 2 , Use) , n l , f a i 1 « check__ex t e r n a l _ d e s i gn 1 1; z ane__c3. a s s ! Zone) , e x t e r T o r ^ d e s i g n !HtWdthRat i o , Wi d t h 1 , S e t b a c k ,, Mi n F l o o r , MaxFI o o r 5 , w r i t e ! " W ri a t i s t h e h e i g h t a n d w i. d t h of t h e p r i n c :i. p a 3. f a a d e'? \ n " ) , w r i t e ! " (The p r i n c i p a l f a c a d e i s t h e b u i l d i n g f a c e s i t u a t e d X n " ) , w r i t e ! " c l o s e s t t o t h e f r o n t p r o p e r t y l i n e . " ) , n l ,n3. , c u r s o r (RI ,C1) , R2 = RI -- 1, C2 = CI + 3 0 , w r i t e ! " \ t l - l e i g h t s \ t " ) , r e a d r e a l (He:;, g h t ) , c u r s o r !R2 , C2) , w r i t e ! " VLWi d t h s \ t " ) , r e a d r e a l ! Wi d t h 2 ) , H e i g h t / W i d t h 2 <= H t W d t h R a t i o , W i d t h 2 < W i d t h ! , n 3. , w r i t e ! " I s t h e p r i n c i p a l a c c e s s t o t h e b u i l d i n g by means of a s t r a i g h t s t a i r c a s e \ n " ) , w r i t e ! " a t r i g h t a n g l e s t o t h e s t r e e t and l e a d i n g t o a f i r s t s t o r e y p o r c h o r open--\n") , w r i t e ! " s i ded v e r a n d a h ? \ t " ) , r e a d c h a r ! X ) , w r i t e ! X ) ,, n l , n l , c h e c k _ a n s l ! X ) , w r i t e ! " I s t h e r e o n l y one p r i n c i p a l e n t r a n c e and i s i t v i a \ n s i n g l e o r d o u b l e d o o r s ? \ t " ) , r e a d c h a r !Y) , w r i t e ! Y ) , n 1 , n l , check., an s i !Y) , w r i t e ! " E x c l u d i n g t h e p r i n c i p a l f a c a d e , how f a r b a c k , i n f e e t , i s t h e \ n " ) , w r i t e ! " c l o s e s t f a c a d e f r o m t h e f r o n t y a r c l ? \ t " ) , r e a d r e a l ( Z ! , Z >= S e t b a c k , n l , w r i t e ! " How h i g h above g r a d e i s t h e f l o o r of t h e f i r s t s t o r e y ? \ t " ) , r e a d r e a l ( H t ) , l-lt >= Mi n F l o o r , Ht < = MaxFI o o r , n l , w r i t e ! " A r e t h e f a c a d e s of t h e b u i l d i n g c o n s i s t e n t , i n t e r m s o f s t y l e , \ n " ) , w r i t e ! " f o r m of a r c h i t e c t u r e , and ex t e r i o r f i n i s h e s , w i t h t. h o s e r e s i den t i a 1 \ n " ) , w r i t e ! " b u i l d i n g s i n t h e ",Zone," D i s t r i c t l i s t e d i n t h e C i t y of V a n c o u v e r \ n " ) , w r i t e ! " H e r i t a g e I n v e n t o r y of A u g u s t , 1986? ! y / n ) \ t " ) , r e a d c h a r !U) , w r i t e ! U ) , n l , n l , c h e c k__aris 1!U) , w r i t e ! " A r e t h e wi ndows p r o p o s e d a1 so c o n s i s t e n t w i t h t h o s e r e s i d e n t i a I \ n " 5 , w r i t e ! " b u i l d i n g s i n t h e ",Zone," D i s t r i c t l i s t e d i n t h e C i t y o f \ n V a n c o u v e r H e r i t a g e I n v e n t o r y \ n " ) , w r i t e ! " of A u g u s t , 1986? ! y / n ) V t " ) , readchar- (W) , w r i t e !W) , n l , n l , c h e c k_ans 1 ! W) , w r i t e ! " A r e t h e r o o f s t y 3. e s pi r op o s e d e i t h e r g a b l e o r h i p •-• o n -- g ab 1 e ? ! y / n ) \ t " ) , r e a d c h a r ! V) , w r i t e ! V) , n 1 , n 1 , c: h e c k ._a n s 1 ! V) , w r i t e ! " A r e s h i n g l e s t h e r o o f m a t e r i a l t o be u s e d ? ! y / n ) \ t " ) , r eadchar!"!"), w r i t e (T) , n l , n l , c hec k _..ansl (T) , ! , c hec k _ex t e r n a I _d e s i g n A , ! ; s h :i. f t w i n d o w (1) , c 1 e a r w i n d o w , z one__c 3. a s s ( Z one) , n 1 , w r i t e ! " The p r o j e c t p r o p o s e d f a i l s t o meet e x t e r n a l d e s i g n r e q u i r e m e n t s . \ n " ) , w r i t e ! " T h e D i r e c t o r of !::' I a n n i n g may p e r m i t a d e v e 3. o p ment w h i c h v a r i e s \ n " ) , w r- i t e ( " f r o m t h e ex t a r n a l d e s i g n c h a r a c t e r i s t i c: s of t h e " ,Zone, " S c: h e d u l e \ n " ) , wr i t e ( " p r o v i ded t h a t s \n \n " 5 , w r i t e ! " •- I t i s c o n s i s t e n t w i t h r e s i d e n t i a l b u i l d i n g s i n t h e X n " ) , wr i t e ! " " , Zone , " Di s t r i c t 1 i s t e d i n t h e C i t y o-f V a n c o u v e r \n " ) , w r i t e ! " H e r i t a g e I n v e n t o r y of A u g u s t , 1 9 8 6 \ n \ n " ) , w r i t e ! " A c o n s i s t e n t a r c h i t e c t u r a 1 s t y l e a n d f a r m i s a c h i e v e d \ n " ) , w r i t e ! " f o r e v e r y b u i l d i n g on t h e s i t e s a n d \ n \ n " ) , w r i t e ! " •- I t r e f 1 s e t s t h e c h a r a c t e r o f t h e s t r e e t s c a p e and i s \ n " ) , w r i t e ! " c o m p a t i b 1 e w i t h t h e d e s i g n o f b u i 1 d i n g s or') a d j o i n i n g s i t e s . \n") , n 1 , w r i t e ! " See more? ! y / n ) \ t " ) , r e a d c h a r ! A ) , w r i t e ! A) , c h e c k _ a n s 1 ! A ) , c I e a r w i n d o w , n I , w r i t e ! " The D i r - e c t o r o f PI a n n i n g may a I s o r e q u i r e t h e r e t e n t i o n X n " ) , w r i t e ! " of any one o r more of t h e f o l l o w i n g a r c h i t e c t u r a l \ n o r o r n a m e n t a l f e a t u r e s : \ n \ n " ) , w r i t e ! " \ t window, d o o r and r o o f d e c o r a t i o n ; \ n " ) , w r i t e ! " \ t - bay wi nclows; \n " ) , w r i t e ("Xt- t o w e r o r t u r r e t f e a t u r e s ; \ n " ) , wr i t e ( " \ t hand r a i I s , b a1 u s t e r s ; \ n " ) , wr i t e ! " X t - wood t r a c e r y or b a r g e b o a r d „ \n " ) , n 1 , w r i t e ! " SEE MORE? ( y / n ) X t " ) , r e a d c h a r (B) , w r i t e ( B ) , c h e c k _ a n s l ! B ) , c l e a r w i n d o w , ! , f a i l , c h e c k __e x t e r n a 1 ,_d e s i g n A s •-- s h i f t w i n d o w ! 1) , c l e a r w :i. n d o w , n 1 , w r i t e ! " The use meets e x t e r n a l d e s i g n r e q u i r e m e n t s , b u t s X n " ) , w r i t e ! " The D i r e c t o r of P l a n n i n g may s t i l l r e q u i r e t h e r e t e n t i o n \ n " ) , w r i t e ! " of any one o r more of t h e f o l l o w i n g X n a r c h i t e c t u r a l o r o r n a m e n t a l f e a t u r e s ; X n X n " ) , w r i t e ( " X t - window, d o o r and r o o f d e c o r a t i o n ; \ n " ! , w r i t e ! " \ t bay w i n d o w s ; X n " ) , w r i t e ! " X t - t o w e r o r t u r r e t f e a t u r e s ; \ n " ) , w r i t e ! " X t - hand r a i 1 s , b a l u s t e r s ; X n " ) , w r i t e ! " X t - wood t r a c e r y o r b a r g e b o a r d . X n " ) , n l . c h e c k_nurnber _ o f _taui 1 cl i n g s 1 s •- sh i f t wi ndow (1) , c l e a r w i nclow , n I ,zone__c 1 a s s ! Zone) , w r i t e ! " The D i r e c t o r of P l a n n i n g may p e r m i t more t h a n one p r i n c i p a l X n " ) , w r i t e ! " b u i l d i n g on s i t e p r o v i d e d t h e f o1 l o w i n g a r e f i r s t c o n s i d e r e d sXnXn " ) , w r i t e ! " - The i n t e n t of t h e ",Zone," s c h e d u l e and w e l l a s a n y X n " ) , w r i t e ! " a p p 1 i c a b 1 e p o 1 i c: i e s a n d g u i d e I i n e s; X n " ) , w r i t e ! " •- The h e i g h t , b u l k , l o c a t i o n , and o v e r a l l d e s i g n o f t h e X n " ) , w r i t e ! " p r o p o s a l ancl t h e i r a f f e c t on t h e s i t e , s u r r oun d i ng Xn " ) , wr i t e ! " b u i 1 d i ngs , s t r e e t s , anc! e:•: i s t i ng v i e w s ; \n" ) , w r i t e ! " The amount of open s p a c e and t h e e f f e c t of t h e p r o p o s a l X n " ) , w r i t e ! " on t h e g e n e r a l a m e n i t i e s ; of t h e a r e a , a n d j X n " ) , wr i t e ! " •- The p r e s e r v a t i on of a r c h i t e c t u r a 1 c h a r a c t e r and t.heXn " ) , wr i t e ! " g e n e r a 1 ament i e s d e s i r e d f o r t h e a r e a . " ) ,nI , n1 , w r i t e ! " DO YOU WANT TO CARRY ON WITH THE EVALUATION? ! y / n ) ? X t " ) , r e a d c h a r ! X ) , wr i t e ! X ) , n 1 , c hi ec: k _an s 2 ! X ) , ! , c 1 e a r w i n d o w , f a i 1 „ c: hi a c k _n u mbe r _o f _ _b u i I cl i n g s 1 s s h i f t w i n cl o w ! 2) , z o n e __c I a s s ! Z o ne) , w r i t e ! " Do any of t h e b u i l d i n g s p r o p o s e d r e q u i r e a r e l a x a t i o n of t h e X n " ) , w r i t e ! " r ear- y a r cl r e q u i r erne n t a s s p e c i f i e cl i n s e c t i o n 4 6 of t h e N n " ) , wr i t e ( " ",Zone," s c h e d u l e ? ! y / n ) X t " ) , r e a d c h a r ! X) , wr i t e ! X ) ,n1 , n1 , c h e c k_ans2 ! X) , !; wr• i t e < " A r e t h e b u i 1 cl i ngs wh i c:h i n t r u d e i n t o t h e r e a r y a r c l h :i. g h e r t h a n 25 •feetAn") , w r i t e ! " o r 1 1/2 s t o r e y s ' ? ( y / n ) \ t " ) , r e a d c h a r (Y) , wr i t e (Y) , n I , n 1 , c hec: k __an s 2 < Y) , i s h i f t wi nclow C1) , c: l e a r w i nd a w , f a i 1 „ g e t _ r e l a;-; a t i on (5.4,8) s - ! ., get__r e l a:-; a t i on (5.3,10) - ! . /* RELAXMS„PRO */ % % RE'LAXNS.PRO c o n t a i n s a l i s t o f s p e c i f i c z o n i n g r e l a x a t i o n s w h i c h may be a l l o w e d by t h e D i r e c t o r of P l a n n i n g % f o r a g i v e n u s e / s i t e c o m b i n a t i o n . I f t h e u s e / s i t e combo f a i l s a z o n i n g r e g u l a t i o n where a r e l a x a t i o n may be % a l l o w e d and t h e u s e and z o n e i n q u e s t i o n match t h e c o r r e s p o n d i n g r e l a x a t i o n , , t h a t r e l a x a t i o n i s i n c l u d e d i n % o u t p u t t h a t EUCLID p r o v i d e s t o u s e r upon c o m p l e t i o n of t h e z o n i n g e v a l u a t i o n . % p r o j e c t "EUCLID" i n c 1 u d e " c ;\\p r og r a m s \ \ t p r o 1 o g \ \ g I o b a1s„pro'' c I a u s e s r e l a x a t i o n ! "RT-6" ,5.1, 11) s z o n e j i l a s s (Zone) , n l , wr i t e < " I f t h e 1 o t i n q u e s t i on was o n recor-d i n 11")e L a nd T i t l e O f f i c e f o r \n " ) , w r i t e !" V a n c o u v e r p r i o r t o A u g u s t 10, 1976 t h e D i r e c t o r o f P l a n n i n g m ay\n"), w r i t e ( " r e l a x t h e minimum s i t e a r e a p r o v i s i o n s a s d e f i n e d i n s e c t i o n 4 „ l \ n " ) , w r i t e ! " of t h e ",Zone," S c h e d u l e . \ n " ) . r e l a x a t i o n ( " R T - 6 " , 5 . 1 , 1 2 ) s- r e l a x a t i o n ( " R T - 6 " , 5 . 1 , 1 1 ) . r e 3. a x a t i on ( "RT-6" , 5. 2 , 1) s - n l , w r i t e ! " The D i r e c t o r of P l a n n i n g may r e l a x t h e a r e a and s i t e c o v e r a g e x n ") , w r i t e ! " 1 i m i t a t i ons f o r ac c e s s o r y b u i 1 d i n g s an d s e c t i o n s 4.7 an d 4.9 o f \ n " ) , wi- i t e ! " t h e P a r k i ng B y - l a w where he i s s a t :i. s f i ed t h a t a d e q u a t e of f s t r e e t \n " ) , w r i t e ! " p a r k i n g c a n n o t o t h e r w i s e be a c c o m o d a t e d , p r o v i d e d t h a t i n \ n " ) , w r i t e ! " d e v e 1 o p me n t s w h e r e a c a r p o r t o r g a r a g e i s p 3. a n n e d h e a I s o h a s \ n " ) , w r i t e ! " r e g a r d t o t h e e f f e c t cJn n e i ghbour i ng s i t e s of b u i 3. d i ng h e i g h t , \n " ) , w r i t e ( " s h a d o w , o p e n s p a c e a n d l a n d s c a p i n g , , " ) . r e l a x a t i o n ! "RT-6" ,5. 3, 10) s - z a n e . _ c l a s s (Zone) , n l , wr i t e ( " The D i r ec t o r of P1 ann i. ng may r e 1 ax t h e s i de y a r d and / o r r e a r y a r d\n '') w r i t e ! " p r o v i s i o n s of s e c t i o n s 4.5 and 4.6 of t h e ",Zone," S c h e d u l e i n \ n " ) , w r i t e ! " t h e c a s e of m u l t i p l e d w e l l i n g s , p r o v i d e d t h a t he f i r s t c o n s i d e r s \ n " ) , w r i t e ! " a l l a p p l i c a b l e p o l i c i e s and g u i d e l i n e s a d o p t e d by C o u n c i l . " ) . r e l ax a t i on ! " RT-6 " , 5 „ 4 , S) : - z one__c 1 a s s ( Zone) , n 1 , w r i t e ! " SEE MORE? ! y / n ) s \ t " ) , r e a d c h a r ( X ) , wr i t e ! X ) , c h e c k _ _ a n s l ! X ) , n l , c l e a r w i ndow , n w r i t e ! " The Di r e c t o r of P1 ann i ng may r e l a x t h e si.de y a r d a n d / o r r ear- y a r d \n " ) , w r i t e ! " p r o v i s i o n s of s a c t i ons 4.5 and 4.6 of t h e ",Zone," S c h e d u 1 e i n t h e \ n " ) , w r i t e ! " c a s e of i nf i 13. and t h e p 1 acement of more t h a n one p r i nc i pa 1 \n " ) , w r i t e ! " b u i l d i n g on t h e s i t e , p r o v i ded t h a t he f i r s t c o n s i d e r s s\n\n") , wr i t e ( " •- A l l app 1 i cab I e po 1 i «:: i e s and g u i d e l i n e s adop t e d by Counc i 1 p \n " ) , w r i t e ! " - The h e i g h t , b u l k , l o c a t i o n , and o v e r a l l d e s i g n of t h e N n " ) , w r i t e ! " b u. i 3. d i n g s a n d t h e i r e f f e c t o n t h e s i t e , s u r r o u n ci i n g b u i 1 d i n g s , \ n " ) , w r i t e ! " s t r e e t s and e x i s t i n g v i e w s ; ; \ n " ) , w r i t e ! " - The amount of open s p a c e and t h e e f f e c t of o v e r a l l d e s i g n o n \ n " ) , w r i t e ! " t h e g e n e r a l a m e n i t y of t h e a r e a ; a n d , \ n " ) , w r i t e ! " - The p r e s e r v a t i o n of t h e c h a r a c t e r and g e n e r a l a m e n i t y d e s i r e d X n " ) , wr i t e ( " f o r t h a t a r e a . \ n \ n " ) , w r i t e ! " SEE MORE? <y/n);;\t") , r e a d c h a r !Y! , w r i t e (Y) , chec: k _ a n s l ! Y) , n l , c l e a r wi ndow , n l wr i t e ! " T h e r e f o r e , A t P r e s e n t s")„ l a : : a t i o n ( "RT 5N" , X , Y) s - r e l a x a t i o n ! "RT-5" , X , Y) . l a x a t i o n ! "RT 5" ,5„ 1 , 11 ) s -- r e l a x a t i o n ! "RT-6" , 5 . 1 , 1 1 ) . 1 ax a t i on!"RT-5",5.1,12) s- r e1 ax ation!"RT-6",5„1,12)„ l a x a t i o n ! "RT 5",5. 2,1) ; n l , w r i t e ! " The D e v e l o p m e n t P e r m i t B o a r d o r The D i r e c t o r o-f P l a n n i n g , a s t heNn") w r i t e ! " c a s e may b e , may r e l a x t h e a r e a and s i t e c o v e r a g e l i m i t a t i o n s f o r N n " ) , w r i t e ! " a c c e s s o r y b u i l d i n g s and s e c t i o n s 4.7 and 4.9 of t h e P a r k i n g By-lawNn") w r i t e ! " where he i s s a t i s f i e d t h a t a d e q u a t e o f f - s t r e e t p a r k i n g c a n n o t N n " ) , w r i t e ! " o t h e r w i s e be a c c o m o d a t e d , p r o v i d e d t h a t i n d e v e l o p m e n t s where a N n " ) , w r i t e ! " c a r p o r t o r g a r a g e i s p l a n n e d he a l s o h a s r e g a r d t o t h e e f f e c t o n N n " ) , w r i t e ! " n e i g h b o u r i n g s i t e s of b u i l d i n g h e i g h t , shadow, open s p a c e andxn l a n d s c a p i n g 1 ax a t i on!"RT-5",5.2,26) s- r e l ax a t i on!"RT 5 " , 5 . 2 , 1 ) . •I ax a t i on ! "RT-5" , 5 „ 3 , 10) s zone_j:::l a s s ! Zone) , n l , w r i t e ! " The D i r e c t o r of P l a n n i n g may r e l a x t h e s i d e y a r d and / o r rear- y a r d N n " ) , w r i t e ! " p r o v i s i o n s of s e c t i o n s 4.5 and 4.6 of t h e " , Z o n e , " S c h e d u l e i n t h e N n " ) , wr i t e ! " c a s e of mu 11 i p i e ci we 11 i n g s , p r ov i c! ed t h a t s N n N n " ) , wr i t e ! " - He f i r s t ' c o n s i d e r s a 11 app 1 i c:ab 1 e po 1 i c i e s and g u i de 1 i nesNn " ) , w r i t e ! " a d o p t ed b y Coun c i 1 , an d \ n " ) , w r i t e ! " No f e w e r t h a t 50 p e r c e n t of t h e d w e l l i n g u n i t s w i t h i n a n y N n " ) , w r i t e ! " b u i 1 d i ng c:ontain two o r more b e d r ooms e x c e p t i n t h e c a s e of Nn " ) , wr i t e ! " a b u i I d i n g d e s i g n e d s o 1 e 1 y f o r sen i o r c i t i z e n h o u s i n g o r o t h e r N n " ) , w r i t e ! " s i m i l a r u s e . " ) . •lax a t i o n ! "RT-5" ,5„ 4,8) : - z o n e _ c l a s s ( Z o n e ) , n l , w r i t e ! " The D e v e l o p m e n t P e r m i t B o a r d o r t h e D i r e c t a r of P 1 a n n i n g , a s t heNn") , w r i t e ! " c a s e may b e , may r e l a x t h e s i d e y a r d a n d / o r r e a r y a r d p r o v i s i o n s N n " ) , w r i t e ! " o f s e c t i o n s 4.5 and 4.6 of t h e ",Zone," S c h e d u l e i n t h e c a s e o f N n " ) , w r i t e ! " i n f i l l and t h e p l a c e m e n t of more t h a n one p r i n c i p a l b u i l d i n g o n N n " ) , w r i t e ! " t h e s i t e , p r o v i d e d t h a t he f i r s t c o n s i d e r s a l l a p p l i c a b l e p o l i c i e s N n " ) , w r i t e ! " and g u i d e l i n e s a d o p t e d by C o u n c i l . And t h a t he f i r s t , has r e g a r d t o N n " ) , w r i t e ! " a p p l i c a b l e g u i d e l i n e s o r p o l i c i e s w h i c h C i t y C o u n c i l may f r o m t i m e N n " ) , w r i t e ! " t o t i m e d e t e r m i n e , , " ) . l a x a t i o n ! " R T - 5 " , 5 . 5 , 1 2 ) s - z o n e _ c l a s s ( Z o n e ) , n l , w r i t e ! " The D i r e c t o r of P l a n n i n g may r e l a x t h e f l o o r s p a c e p r o v i s i o n s of N i l " ) , w r i t e ! " s e c t i o n 4.7.1 of t h e " , Z o n e , " S c h e d u l e i n t h e c a s e of one f a m i l y N n " ) , w r i t e ! " and two f a m i l y d w e l l i n g s where he i s s a t i s f i e d t h a t t h e i r - d e s i g n N n " ) , w r i t e ! " r e f l e c t s t h e c h a r a c t e r of t h e a t r e e t s c a p e and i s c o m p a t i b l e w i t h N n " ) , w r i t e ! " t h e d e s i g n a n d s i t i n g o f b u i 1 cl i n g s o n a d j o i n i n g s i t e s , p r o v i d e cl N n " ) , w r i t e ! " t h a t : NnNn") , w r i t e ! " -- H e f i r s t c o n s i cl e r s a 11 a p p 1 i c: a b l e p o 1 i c i e s and g u i d e 1 i n e s N n " ) , w r i t e t " a d o p t e d by C o u n c i l , and t h e s u b m i s s i o n of any a d v i s o r y g r o u p , \ n " ) , ^ w r i t e (" p r o p e r t y owner o r t e n n a n t , and; \n") , ~~' w r i t e ! " The - f l o o r s p a c e r a t i o d o e s n o t e x c e e d 0. 75..\n\n") , w r i t e ( " SEE MORE? ( y / n ) s \ t " ) , r e a d c h a r ! X) , w r i t e ( X ) , c h e c k _ a n s 1 ( X ) , n 1 , c I e a r w i n d ow,n1, w r i t e ! " T h e r e - f o r e , At P r e s e n t s " ) . • r e l a x a t i o n ( "RT--4M" , X ,Y) s -• r e l a x a t i on ( "RT-4" , X , Y) „ ^ r e l a x a t i o n ("RT-4" ,5„ 1 ,11) s - r e l a x a t i o n ("RT--6" ,5.1, 11) „ relaxation("RT-4",5„1,12) s- relaxation("RT-6",5„1,12)„ ^ r e l ax a t i on ( " RT-4 " ,5„ 2, 1) s •- r e l ax a t i on ( " RT--5 " , 5. 2 , 1) „ r e l a x a t i o n ( "RT-4" ,5„ 2,26) s -- r e l a x a t i on ( "RT-5" ,5„ 2 , 1) ., ^ r e l a x a t i on ( "RT-4" ,5.4,8) s -- zone__cl a s s ( Zone) , n l , w r i t e ! " In o r d e r t o ma i n t a i n t he c h a r a c t e r o f t h e ne i g h b o u r h oo d i n c1ud i n g\n " ) , ^ w r i t e ! " where p o s s i b l e t h e r e t e n t i o n o f e x i s t i n g b u i l d i n g s , t h e D i r e c t o r \ n " ) , w w r i t e ! " of P l a n n i n g o r t h e D e v e l o p m e n t P e r m i t B o a r d , a s t h e c a s e may b e , \ n " ) , w r i t e ! " may r e l a x t h e s i d e y a r d a n d / o r r e a r y a r d p r o v i s i o n s of s e c t i o n s \ n " 5 , w r i t e ! " 4.5 and 4„6 of t h e ",Zone," S c h e d u l e i n t h e c a s e of i n f i 1 1 , \ n " ) , • w r i t e ! " p r o v i ded t h a t he f i r s t c o n s i d e r s a l l app 1 i c a b 1 e p a l i c i e s and\n") , w r i t e ! " g u i d e l i n e s a d o p t e d by C o u n c i l . " ) . r e l ax a t i on ! " RT--2" , 5 „ 1. , 12 5 s - - n l , w r i t e ! " The D i r e c t o r of P l a n n i n g may r e l a x t h e minimum s i t e a r e a \ n " 5 , w r i t e ! " r e q u i r e m e n t s of s e c t i o n 4.1 w i t h r e s p e c t t o two f a m i l y d w e l 1 i n g s \ n " ) , w r i t e ! " p r o v i d e d t h e l o t was on r e c o r d i n t h e Land T i t l e O f f i c e f o r \ n " > , • w r i t e ! " V a n c o u v e r p r i o r t o S e p t e m b e r 7 t h , 1 9 6 5 . " ) . /# GLOBALS„PRO */ /# GLOBAL DECLARATI ONS #/ / # «•# •» # # K- * * * -si- * •» •& * * * * * -if # # # # «• * •»• # -ft- * * ->i- -i<- # # * / % % T h e c o n t e n t s o f G L 0 B A L S . P R O cl e f :i. n e cl o m a i n s , p r e d i c a t e s , and d a t a b a s e s w h i c h a r e t o be s h a r ed by a 1 1 t h e % m o d u l e s o f t h e EUCLID program,, T h a t i s t h e y a r e g l o b a l r a t h e r t h a n l o c a l ( t o t h a t module) i n s c o p e . % % T h e s e g l o b a l d o m a i n s h a v e been s p e c i f i e d t o make t h e p r o g r a m e a s i e r t o r e a d and t o d i f f e n t i a t e b e t ween t h e % d i f f e r e n t p i e c e s of i n f o r m a t i o n s u p p l i e d by t h e u s e r and c o n t a i n e d w i t h i n t h e d a t a b a s e s . % % ' u s e s l i s t = i n t e g e r * ' - means t h a t t h e domain u s e s l i s t i s made up of a l i s t o f i n t e g e r s , , T h i s l i s t d e f i n e s % w h i c h u s e s a r e a l l o w e d i n ea c h z o n e . % % ' u p a c ' -- means ' LI n i t s P e r A C r e ' a n cl d e f i n e s t h e dens i t y a 11 o w e d f o r d w e l l i n g u n i t s a s a r e a 1 n u m b e r „ % g1ob a1 d o m a i n s u s e s 1 i s t ::::: i n t e g e r * z o n e , w i n do w s, r o o f = s t r i n g s q f t , f e e t , s t o r e y s , r a t i o , p e r c e n t , upat:, h e i gh t _ _ w i d t h _ r a t :i. o , wi d t h , mi n _ f 3. o o r , max _ f 1 o o r = r e a l h e i g h t , m a x j i e i g h t , s e t b a c k_f t , area__per c e n t , a r e a _ _ s q f t , d e c i b e l s , a n s r e a l f r o n t , l e f t , r e a r , r i g h t , l o t a r e a , - f l o o r - a r e a , f 1 o o r s p a c e , f r o n t d e p t h , r e a r d e p t h = r e a 1 numb e r , u s e , ac c _ r o o f = i n t e g e r /**###**#*******##**##*******####**#*##/ /•:t GLOBAL PREDICATES */ / * •*• * * # # # * -S- # * -H- * * « * * * S * • » # # * # -H- * * * * * « i'c * * # # # / % B e l o w a r e 1 i s t e d t h e p r e d i c a t e s whi ch are s h a r e d by a l l moduI e s of t h e EUCL. ID p r o g r a m . % % N o t e t h a t p r e d i c a t e s w h i c h t a k e one o r more a r g u m e n t s ( t h e t e r m s between b r a c k e t s ) a l s o h a v e t o h a v e t h e i r % i n p u t / o u t p u t p a r a m e t e r s -•• e„g„ (:L,o) ( o , i ) - s p e c i f i e d . % % The key w o r d ' n o n d e t e r m ' b e f o r e a p r e d i c a t e i n d i c a t e s a p r e d i c a t e w h i c h h a s more t h a n one p o s s i b l e s o l u t i o n o r % whi ch may l e a d t o b a c k t r a c k i n g . S i n c e g1oba1 p r e d i c a t e s a r e by d e f a u l t d e t e r m i n i s t i c ( i . e . t h e y l e a d t o one % and o n l y one s o l u t i o n ) a n o n d e t e r m i n i s t i c g l o b a l p r e d i c a t e p r o d u c e s an e r r o r message. P l a c i n g ' n o n d e t e r m ' i n % f!'-ont o f t h e p r e d i c a t e p r e v e n t s t h e message and f o r c e s T u r b o P r o 1 og t o hand 1 e i t c o r r e c 1 1 y. % % The f o 1 l o w i ng p i r e d i c a t s s f or• m t h e ana 1 y t i ca3. c o r e o f t h e EUCL. ID system,. The p r i nc i pa 1 g 1 oba 1 p r e d i c a t e s a r e s % % c h e c k _u s e (z o n e , u s e) % c h e c k _p u t r i g h t __a p p (z o n e , i n t e g e r ) % check__cond i t i o n a 1 _app (one , i n t e g e r ) % e h e c k _ r e g s ( z o n e , i n t e g e r ) % ;:: h e c k _r e s t o f __r e g s (z o n e) g 1 o ta a 1 p r e d i c a t e s n o n d e t e r m c: h e c k __u s e ( 2 o n e , u s e) - (:i. , :i. ) c: h e c k __a n s 1 (c: h a r ) - ( i ) chec::k...ans2 (char-) ( i ) check._ans3 ( c h a r ) - ( i ) c h e c k __o u t r i g h t __a p p ( z o n s , i n t e g e r - ) --• ( i , i ) (o , o) ( i , •) (a , i ) c h e c k _ c 0 n d i t i o n a 1 _ a p p (z o n e , i n t e g e r-) - ( i , i ) (o , o) ( i , o) (o , i ) n o n d e t e r m chec:k_r-egs ( z o n e , i n t e g e r ) -- ( i , i ) ( 0 , 0 ) ( i , o ) ( o , i ) n o n d e t e r m c h e c k _ r e s t _ _ o f __regs ( z o n e ) ( i ) ' n o n d e t e r- m r • e .1 a ;•; a t i o n (z o n e , r e a l , i n t e g e r ) - ( i , i , i ) (o , o , o) ( i , o , a) g e t _ r e 1 a ;•; a t i o n ( r e a 3. , i n t e g e r ) •- ( i , i ) (o , o) ( i , o) (o , i ) % The p r e d i c a t e s b e l o w a r e u s e d t o d e s c r i b e t h e r e g u l a t i o n s w h i c h a p p l y -for e a c h z o n e r e g a r d l e s s % of t h e u s e p r o p o s e d ,, They a r e a c c e s s e d v i a ' c h e c k _ r e s t _ _ o f __regs (z one) ' and a r e u s e d t o t e s t % wheth e r o r n o t t he s i t e / u s e c omb i n a t i on p r o p o s e d i s p e r m i t t e d i n t h e z o n e i n q u e s t i o n , % c h e c k _ h e i g h t 1 c h e c k _ h e i g h t 2 chec:k__he:i.ght3 c hec k _ _h e i g h 14 c h e c k __f r o n t __y a r d 1 c h e c k _ f r o n t _y a r d 2 c h e c k _ f r o n t __y a r d 3 e h e c k _ s i d e __y a r d s 1 c h e c k __r e a r _y a r d 1 c h e c k _ r e a r _ y a r d 2 check_;fsr-4 c h e c |< __s i t e __c o v e r a g e ! c !i e (.: _..e ;< t e r- n a 1 __c:i e s i g n 1 chec:k_e>: terna3. _ d e s i gnA c h e c: k _n u m b e r • __o -f _b u i 1 d i n g s 1 /•* CONSTANTS */ % % The c o n s t a n t s s e c t i o n a l l o w s ; s p e c i a l t e r m s t o be d e f i n e d f o r u s e by a l l t h e m o d u l e s of EUCLID,. In t h i s % c a s e ' f t _j::s e r ..._a e r e ' i s d e f :i. n e d a s h a v i n g t h e v a l u e 43560 a n cl i s a c o n v e r s i o n f a c t o r f or- c: a 1 c: u 1 a t i n g % cl w e 11 i n g u n i t cl e n s i t i e s „ % c o n s t a n t s f t _ _ p e r _ a c r e =: 43560 (q a a 4. a i. •;]. v? -.J) p -j B A " vi u o • j :;~ ( s A a • J o q. s 6 s A a o q. s ' q. a a •}•) q. q (s A a o 4 s 1 4 a a j . ) 4 q 5 x. a q ( q.3 3 4. ) 3 B B 4 U Q -J •}• KBUJ < q. j . b s ' 4 ; j -bs} T P 3 . j B~~a 4 1: s ~ u tUJ ( 4 4- bs1?a . . ,1 x?/ a 4 Ts~~u t UJ ( 4 s x x s a s vi 5 s a s n ~ p a 4 4 1: UJ -.J a d ( a u o z ) s s e '[ a"""auo z o•}• u 1.6 u x u o z a s ; B q B q . B p [x?qo' i ;& % • o ^ u t B u i u o z o q u t p a p B o x p u e a ^ e D t p s j d , a s e q e ^ p p 4 3 6 , % B U T Aq p 3 5 S 3 D D s ? a j E q r j i q M s e f i j - s s e q e + s p LIT p s j o ^ s a-je s o a d s B u x u o z a q j . . "paqsaq s i j a s n BL|:|. Aq % it X d d n s u 0 T 4 e u u . j 0 j . U T qox . qw ^ S U I E S B p u p ma 4 is As aqq u x. s u o 1 4 B O I 4. p a d s Buxuoz s a - j o ^ s a s B q e ^ e p o : ( . u t 6 u t u o z a q j _ % % /*#*##**#*#####ft-***##*#*###* ft* ##** * ###*/ /* dsyayiya s a inaams ONINOZ */ /#**#*###*#**##****#•»•###•»#*##*#####****/ ( q q d a p j e a - j * q q . d 3 p q u o . j 4 . ' aoeds-joo x j - ' e a j e j o o x j - ' s a j e ^ o i ' q . q 6 T . j ' JBBJ ' ^ i - s - I * q.uo.J4-) s u o x s u a i t i i:p s 1 j o T s u 3 UJ T p ... 3 s B q B q B p x e 0 1 & % , s u D | ' i e , [ n 6 a . j BUT. u o z aqq s e x i £ 5 M - s p X' e Ao.jdde x e u o TI- Tpuoa p u s qqBx. .jq.no J O J- q.s;aq q a x q M s a q e o i p e - j d % aqq. Aq a s n -JO± q. x. s a - j o q s p u e „ s u o i s u a u . ' T p"~ qaB, Aq p a-jsqqeB u o r i B i i i J o j - u t aq. xs /qox aqq sa;]e : i a s B q B q B p s x q x % % / ft ft ft * ft ft ft ft- -X- ft ft ft ft ft ft ft * ft- ft- ft- ft ft * ft ft- ft ft- -Si- ft ft ft ft ft ft ft- ft ft ft- / /# a s y a y i y a SNOISNBWIU i c n #/ / * * * # •»«•* ft «•» * * * * # * * * * * •» •» * ft •» * •>• / ( xB a • J ) 4 q B y. a u~~ -J a M S U © < X B a ..J ) s A a - J O 4 s"~ s u B ( j e q a ) a s w q ~ 5 u e . J F L | O ) x 1 a:)-"sLl© < XB3 . . J ) q .q" " S U B ( S U B ) s a p i s (-..-! B i..| o 1 . j B q 0 ) ::i a B ..J q .~ s u B (a s r 1 > a s n"~ p a s o d o • J d aBeJo : i.s - a si- B q e 4 B p - [ B q o x & % - u o T s s a s aqq u 1: s i u m d qus - jaj-;}- TP 4B a auo u B q 4 a-jouj u o x 4 B U J . J O ;}-U 1: au.JBs; a q 4 - 1 0 1 % pa>jS;B aq 0 4 a AS? q ' S S S B O aujos u i ' p x n o M - j a s n a q 4 a s B q s ^ B p s x u 4 4x1044 x^ "s^aq.Ba xpa-jd j a q ^ o Aq uo -JS^.B Y a s m % •JO 4. qn dux -jasri 4.0 s a o a x d u XB 4 . J 3 0 s s a j o ^ s pue s s s o d j n d xysu-ja^u x ,,104- Axa-Jnd p a s n s x a s s q B 4 B p aBe-Jo^s a q j % % /* saaMswy :awos QNiyois tio-i asyayiya */ / # # • » * * • » * « • » * # * * • « » f t * * « • * # * * • » -w- * ft • » * • » / f r o n t _ y d ( f e e t ) s i d e _ y a r d s ( r a t i o , f e e t ) s i d e _ _ y d s ( f e e t ) r e a r _ y a r d ( f e e t ) f s r ( r a t i. o , r a t i o) s i t e __c o v e r a g e (p e r c e n t ) s i t e _ c o v ( p e r c e n t , p e r c e n 1 5 p a r k :i. n g __c o v e r a g e (p e r c e n t ) ti w e l l i n g _un i t __d en s i t y 1 (up ac ) d w e 1 1 i n g __u n i t _d e n s i t y 2 (u p a c ) number-__pf _ b u i 1 d i n g s (number ) n o i s e _ l e v e l ( d e c i b e l s , d e c i b e l s , d e c i b e l s , d e c i b e l s ) e ;•; t e r i a r _d e s i g n ( h e i g h t __w i d t h __r a t i o , w i ci t. h , s e t b a c k _ f t , m i n __f I o o r , m a __f l a a r ) ac:c: e s s a r y_b u i 1 ci i n g s (h e i gh t , ma;•; _ h e i g h t , s e t bac k f t , area__per c e n t , a r e a _ s q f t , r a t i o) 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0098511/manifest

Comment

Related Items