geographic information ystem spatial data …
TRANSCRIPT
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 2
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 3
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 4
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 5
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 6
• 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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 7
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 8
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.)
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 9
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 10
Table 4. Topology Rules
Rule Rule Description
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 11
Table 4. Topology Rules
Rule Rule Description
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 12
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 13
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 14
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..
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 15
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 16
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.
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 17
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 18
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 19
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 20
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 21
(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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 22
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
This Geodatabase does not contain any GeometricNetworks.
Edge-Junction Geometric Network Connectivity Rules
This Geodatabase does not contain any GeometricNetworks.
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 23
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]
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 24
WaterType String 0 0 255 Sewage ssDomainWaterType
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)
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 2
Elevation Double 0 0 8
LocationDescription String 0 0 255
WaterType String 0 0 255 Sewage ssDomainWaterType
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
Spatial Data Standards Specification Version 1.1 Revised July 2008 GIS Implementation—Phoenix Sky Harbor International Airport, City of Phoenix, Arizona 25
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.