GSP 536

Lab 2 – Urban Geodatabase Design

Submit: jb3379_Design.doc(x)
Due date: Sunday, September 25, 2016

Scenario: You have accepted the position of GIS developer for the City of Flagstaff. After the first week working in this new position, you find that many departments of the city use spatial data, and each department maintains its own data sets.  Spatial data formats maintained in the city are mainly shapefiles with some coverages, rasters, TINs and ortho photos. Moreover, you realize that data inconsistency among departments has become a serious problem because of this data management practice.  For example, the street centerline shapefile is maintained by almost every department, but different departments maintain different versions of it.  Data sharing used to be carried out mainly by email and sometimes by delivering disks through the internal mail system although many departments now choose to share data on public folders on the intranet. Obviously, this old fashion data management is inefficient and problematic.  It has caused a loss of data quality control and conflicts in data since every department maintains and edits one dataset in different ways.

After a careful survey in the second week, you have identified major GIS users in the City and made an inventory of existing data sets and GIS functions used by different departments (table below).

Major GIS users, data sources and functions of the city
User Existing data GIS Functions
Community Development City limits
Street centerlines
Zoning
Townships, ranges, sections
Parcels
Establishments
Addresses
Zip codes
Ortho photos
Census tracts/block groups/ blocks
Census tables (Excel)		 Development planning
Zoning
Subdivision
Recorder Parcels
Easements
Owners (books)
Street centerlines		 Land and property recording
Assessor Street centerlines
Zoning
Parcels
Easements
Tax records (Access database)
Flood plains (paper map)		 Land and property assessment
Tax assessment
Transportation Department Street centerlines
Road conditions
Bus routes (pdf diagrams)
Bus schedules (Excel worksheets)		 Transportation planning
Transportation facility maintenance
Network analysis
Public Works Department Street centerlines
Water lines
Water junctions
Water valves
Fire hydrants
Sewer lines
Sewer valves
Sewer mainholes		 Utility construction / maintenance
Quickly locate utilities
Utility network analysis
Fire Department Street centerlines
Fire districts
Fire station locations
Water lines
Hydrants
Building footprints		 Emergency dispatch
Emergency rescue plan

Knowing that a geodatabase can provide a central data repository for an organization, you decide to develop one using ArcSDE, with Oracle as the back end.

You reference Dr. Huang's lecture notes, and also utilize the ArcGIS Urban Data Model, based on a model for the geodatabase of Ontario province, Canada.

Part I: The Logical Data Model

Based on the second week's survey and your understanding of the users, data, and functions of the city, you decide to adopt the Logical groups of data as demonstrated in the lecture, leaving the option open to make adjustments to contents of the groupings or even create your own data groupings. You plan to design a logical data model, adopting the land records diagram as part of your model. By following the example of the land record logical model, you identify attributes for at least four feature/object classes in each data group. As a preliminary design, you define at least one range domain and one coded value domain for any feature class, and one relationship between feature classes or tables in each group. Topology does not have to be defined for this lab so you decide to do it later.

Part II: The Implementation Design

For the physical implementation design, you found that most of the existing feature classes are in Arizona Central Zone State Plane coordinate system (FIPS 0202) with NAD 1983 (feet) datum. However, some of the data that you will download from the US Census Bureau and USGS are in a Geographic Coordinate System (GCS) instead. So the logical data groupings cannot be directly implemented as feature datasets because a feature dataset holds only one coordinate system. You design a set of feature datasets to organize your data in different categories. For each of your feature datasets, you list the spatial references,  storage resolution, as well as contents (feature classes, relationship classes, and topology etc) as per Slide 19 in the lecture.

You model requirements, that you will place into a Microsoft Word document, are as follows.

  1. Conceptual modeling
    • Since it is not possible for us to conduct such comprehensive work in two weeks, we'll have to assume that a conceptual model has been completed, and the simplest report is presented in slides 5 to 7, particularly slide 7. You may simply copy the contents of slide 7 as your conceptual modeling result, or you may reorganize the data and create your own logical groupings.
  2. Logical modeling
    • Diagrams of logical data model

      1. Attributes of at least four feature classes / tables
      2. At least one range attribute domain for a feature class in each data group
      3. At least one coded value attribute domain for a feature class in each data group
      4. At least one relationship between feature classes/ tables in each data group
  3. Implementation design:

    1. Feature datasets
      1. Spatial reference
        • projection/coordinate system
        • storage resolution
      2. Contents: feature classes, relationship classes, topology, etc.
    2. Non-spatial tables