GEOGRAPHIC INFORMATION YSTEM SPATIAL DATA …

GEOGRAPHIC INFORMATION SYSTEM

SPATIAL DATA STANDARDS SPECIFICATION

FINAL

Geographic Information System Implementation Project

Phoenix Sky Harbor International AirportCity of Phoenix, Arizona

Revised July 2008

Spatial Data Standards Specification—Final

Geographic Information System Implementation Project

Phoenix Sky Harbor International Airport

City of Phoenix, Arizona

Version 1.1 Revised July 2008

Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona i

QUALITY

We invite your comments and suggestions for improving this document.

TRADEMARKS

All brand names and product names are trademarks or registered trademarks of their respective

companies.

Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona ii

TABLE OF CONTENTS

1. INTRODUCTION............................................................................................................ 1 1.1. Purpose .............................................................................................................................................................1 1.2. Scope ................................................................................................................................................................1 1.3. Intended Audience............................................................................................................................................1 1.4. References to parties.........................................................................................................................................1 1.5. Related Documents...........................................................................................................................................2 1.6. Request for Waiver...........................................................................................................................................2 1.7. Revision History...............................................................................................................................................3

2. OVERVIEW OF SPATIAL STANDARD .............................................................................. 4 2.1. Spatial Data Standards Lineage........................................................................................................................4 2.2. GIS Tools and Storage......................................................................................................................................4 2.3. Data Format......................................................................................................................................................4 2.4. GIS Database Components...............................................................................................................................5

2.4.1. Feature Datasets.......................................................................................................................................5 2.4.2. Geometric Networks ................................................................................................................................5 2.4.3. Feature Classes ........................................................................................................................................5 2.4.4. Attributes .................................................................................................................................................5 2.4.5. Subtypes...................................................................................................................................................6 2.4.6. Domains...................................................................................................................................................6 2.4.7. Relationship Classes ................................................................................................................................7 2.4.8. Annotation and Labeling .........................................................................................................................8 2.4.9. Topology..................................................................................................................................................8 2.4.10. Symbology.............................................................................................................................................13

2.5. GIS Data Creation Rules ................................................................................................................................13

3. DATA DELIVERY AND ACCEPTANCE ........................................................................... 14 3.1. Delivery Formats and Media ..........................................................................................................................14 3.2. Delivery Procedures .......................................................................................................................................14

3.2.1. Data Security .........................................................................................................................................14 3.3. Data Development Quality Control and Quality Assurance...........................................................................15

3.3.1. Quality Assurance Requirements...........................................................................................................15 3.3.2. Quality Control Requirements ...............................................................................................................15

3.4. Acceptance Testing Procedures......................................................................................................................15 3.4.1. Attribute Domain Conformance ............................................................................................................16 3.4.2. Attribute Integrity ..................................................................................................................................16 3.4.3. Topologic Integrity ................................................................................................................................16 3.4.4. Spatial Accuracy....................................................................................................................................16 3.4.5. Quality Control Report ..........................................................................................................................16 3.4.6. Accepted Data........................................................................................................................................16

4. SAMPLE GEODATABASE DESIGN REPORT................................................................... 17

5. SAMPLE GIS DATA CREATION RULES ........................................................................ 25

Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona iii

LIST OF TABLES

Table 1. Revision History ..............................................................................................................................................3 Table 2. Coded Value Domain Example .......................................................................................................................7 Table 3. Range Domain Example ..................................................................................................................................7 Table 4. Topology Rules ...............................................................................................................................................9

Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 1

1. INTRODUCTION

1.1. PURPOSE

All GIS-based spatial data created for the Aviation Department must be developed and submitted

according to the specifications documented in this standard. This includes data prepared internally by

airport employees and data prepared by outside consultants.

Each submitted GIS dataset becomes part of the permanent archive and also serves as a source for

updating information within the city’s enterprise Geographic Information System (GIS) and, thus, part of

the foundation for future work at Aviation Department facilities. The availability of standardized data

products and drawing files for use on future projects enhances the value of the original data creation

effort. Standardization allows drawing files and individual data layers to be integrated with other data

components, ensuring consistency in planning and design at Aviation Department facilities.

Additionally, the FAA needs standard airport geospatial data so that it can share important information

with airports and internally within the FAA. The data standards described in this document are intended

to support those needs.

1.2. SCOPE

This standard encompasses all aspects of GIS spatial data for the Aviation Department’s GIS. It does not

include other data issues, such as aerial photography, coordinate systems, CADD standards, or metadata.

The specifications for these items are covered in separate standards as described below.

1.3. INTENDED AUDIENCE

This document is intended to be used by people who maintain or create GIS data for the Aviation

Department’s GIS. All city staff and outside consultants should understand the requirements of this

standard and follow its specifications for submitting spatial data to the Aviation Department.

1.4. REFERENCES TO PARTIES

The primary receiving party and owner of the GIS its content and the standards is referred to as the

Aviation Department. The Aviation Department is the short name for Aviation Department a department

with the City of Phoenix.

The party providing the GIS database information is referenced as the submitting organization. This is

generally going to be a party external to the Aviation Department whose submittals are controlled by

contract. This standard and its related documents are meant to be part of the contract addendum.

The primary Aviation Department contact between the Aviation Department and the submitting

organization is the Project Manager.


1.5. RELATED DOCUMENTS

This document is intended to be coupled with the geodatabase design itself, which is published in a

document titled “Phoenix Aviation Department GIS Geodatabase Design Report”, (hereinafter

referred to as the Geodatabase Design). Any outside organization must contact the City of Phoenix

Aviation Department’s assigned Project Manager to obtain the latest version of the Geodatabase Design

prior to beginning data development.

All data must be developed to be consistent with the document titled “Phoenix Aviation Department

GIS Data Creation Rules”, (hereinafter referred to as the GIS Data Creation Rules).

Additionally, all data must be developed using the Aviation Department’s current GIS symbology. The

current symbology dataset will be provided to any outside organization at the beginning of any project

creating GIS data.

This document is a supplement to the City of Phoenix Information Technology Standard ‘Enterprise

Spatial Data’ document for the Aviation Department based on specific business needs of the Aviation

Department. The Aviation Department supplement and the City Standard will ensure that airport-specific

implementation of GIS requirements are met. This document is fully compliant to the City Enterprise

Spatial Data standard as published on May 12, 2005 - (refer to

http://www.phoenix.gov/AGENCY/PHXITD/STANDRDS/d1_8.pdf)

In addition to this Spatial Data Standards document, the Aviation Department has developed a set of

standards that comprise the GIS Standards Data Guidebook. The Guidebook is comprised of the

following documents:

• Coordinate System Standards

• Spatial Data Standards (this document)

• Metadata Standards

• Quality Control Standards

• CADD Data Standards

Together, these standards document the concepts, policies, and data creation practices necessary for the

Aviation Department to incorporate data into the GIS Program. These documents are designed to develop

the GIS for the Aviation Department so that city-maintained spatial data relevant to the Aviation

Department is shared through the process of replicating appropriate datasets from the city GIS in the data

tier. The converse of this applies for Aviation Department datasets required by city GIS users.

It is the responsibility of the submitting organization to obtain the latest set of GIS Standards referenced

in this document. The submitting organization is encouraged to contact the Aviation Department Project

Manager to facilitate obtaining these documents.

1.6. REQUEST FOR WAIVER

Situations may arise where data should be created for the Aviation Department GIS that would not be

consistent with this standard. If such a situation were to arise, the party creating the data must request a

waiver to this standard. The request must define the specific section of the standard for which the waiver

is requested, the reason for the waiver, the resulting impacts on the use of the data in the GIS, and any

alternative approaches that should be considered. The request will also include a detailed description of


the business need for the waiver request and why adherence to this standard will prevent satisfaction of

the business need.

The Aviation Department must approve any waiver request before such data can be submitted.

1.7. REVISION HISTORY

As changes to the Spatial Data Standards are indicated and accepted, this document will be updated

accordingly. The following revision history will summarize these changes.

Table 1. Revision History

Name Date Reason for Change Change Control Form

Ted Melnik July 2008 Added certification requirements in section 3.4.4 Spatial Accuracy


2. OVERVIEW OF SPATIAL STANDARD

2.1. SPATIAL DATA STANDARDS LINEAGE

The Aviation Department Spatial Data Standards were created by incorporating elements of the following

documents:

• Federal Aviation Administration Advisory Circular 150/5300-18 (General Guidance and

Specifications for Submission of Aeronautical Surveys to NGS: Field Data Collection and

Geographic Information System (GIS) Standards). These standards are based on the Spatial Data

Standards for Facilities, Infrastructure and Environmental (SDSFIE) and have been expanded to

better facilitate use at aviation facilities. These standards focus on exterior (outside the building)

features and generally lack for interior features.

• Spatial Data Standards for Facilities, Infrastructure, and the Environment, (SDFIE) as

developed and maintained by the Department of Defense’s CADD/GIS Technology Center at

https://tsc.wes.army.mil/products/TSSDS-TSFMS/tssds/html/. (Note: If this hyperlink does not work

within the document, copy the link and paste it in the browser).

• ESRI’s Geodatabase Data Models. These data models were created by ESRI as starting points for

many common types of datasets. They are available at ESRI’s website at

http://support.esri.com/index.cfm?fa=downloads.dataModels.matrix.

2.2. GIS TOOLS AND STORAGE

This standard references tools and storage of GIS data that utilize ESRI products. For more information

on these items refer to the ESRI website http://esri.com/. Aviation Department has standardized on ESRI

including ArcSDE and the ArcGIS suite of products.

2.3. DATA FORMAT

2.3.1. Aviation Department GIS

All GIS data shall be stored in Oracle Spatial SDO_Geometry Oracle/SDE.

2.3.2. Delivery of Spatial Data to Aviation Department

All spatial data shall be delivered to the Aviation Department in a manner readily converted to the

Department GIS format. The database may be exported into an XML Workspace format using ESRI

ArcCatalog ArcEditor or by creating a file based GEODATABASE in ArcCatalog ArcEditor. Microsoft

Access databases are not recommended because of potential incompatibilities in the manner in which data

is stored on that format versus the Aviation Department Oracle Spatial database.


2.4. GIS DATABASE COMPONENTS

The detailed geodatabase design that all data must adhere to is found in the “Phoenix Sky Harbor

International Airport GIS Geodatabase Report.” The following sections introduce and explain the

fundamental terms needed to understand the geodatabase design.

2.4.1. Feature Datasets

Feature datasets are used to build a geometric network or topology. They store a group of features with a

shared geographic extent, spatial reference, attribute table, etc. A single feature dataset can only maintain

one topological relationship—either a geometric network or topology, but not both. Additionally, feature

datasets shall only include feature classes that participate in a geometric network or topology. They

should not be used to simply group or organize data. All feature classes within a feature dataset shall have

the same spatial reference by default because ESRI constraints require the spatial reference be set at the

feature dataset level.

2.4.2. Geometric Networks

Geometric networks are used to model linear networks of line and point features and allow for tracing and

other analysis. Only line and point feature classes can participate in a geometric network and must be

within a feature dataset. All lines within a geometric network shall be created as edges as defined in the

geodatabase. In addition, all lines within a gravity system where a fixed flow direction exists must be

digitized in the flow direction.

2.4.3. Feature Classes

The feature class level is used as the primary means to segregate different types of spatial data. All feature

data shall be properly segregated into the appropriate feature class as specified in the database design.

2.4.4. Attributes

An attribute is used to track descriptive information for a particular feature within an object or feature

class. All attributes designated as “required” must have a value assigned for the feature. Non-mandatory

attributes will be assigned values by the project team on a case by case basis depending on the needs of

the particular project.

2.4.4.1. Attribute Data Types

The attribute data types and their constraints are defined below.

• Small/Short and Long Integer: Both short and long integers can store only real numbers. Fractions

or numbers to the right of the decimal place cannot be stored.

• Single/Float and Double: Floats and doubles are both binary number types that store the positive or

negative nature of the number, a series of significant digits, and a coded value to define the placement

of a decimal point. This is referred to as the exponent value.

• Text/String: A text field represents a series of alphanumeric symbols. This can include street names,

attribute properties, or other textual descriptions.


• Date: The date data type can store dates, times, or dates and times. The default format in which the

information is presented is mm/dd/yyyy hh:mm:ss and a specification of AM or PM. When users enter

date fields in the table, then field values are converted to this format.

• BLOB (binary large object): Data stored in the geodatabase as a long sequence of binary numbers.

Items such as images, multimedia, or bits of code can be stored in this type of field.

• Global Identifier (also referred to as a GlobalID or GUID (Globally Unique Identifier): Data

types store registry-style strings that uniquely identify a feature or table row within a geodatabase and

across geodatabases. Developers can use them in relationships or in any application requiring globally

unique identifiers. GlobalID fields are 38 bytes (36 characters).

• Raster: Unlike a hyperlink that only links a feature’s field to an image, a field type of raster can

actually store the raster data within or alongside the geodatabase. For example, a photograph of the

commercial property can be added as an attribute of a parcel feature or a scanned drawing of property

features. Only one raster type field may be used on each feature class or table. Use a different table

with a relating field to associate more than one raster dataset with each feature. In addition, only

appropriate raster imagery should be added as an attribute to a feature class. All valid raster formats

are available, but it is highly recommended that only small pictures (files of less than 100K bytes) be

used for this field.

2.4.5. Subtypes

A subtype is an attribute that can be used to distinguish features within an object or feature based on the

subtype value. Each unique subtype allows the other attributes within the object or feature class to have

their own default values, associated domains, and validation rules. All subtypes must be populated for

each feature.

2.4.6. Domains

All GIS data must comply with the constraints defined by the GIS domains. If changes to a domain are

required to accurately input data, the changes must be requested through change control.

There are two types of domains—coded value domains and range domains. Below is a description of

the uses and constraints for each domain type.

2.4.6.1. Coded Value Domains

Coded value domains are used for both numeric (double/single/integer/small integer) and string fields.

They manifest themselves to users as a dropdown list of valid values in ArcMap’s editing environment.

An important concept with coded value domains is the distinction between the code and description for

each item in the domain. The code is the actual value that shall be stored in the geodatabase. The

description is the value that is displayed to the user in the dropdown list. This allows for more efficient

storage of information in the geodatabase by using the smallest data type and precision/scale/length

possible.


Table 2 shows an example of a coded value domain.

Table 2. Coded Value Domain Example

Code Description

2 2 inch

4 4 inch

6 6 inch

8 8 inch

10 10 inch

2.4.6.2. Range Domains

Range domains are used for numeric fields (double/single/integer/small integer) and specify the minimum

and maximum values for information within that field. To the end user in the editing environment, fields

with associated range domains are edited like any other normal non-domain associated field. However,

when the user validates features, the entered values are compared within the database to the range domain

to ensure that the entered value falls within the minimum and maximum values.

Table 3 shows an example of a range domain.

Table 3. Range Domain Example

Minimum Value Maximum Value

0 50

2.4.7. Relationship Classes

For a non-attributed relationship, an origin primary key field is defined within the origin feature and

linked to an origin foreign key in the destination feature. For an attributed relationship, which is required

for a many-to-many relationship but is otherwise optional, an addition table, the relationship class table, is

used to mange the data between the origin and destination table. An origin primary key field is defined

within the origin feature table and linked to an origin foreign key in the relationship class table. Likewise,

a destination origin primary key field is defined within the destination feature and linked to a destination

foreign key in the relationship class.

2.4.7.1. Simple Relationships

Simple relationships are normal relationships linking two objects that exist independent of one another. A

simple relationship can have a one-to-one, one-to-many, or many-to-many cardinalities and be non-

attributed or attributed. Additionally, one feature can participate in multiple simple relationships.

2.4.7.2. Composite Relationships

A composite relationship is a relationship where the existence of one of the features is dependent on the

existence of the other. That is, a feature, row, or table is not only related to another, but creating, editing,

and deleting one feature in the relationship will effect the other object in the relationship. For example, in

a composite relationship between a pole and a transformer, if the pole is deleted, so is the transformer.

Composite relationships only have a one-to-one cardinality.


2.4.7.3. Relationship Creation Rules

The ObjectID should never be used when creating user-defined relationships since the ObjectID is not a

static number. If using an attributed relationship class, the primary keys fields used to build the

relationships should be programmatically generated, allowing users to employ the “Add New” function

within ArcMap when adding a new related feature through the primary feature in the attribute editor

window.

2.4.8. Annotation and Labeling

2.4.8.1. Labeling

Labels are the preferred method for adding text information in a map. Annotation feature classes should

only be used if labeling is not adequate to produce cartographically-pleasing maps for display or plotting.

This is due to the complexity of needed placement or if repeated annotation use in a fixed location is

needed for use with multiple maps.

2.4.8.2. Annotation Feature Class

An annotation feature class is used to define and display spatially-referenced text and symbol features.

Annotation feature classes are typically used to maintain a static location of the annotation when:

• The complexity of placement exists with the subsequent need to adjust one or more display properties

of an individual piece of annotation in order to place it in a desired location of choice.

• The annotation is used in multiple maps using the same placement location.

2.4.8.2.1. Standard versus Feature Linked Annotation

Standard annotation should only be used for annotation that is not associated to any information tracked

within attributes of the geodatabase feature classes. Otherwise, feature-linked annotation should be used

to generate the annotation.

Within annotation feature classes, one or more annotation classes can exist that determine how a subset of

annotation in the feature class displays. For standard annotation feature classes, the annotation class

properties include what default symbology is applied when creating new annotation and the visible scale

range. For feature-linked annotation feature classes, the annotation class properties also include how the

annotation text strings shall be defined. This shall be based on attributes in the linked feature class, which

features in the linked feature class shall be annotated by the annotation class, and how to place the new

annotation.

2.4.9. Topology

Topology is used to define the spatial relationship between features in one or more feature classes through

a set of predefined rules. Table 4 represents the types of topology rules that can be used in the Aviation

Department GIS. (Note: a Polygon may have one or more topology rules associated to it.)


Table 4. Topology Rules

Rule Rule Description

Polygon Rule Rule Description

Must Not Overlap

This rule requires that the interior of polygons in the feature class not overlap. The polygons can share edges or vertices. This rule is used when an area cannot belong to two or more polygons. It is useful for modeling administrative boundaries, such as lease lines codes or airspace surfaces, and mutually exclusive area classifications, such as land cover or landform type.

Must Not Have Gaps

This rule requires that there are no voids within a single polygon or between adjacent polygons. All polygons must form a continuous surface. An error will always exist on the perimeter of the surface. You can either ignore this error or mark it as an exception. Use this rule on data that must completely cover an area. For example, polygons illustrating individual concrete panels in the runway cannot include gaps or form voids—they must cover an entire area.

Must Not Overlap With

This rule requires that the interior of polygons in one feature class must not overlap with the interior of polygons in another feature class. Polygons of the two feature classes can share edges or vertices or be completely disjointed. This rule is used when an area cannot belong to two separate feature classes. It is useful for combining two mutually exclusive systems of area classification, such as pavement and landscaping type, where areas defined within the pavement class cannot also be defined in the landscaping type class and vice versa.

Must Be Covered By Feature Class Of

This rule requires that a polygon in one feature class must share all of its area with polygons in another feature class. An area in the first feature class that is not covered by polygons from the other feature class is an error. This rule is used when an area of one type, such as an airport property, should be completely covered by areas of another type, such as airport land use type (revenue, non-revenue).

Must Cover Each Other

This rule requires that the polygons of one feature class must share all of their area with the polygons of another feature class. Polygons may share edges or vertices. Any area defined in either feature class that is not shared with the other feature class is an error. This rule is used when two systems of classification are used for the same geographic area, and any given point defined in one system must also be defined in the other. One such case occurs with nested hierarchical datasets, such as small watersheds and large drainage basins. The rule can also be applied to non-hierarchically related polygon feature classes, such as soil type and slope class.

Must Be Covered By

This rule requires that polygons of one feature class must be contained within polygons of another feature class. Polygons may share edges or vertices. Any area defined in the contained feature class must be covered by an area in the covering feature class. This rule is used when area features of a given type must be located within features of another type. This rule is useful when modeling areas that are subsets of a larger surrounding area, such as taxiways within aircraft movement areas.

Boundary Must Be Covered By

This rule requires that boundaries of polygon features must be covered by lines in another feature class. This rule is used when area features need to have line features that mark the boundaries of the areas. This is usually when the areas have one set of attributes and their boundaries have other attributes. For example, parcels might be stored in the geodatabase along with their boundaries. Each parcel might be defined by one or more line features that store information about their length or the date surveyed, and every parcel should exactly match its boundaries.

Area Boundary Must Be Covered By Boundary Of

This rule requires that boundaries of polygon features in one feature class be covered by boundaries of polygon features in another feature class. This is useful when polygon features in one feature class, such as subdivisions, are composed of multiple polygons in another class, such as parcels, and the shared boundaries must be aligned.




Contains Point

This rule requires that a polygon in one feature class contain at least one point from another feature class. Points must be within the polygon, not on the boundary. This is useful when every polygon should have at least one associated point, such as when parcels must have an address point.

Line Rule Rule Description

Must Not Overlap This rule requires that lines not overlap with lines in the same feature class. This rule is used where line segments should not be duplicated; for example, in a stream feature class. Lines can cross or intersect but cannot share segments.

Must Not Intersect

This rule requires that line features from the same feature class not cross or overlap each other. Lines can share endpoints. This rule is used for contour lines that should never cross each other or in cases where the intersection of lines should only occur at endpoints, such as street segments and intersections.

Must Not Have Dangles

This rule requires that a line feature must touch lines from the same feature class at both endpoints. An endpoint that is not connected to another line is called a dangle. This rule is used when line features must form closed loops, such as when they are defining the boundaries of polygon features. It may also be used in cases where lines typically connect to other lines, as with streets. In this case, exceptions can be used where the rule is occasionally violated, as with cul-de-sac or dead end street segments.

Must Not Have Pseudonodes

This rule requires that a line connect to at least two other lines at each endpoint. Lines that connect to one other line (or to themselves) are said to have pseudonodes. This rule is used where line features must form closed loops, such as when they define the boundaries of polygons or when line features logically must connect to two other line features at each end, as with segments in a roadway network, with exceptions being marked for the originating ends of first-order roadways.

Must Not Intersect Or Touch Interior

This rule requires that a line in one feature class must only touch other lines of the same feature class at endpoints. Any line segment in which features overlap or any intersection not at an endpoint is an error. This rule is useful where lines must only be connected at endpoints, such as in the case of lot lines, which must split (only connect to the endpoints of) back lot lines and which cannot overlap each other.

Must Not Overlap With

This rule requires that a line from one feature class not overlap with line features in another feature class. This rule is used when line features cannot share the same space. For example, roads must not overlap with railroads or depression subtypes of contour lines cannot overlap with other contour lines.

Must Be Covered By Feature Class Of

This rule requires that lines from one feature class must be covered by the lines in another feature class. This is useful for modeling logically different but spatially coincident lines, such as routes and streets. A bus route feature class must not depart from the streets defined in the street feature class.

Must Be Covered By Boundary Of

This rule requires that lines be covered by the boundaries of area features. This is useful for modeling lines, such as lot lines, that must coincide with the edge of polygon features, such as lots.

Endpoint Must Be Covered By

This rule requires that the endpoints of line features must be covered by point features in another feature class. This is useful for modeling cases where a fitting must connect two pipes, or a street intersection must be found at the junction of two streets.

Must Not Self Overlap

This rule requires that line features not overlap themselves. They can cross or touch each other, but must not have coincident segments. This rule is useful for features such as streets, where segments might touch in a loop, but where the same street should not follow the same course twice.

Must Not Self Intersect This rule requires that line features not cross or overlap themselves. This rule is useful for lines, such as contour lines, that cannot cross themselves.

Must Be Single Part

This rule requires that lines not have any breaks. This rule is useful where line features, such as highways, may not have multiple unconnected parts.




Point Rule Rule Description

Must Be Covered By Boundary Of

This rule requires that points fall on the boundaries of area features. This is useful when the point features help support the boundary system, such as boundary markers, which must be found on the edges of certain areas.

Must Be Properly Inside Polygons

This rule requires that points fall within area features. This is useful when the point features are related to polygons, such as wells and well pads or address points and parcels.

Must Be Covered By Endpoint Of

This rule requires that points in one feature class must be covered by the endpoints of lines in another feature class. This rule is similar to the line rule, "Endpoint Must Be Covered By," except that, in cases where the rule is violated, it is the point feature that is marked as an error, rather than the line. Boundary corner markers might be constrained to be covered by the endpoints of boundary lines.

Must Be Covered By Line

This rule requires that points in one feature class be covered by lines in another feature class. It does not constrain the covering portion of the line to be an endpoint. This rule is useful for points that fall along a set of lines, such as taxiway signs along taxiways.



2.4.10. Symbology

Symbology will be created according to the symbol dataset used by Aviation Department GIS. The data

creator will contact the Aviation Department’s Project Manager to obtain the latest version of the symbol

dataset prior to beginning the data development.

2.5. GIS DATA CREATION RULES

GIS data will be created to be consistent with the data creation rules defined in the “Phoenix Sky Harbor

International Airport GIS Data Creation Rules” document. Any outside organization must contact the

City of Phoenix Aviation Department’s GIS Manager to obtain the latest version of the Geodatabase

Design prior to beginning data development.


3. DATA DELIVERY AND ACCEPTANCE

3.1. DELIVERY FORMATS AND MEDIA

All data shall be submitted in a stable electronic media format. The media shall be of an acceptable type

to the Aviation Department. If the delivery is larger than available space on a single disk or tape, an

alternative delivery approach shall be pre-approved by the Aviation Department.

3.2. DELIVERY PROCEDURES

This section applies to all data that will be created by external organizations for inclusion into the GIS.

3.2.1. Data Security

All GIS data shall be created exclusively for use and ownership by the Aviation Department, and no

copies of the data will be provided to any other parties.

3.2.1.1. Before Delivery

The submitting organization will acknowledge their understanding of the requirements of the Spatial Data

Standards and their commitment to them in a formal letter to the city within 30 days of the initiation of

any project that will deliver GIS data.

The submitting organization must develop a Quality Control plan that meets the requirements of this

standard and submit it in a formal letter to the city within 60 days of the initiation of any project that will

deliver GIS data. The plan must be approved by the Aviation Department Project Manager prior to any

data being developed.

The submitting organization shall document and enforce a process that ensures the security of the data

before delivery, at the security level the data established in the contract.

3.2.1.2. At Delivery

The submitting organization shall provide for transport of the data in a secure manner from their office to

the Aviation Department GIS. Chain-of-custody documentation (including transmittal) shall be

established by the organization for each spatial data delivery.

As part of each data delivery, the submitting organization must remit a document certifying that the data

to be delivered to Aviation Department was reviewed by the vendor and it was found to be in compliance

with the standards. The document will contain an inventory of the data and will document any deviations

from the standard that were detected. All such deviations shall be examined by Aviation Department who

will then make a determination whether the dataset submitted is acceptable or not.

Unapproved deviations from the standard may be subject to rejection of the entire submittal.

3.2.1.3. After Loading/Post-Use

Delivered GIS data media shall be stored in an appropriate secure location by Aviation Department..


3.3. DATA DEVELOPMENT QUALITY CONTROL AND QUALITY ASSURANCE

3.3.1. Quality Assurance Requirements

The quality assurance requirements for GIS data are as follows:

3.3.1.1. Quality Control Testing

As defined in this document and the contract scope, 100% of the GIS data must pass the quality control

testing. A quality control report must be included with each submittal that documents the quality control

testing that was performed, the results that were reported, and any corrective action that was taken. If any

waivers to the standard were granted, those waivers must also be included with the submittal.

3.3.1.2. Spatial Data

Standards defining the accuracy of spatial data have been developed by the U.S. Geological Survey, and

can be found at http://erg.usgs.gov/isb/pubs/factsheets/fs17199.html. This standard will be applied to all

data developed according to this document, except that no less than 95% of the spatial data will be placed

within the defined national map accuracy standards based on the nominal accuracy of the product map, or

as defined in the contract scope.

This requirement will be evaluated by visual spot checks versus original source documents. The data

creator will perform a spot check using a statistically significant sample size based on random selection

methodology that will compute a confidence interval that the accuracy is within the parameters of the

requirements. This test will be fully documented with a memo stating that the procedures were undertaken

and that the actual results obtained are within the constraints.

3.3.1.3. Attribute Data

No less than 95% of the attribute data for each feature will be accurate.

This requirement will be evaluated by programmatic checks and/or spot checks versus original source

documents. The data creator will perform a spot check using a statistically significant sample size based

on random selection methodology that will compute a confidence interval that the accuracy is within the

parameters of the requirements. This test will be fully documented with a memo stating that the

procedures were undertaken and that the actual results obtained are within the constraints.

3.3.2. Quality Control Requirements

All data to be entered into the Aviation Department GIS will be subjected to a rigorous quality control

process to ensure that it is compliant with this standard. The submitter will perform an electronic, pre-

submission quality control check of each spatial data deliverable. A report documenting the results of the

quality control process shall be submitted with each spatial deliverable to the Aviation Department.

3.4. ACCEPTANCE TESTING PROCEDURES

Acceptance of a spatial data delivery to the Aviation Department GIS shall be evaluated against the

criteria in this document.


The Aviation Department shall run a quality control application that programmatically checks and reports

the compliance with the Spatial Standards of the deliverable. The Aviation department may reject

submittals that exceed the quality thresholds. The quality control checks will include but not be limited to:

• Attribute domain conformance

• Attribute integrity

• Topologic integrity

• Spatial accuracy

3.4.1. Attribute Domain Conformance

All attributes will be evaluated against the domains defined for each feature class and attribute. Any

values that fail these criteria will be flagged. If the submitting organization believes that the domain

values should be modified, this information must be submitted to the Aviation Department for review at

least 30 days prior to submission of the data.

3.4.2. Attribute Integrity

All attributes will be evaluated against the GIS Data Creation Rules using an automated checking process.

Any values that fail these criteria will be flagged. If the submitting organization believes that the data

creation rules should be modified, this information must be submitted to the Aviation Department for

review at least 30 days prior to submitting the data.

3.4.3. Topologic Integrity

All topology will be evaluated against the GIS Data Creation Rules using an automated checking process.

Any values that fail these criteria will be flagged. If the submitting organization believes that the data

creation rules should be modified, this information must be submitted to the Aviation Department for

review at least 30 days prior to submitting the data.

3.4.4. Spatial Accuracy

Spatial accuracy will be evaluated through a visual inspection procedure. The visual inspection will be

performed by comparing the ArcGIS features with the scanned images (where available), with the digital

orthophotos, and with the source documents. In addition Aviation Department may choose to survey

certain features for comparisons to the database submittal. Any anomalies uncovered during the

inspection will be identified. All topographic data (contours) are to be certified by a Registered Land

Surveyor to meet the requirements of Arizona Revised Statutes Title 32, Chapter 1.

3.4.5. Quality Control Report

All data items that have been flagged from the quality control processes will be documented in a quality

control report. If the dataset fails the quality control criteria, the dataset will be returned to the submitter

for rework. The updated data will be resubmitted for acceptance until it passes the quality control testing.

3.4.6. Accepted Data

Once the data has passed the quality control process, it will be loaded into the Aviation Department’s GIS

system. Aviation Department will then formally accept the data.


4. SAMPLE GEODATABASE DESIGN REPORT

The Aviation Department GIS Geodatabase Design Report will be a separate document, containing the

output from ESRI’s Geodatabase Reporting Tool.

A sample of the first few pages of such a report is provided below.

Geodatabase Reporting Tool

Date Of Report 03/28/2002 8:15:22 AM

Generated By Sushka (on SUSHKA)

Geodatabase Type Personal [Version 1.1.0 (Current Release)]

Database G:\GI\Projects\59921-SarasotaES\Database\Sarasota_Sanitary.mdb

Geodatabase Report Contents

Geodatabase Summary

Geometric Network Summary

Edge-Junction-Edge Geometric Network Connectivity Rules

Edge-Junction Geometric Network Connectivity Rules

ObjectClass Information

RelationshipClass Information

Domain Information

RasterDataset Information

Spatial Reference Information

Row/Feature Count Information

Version Information

Privilege Information


Geodatabase Summary

FeatureDataset Object Name (Alias) Type Geometry Subtypes

ssAnode (ssAnode) (C) Simple Feature Point None

ssCasing (ssCasing) (C) Simple Feature Polygon AccessTunnel Casement ConduitBridge ProtectiveTunnel

ssScadaSensor (ssScadaSensor) (C) Simple Feature Point None

ssSpatialOperationsRecord (ssSpatialOperationsRecord) (C) Simple Feature Point

Inspection Leak Maintenance Repair

ssThrustProtection (ssThrustProtection) (C) Simple Feature Polygon

Anchor Blocking Deadman Kicker

ssUndergroundEnclosure (ssUndergroundEnclosure) (C) Simple Feature Polygon

MeterBox ValveVault Vault

Sewer Features (S)

ssWaterStructure (ssWaterStructure) (C) Simple Feature Polygon

DischargeStructure DiversionChamber DiversionPoint JunctionChamber LiftStation ProductionWell PumpStation SplitManhole StorageBasin TideChamber TreatmentPlant

ssCatchBasin (ssCatchBasin) (C) Simple Feature Point None

ssCleanOut (ssCleanOut) (C) Simple Feature Point Cleanout FlushingStructure LampHole

ssControlValve (ssControlValve) (C) Simple Feature Point

AirControl AirGap AirRelease Altitude AtmosphericVacuum BackflowControl CVCombination DoubleCheck PressureVacuum ReducedPressureBackflow RPZ SimpleCheck VacuumBreaker VacuumRelease VacuumValve

Sewer Network (S)

ssDischargePoint (ssDischargePoint) (C) Simple Feature Point None


ssFitting (ssFitting) (C) Simple Feature Point

Bend Cap Coupling Cross ExpansionJoint Offset Reducer Riser Saddle Sleeve Tap Tee Weld Wye

ssGravityMain (ssGravityMain) (C) Simple Feature Polyline

Collector Culvert InlineStorage Interceptor InvertedSiphon OpenChannel Outfall Overflow Tunnel

ssLateralLine (ssLateralLine) (C) Simple Feature Polyline

Combination Commercial Domestic Industrial Irrigation

ssLateralPoint (ssLateralPoint) (C) Simple Feature Point None

ssManhole (ssManhole) (C) Simple Feature Point None

ssMeter (ssMeter) (C) Simple Feature Point

FlowTube Flume Magnetic MeterTurbine ModifiedVenturi Multijet OrificePlate Propeller Proportional Sonic Venturi Weir

ssNetworkStructure (ssNetworkStructure) (C) Simple Feature Point

DischargeStructure DiversionChamber DiversionPoint JunctionChamber LiftStation ProductionWell PumpStation SplitManhole StorageBasin TideChamber TreatmentPlant

ssPressurizedMain (ssPressurizedMain) (C) Simple Feature Polyline

Force PipeBridge Pressure Vacuum

ssPump (ssPump) (C) Simple Feature Point AxialFlow Centrifugal Jet


Reciprocating Rotary Screw Turbine

ssSystemValve (ssSystemValve) (C) Simple Feature Point

Ball Butterfly Cone Gate Plug

ssAnalysisPoint (ssAnalysisPoint) (C) Table None None

ssBarrel (ssBarrel) (C) Table None None

ssBarScreen (ssBarScreen) (C) Table None None

ssChemicalInjector (ssChemicalInjector) (C) Table None None

ssControlValve_Has_SpatialRecord RelationshipClass ssControlValve->ssSpatialOperationsRecord

ssControlValve_WHControlValve_Relate RelationshipClass ssControlValve->ssWarehouseControlValve

ssConValve_Has_AnalysisPoint RelationshipClass ssControlValve->ssAnalysisPoint

ssGravityMain_Has_SpatialRecord RelationshipClass ssGravityMain->ssSpatialOperationsRecord

ssLateralLine_Has_SpatialRecord RelationshipClass ssLateralLine->ssSpatialOperationsRecord

ssMeter_Has_AnalysisPoint RelationshipClass ssMeter->ssAnalysisPoint

ssMeter_WHMeter_Relate RelationshipClass ssMeter->ssWarehouseMeter

ssMotor (ssMotor) (C) Table None None

ssOperationsRecord (ssOperationsRecord) (C) Table None None

ssPressMain_Has_SpatialRecord RelationshipClass ssPressurizedMain->ssSpatialOperationsRecord

ssPump_WHPump_Relate RelationshipClass ssPump->ssWarehousePump

ssRegulator (ssRegulator) (C) Table None None

ssStandByPower (ssStandByPower) (C) Table None None

ssSystemValve_Has_AnalysisPoint RelationshipClass ssSystemValve->ssAnalysisPoint

ssSystemValve_Has_SpatialRecord RelationshipClass ssSystemValve->ssSpatialOperationsRecord

ssSysValve_WHSysValve_Relate RelationshipClass ssSystemValve->ssWarehouseSystemValve

ssTideGate (ssTideGate) (C) Table None None

None

ssWarehouseControlValve Table None WHControlValveAirControl WHControlValveAirGap


(ssWarehouseControlValve) (C) WHControlValveAirRelease WHControlValveAltitude WHControlValveAtmosphericVacuum WHControlValveBackflowControl WHControlValveCombination WHControlValveDoubleCheck WHControlValvePressureVacuum WHControlValveReducedPressureBackflow WHControlValveRPZ WHControlValveSimpleCheck WHControlValveVacuum WHControlValveVacuumBreaker WHControlValveVacuumRelease

ssWarehouseMeter (ssWarehouseMeter) (C) Table None

WHMeterFlowTube WHMeterFlume WHMeterMagnetic WHMeterModifiedVenturi WHMeterMultijet WHMeterOrificePlate WHMeterPropeller WHMeterProportional WHMeterSonic WHMeterTurbine WHMeterVenturi WHMeterWeir

ssWarehousePump (ssWarehousePump) (C) Table None

WHPumpAxialFlow WHPumpCentrifugal WHPumpJet WHPumpReciprocating WHPumpRotary WHPumpScrew WHPumpTurbine

ssWarehouseSystemValve (ssWarehouseSystemValve) (C) Table None

WHSystemValveBall WHSystemValveButterfly WHSystemValveCone WHSystemValveGate WHSystemValvePlug

EnabledDomain Domain Coded Value

ssDomainAccessDiameter Domain Range

ssDomainAccessType Domain Coded Value

ssDomainAdministrativeArea Domain Coded Value

ssDomainBoolean Domain Coded Value

ssDomainFrameCoverMaterial Domain Coded Value

ssDomainGravityMainShapes Domain Coded Value

ssDomainJointType Domain Coded Value

ssDomainJunctionMaterial Domain Coded Value

ssDomainLifecycleStatus Domain Coded Value

ssDomainMainDistributionDiameter Domain Coded Value


ssDomainManufacturer Domain Coded Value

ssDomainNetworkStructureUsage Domain Coded Value

ssDomainOperatingArea Domain Coded Value

ssDomainPressurizedMainDiameter Domain Range

ssDomainScadaSensorType Domain Coded Value

ssDomainWarehouseStatus Domain Coded Value

ssDomainWaterLineMaterial Domain Coded Value

ssDomainWaterType Domain Coded Value

ssDomainWHSystemValveRegulationType Domain Coded Value

Geometric Network Summary

This Geodatabase does not contain any GeometricNetworks.

Edge-Junction-Edge Geometric Network Connectivity Rules


Edge-Junction Geometric Network Connectivity Rules


ObjectClass Information

ssAnode (Simple Feature) (Point)

No Subtypes

Field Name Field Type Pre Sc Len DV Domain

OBJECTID OID 0 0 4

Shape Geometry 0 0 0


LifecycleStatus String 0 0 20 Active ssDomainLifecycleStatus

AdministrativeArea String 0 0 60 ECO ssDomainAdministrativeArea

FacilityID String 0 0 20

InstallDate Date 0 0 8

OperationalArea String 0 0 60 ssDomainOperatingArea

WorkorderID String 0 0 20

Subtype Integer 0 0 4 1

Elevation Double 0 0 8

LocationDescription String 0 0 255

WaterType String 0 0 255 Sewage ssDomainWaterType

AnodeCount Integer 0 0 4

Material String 0 0 20 ssDomainJunctionMaterial

Weight String 0 0 10

ssCasing (Simple Feature) (Polygon)

Subtype: Casement (Subtype = 1) [Default]


OBJECTID OID 0 0 4













Diameter Integer 0 0 4 20 ssDomainMainDistributionDiameter

Material String 0 0 20 ssDomainWaterLineMaterial

RecordedLength Double 0 0 8

Shape_Length Double 0 0 8

Shape_Area Double 0 0 8

Subtype: ConduitBridge (Subtype = 2)


OBJECTID OID 0 0 4












Diameter Integer 0 0 4 20 ssDomainMainDistributionDiameter

Material String 0 0 20 ssDomainWaterLineMaterial

RecordedLength Double 0 0 8

Shape_Length Double 0 0 8

Shape_Area Double 0 0 8


5. SAMPLE GIS DATA CREATION RULES

The actual GIS data creation rules are contained in a separate document. The content below is a just a

sample of the information contained in the data creation rules.