3D Evacuation Plan and Visualization for King Abdulaziz University

King Abdulaziz University (KAU) is one of the largest and most prestigious universities in the Middle East that seeks to recruit new developments and technologies to improve operations that help controlling facilities and services in the campus. In recent years, GIS has been improved in capturing, manipulating, analyzing, managing, and visualizing spatial data in 3D forms. KAU authorities and decision-makers decided to benefit from these advances especially from its 3D uses. In this project, the project team built and manipulated two different databases for the two parts of the project: 3D modeling and 3D interactive indoor evacuation plan. The first database was built to store all the spatial data and visualize it in a 3D model. The KAU model was prepared to be published to the public as a web scene to facilitate storing and sharing the spatial data with better visualization capability. In addition, due to the lack of the safety standards at KAU, a second database was built to develop an interactive indoor evacuation plan that has been customized for the King Abdulaziz University Hospital building. The evacuation plan supports both handicapped and non-handicapped modes.


Chapter 1 -Introduction
One idea to help manage a large campus that hosts a large number of students and employees is to create a conceptual model for an existing campus. Such model would simulate reality and be used in managing and maintaining old structures and in reaching the goals behind proposed new constructions on campus. In this project, the client needed a 3D model in order to have better observation and management of King Abdulaziz University (KAU) as well as to use spatial analysis for addressing the university's concerns. One of these spatial analyses is for raising the safety standards in KAU buildings that host a large number of university employees, attendee and visitors.
Precisely, focusing on the King Abdulaziz University Hospital (KAUH), the largest building at KAU, the safety standards would be raised by creating an indoor evacuation plan.
KAU was founded in 1967 as a private university on the west coast of Saudi Arabia, in Jeddah (figure 1-1). In 1974, KAU became a public university by command from the king at that time (King Abdulaziz University, Our History, 2010). Since then, the university has sought to build facilities and provide the best service centers to its attendees. Over the last twenty years, the university grew rapidly and the number of students and employees increased. The fast growth is now forcing the university to build more facilities and service centers to serve its students, with consideration of the old structures and projects. In order to control the growth of this huge campus, the client needed a model that would simulate reality. In addition, the university data had been to be used to support new analytical projects such as determining the strengths and weaknesses of buildings and creating safety plans.

Problem Statement
In a large area such as the KAU campus, with much existing information and data, it is hard for developers and decision-makers to get an overview of all facilities and structures and their geographic locations in a single map especially when the data are in many different formats such as blueprint, AutoCAD data, GIS data, tables, and other hard-copy and digital data. Therefore, the VPP wanted a 3D model that contains all the university data to simulate reality.
Furthermore, the KAU campus has many very large buildings, such as the KAUH building, that host many people but don't meet the required safety standards including emergency evacuation plans. The VPP sought to meet the safety standards by creating an interactive system that could help the Disaster and Emergency Center and the General Administration of Security Services in case of an emergency so that staff can locate damaged places inside buildings and establish an evacuation plan.

Proposed Solution
The proposed solution to help KAU authorities and decision-makers was to create a model that would simulate the real word and include both hard-copy and digital spatial data.

Goals and Objectives
There are two major goals in the project. The first goal was to create an ideal comprehensive 3D model. This model would contain all the spatial information and data the VPP has, whether it's raster maps, digital data, hard-copy data, or the buildings' exterior architectural styles and models. All of the data will be assigned to a unified coordinate system. The 3D model would serve all the VPP employees from different departments easily by sharing the 3D proposed model to a web application and authorizing the VPP employees to use it. This web application would allow users to express their opinions and offer suggestions by leaving comments on the model web scene. These comments could be seen by all the web scene users.
The second goal of this project was to raise the safety standards for the KAU campus, especially for buildings that have many visitors such the KAUH building. This system would include a tool. This tool will show the best shortest path that would lead anyone in an affected building to the closest exit or the closest assembly point for people with disabilities while avoiding the affected areas. VPP and KAU authorities are willing to extend the evacuation plan tool to all KAU buildings in the future.

Scope
There were two proposed solutions in this project: 3D model for KAU, Evacuation plan for KAUH. The first proposed solution was focused on searching for a suitable environment for creating a 3D model for the KAU campus area. This model should include all the spatial data and information that related to the objects in the study area.
All the objects in the study area should represent the object in 3D visualization. The campus area has more than 400 structures and buildings and each building has many information ( Figure 1-2), and they were one of the data that need to be included in the 3D visualization. This environment should interact with different data formats by taking the 2D vector data such as building footprints, centerline streets geometry, green area and trees data, and imagery and prepare it for creating a smart 3D model.

Figure 1-2: The KAU Target Area with Existing Buildings
As for the evacuation plan, the tool should meet the client requirements. For the KAUH building, the most suitable environment would be provided for this tool and especially a geometric network. The geometric network will connect all KAUH rooms to the halls, and all the halls will lead to the exits and assembly points. This tool needed to be flexible so the client could extend it to all KAU buildings in the future.

Methods
Esri CityEngine is a suitable environment to create the 3D model, in which it can interact with diverse types of data formats such as DAE, DXF, GDB, KML, KMZ, OBJ, OSM, and SHP to facilitate transferring the created model into different types of software. Also, CityEngine provides a correlative attributes table for the geometries. In order to create the 3D model for KAU, all available information was needed: vector and raster data, hardcopy data, and external architecture. As a preliminary step, all this data should be prepared in one of the CityEngine accepted formats to be included in the 3D model.
CityEngine will use all this data with attribute tables that contain much useful information, such building names and numbers, and most importantly, the z-value which represents the third dimension of the 3D model. After that came choosing the right Computer Generated Architectures (CGA) rule, which would extract the 2D campus data based on z values, and be consistent with the architectural texture of the buildings in the study area. CityEngine interacts with taking 2D GIS data and uses its attributes with rules to create 3D models. This approach is known as procedural modeling. Some structures can not be represented correctly using CGA rules because of its unavailability such as KAU stadium. Therefore, SketchUp software was used to model the stadium and represented on KAU 3D model. Figure 1-3 illustrates how CityEngine deals with the data, attribute tables, and CGA rules package to build a 3D model.

Figure 1-3: 3D Creation Methodology in CityEngine
Working inside the KAUH building and searching for the proper and easy way to move inside the building, the suitable environment will be needed for creating a network dataset. The network dataset must be made in a way that all the halls connect all the KAUH rooms to the exits and to the assembly point without any duplication or overlap.
The halls in each floor will be drawn in the network as layers on top of each other.
Therefore, every geometry has to be attached with attributes that contain z values and the geometry's height from the ground floor. ArcGIS is used to connect all floors with different types of z values, and then the network will be complete and ready to use.
The proposed evacuation tool contains six parameters: select a network, start point location, select facility type, select impacted areas, output location, and a the handicapped-accessible check box. If the handicapped-accessible check box is selected, the tool will not use the staircase, and the tool will draw an evacuation route to the nearest assembly point on the same floor. Otherwise, the tool will draw an evacuation route from the entry point to the nearest exit.
There are two ways to customize a tool: writing a script and using ModelBuilder.
With the evacuation tool, ModelBuilder was used to take advantage of the available tools and the model was customized according to the client-specific requirements.

Audience
This project targeted a broad array of beginner and expert users including KAU website visitors, students, faculty and staff, the Vice President for Projects departments, KAU 3D Model administrators, and KAU authorities and decision-makers, campus planner, and emergency management.

Overview of the Rest of this Report
This report is divided into six chapters beside this chapter. These chapters provide more details and information about related projects, implementation methods and workflows, and recommendations for future projects. Chapter 2 covers background information and literature review, which focuses on creating 3D campus models and using Network Analyst and 3D indoor routing. Furthermore, chapter 2 mentions related previous projects and research and examines their pros and cons and highlights their similarities and differences. Chapter 3 discusses the project requirements, the system design, and the project plan. Chapter 4 covers the database design including the conceptual model and logical data model with the required data and its sources. Chapter 5 clarifies the implementation process, while chapter 6 illustrates the results of the analysis. Chapter 7 is the conclusion of the project including the project summary and possible future works.

Chapter 2 -Background and Literature Review
This chapter discusses some previous projects that are similar to the 3D Evacuation Plan and Visualization project for King Abdulaziz University. This chapter is divided into three sections, and each section has a number of subsections. Section 2.1 describes the creation of the 3D model and its significance to the campus authorities and administrators. In addition, subsections 2.1.1 and 2.1.2 describe two different previous projects and the methods used to create the 3D campus models. Section 2.2 focuses on the Network Analyst extension and its advantages. Subsections 2.2.1 and 2.2.2 explain both Network Analysis and 3D indoor routing and includes some previous instances. The last section is a summary of this chapter.

Creating 3D Campus Model
In the early1990s, GIS became a useful system for collecting, maintaining, modifying, and analyzing spatial data and information as 2D data (Stoter & Zlatanova, 2003). Over the year, the limitations of 2D maps have become more apparent in some situations. It can be a challenge for a single 2D map to show all the spatial data for a particular area, especially areas that are overcrowded data with spatial, such as campuses (Esri,2014).
Since then, the technology of 3D visualization for GIS has become a solution to overcome 2D maps' limitations. Using 3D technology has can resolve many challengesfor example, the overlapping between a street and a bridge -that 2D maps could not meet ).

George Mason University Model
A good example of a 3D campus model depicts George Mason University, in Fairfax County, Virginia. In this web scene, Zhihang Li, Michael Rodriguez, and Alec Zhang created the 3D model. The goal of this web scene is to create a 3D model that simulate reality in the campus area which include the terrain heights. The project team went through several steps to reach the final product that is shown in the web scene. (Piccione, Jefferson, Fuhrmann, 2016) In the beginning of any 3D modeling project, the terrain and the different surface heights must be considered. There are multiple methods to represent the surface level such as using a triangulated irregular network (TIN), a digital elevation model (DEM), or a digital terrain model (DTM). In the George Mason University, the team used a TIN file for representing surface heights in the study area. In preparation, the authors converted the TIN file to a raster image, TIFF, and clipped it to the campus area to be acceptable for Esri CityEngine. The produced raster image represents the surface level. (Piccione, Jefferson, Fuhrmann, 2016) Terrain in Esri CityEngine consists of two parts: a surface level and aerial imagery. The team relied on OpenStreetMap (OSM) for finding the aerial imagery to be used in the terrain. This imagery was combined with the TIFF elevation image to create the terrain. For improving the overall appearance, the terrain was clipped with a border polygon that has the same coordinate system as the terrain. (Piccione, Jefferson, Fuhrmann, 2016) The team then imported the geometries. CityEngine could accept different formats such 2D GIS data; CAD packages; or Trimble SketchUp, KMZ, or DXF files. In this web scene, some of the building models were imported from SketchUp 3D Warehouse models (3dwarehouse.sketchup.com), which provides 3D designed models, and some buildings were built by the project team using SketchUp. However, there are two common problems to importing SketchUp building models to CitEngine: file size and shapes that are not georeferenced. The 3D buildings must be georeferenced to be located in a web scene correctly. If many SketchUp models are imported, the file size will be large and the scene may crash. Therefore, paying attention to the file size and reducing it would be critical (Piccione, Jefferson, Fuhrmann, 2016).
After that, Li and his team imported the building footprint provided by OSM. All the objects added to the workspace had to be aligned to the terrain. CityEngine deals with generating building footprints to 3D models by using computer-generated architecture (CGA) rule packages. These rule packages included detailed information about the buildings such as their heights, side textures, and roof types. Trees and vegetation layers were also generated with CGA rules and KMZ SketchUp files. Nowadays, this web scene is published on the author's account and the 3D model succeed to represent the existing objects in the study area (Piccione, Jefferson, Fuhrmann, 2016). The team work succeed to simulate the existing objects in the study area and conducted 3D analysis on the produced 3D model.

Esri Campus Model
The Esri campus is another excellent example of a 3D model created by the Esri CityEngine team. The goal of this project is to use the CityEngine software to create a web scene. This web scene shows Esri campus in Redlands with focusing on the headquarter development and the interior floor plans for the M, N, and MA buildings.
This web scene used 2D GIS data for all the objects including building footprints, street centerlines, street lights, trees, green areas and vegetation, and rocks. The Esri CityEngine team developed CGA rule packages to generate simulations of all the objects in the study area. Finally, CityEngine team shared and published the produced 3D model as a 3D web scene (CityEngine Team, 2015).

Network Analyst Extension
The strength of GIS is based on having information and data linked with geographic location. The ArcGIS Network Analyst extension made improvements by linking, making this network a powerful and sophisticated system. ArcGIS Network Analyst includes spatial analyses such routing, travel direction, services areas, and closest facilities (Esri, 2015). All the previous analyses can be conducted through a realistic network. The network can be enhanced manually by adding some conditions such as speed limits, expected arrival time, and traffic conditions at different times of day.
World Closest Facilities is a good example of using Network Analyst. This product includes a variety of GIS data layers, such as the street network, and target facilities like police, fire stations, and hospitals. Via the street network, the user can choose any location in the world, as well as the type of facility. Network Analyst will locate the closest facility to the location with consideration given to the distance, the expected arrival time, and the real-time traffic. This service can be used anyplace in the world. (Esri, NAVTEQ, 2014)

3D Network Analyst
Network Analyst plays an effective role in collecting all the spatial data that is located in a specific area of a feature dataset and illustrating relationships between different feature classes in the dataset. Also, Esri has tried to improve this system by looking for the Shortcomings and finding solutions for them. The 2D Network Analyst has some limitations in visualizing overlaid spatial data and conducting spatial analysis such as for streets that intersect or buildings with multiple floors. Therefore, Esri has improved the Network Analyst to be capable for better network visualization, analysis, and understanding. The geoprocessing tool in Network Analyst requires z-value to represent the geometries' heights. However, despite to the progress made in Network Analyst, the 2D spatial analysis was superior to the 3D analysis (Esri, 2015).

3D Indoor Routing
3D Indoor Routing and Visualization for the University of Redlands is another example of 3D indoor routing. This web scene was created by Umar Makdoom. In this project, Makdoom visualize the UofR campus as a 3D conceptual model and focused on Appleton Hall to apply the 3D indoor routing. Three feature classes were used in Appleton Hall: the floor plans, the indoor network, and the outdoor network. All of these feature classes were placed in a single feature dataset in order to build a geometric network. The floor plans had been received as CAD data; therefore, data conversion was essential. Due to the CAD data was not georeferenced, the floor plans had to be converted to 2D GIS data and needed to georeference the right location. There are three approaches to creating an indoor network: TIF, Fishnet, and manual digitization.
Makmoom chose to digitize the indoor network manually because it was for a single building. The network connectivity was checked after digitizing the network to ensure the network quality without disconnecting or overdigitizing. After that come identifying the required restriction attributes to be clarified in the network; this is the most important part in building a geometric network. One of the restriction attributes was that there were two check boxes: handicapped and nonhandicapped. Due to people with certain significant disabilities are unable to use stairs, the tool will create a route using the elevator in case chosen two points are on different floors. Otherwise, the tool will create a route that uses the stairs (Makdoom, 2015).  In another example of 3D indoor routing, the focus was on the headquarters building of the Esri campus. This example used the 3D Indoor Routing JavaScript application, created by Anjusha Sandeep. This web application used JavaScript to create a web page. The application included the building's floors and a basemap. It also had two buttons, Reset and Animate. This web application allowed users to pick two or more points on the building's floors. The route was created immediately between the points in numerical order. After that, the user could use the two buttons to make an animation for the created route or to reset the application and start over from the beginning (Sandeep, 2015).

Summary
With the progress in using 3D in GIS spatial data visualization and analysis and the limitations of 2D spatial data, especially in overcrowded areas with features using zvalues, many projects use 3D models. The power of 3D is apparent in visualizations of areas requiring large quantities of spatial data that have different z-values. Also, 3D

Chapter 3 -Systems Analysis and Design
This chapter discusses the system analysis and design and consists of five sections.
Section 3.1 discusses the obstacles and problems that the client faced. Section 3.2 illustrates the project's functional and nonfunctional requirements, which is considered in the project requirements analysis. Section 3.3 defines the system design, which includes all the principal components and the required hardware and software. Section 3.4 lists the project plan phases and explains the tasks in each phase. Finally, section 3.5 provides the chapter summary and conclusion.

Problem Statement
The King Abdulaziz University (KAU) campus has over than 400 buildings with diverse uses and purposes, including administration buildings for KAU employees; residential buildings for students, staff, and faculty; and scholastic and facilities buildings for KAU students and visitors. KAU authorities and decision-makers have access to many types of spatial data in different formats, and it became a challenge to display all this spatial information on a single map.
Some of this spatial data is focused on the safety-related issues of the study area such as the quantity and location of safety equipment. Therefore, KAU authorities hoped to increase campus safety by using the power of GIS to create an interactive indoor evacuation plan that would be suitable for all the campus buildings, particularly the most visited buildings, such as King Abdulaziz University Hospital (KAUH). This would help the university's Disasters and Emergencies Center and the General Administration of Security Services to plan ahead, using different scenarios depicting emergencies or disasters.

Requirements Analysis
Requirements analysis is critical to the success of any project and to meet the client's needs. The requirements are categorized into functional requirements and nonfunctional requirements.

Functional Requirements
The functional requirements consist of what the system will produce. This project has several functional requirements based on the client's needs. Table 1 lists each of the project's functional requirements with a brief description.

Nonfunctional Requirements
The nonfunctional requirements comprise how the system will perform, and this project has several nonfunctional requirements. Table 2 lists the project's nonfunctional requirements with a brief description of each.

System Design
The system design of this project contains six fundamental components, starting with the client's data and ending with delivering the results to the client at the end of the project's life cycle. The figure below illustrates the system design components.

Figure 3-1: The Project System Design
The first step was processing the data once it had been received from the client.
Processing included data conversion, enhancement, and modification using ArcGIS 10.3

Project Plan
There were five fundamental phases to meet the client's goals and objectives and make this project a success ( figure 3-2). Each phase included a number of deliverables, some of them being scientific and others being productive. The project started with the planning phase, which involved specifying the study area, King Abdulaziz University campus, in accordance to the client data. This data were examined to determine whether to modify or improve it, delete unnecessary parts, or complete it by adding more data if necessary.
Also, the planning phase included clarifying the project goals and objectives and identifying the project's scope based on the previous data examination and the project goals. Afterwards, all the final outcomes were tested to ensure the project's overall quality and effectiveness. After that, the client checked on the project results as a deployment phase to make sure that the outcomes had met the goals. Finally, concluding the project included modifying and addressing shortcomings and defects after the client's feedback and completing the project documentation such as the project report and the metadata.

Summary
This chapter clarified the problem statement, and discussed how it is important to the project's client to find a solution. Also, it described the requirements analysis and the

Chapter 4 -Database Design
This chapter includes discussion about the project's geodatabase and contains six sections. Section 4.1 describes the relationships between the project's different components; the relationships are demonstrated by the conceptual data model in both parts of the project. Section 4.2 illustrates the structure and the details of the project components, known as the logical data model. Section 4.3 discusses the data sources, and section 4.4 explains the methods used to collect the data. Section 4.5 discusses the data processing and transferring to prepare the final designed geodatabase. Section 4.6 is a brief summary and conclusion for the geodatabase design.

Conceptual Data Model
The conceptual data model is the structure that shows the relationships between different entities. Figure 4-1 illustrates the relationships between all the feature classes in the 3D Evacuation Plan and Visualization for King Abdulaziz University.

Figure 4-1: The Conceptual Data Model
In the King Abdulaziz University (KAU) 3D modeling, all the feature classes involved in 3D model are located on the campus area and have spatial relationships with the campus area. The street is the only polyline feature class which represents the model network. In addition, the street has several relationships with many feature classes such as the parking and the street furniture (light poles and trees). Some of the trees are located next to streets and others on green areas, which built relationship between the three feature classes. The parking feature class is the connection between the streets and the building feature classes.
In the case of the evacuation plan for the King Abdulaziz University Hospital (KAUH) building, all interior data have indirect relationships with the KAUH building footprint. The KAUH building consists of seven floors. Each floor has several rooms, hallways between these rooms, assembly points, and exits. The hallways feature class is the direct connection between the rooms, exits, and assembly points. Logical Data Model The logical data model is more complicated than the conceptual data model which includes data fields and how these fields connect the data. Before defending the logical data model and discussing the project's logical elements, all the data had to be collected, organized, and designed as the client ordered. This model is known as the system design model. Figure 4-2 illustrates all required data as organized in the system design model.

Figure 4-2: The System Design Model
In Figure 4-2, the red cylinders represent geodatabases, the gray ovals show different data type, the gray rectangles represent needed raster data, the green rectangles illustrate different feature types, the orang rectangles represent feature datasets, and the yellow rectangles show feature classes. In this system design model and based on what the client wanted, the project data was divided into two geodatabases: the 3D Visualization geodatabase and the Evacuation Plan geodatabase. The 3D visualization geodatabase has raster and vector data; however, the Evacuation Plan geodatabase has just vector data. The raster data was needed because of the scarcity of orthoimagery to play the background role and cover the gaps in the study area. Both geodatabases have point, line, and polygon feature classes. In the 3D visualization, building footprints, green areas, parking, vacant lands, streets, and light poles are the feature classes required to make the KAU 3D model. Also, the trees feature dataset includes six different types of trees and palms, which were required to be represented in the 3D model. In the Evacuation Plan geodatabase, there are two feature datasets: Room and Network Dataset.
The rooms feature dataset includes seven feature classes, and each represents the rooms located on a single floor, from the ground floor to the sixth floor. The Network Dataset has just one feature class, which is KAUH hallways. This feature dataset is required to build the indoor network dataset for KAUH. Also, the Evacuation Plan geodatabase has three additional feature classes: floors, assembly points, and exits.
The logical data model is the completing step after the conceptual and the system design models, which includes more details. In the logical data model, the data attribute tables are modeled independently, and the relationships between fields in different attribute tables are settled and identified. Figure 4-3 illustrates all the feature classes in the Evacuation Plan geodatabase, and how they are connected.

Figure 4-3: The Logical Data Model for the KAUH Evacuation Plan
The KAUH building polygon is the main feature class that contains all the rest of the feature classes. Building feature class has the Building_ID as the primary key, and it contains seven different floors. Each floor has an identification number in the Floor_ID field, the primary key, and has a relationship with KAUH building through Building_ID field as a foreign key. The floor feature class has relationships with all of the following feature classes: Exit, Assembly_Point, Hallway, and Room. Therefore, the Floor_ID field is shown in all four feature classes as a foreign key.

Data Sources
There are several data sources for this project; however, the project relied most on the data provided by different departments of the Vice President for Projects (VPP). Table 3 shows all the obtained data with their sources.In the first part of this project, which was creating a 3D model for King Abdulaziz University (KAU), the majority of the data such as building footprints, parking lots, trees, light poles, and green areas and the orthoimagery were received from the VPP. The street network was acquired from OpenStreetMap(OSM) as a OSM file, and the Computer Generated Architectural (CGA) rule packages that were used to generate the 3D model were downloaded from CityEngine tutorials. SketchUp 3D Warehouse website was used to get some 3D models such as light poles model. The vacant land feature class was created in order to have better representation at the KAU 3D model. For the evacuation plan, KAUH rooms and floors data were received from the VPP. The hallways, the assembly points, and the exits were created with regard to the client's regulations and strategies. All the data received from the VPP was meant for 2D purposes and did not support 3D representation. Therefore, the data processing was required to include z-values in all geometries to represent the buildings' heights in 3D representation. Section 4.5 explained the data processing in detail.

Data Collection Methods
Archival research was used for data collection. All the needed data was collected, prepared, and organized into two geodatabases in order to reach the project goals successfully. Several methods were used for collecting the project data (Table 4). Furthermore, some feature classes and models had to be custom built because of their unavailability. For instance, the KAUH hallways network was required for the KAUH indoor network in order to create the network dataset and to run the evacuation tool. Also, the emergency assembly points were required for using the evacuation tool in the scenarios involving handicapped.

Data Scrubbing and Loading
After collecting all the project necessary data, format conversion step was mandatory to make the formats useful. For instance, the KAUH assembly points were received on a paper map, and these points needed to be converted into a point feature class with the zvalues to be used in creating the KAUH network dataset. Also, the KAU stadium model was created using Revit as an RVT file. RVT files can't be read in CityEngine, so the RVT file was converted into an OBJ file.
After the format conversion, data completion and preparation were required to ensure the quality of the project results. Since the client created the GIS data for 2D representation, all the client's feature classes needed to include z-value to represent the third dimension. For instance, the building footprints feature class included the NumberOfFloors field for each building. According to the client, the floor height is almost four meters. Therefore, the z-value field was filled and calculated by using the number of floors in each building and multiplying it by the floor height. This step made the feature attribute table complete and ready for the 3D modeling. All the other feature classes in the campus visualization needed to add the z-value field by using the same previous method. As the last step of the data preparation, all the features were made to correspond with the WGS_1984_UTM_Zone_37N as a projected coordinate system. The corresponding coordinate correctly places all the spatial features in the right places.

Summary
The power of GIS appears in spatial data and the relationships within it. The data in almost all database projects go through several stages to ensure data quality and the relationships between the data components. If the data is clean and accurate, using the data is easier and results are better. Therefore, this chapter discussed the needed data with the relationships among them in the conceptual and logical data models. Also, this chapter illustrated the data sources and the methodologies of collecting the data. The last part is a discussion of the data scrubbing and loading such as format conversion, data processing, field completion, and coordinate unification, in order to be useful in the software environments.

Chapter 5 -Implementation
This chapter discusses the implementation processes that were used for the final products: the 3D model for King Abdulaziz University (KAU) and the evacuation tool for King Abdulaziz University Hospital (KAUH). This chapter is broken down into three sections.
The first two sections respectively, illustrate the implementation process of the two project deliverables. The last section is a brief summary of the chapter. Section 5.1 and section 5.2 are each divided into multiple subsections identified at the beginning of each section.

3D Model Implementation
Esri CityEngine was a suitable software to implement the KAU 3D model because it is suited to represent all the data obtained for the KAU 3D model. The produced model used many data sources in different formats. Also, different methods were used to extrude the 3D model. Using the 2D GIS data with its attribute tables, rule packages was the most frequently used method to extrude the model. Other structures required 3D models, whether existing models or customized ones, to better simulate reality. The client supported the 3D modeling by providing data; however, some departments of the Vice President for Projects (VPP) refused to share their data, and they are content with sharing their data partially.
Building the 3D model has five phases; each phase is illustrated in a subsection.
Section 5.1.1 explains the first step of starting a CityEngine project. Section 5.1.2 contains discussion about data processing and creation. Section 5.1.3 illustrates the methodology of using rule packages to extrudes 3D models. In some situations, it was required to use different methods and software to build 3D shapes, and this is discussed in section 5.1.4. Lastly, section 5.1.5 explains exporting the 3D model as a web scene in order to publish it to the public.

Establishing New CityEngine Project Workspace
Establishing a new project workspace on CityEngine software is the first step of the 3D modeling. Any new project on CityEngine has a unique name and includes a series of default fields. The project folder name is KAU_3D. KAU_3D framework includes all the default fields: assets, data, images, maps, models, rules, scenes, and scripts. These fields contain all the data used in the KAU 3D model, for instance, the 3D Visualization geodatabase is stored in the data field in the KAU_3D workspace.

Data Processing
The data needed for KAU 3D visualization are the building footprints, streets, parking lots, vacant Lands, green areas, light poles, and trees feature classes and the orthoimagery. The orthoimagery used in the King Abdulaziz University (KAU) 3D model was obtained from the client. The orthoimagery played an effective role in the 3D model as the basemap. This image covered the whole campus area plus neighborhoods surrounding the study area. Regarding the model created for the KAU campus, the orthoimagery was clipped to fit the campus area. The produced orthoimagery was saved in the KAU_3D workspace folder, to be used as the model background. Figure 5-1 shows the photo processing used to get the final result.

CGA Rule Packages
Computer generated architecture (CGA) is the programming language used in CityEngine projects to identify the rule packages and represent geometries in 3D models. The majority of the objects involved in the KAU 3D model used the CGA language to customize the masses, shapes and convert them from 2D GIS data to 3D models. All the CGA rule packages used in the KAU_3D workspace folder were provided by Esri CityEngine examples and tutorials. Some CGA rules were assigned with the existing 3D model to suit the client's needs. For instance, there is no CGA rule available to create light poles in the model. Therefore, the Insert_Object.cga file was use to simulate the light poles by assigning a light pole model obtained from SketchUp Warehouse 3D. All

Revit Modeling
The majority of the objects on the campus area were extruded to the 3D model by using CGA rule packages. However, some did not simulate reality correctly because of unavailability of CGA rules for unique structures. Therefore, a structure was built using Revit software to simulate the actual structure in detail. This structure is the KAU stadium. Figure 5-2 shows the KAU stadium in an image taken from Google Maps, and figure 5-3 displays a ground-level picture of the stadium. CityEngine allows users to import 3D models created by architectural software, so Revit was used to create 3D models with architectural details. There are several types of software to create 3D models with architectural detail, such as Revit and SketchUp.
However, Revit was chosen to design the KAU stadium because the client had previously used Revit to design structure 3D models in the study area, and the client wanted to document the methodology to import Revit models in the project report. Figure 5-4 shows the stadium model produced by Revit.

Figure 5-4: KAU Stadium Created on the Revit Platform
The produced model was exported as an RVT file. Due to the fact that CityEngine does not support RVT files, the stadium model was converted to an OBJ file. The KAU stadium model was stored in the KAU_3D project folder. When the model was imported into the CityEngine workspace, the model was imported as a mass with one color. Figure   5-5 shows the stadium designed model imported into CityEngine.

Creating 3D Web Scene
After completing the 3D model of the KAU campus, importing the model as a web scene in 3WS file format was the next and last step in this part of the project. After importing the 3D model into a web scene, the model was ready to be published in web pages by using an ArcGIS enterprise account. The produced 3WS file was stored in the KAU_3D workspace folder in the models file. This web scene file was delivered to the client, with all the files and data in the KAU_3D workspace folder, ready to be shared on the client's enterprise account. The web scene was stored in the KAU_3D folder, in the models file.

Evacuation Geoprocessing Tool
The evacuation geoprocessing tool was the last deliverable after a series of steps. The first step was preparing the data to be useful, which is discussed on section 5.2.1. Section 5.2.2 explains the methodology of the network dataset's creation. The last section 5.2.3 illustrates the geoprocessing tool creation.

Data Conversion
The data needed for the evacuation plan included the exits, assembly points, floors, rooms, and hallways as the feature classes. Section 4.5 discussed preparing the exits and assembly points by converting their locations from hard-copy maps to feature classes.
Two methods were considered to create the KAUH hallways: using the Fishnet tool and digitizing manually. The Fishnet tool creates a net feature class consisting of rectangular cells. The advantage of using Fishnet is that it can cover the entire study area. However, the created net needed to disconnect the hallways from the walls and keep the network connected through doors. Using Fishnet would have taken longer for cleaning up the network. The second option, digitizing the indoor network manually, was chosen for building the hallway network. This method was chosen because it suited the situation, since the targeted area was just a single building. Furthermore, the goal of creating the network was to allow end users to pick a point on the produced network; the system would not select the current location. Therefore, this method was the most suitable method. ArcGIS for Desktop was used to digitize the hallway center lines on all of the floors, without the transition between the floors. The z-value field was added to create KAUH hallways in the 3D visualization. Figure 5-6 illustrates the hallways on all of the floors, without stairs.

The Feature to 3D By Attribute Tool
The Feature to 3D By Attribute tool was used to convert all involved data in the evacuation plan (room, exit, assembly point, and hallway) to be z point, z line, and z polygon.

Integrate
Creating the hallways network by manually digitization was the chosen creation method.
Creating a transportation network required having vertexes at the beginning and the end of each segment. Also, creating a network required having a vertex at any junction between hallways. Therefore, the Integrate tool was used in order to ensure the placement of vertexes between all the junctions in the Hallway feature class.

Network Dataset Creation
There are up to nine steps to build a network dataset. Figure 5-9 shows the steps to create a network dataset.

Figure 5-9: Network Dataset Creation Methodology
The first step was to give the network dataset a name. KAUH_ND was the name chosen for the network dataset. The second step was selecting network input sources.
There was just one feature class, the KAUH Hallway feature class, involved in creating Dataset setting driving directions. And the ninth step, building a service area index, was not necessary. These steps produced the KAUH_ND network dataset plus the junctions feature class, KAUH_ND_junction.

Length Attribute
The Length attribute was created to count the geometries' lengths, which show the total distance that the created route would go through. Since the client is from Saudi Arabia, the meter was chosen as the distance measurement unit in order to suit the client's environment. The Double data type was selected in order to make decimals acceptable.

Escaping Time Attribute
The Escaping Time attribute was added to KAUH_ND to assume the walking time from the starting point to the closest facility. Based on the work of Robert Garrity, a speaker at the Indoor Location, Tracking, and Routing session at The 2016 Esri User Conference and an indoor network specialist, the walking speed average is 3 kilometers per hour (Garrity, Indoor Location, Tracking, and Routing, Esri Video, 2013), which equals 50 meters per minute. Therefore, the equation for calculating the escaping time is the route length divided by 50. The walking time used in this project is the average for walking on a flat, straight path. However, this equation will not give a reliable walking time because it does not account for using stairs or having crowded areas.

Handicap Attribute
Due to many people are unable to use stairs, the Handicap attribute was added to the KAUH_ND network dataset proprieties. This attribute was added as a usage restriction.
In the KAUH_ND, there is the Stairs field. The Stairs field has two values: 0 and 1. If the value in the Stairs field is 0, the geometry is part of a staircase, and if the value of the field was used in the equation to prohibit using the stairs if the Handicap check box is selected. Figure 5-12 shows the query used to create the Handicap attribute.

Geoprocessing Tool Creation
The Network Analyst extension was used in ArcGIS for Desktop to create the evacuation geoprocessing tool. The tool will calculate the closest facility route based on the user inputs. The produced tool has six parameters: the input network dataset, the input facility type, the input incidence locations, the input restrictions or impacted areas, the output file location, and the handicapped check box. In addition, the evacuation tool consists of six tools: the Make Closest Facility Layer tool, three Add Locations tools (for adding the facility feature class, incident locations, and the impacted locations), the Solve tool, and the Save to Layer File tool. Figure 5-13 illustrates the evacuation geoprocessing tool in ModelBuilder.
The evacuation tool begins with Make Closest Facility Layer tool in order to achieve the project goal which is determining the closest exit or assembly point. The Make Closest Facility Layer tool will allow the user to select two things: the network dataset and the handicap restriction. The three following tools are the same which is Adding Locations. The first Add Locations tool allows the user to choose the facility layer, the second for choosing the incident locations, and the third for selecting the affected areas. The incident locations and the affected areas can be selected by clicking on the selected network dataset. The fifth tool is Solve to make the closest facility layer based on the user inputs, and the Save To Layer File is the last tool used in the evacuation tool to save the result as LYR file.

Chapter 6 -Results and Analysis
After implementing all the project stages, this chapter covers the results and their analysis. The project mission was to take advantage of using 3D GIS technologies to create models and applications for better visualizing and analyzing areas with crowded overlaid spatial data. This project has two fundamental parts, which are the 3D model for the King Abdulaziz University (KAU) campus and the interactive evacuation plan for the King Abdulaziz University Hospital (KAUH) building. Therefore, this chapter divided into two sections besides the conclusion section. Section 6.1 addresses the results of the KAU 3D model, which includes the project workspace folder with the web scene and the needed data. Section 6.2 shows the interactive evacuation system, which includes the produced evacuation tool with the necessary feature classes. The chapter ends with a brief summary and conclusion in section 6.3.

3D Web Scene Model
The produced KAU model is the first product of this project. The KAU model was created by using CityEngine software, and it is stored in the KAU_3D workspace folder. The KAU 3D model represents all the feature classes involved in the project workspace.
These feature classes are BuildingFootprint, GreenArea, VacantLand, CenterStreetLine, LightPole, and the feature classes in the Tree feature dataset. Different methods explained in chapter 5 and the computer generated architecture (CGA) rule packages (explained in chapter 5 section 5.1.3) were used in order to build the 3D model. Figures 6-1, 6-2, 6-3, and 6-4 show the KAU model from different perspectives. After completing the 3D model, importing the created 3D model into a web scene was the last step of this part. This web scene was created to be published on the web in order to share it with the public. This web scene will be hosted in the university's web platform by the client. Figure 6-5 illustrates the KAU 3D web scene interface.

Figure 6-5: The KAU 3D Web Scene Interface
The produced KAU 3D web scene interface has multiple buttons, toggle layers, and tools. The web scene has toggle layers to turn the involved layers on and off. In Figure 6-5, the blue window on right shows the involved layers in the web scene. In addition, there is the search tool for exploring information within the 3D model. The search too could be used to search for any specific building or street by type its name or number. The search tool supports both the Arabic and English languages. Figure 6-6 shows the search panel on the web scene. Also, the web scene includes a setting panel to allow the users to see the models shadows in different times in the whole year. Also, the setting panel allows users to take screenshots of any view in the web scene. Figure 6-7 web scene was required for this project; therefore, a comment panel was included. The last button in the right top corner in the web scene is the information panel. The information panel would appear by clicking on any object in the web scene, and

3D Evacuation Plan
The indoor 3D evacuation plan was focused on the KAUH building. All of the required data in this part of the project was stored in the 3D geodatabase. The required data involved in the evacuation tool are Exit, AssemblyPoint, Hallway, KAUH_ND, and KAU_ND_Junction, and all the room feature classes in the Room feature dataset. The evacuation geoprocessing tool was created after the KAU_ND was built. End users need to double-click on the evacuation tool to open the tool interface. Figure 6-6 illustrates the evacuation tool interface. The evacuation tool required four user inputs to the tool interface: Input Network Dataset, Input Facility Layer, Input Incident Locations, and Output File. In addition, there were two optional inputs: the Handicap check box and the Input Restriction Locations, to be entered into the evacuation tool interface. The Input Network Dataset was the first input, and analysis would be conducted using the entered hallways network. The second required input was for selecting the facilities. There are two approach scenarios based on the project requirements, involving the Exit and AssemblyPoint feature classes. The assembly points were for accommodating handicapped people, and the exits were for the nonhandicapped people. The third input was the Handicapped check box, which was input required was to choose the incident locations by clicking on the network. The fifth input location restrictions is optional input and was built for user to select affected areas in case of emergency. This affected area static and it can't be changed. The last input is the Output File. The file should have a unique name; the default file is the Evacuation_Plan geodatabase. Figure 6-7 shows the first scenario, which involves using the evacuation tool by selecting an incident location on the sixth floor, choosing the Exit feature class as the facility.

Summary
This chapter illustrated the final products: the 3D web scene for the KAU campus and the interactive indoor evacuation system for the KAUH building. The first deliverable is the 3D model for the campus area. This model would help the KAU authorities and decisionmakers share their opinions and comments and to visualize the campus better by running 3D Analyst through the created model. In addition, the web scene could be hosted on the KAU website to allow university visitors to have a better understanding of the campus.
The second deliverable is the indoor evacuation system. The indoor evacuation system includes the produced evacuation geoprocessing tool, which can serve both handicapped and nonhandicapped people.

Chapter 7 -Conclusions and Future Work
The purpose of this project was to create a 3D model for the King Abdulaziz University (KAU) campus and build an interactive indoor evacuation plan for the King Abdulaziz University Hospital (KAUH) building. The project's missions were accomplished by using GIS technologies to meet the client's requirements and needs. The deliverables met the client's needs with all the functional and nonfunctional project requirements. This is the last chapter of the project report and includes three sections. Section 7.1 includes a discussion of the project's conclusion. Section 7.2 illustrates the challenges that limited the scope of the project. The future work that could be done to improve the project's products is explained in section 7.3.

Conclusion
The required data were received from different resources. These data went through multiple stages and were finally stored into two different geodatabases. The 3D Geodatabase was stored in the KAU_3D project workspace folder. This folder consisted of several files that included all data, models, rule packages, and information involved in creating the KAU 3D model. This folder was delivered to the client with the 3WS file that contained the produced 3D model.
The second geodatabase was the EvacuationPlan geodatabase. This geodatabase stored all the data involved in creating the 3D model such as the rooms, assembly points, exits, and floors feature classes with the KAUH_ND network dataset and its junctions.
Also, this geodatabase included the Evacuation Tool, which was customized to fit the client's requirements and needs.

Limitations
There are several project limitations that affected the project deliverables. Time was the biggest challenge to provide the project's deliverables. For instance, work was limited due to the existing computer generated architecture (CGA) rule packages used to extrude the 3D model. If the project deadline could have been extended by months, the CGA rules could have been customized in order to better fit reality. The customized rule packages could be saved as an RPK file and shared to be applied to the other KAU campuses buildings.
Finding the suitable software was a required to achieve the goals of this project successfully. CityEngine was a suitable environment to generates all the objects in the study area to 3D models. However, there are some limitations that limits the software operations. The search tool in the KAU_Model web scene can search for any specific object in the study area by its name or number. For instance, searching for the KAUH building by its name, Hospital of University, produced 963 results found because the search tool looks for any match information of all the words in the search box individually (Figure 7-1). Figure 7-2 illustrates the right way to search for a specific building by typing the name between the quotation marks. Working on this project for so distance study area was another issue that limited the final 3D model. When the provided data were insufficient, it was difficult for the project team to collect the missing data. For instance, one method to extrude 3D models is to assign façades to buildings on the model. Due to the distance between Redlands, California, where the project was developed, and the study area, it was impossible to capture the building façades with the building shapes.
Data limitation is another obstacle the project faced. The client provided data that helped the project accomplish its goal. However, the project mission in the 3D visualization was to include all the client data, and some departments at VPP refused to share their data, therefore, the mission was not accomplished completely. For instance, the VPP General Administration for Studies and Design Department had 3D models for the existing buildings that would have enhanced the KAU 3D web scene. Another example is that the building doors data wasn't available. The doors in the evacuation plan is important because most of the doors open in just one direction. In addition, some doors are prohibited to the public and their use is limited to the staff and employees use only.
Due to the unavailability of the KAUH doors data, the KAUH doors weren't included in the project considerations. Therefore, the escaping times and distances provided with running the tool are estimates.

Future Work
The development of GIS technologies is constantly in progress and has unlimited potential. Developers aim to improve the GIS technologies to perform better. In the 3D Evacuation Plan and Visualization for King Abdulaziz University, the final deliverables were a 3D model for KAU and an evacuation tool which applied on the King Abdulaziz University Hospital (KAUH) building. Each product could be improved upon in order to get better results.
In the KAU 3D visualization, multiple improvements could be made to simulate the KAU campus area better. One of these would be to add all the existing data with its attribute tables to the created model. In addition, the client had created several 3D building models by using Revit software; it would be advantageous in that allowing developers to add the building models to the web scene. CGA rule packages could be customized to simulate reality in greater detail.
For the evacuation geoprocessing tool, there are potential improvements that could be made upon in order to get better deliverables of the project. First, the produced network was specifically for the KAUH building, and the network could be improved by extending it to include all the buildings of the KAU campus. This expansion would enable analysts to find safe assembly areas outdoor in case of emergency. Furthermore, converting the Room polygons feature class to a z-point feature class and make the room points contiguous with the hallways network. This way, the evacuation geoprocessing tool would allow the user to select the starting point by searching by room name or number to make the route from that selected room. Also, including the KAUH doors in the project considerations is another improvement can be made in order to suit the right room accessibility and estimating the evacuation route and distance better with running the evacuation tool. Another option is to create a network by using Fishnet for each floor and selecting the starting point automatically from the user's current location. One last future work suggestion would be to create a web application and a mobile application to use the network and the tool easily from anywhere.