Corporate Spatial Data Infrastructure Standards

(1)

Corporate Spatial Data Infrastructure

Standards

Version 2.4

Prepared by:

Geomatics Yukon

Department of Environment

Department of Energy, Mines, and Resources

Pacific GeoTech Systems North Inc.

(2)

1 REVISION HISTORY

This section of the document records various releases of this document. Initial releases will start with 0.1. The first approved published release will be 1.0.

Release Date Author Details/Description

0.1 November

28, 2005

PGTS North Inc. Draft

0.2 December

04, 2005

PGTS North Inc., Lauren Crooks, Stuart Alexander, Manon Desforges and Gerry Perrier

Revised based on Lauren Crooks, Stuart.Alexander, Manon.Desforges and Gerry Perrier comments

0.3 December

06, 2005

Lauren Crooks, Stuart Alexander, Manon Desforges, Gerry Perrier and Eugen Toaxen

Added roles and responsibilities, new schema naming from Lauren, other edits

0.4 December

12, 2005

Lauren Crooks, Stuart Alexander, Manon Desforges, Gerry Perrier, Diedre Davidson and Eugen Toaxen

Revised document

0.5 January 6th

2006

Olga Kopriva, Eugen Toaxen Incorporate changes from

version 0.2,3,4. Revised Operational, added delivery structure

0.6 January 17th

2006

Lauren Crooks, Stuart Alexander, Manon Desforges, Diedre Davidson, Eugen Toaxen and Olga Kopriva

Data Standard review workshop. Changed recommendations to decisions.

1 January 23rd

2006

Olga Kopriva Incorporating changes from

January 17th workshop, creating appendix X “Parking Lot” attachment for decisions and samples appendix C

1.1 August 3,

2006

Lauren Crooks Incorporating changes from

implementation of Phase 1. Updating and ensuring consistency of terminology. Correcting grammatical and spelling mistakes.

1.2 September

30, 2006

Lauren Crooks Updating for CSW2

(Geoconnections project)

2.0 March 19,

2007

Lauren Crooks Incorporating standards

developed during CSW2 – needs approval of DAC before official

2.1 June 26,

2008

Lauren Crooks Updating schemas and sde

feature classes, feature class naming, appendix A

2.2 Dec 4, 2008 Lauren Crooks Updating schemas and sde

feature classes, feature class naming, add TBL as a feature_geometry_type

2.3 October 25,

2010

Lauren Crooks Updating Appendices A and B

2.4 November 9,

2011

(5)

2 INTRODUCTION

2.1 Background

2.2 Overview of the Corporate Spatial Data Infrastructure (CSDI)

project

The objective of this document is to identify the minimum standards necessary for Yukon government to fully implement the Corporate Spatial Data Infrastructure (CSDI). This report sets the direction that will guide the Information & Communications Technology (ICT) Department and other related Yukon Departments through the implementation of the Corporate Spatial Warehouse (CSW) and Operational databases. There are several objectives of the CSDI implementation. When all the following objectives are met, the CSDI implementation will be considered complete:

1. A corporate spatial warehouse is created as a read-only ESRI Spatial Database Engine (SDE)/Oracle database;

2. Operational database environment(s) are created and configured that support day to day editing, maintaining and updating of each business area;

3. Relevant datasets are migrated and managed in an SDE Operational database within the CSDI infrastructure;

4. Clear standards have been defined for SDE layer naming, symbology, metadata requirements and access security;

5. Relevant datasets are migrated from existing formats and department environments to the warehouse;

6. Enterprise applications are in place to facilitate data access, management, and editing where necessary. Department-specific applications are migrated or their relevant functionality integrated into other business applications; and

7. Data is accessible to users via Web Map Viewer and/or GIS desktop tools.

2.3 Purpose of the Corporate Spatial Data Infrastructure is

• To maintain data integrity by limiting insert, delete, and update privileges; • To protect sensitive or confidential information;

• To enforce copyrights and data-use agreements; • To ensure that standards are followed;

• To guide the growth of the warehouse;

• To ensure that the warehouse contains appropriate data; and • To serve clients in support of day to day operations;

(6)

2.4 Scope

The scope of the Corporate Spatial Data Infrastructure is reflected in the range of services, content and data formats that are offered:

• Services o Metadata o Distribution o Access o Population o Support • Types of Content

o Cadastre ( for example, tenures, ownership, boundaries) o Resource Information (vegetation, fisheries, wildlife, ecology) o Territorial Atlas (rivers, roads, buildings, topography, survey) o Planning and Analysis Information (any planning units) • Data format

o Tabular (attribute data) o Vector (spatial data) o Raster (images)

o Documents (associated with other CSDI content)

The scope of the CSDI project is to:

• Establish a corporate repository for integrated land, resource and geographic data that supports a variety of business requirements for the natural resource sector, other government agencies, industry and the public;

• Provide unified access and discovery services to qualified clients with the ability to view and locate data from CSW;

• Provide clients with key information that supports their day to day operational needs such as data views, data downloads, data distribution and querying capability; • Provide clients with data administration and population services;

• Encourage custodians to populate the warehouse with well structured, integrated and analyses-ready datasets;

• Establish the corporate spatial warehouse by consolidating and rationalizing existing operational datasets; and

(7)

• Improve the relevance and value of existing spatial data by replacing data silos with data in the corporate spatial warehouse.

2.5 Definitions

ArcSDE Layer

An Oracle object/table that has been spatially referenced. An ArcSDE layer references an ESRI Feature Class and defines characteristics about how it is represented when displayed or printed.

AXL File

(pronounced 'axle file'). A file in XML format used by ArcIMS that stores the path to a source dataset and other layer properties, including symbology. Similar to a 'Layer File'. Business View

A non-physical grouping of data for a specific business need. See also 'View'. Coverage

A proprietary data storage format for storing geographic features using ArcInfo software. A coverage stores a set of thematically associated data considered to be a unit. In a coverage, features are stored as both primary features (points, arcs, polygons) and secondary features (tics, links, annotation). Feature attributes are described and stored independently in feature attribute tables. Coverage’s usually represent a single layer, such as soils, streams, roads, or land use.

Data Attribute

A particular characteristic of a data entity for which information is to be collected. For example, weight and gender could be attributes of a ‘Person' entity.

Data Collection

An aggregation of datasets or similar data. Data Set

A managed grouping of similar business data with a single data custodian. The data that results from and is maintained by a distinct set of processes within a business area. Examples include Base data, Geology data, Forestry data, and Mineral data. Data Warehouse

A collection of software and data organized to collect, cleanse, transform and store data from a variety of sources, and analyze and present information to support decision-making, tactical and strategic business processes.

Feature

An abstraction of a real world phenomenon; it is a geographic/spatial feature if it is associated with a location relative to the Earth. A feature is a single instance of a feature class.

Feature Class

A collection of geographic features with the same geometry type (such as point, line, or polygon), the same attributes, and the same spatial reference. Feature classes can be defined in Geo-database, shape files, coverages, or other data formats. Feature classes allow homogeneous features to be grouped into a single unit for data storage purposes. For example, highways, primary roads, and secondary roads can be grouped into a line feature class named "roads."

(8)

A group of layers that appear and act as a single layer. Group layers make it easier to organize a map, assign advanced drawing order options, and share layers for use in other maps.

Layer

The visual representation of a geographic dataset in any digital map environment. Conceptually, a layer is a slice or stratum of the geographic reality in a particular area, and is more or less equivalent to a legend item on a paper map. The physical grouping of a geographic data set somewhat equivalent to a grouping of (a) feature class. Also known as 'Map Layer'. See also 'ArcSDE Layer'.

Materialized View

A table which is automatically updated based on a pre-defined view definition and update interval. Materialized views have two usages: for replication and for performance. See also 'View'.

Presentation View

A grouping of data with display properties, usually based on a specific business need. See also 'View'.

Spatial View

Spatially enabled view of feature classes that may or may not be combined with attribute data.

Theme

1) A business grouping of data with one or more custodians. 2.) A complete set of layers with unique symbology bundled together to meet a specific business requirement in a mapping application. 3.) In ArcView 3.x, a set of related geographic features such as streets, parcels, or rivers, along with their attributes. All features in a theme share the same coordinate system, are located within a common geographic extent, and have the same attributes.

View

A means of accessing a subset or superset of data. See also 'Business View', 'Database View', 'Materialized View', 'Presentation View', 'Spatial View'.

3 CSDI Governance, Principles, and Technical Roles

CSDI governance is described in a separate document, entitled Corporate Spatial Data Infrastructure Governance. Governance describes decision making authority. Technical roles and responsibilities for implementing and maintaining the CSDI are described below in Section 3.3.

3.1 CSDI Principles

The following are the principles under which the CSDI will operate. 3.1.1 Data quality

The corporate spatial warehouse should contain data of (i) the highest quality available based on business needs; and (ii) of known quality that is documented in metadata. There may be cases where data availability is more important than data quality; in those cases, the warehouse should contain such data.

(9)

3.1.2 Data integration

Full spatial integration of all data is a long-term goal. In the meantime, proper registration/alignment with Data Advisory Committee approved bases, used in the warehouse is the next best thing.

3.1.3 Access to data

Data Custodians (defined in Corporate Spatial Data Infrastructure Governance) have ultimate authority on access. Access privileges must conform to Access to Information and Protection of Privacy (ATIPP) legislation, copyright, sensitivity issues, etc.

3.1.4 Data management

• All data editing occurs in operational systems outside of the warehouse; • Data redundancy should be avoided; and

• Data subsets are best created with Views

3.3 Technical Roles

3.3.1 ICT Database Administrators (DBAs)

Application Services staff at ICT are responsible for:

• Assisting Geomatics Yukon with maintaining a stable CSDI Environment; • Developing, maintaining and monitoring CSDI Oracle database services; • Managing Oracle accounts and user groups; and

• Backing up the Oracle databases. 3.3.2 ICT Network Administrators

• Assisting Geomatics Yukon with maintaining a stable CSDI Environment; and • Building and maintaining the CSDI infrastructure – server hardware and network 3.3.3 SDE Administrator

The SDE Data Administrator is responsible for:

• Maintaining a stable CSW SDE Environment with support from other Geomatics and ICT staff;

• Providing operational SDE support;

• Developing, maintaining and monitoring spatial data services (i.e. ArcSDE services,); and

• Making sure population processes (acquirers) from the Operational repositories to the Warehouse are reliable and secure.

3.5 Responsibilities

3.5.1 Use, Distribution and Support Responsibilities

1. Custodian must establish consistent rules for distribution of data to client groups. 2. Security profile is mandatory.

(10)

4. Support to users questions must be available via help desk ([email protected])

4 Oracle/SDE Database Standards

4.1 Oracle Standards

The Department of Environment Oracle standard is adopted for the CSDI: YEIS_Standards_v2.doc.

4.2 SDE conventions

4.2.1 Schema Naming

Schema can include data from more than one custodian and include multiple scales. Schema should group data from similar subject areas. This is the dominant factor. The Oracle schema will be used as a subject area for classifying or grouping the data as determined by the Data Advisory Committee. Appendix B shows the Data Classification Hierarchy. The first level is a broad subject area grouping and will not be reflected in ArcSDE (however it will be used in Metadata, Layer files, and presentation services). The second level is the subject area and will be used as the actual schema name. The third level is the SDE feature class name (data layer).

4.2.1.1 Constraints

1. Oracle physical table generation restricts names to 30 characters; therefore, SDE feature class names may be up to 30 characters long. The schema name is not included in the 30 characters, just the prefix, descriptive name, and suffix. To allow for the creation of spatial views with the same name as the base table, feature class names should be restricted to 26 characters except for those feature classes that will never have spatial views (e.g. rasters).

2. Feature class names must start with a letter, and may contain only letters, digits, and '_' (underbar).

3. Names cannot contain blanks; therefore, words within the name will be separated by '_' (underbar).

4. Oracle table names are case-insensitive. Although names can be entered and queried in upper or lower case, they will be stored and compared in UPPER CASE only. 5. SDE includes a layer description field, which is limited to 63 characters. This is a free

text field, which may contain blanks and other punctuation. 4.2.2 Feature Class Naming

Org Code>_<Intuitive Descriptive Name >_ <Version>_<Feature Geometry>_<Compilation Scale>

(11)

Org Code: section. OPTIONAL Refer to Appendix A for codes.

Intuitive/Descriptive Name section. MANDATORY.

This section must contain a descriptive name, with words separated by '_'. The intention is that the name should be as intuitive of the information the layer contains as is possible, e.g. GAME_MGMT_SUBZONE. The name should be singular.

Feature Classes that are identical at different scales, must have identical names except for the compilation scale section. Base table names and spatial views should be identical. For feature classes that have imagery or raster feature geometry type, the resolution of the data is contained within this section after the descriptive name. For imagery data, either “satellite” or “ortho” is also contained within this section after the resolution. Example:

BLUE_MARBLE_500M_SATELLITE_IMG.

This section of the layer name could also contain a code for the geographic extent of the layer data if it is needed to distinguish the dataset. This is a mandatory field.

Version section. OPTIONAL. Versions are represented by dates. If version is used, the Year is mandatory. Format is YYYYMMDD.

The capture date is optional and should be only used if required for name uniqueness. Month naming convention

JA FE MR AP MY JU JL AU SP OC NO DE

Feature geometry type section. MANDATORY (5 CHAR) POLY PT LN LLN ANNO IMG

(12)

RSTR COGO TBL

The exception is for POLY: where AREA is part of the descriptive name, it is optional. E.g. PARK_PROTECTED_AREA.

Satellite or orthoimagery has the feature geometry type IMG. Other raster data like DEMs, shaded relief, classed data has the feature geometry type RSTR.

LLN refers to leader line (associated with annotation) TBL refers to a table with no geometry (as in NRN)

Compilation Scale section. MANDATORY when the data have been compiled against a particular scale of base data. An exception, where this is NOT mandatory, is for raster (RSTR) and image (IMG) feature classes. Rather data resolution is contained within the intuitive/descriptive name.

10K 25K 50K 250K 1M 2M 4.2.3 Role naming 4.2.3.1 Standard Roles

A standardized security authorization service should be developed as part of the CSW project. It is recommended to create a hierarchical role based security infrastructure. Each layer in CSW is one of the three roles:

• Public (IMS_SELECT);

• Government (CSW_YNET, schemaname_BASE); and • Special Access.

(13)

Special Access roles can be used to control the access to subsets of layers (e.g. by department or business area, data owner or custodian, data set version, etc.) to end-users or groups of end-users. The ‘sensitive’ layers need to be identified and flagged in the Discovery and Metadata review process.

Database accounts will fall into the following categories: 1. Data administration;

2. Web applications; Each Web application will require two unique proxy accounts (application Oracle users) (i) A development proxy account for use by the developer. This account will be locked and password reset when the new or updated application is promoted to production; and (ii) a production proxy account to be utilized by the application when it is promoted to production; haven’t implemented this – should we? 3. Custom client server application (requiring individual database accounts); and

4. Direct-connect analytical user (government staff or government sponsored) using tools like ArcGIS and Oracle SQL.

4.2.3.2 Oracle Roles for Specific Access

In general, when a role is defined in the corporate warehouse, these rules must be followed:

» When possible, must be defined hierarchically. This means that any role must be based in any other role with lower hierarchy,unless the role is intended to be used with the most basic grants and there is no role with a lower hierarchy.

» Must be related to a data custodian/steward or data classification schema name unless the role is intended to be used for database administrative purposes; » Must not include any Oracle - specific roles, such as RESOURCE or CONNECT For role naming, the following standards are suggested:

Government S p e c ia l A c c e s s Public S p e c ia l A c c e s s S p e c ia l A c c e s s S p e c ia l A c c e s s S p e c ia l A c c e s s S p e c ia l A c c e s s

(14)

• Use only the characters A-Z and underscores (_).

• Use a maximum of 30 characters, including underscores. • Use the following naming convention:

CSW_<Data_Custodian_short_name>_<Security_level>

Where:

Data Custodian/Classification short name: Up to 17 characters. It defines the short name of the data classification schema name as it is defined in the database or intended Data

Custodian/Steward name.

In the cases in which a specific role to access the information belonging to different data classification schemas is required, the short name must describe as much as the purpose of the role. However, the creation of specific roles must be avoided, concentrating the efforts in a better distribution of the layers in different data classification categories. Examples:

- If the data classification schema name is CSW_ADMIN_BOUNDARIES, its short

name could be CSW_ADMN_BOUND_

Security level: This portion of the role name is intended to describe the purpose of the role. Below is a list of descriptive words that can be used to describe specific aspects of a role.

ADMIN

Highest role assigned to an entire business dataset corresponding to a specific data custodian/steward. There should be only one ADMIN role for each data classification or business area. If there is a need for two different roles that have similar but different administration needs, the MGR name should be used instead.

MGR Highest role for a portion of an application or business area. MGR roles are junior in

privileges to the ADMIN role USER

Least privileged role used by a functional area. May require the base role. Due to the multiple uses of the term user, adding additional description to the role name is mandatory (e.g. CSW_MVB_DRIV_EXECUTIVE_USER)

BASE

Least privileged role for an application or functional area; replaces roles such as READ_ONLY, SELECT and IMF used in operational databases. A base role must never have “child” roles.

xxx

Lower levels of security (business area or individual business specific functions) should be described using a descriptive name (e.g.

CSW_MVB_VEH_ACCOUNTS_CLERK).

The purpose of the role type is to make the administration tasks easier. When a database has many roles, it is difficult to determine which role is associated with a particular purpose. With the role type and the description associated in addition to the data

(15)

custodian, the number of roles that need to be investigated is reduced and will be easy to find.

4.2.4 User naming

Each user will connect to SDE with a unique username. The required roles will be

granted to that user. The username will be identical to the user’s YNET account name (eg jdbrown).

5 Spatial Data Standards

5.1 Storage Standards

Projection

Territorial datasets will all be in the Standard Yukon Albers projection. The coordinate units should be meters.

Standard Yukon Albers Projection Projection Albers Equal Area Conic Datum NAD83

Spheroid GRS80

Central Meridian 132°30’00" W (-132.5 in decimal degrees) Projection Origin 59°00’00" N (59.0 in decimal degrees) 1st Standard Parallel 61°40’00" N (61.666667 in decimal degrees) 2nd Standard Parallel 68°00’00" N (68.0 in decimal degrees) False Easting 500,000 m

False Northing 500,000 m

Each dataset is assigned the same ArcSDE projection parameters.

Datum transformation between NAD27 and NAD83 MUST use the Canadian National Transformation matrix.

Accuracy and Precision/Resolution

Feature classes loaded prior to ArcGIS 9.2

Unless there is a clear need for sub-meter resolution or where the area of polygon exceeds the maximum storage size, datasets within the CSDI should be stored in single precision coordinates (i.e. the precision in SDE should be set to 1000). This is sufficient for data used by the Yukon Government, as Albers (or even UTM) projection coordinates can be stored in single precision with meter accuracy.

Feature classes loaded at ArcGIS 9.2 or later All data sets will be loaded with double-precision.

(16)

Data Registration

Where possible, data should be registered to existing topographic or planimetric data. The largest scale data with full coverage of the Yukon is the 1:50,000 NTDB, which, has been planimetrically corrected by NRCAN Center for Topographic Information, Sherbrooke (CTIS) using more accurate ground control points (correction matrices) to enhance the geometric accuracy of the base data (CTI, 2005). For smaller scale mapping, the NTDB 1:250,000 Scale Base Mapping has been adopted as a registration base for many projects within the Yukon Government.

5.2 Metadata

Metadata or "data about data" describe the content, quality, condition, and other characteristics of data. Every dataset must have metadata attached to it. Metadata is information about a dataset, such as who is responsible for it, when it was created, what its source was, its spatial extent, its accuracy, etc. The Yukon government follows the FGDC standard for capturing information. Further information on the FGDC standard can be found at the following URL:

http://www.fgdc.gov/metadata/metadata.html 5.2.1 Metadata Standards

Metadata management is an important part of data warehousing. Current, descriptive metadata adhering to content standards should be maintained for all shared data sets. The following table describes the minimum Corporate Metadata service elements that need to be populated before publishing to METADATA server.

(17)

Corporate Metadata Service Elements

Sections

Tabs Categories Types Schema Name Description Comment

Title Follow the naming convention. This section is

used by other sections of the metadata standard.

Mandatory

Originator This is the person or organization that created the

data set.

If the name of editors or compilers are provided, the name must be followed by "(ed.)" or "(comp.)" respectively.

Mandatory

Publication Date The date that the dataset was published or

otherwise made available for release.

Mandatory Citation

Title The name by which the data set is known. Mandatory

This is the person and organization to contact for more information about the data set. This may be the same as Originator.

Mandatory

Person The person, and the affiliation of the person,

associated with the data set.

Used in cases where the association of the person to the data set is more significant than the Association of the organization to the data set.

Mandatory or Optional (should be mandatory? - to discuss at the workshop Point of Contact

Organization The organizational unit name of the custodial

organization. Custodial responsibility lies with the Director or most senior official.

Optional

Abstract A description of the data set. This field is very

important since during internet searches all that is returned is the title and the abstract.

Mandatory

Purpose A summary of the intentions with which the

dataset was created.

Mandatory

Access Constraints Identifies the access constraints for the dataset. Mandatory

General

Use Constraints Identifies the use constraints for the dataset. Mandatory

Information about the date and time of an event. Mandatory Time Period of Content

Currents Reference Select from the dropdown list.

Default=”publication date”.

Mandatory An indication of the status of the dataset

Progress The state of the data set.

Default = “complete”. You must use the dropdown list.

Mandatory Status

Maintenance and Update Frequency

A description of the frequency with which changes and additions are made to the resource after the initial resource is completed. Default = “none planned”.

Mandatory

Identification

(18)

North Northern-most coordinate of the limit of coverage expressed in latitude.

Mandatory

South Southern-most coordinate of the limit of

coverage expressed in latitude.

Mandatory

East Eastern-most coordinate of the limit of coverage

expressed in longitude.

Mandatory

West Western-most coordinate of the limit of coverage

expressed in longitude.

Mandatory

Theme Keyword Thesaurus

Common-use word or phrase used to describe the subject of the

data set.

Mandatory

Place Keyword Thesaurus

Reference to a formally registered thesaurus or a similar

authoritative source of place keywords.

Mandatory if applicable

Stratum Keyword Thesaurus

Reference to a formally registered thesaurus or a similar authoritative source of stratum keywords.

Mandatory if applicable Temporal Keyword

Thesaurus

Reference to a formally registered thesaurus or a similar authoritative source of temporal keywords.

Mandatory if applicable Keywords

Keywords Words or phrases summarizing an aspect of the

data set.

Mandatory or Optional

Tabs Categories Types Description Comment

Date Follow date convention. Default = “2001/01/01 Mandatory

Standard Name Metadata Standard Name “FGDC Content

Standard for Digital Geo-spatial Metadata”

Mandatory Metadata

Standard Version unless you are importing from another source,

use the default = “2"

Mandatory

Contact This is the contact for the metadata information

(not the spatial data, although this may be the same person). This field references the same list of contacts that is used for the identification section.

Mandatory or Optional

Person The Name of the person, select from the list on

the left or add a person name if required.

Mandatory Contact

Telephone

The telephone number by which individuals can speak to the

organization or individual.

Mandatory

Mailing Address default = “mailing address”. You must use the

dropdown list.

Mandatory

City The city of the address. Mandatory

Province or State The state or province of the address. Mandatory

Metadata Reference

General

Address

(19)

6 Warehouse Standards and Procedures

6.1 Procedures for Warehouse Delivery

This section provides a set of standards and guidelines for the delivery of applications and `datasets into the Corporate Spatial Warehouse.

The goal of documenting delivery standards is to facilitate a smooth and orderly delivery process. By following these standards and guidelines, better organization, communication and streamlined dataset loading will be achieved.

6.1.1 Warehouse Environment

There are 3 warehouse instances each providing a separate function in the application delivery and migration process.

Name Function

CSW Delivery Data compilation, initial data verification

CSW Test User acceptance testing CSW PROD Production server for

internal and public access 6.1.1.2 Warehouse Delivery Responsibilities

The delivery of an application rarely requires the talents of a single resource, although an individual may perform many roles. The following is an explanation of the roles played by team members in the warehouse delivery process.

6.1.1.2.1 Application Administrator

Responsibility - Business Area:

• Responsible for the ongoing operations of the application;

• Co-ordinates with the Business Analyst to schedule delivery of new versions or releases;

• Responsible for the User Acceptance Test (UAT) process; and

• Verifies that the application functionality adheres to government standards.

6.1.1.2.3 Delivery Personnel

Responsibility - Vendor or Designated Business Area Staff:

• Vendor or business area staff members responsible for delivering applications to the government;

• Must designate one individual as the primary contact; and • Responsible for running all scripts in delivery environment

(20)

6.1.1.2.4 ICT Database Administrator

Responsibility - ICT:

• Provides administrative support for the government's Oracle based applications; • Responsible for ensuring a stable application environment is available for the delivery

of corporate applications;

• Normally performs all of the Database Administrator (DBA) tasks associated with a warehouse delivery; and

6.1.1.2.5 Vendor/Business Area Project Manager

Responsibility - Vendor/Business Area:

• Primary vendor/business area contact for the application; • Responsible for the delivery process; and

• Responsible for ensuring that the application delivery adheres to Yukon government standards.

6.1.1.2.6 Geomatics Business Analyst

Responsibility – Geomatics Yukon:

• Coordinates all communication between the government staff and the vendor; • Ensures that Yukon government standards and guidelines are followed for the

application delivery; and

• Will co-ordinate all of the ICT resources required for the delivery process. • Responsible for performing all aspects of the migrations to test and production

(except for data conversion).

6.1.1.3 Warehouse Delivery Naming Conventions

6.1.1.1.1 Naming of files prior to 2010

Each delivery is considered a patch and is stored on ‘ict-data’ on hunter:\GY\CSDI\CSW\CSW_patches

Naming conventions must be followed for all application deliveries; all files delivered must be in a compressed archive format using the naming convention shown below: <dataset name>.<version>.zip

The <dataset name> is representative of the dataset or related application acronym. The <version> portion is the assigned version number for this delivery

dataset.1.0.0.zip First Release of "dataset". dataset.1.0.1.zip Patch release for "dataset"v1.0.1 dataset.1.1.0.zip New minor release of "dataset".

(21)

dataset.1.1.1.zip Patch release for "dataset"v1.1.1 dataset.1.1.2.zip Patch release for "dataset"v1.1.2 dataset.2.0.0.zip New major release of "dataset".

The versions are determined as <major release>.<minor release.<patch>. To constitute a major release the data must have "fundamentally changed". For a minor release, the database must have been altered significantly. For example, deleting or inserting a table, view, trigger etc. A patch would be delivered when there are only small updates.

6.1.1.1.2 Naming of files from 2010

Each delivery is considered a patch and is stored on ‘ict-data’ on

hunter:\GY\CSDI\CSW\CSW_patches. A folder should be created for each schema and patches should be stored under this folder. The name will be the same as the schema name without the ‘CSW’ prefix. Patch releases will follow the patch release naming convention above, but should be unique for each schema.

6.1.1.4 Delivery Directory Structure

An application or dataset specific directory should be created in the delivery base directory for each new application. This can be coordinated through the ICT Delivery Specialist. In the home directory for each application, the following directories will need to be created by the ICT Delivery Specialist prior to the application delivery:

Directory Name Description

/delivery Delivery instance

/test Test Instance

/prod Prod Instance

(22)

Instance Directory Structure

For each instance of delivery, test and prod there will be a series of sub-directories created by the ICT Delivery Specialist prior to the initial application delivery. The structure of these sub-directories is as shown below:

Sub-Directory Name Description

/admin Scripts that will be used on a regular basis for admin purposes.

/scripts Scripts that will be used once on delivery i.e. database objects, patch scripts, and SDE scripts

/docs All documentation

regarding all datasets, including the initial readme file delivered.

/versions Version source directory 6.1.1.5 Versions Directory Structure

The versions directory is an inventory of all versions related to the datasets loads. For clarification, the <version> stated below is of the format ##.##.## where the first '##' represents a major release, the second '##' represents a minor release, and the third '##' represents a patch release. The files get copied into the corresponding <instance>/source directory as part of the delivery.

Version # Sub-Directory Name Description

<version> Version number that should

be created when the delivered file is unzipped. I.e. Initial release of an application should be 1.0.0. /admin Scripts that will be used on

a regular basis for admin purposes.

/scripts Scripts that will be used once on delivery i.e. database objects, patch scripts, and SDE scripts

/docs All documentation

regarding all datasets, including the initial readme file delivered.

(23)

6.1.1.6 Detailed List of Delivery Tasks

Task Responsibility

Schedule delivery with ICT/Geomatics Yukon;

Project Manager Verify the delivery scripts at the

development (vendor's) site;

Delivery Personnel Create the delivery kit following the

delivery structure and compress with zip;

Delivery Personnel Transfer the delivery kit to the ftp delivery

server <dataset>/delivery/source/versions directory or directly to delivery location on ‘ict-data’ on hunter;

Delivery Personnel

Extract the files being delivered from the delivery kit;

Delivery Personnel Install the new version of the

dataset/application following the instructions in the readme file;

Delivery Personnel

Revise the readme instructions if any errors or discrepancies are encountered;

Delivery Personnel Verify the dataset and/or functionality of the

application;

Delivery Personnel Notify the Business Analyst and Delivery

Specialist that the delivery has been completed

Project Manager

Notify the Delivery Specialist if the delivery includes a CASE dump file.

Project Manager

Migrate to test instance Geomatics Business Analyst

Usability Test Application Administrator

Sign-off Migration to Test Application Administrator Migration to prod Geomatics Business Analyst Final Sign-off Application Administrator 6.1.1.7 Warehouse Dataset Delivery Requirements

In the CSW the datasets reside in shared CSW_ schemas such as CSW_BASE or CSW_; there are some tasks associated with Warehouse dataset deliveries that must be

completed. These include:

• The Vendor Delivery Personnel must contact the Geomatics Business Analyst to request table space names, role names and SDE configuration keywords to be used in the scripts if not known prior to the delivery;

• Output from the scripts must be spooled to a file; in case of failure this output will be sent back to the Vendor/Business Area Delivery Personnel for review;

• Data loading should be done via scripts containing insert statements. If this is not a valid method for data delivery the Vendor Delivery Personnel must contact the ICT Business Analyst to discuss other options;

(24)

• Scripts must be provided that uninstall the new objects. The scripts must contain statements that perform uninstall at both the object and SDE metadata levels. These will be used when the objects have to be re-created;

• An exception to the standard delivery process is scripts are not required for the table space and data file creation or the schema creation;

• All data to be loaded into the CSW must be modeled and approved by the Data Administrator. After approval the data model must be loaded in the data model repository;

• Application CASE Dump files should be left in the .../versions/<version>/case directory and notification sent to the Delivery Specialist that the delivery includes an Oracle CASE dump file. The Delivery Specialist will then copy the dump file into the application's <app>/case directory and notify the Data Administrator, who will then load the dump file into the ICT CASE Repository;

• Any large scale data conversion or loading from other systems is the responsibility of the Vendor/Business Area Delivery Personnel on all the instances. It is also the Vendor's responsibility to ensure that new statistics are generated after the data load process; and

• Each delivery must include a readme.<version>.txt file that resides in the

<version>/docs sub-directory. The readme file should include complete directions on how to install the version of the dataset/application being delivered. If the delivery is a patch release, it should also include what changes are actually being made to the database. Any changes to the database should be described down to the object level. For example listing any triggers, functions, procedures, and packages that are updated, or table changes and data conversions that are performed. The readme provided will include instructions surrounding any foreign keys that may need to be disabled if the object will be utilizing replication in the CSW.

6.1.1.8 Creation of application schema

Some datasets are used in a context of an application and require application specific tables. Here is a list of requirements for handling application related objects:

• In CSW the application schema name must be named APP_<appname> where <appname> is the assigned application acronym. Relevant system privileges must also be granted to this schema. Scripts must be provided to Delivery Specialist to run prior to delivery;

• Creation of the application objects, public synonyms, etc.;

• Creation of application PROXY account and its associated privileges. This account must be created for any application that accesses the CSW, access is not permitted via the application owner. This account must be PROXY_<appname>. If the application has replication requirements these must be communicated to the Delivery Specialist prior to the delivery. Specific steps associated with replication must be completed as part of the delivery;

• Creation of user account in the source database for access from the CSW over a database link. The account name must be DBLINK_<appname> where <appname> is the assigned application acronym;

• Creation of materialized views; these objects must have a _MVW suffix so they can be easily identified;

(25)

• Refresh type, frequency and schedule must be determined and approved the Delivery Specialist;

• Snapshot logs created in the source database; and

• Any materialized views involving complete refresh (i.e. no snapshot logs on the source database) must be approved by the Delivery Specialist.

6.2 Data Promotion Standards

Data promotion to the corporate warehouse is a collaborative effort between the data custodian and the warehouse administrator. Data promoted to the CSW must comply with the Yukon government standards. As many types of information, spatial and

attributes, hosted in the existing operational systems has value to a broad audience, it will be promoted to CSW. The CSW will formalize promotion process in order to achieve: • Content Management;

• Acquirer and replication services; and • CSW operational services.

In support of the promotion standards, some physical requirements should be noted: • CSW must have sufficient disc capacity;

• Server performance must be adequate to handle the traffic; and • Access to CSW must be secured.

6.2.1 Minimum Data Standards for Data Loading 6.2.1.1 Criteria for inclusion

• The data subject area has value to wide audience and/or has significance if it can be integrated with other land and natural resource data;

• Supports government resource management, planning or environmental monitoring activities;

• Has a designated custodian (Data Custodian Guidelines and Policies must exist in order to create the framework and to assure that data is managed based on both custodian business needs and user requirements);

• There is commitment to ensure continual refreshing of the data into the warehouse; • Custodian can attest to fitness of data (e.g. model, quality assurance processes,

metadata, updates, accuracy, etc.); • Minimum geographic extent is captured;

• Is fully described in the Department’s metadata repository (all data to be published must be described in the Metadata Repository to Department metadata standards. Metadata includes a description of fitness for use, the purpose for which the data is intended, and restrictions on use or modification. Data administrator has a support role in assisting the custodian in capturing metadata);

• Is well modeled, with its data model in the Department’s Oracle design repository (data models may be developed based on models of operational systems or, on approval of the Data Administrator, “as-built” in an existing data set. Where transformations are required to present the data in an integrated fashion or to

(26)

data set, these transformations need to be addressed in the data model. Data administrator has a support role in the development of data models);

• Has appropriate security defined. Security definitions need to include both the description of security requirements; i.e., a description of limits or restrictions on access, and any authorization mechanisms, such as Data Use Agreements, and the implementation, i.e. what system user groups will have what permissions, and any authorization mechanisms. Security definitions should include any restrictions related to freedom of information and restrictions to distribution); and

• There is commitment to ensure continual refreshing of the data into the warehouse.

6.2.1.2 Data Model Standards

Data modeling refers to the process of creating a description of the data classes (e.g. database tables) within a data set, their properties (columns/attributes) and the

relationships between these data classes. A data model includes a blueprint describing the data classes and relationships between data classes for human consumption and a data dictionary for use by the CSW services.

The warehouse requires two data models, one describing the structure of the data in the operational system and another describing the structure of the data in the warehouse. The operational data model is used to define the warehouse data model and the

publication process, which is how the data is published to the warehouse. The warehouse data model is also used by the services to automatically interact with the data and can be used by the users of the data to understand its structure.

A. Logical Naming conventions

In order to create appropriate descriptions for the objects in a well defined data model, these rules must be taken in consideration:

An object’s description must be:

• Meaningful: Use of one to four real words. When the entity name is only one word, it must not be an Oracle reserved word or a word that is not self-explanatory. E.g. the words ACTION, RANGE or PERMIT;

• Self-documenting: By looking at the name, the reader should have a good idea what the name means without having to read the description);

• Derived from the business use or purpose but understandable to a non business user; • Abbreviations or acronyms should be used only where no combination of names

would produce an acceptable result. They are to be avoided unless universally understood;

• Entities and attributes do not contain ‘_’ (underscores);

• If the entity represents a code table it has the suffix CODE; and • If the entity represents a cross-reference table it has the suffix XREF.

(27)

Relationship naming

• Relationship names must be meaningful;

• Both sides of a relationship must be named; and

• Phrases as 'has' 'is' 'related to', 'associated with' should be avoided in favor of more descriptive names.

Descriptions for Entities

The description of an entity must be clear, concise and understandable, following these rules:

• The first sentence of the definition should give a noun, or group of nouns, with modifying adjectives or phrases which summarize the meaning of the entity; • In the cases in which an entity has an acronym in its definition, it must be fully

qualified, e.g.. Universal Transverse Mercator (UTM);

• Examples of the information contained must be included. The first example should be one which is firmly in the collection, which will help the reader’s understanding; • Business intent of entity must be included. Where possible, the intent of the entity

should be shown. This allows the reader to understand the rationale for the entity and fit their own understanding of the business into the one represented by this entity; and • The descriptions for entities should not contain verbs that reference physical objects

or mention of the physical database object. Descriptions for Attributes

• The First sentence summarizes the attribute description. It must contain a noun, or group of nouns, with phrases which clarifies the meaning of the attribute. e.g.: An EMPLOYEE ID is unique identifier for each employee, who works or has worked, for the company;

• Example should be included. The first example should be one which is firmly in the collection, which will help the reader’s understanding. Other examples should reveal the bounds of the attribute; and

• Differentiation: Where there is confusion between two similar attributes in an entity, either because their names are similar or because their descriptions are similar, there should be an explicit text explaining the difference.

Descriptions for Views

• The views need to be described just like entities and their attributes; and

• If the view in the current data model uses and object from another data model, that object and column must be indicated in the column description.

B. Physical Naming Conventions

The conventions to define spatial and database objects related to the spatial layers using Oracle Designer, such as columns, sequences, views, triggers, indexes and constraints shall follow these basic conventions:

• Any object name should be a maximum of thirty characters long;

• Database names are limited to 8 characters. However, the database links names can be defined up to 128 characters and can contain periods (.) and at (@) signs;

(28)

• Should not contain quotation marks;

• Can only contain alphanumeric characters from the database character set; • Should contain underscores (_) to better qualification;

• Must begin with a letter;

• Must not duplicate an Oracle reserved word or Oracle keyword;

• Must not duplicate the name of another database object, even when it is in different database schema;

• Should use nouns rather than verbs; and • Should not be ambiguous.

In addition, an Application name prefix, up to 4 characters must be used to define all database objects.

Column naming

• Column names, including foreign key columns, must NOT be prefixed with an application acronym or data custodian;

• When possible, the foreign key columns must be the same as the primary key defined in the parent table; and

• The column that defines the primary key composition must be suffixed with “_ID”. Primary key name

• It must contain the table alias used in the entity definition and should be kept as generated by the Data Design Transformer. In addition, must contain the data custodian prefix and an underscore (_).

Foreign key name

• Must contain the table alias, suffixed by _FK and prefixed by the data custodian acronym.

Check constraint name

• Must be prefixed by the data custodian acronym, table alias, column name and suffixed by _CH. e.g. MTA_CLI_CATEGORY_CH.

Flags or indicators

• When a column is needed to store a flag or indicator, this must be suffixed with “_IND”. E.g. ACTIVE_STATUS_IND.

Domain naming

• Domains are unique for the entire database; therefore, the naming of a domain should be carefully considered

Indexes naming

• Must be prefixed by the data custodian acronym and suffixed with “_I”; and

• The table aliases must be used (e.g. CLI_TEN_FK_I is an index for the foreign key created from the client table to the tenure table).

(29)

Views naming

• The view name should be descriptive, showing which tables are used within the view; • For views accessing 1 feature class, the view name should be identical to the

feature class name with a “_SVW” suffix.

• The suffixes used are: “_VW” for plain views, “_SVW” for spatial views and “_MVW” for materialized views; and

• Must be prefixed with the data custodian acronym and an underscore, and suffixed as the type of view that it is. e.g.: PTB_PETROLEUM_TITLES_2005_SVW.

Sequences naming

• Must be prefixed with the table name –which is prefixed by the data custodian acronym) and an underscore, e.g.: PTB_PETROLEUM_TITLE_SEQ; and

• If multiple sequences are required for the same table, the sequence should be suffixed with SEQ#, where # increments sequentially.

Database triggers

• Must be named in the following manner:

<Data_custodian>_<table_alias>_<B/A>_<R/S>_<I/U/D>_TRG Where: B/A indicates Before/After, B/R is Row/Statement, IUD is Insert/Update/Delete, e.g., PTB_TIT_BR_ID_TRG is a trigger on

PTB_PETROLEUM_TITLES table, triggered Before Row, when an Insert or Update is performed.

For more detail please see proposed Environment standards document: YEIS_Standards_v2.1.doc.

6.3 Data Depiction Standards

6.3.1 General Rules English title of the layer

The names of ArcSDE tables are sometimes difficult to understand, therefore, an English title should be used when creating layer files. The English title will become the layer name and layer file name. The layer name is the name shown in the Table of Content in ArcMap whereas layer file name is the file name used to save with. An example of a layer name is Water, Wetland Polygon 2M. But layer file names cannot contain any spaces or special symbols, so the layer file name would have to be

Water_Wetland_Polygon_2M.lyr. The file name and layer name, though they are not exactly the same, should be similar. (I.e. replace commas and spaces with underscore.) Symbology

This refers to how geographic features are displayed in ArcMap. What color and how thick of a line is used for stream? Should wetland polygons be solid filled or hatched? Will the layer be color themed, instead of color filled? If so, which attribute is the theme based upon? This information is usually defined by the data custodian.

(30)

Joins

All joins performed in ORACLE. Scale Dependency

Scale dependency should always be set. If this has not been specified, or you wish to make visible over the entire territory, the scale should be set to a maximum factor of XX. Some layer files contain large datasets and, therefore, take time to draw in ArcMap or IMF. It is suggested that ArcMap layer files should be finished drawing in the 0-3 second range, so the scale factor may need to be decreased. However, it is difficult to make a judgment on whether you need to reduce a scale dependency factor for a layer before it is tested also in the IMS application. As a general rule of thumb, if it takes more than three seconds in ArcMap, it will most likely fail in IMF.

Definition Query

Sometimes a subset (filter) of the dataset may be required in order to meet the theme for the layer. For example, if the layer file contains all photo centers, and you would like to look at a specific year, you will need to apply a filter.

Attribute Naming Convention

To make it easier on the end user, you may wish to change the attribute name display to something more easily understood, or simply not show extraneous attributes (such as system attributes or confidential information).

It must be stressed that the data custodian must be consulted in the process as they have the ultimate responsibility for the information.

6.3.2 Symbology File Naming Standard (layer file)

The following criteria should be followed to create a layer file:

• Descriptive name should be part of the layer file name. This section must contain a descriptive name, with words separated by '_' . The intention is that the name should be as intuitive of the information the layer contains as is possible;

• Scale (e.g. 250K) is included in the layer file name where there is more than one scale available for the layer file. The scale should be appended at the end (e.g.

Watershed_Atlas_20K);

• All business prefixes or agency names should not be included in the layer file name. Example of business prefixes or agency names: YESAB, ENV; and

• For Grids or Map Tiles, 10K should be used to represent 1: 10,000 in layer title. 6.3.3 Layer Structure and Ordering

Although an ArcSDE table in CSW contains only one type of spatial feature (points, lines, polygons), the “layer file” being created may contain several ArcSDE layers which combine these spatial features. Also, for some polygon layers, a “group layer file” could be created that contains a duplicate of the ArcSDE table; once for the outlined layer and once for the color filled or color themed layer.

(31)

The outlined polygon is the topmost layer followed by the colour filled or colour themed layer.

A layer “group” needs to be created when more than one layer file is attached to the theme you are creating (including situations where the same layer file is attached multiple times, such as color themes and outlines). Do not, however, create a group when only one instance of one ArcSDE table is being viewed.

6.3.4 Layer Title Naming Standard

Layer title can be named slightly different from layer file name. Layer title is the English title that is included in the layer file. Please note that spacing is allowed for layer title, but, again, no special characters such as double dash (--), ampersand, comma, colon, slash, etc. are allowed anywhere in the layer file.

A layer title consists of several elements: English title, business prefixes (if necessary) and, scale (if necessary).

Examples:

Transfer of Administrative Control; Water Lines (6M); and

Water Polygon – Outlined (250K).

For polygon layer, there is a need to create a group layer for outlined polygon, color filled/themed polygon, and the type of polygon must be specified for the layer in the layer title.

Polygon group layers—Transparent layer.

Three layers for every polygon layer should be created and grouped together in ArcMap. Note that the fill transparency is set differently in ArcIMS compared with ArcMap. For example, if the transparency level in ArcIMS is set to 20%, the transparency level should be set to 80% (100% - 20%) in ArcMap.

(32)

7 Operational Database Standards

7.1 Overview

Once a given dataset has been fully migrated to the warehouse, it will require an editable spatial layer in the operational database for continual maintenance. Ongoing maintenance takes place in the Operational Database. Each department within the Yukon Government is responsible for the administration and dissemination of their own data.

The operational environments are hosted by ICT in a shared environment or by the departments. Standards will not be as strict as for the CSW, but guidelines are required for easy management and integration. Also clear procedures are required for transferring of data from the operational databases to the CSW. The recommended environment for operational database is Versioned Geodatabase. A Geodatabase could only be edited by multiple users if it had been versioned. This includes all spatial and non spatial database tables. While this presents few problems for GIS-only databases, it does create some difficulties for business areas that use the same database for GIS and non-GIS applications due to the limitations of using native database relations and constraints. Versioning strategies have to be well thought-out, and should closely replicate quality assurance/quality control (QC/QA) procedures within the departments.

Please note that at version ArcGIS 9.2, multi-user editing is possible without versioning. ESRI has added a short transaction editing model for simple feature databases that can be applied on a table-by-table (feature class-by-feature class) basis. In this way, both GIS and non-GIS applications can share access to a common DBMS without adding the overhead of versioning to those applications that do not need it. For small number of users this will simplify the data management and also simplify the synchronization with CSW.

7.2 Current Environments

Currently, there are several production environments housing the spatial and attribute data. There are 2 production SDE servers, SDECSW is the Warehouse production server and SDEOPR is the operational production server. There are also servers to support the web mapping and imagery environments. Please refer to the Infrastructure diagram for a complete schematic of the current CSDI infrastructure.

7.3 Governance of the new Operational Environment

This section still needs to be developed

7.4 Synchronization between operational databases and the warehouses

The Operational Database is the master repository and the warehouse is synchronized with the Operational Database.

(33)

7.4.1 Using a bridge (acquirer)

Refer to Appendix C for a list of acquirers. All acquirers are housed on Flanker (a virtual server) under C:\Acquirers.

For users which are using multi-user Geodatabase operational environment, the

synchronization between the operational datasets and their corresponding datasets will be made using an acquirer (custom bridge), connecting to the source and target datasets using different connections managed by a data mapping process, called geoprocessing. Acquirers are the means by which data flows from operational layers into the CSW. Acquirers can either be continuous, reacting to and sending changes to the state of layers on a near real time basis, or they can be bulk, sending all information based upon a scheduled event. Acquirers can also be used to bridge between other Oracle databases. In this process, the data custodian or data steward in charge of the data administration in the multi-user Geodatabase environment will be able to set one or more features to be transferred (as new or modified features) to its corresponding dataset in the CSW. There are several ways to implement an acquirer based on the specific requirements (the frequency of the transfer, partial layer structure vs. the entire layer transfer, etc.). A detail requirements/design document needs to be created to define the acquirer.

An example on how to control the replication and synchronization of spatial features into the CSW is by enabling snapshot logs and adding the following columns to each dataset required for synchronization (assuming that both source and destination are simple SDE layers):

SOURCE_FID : Identifies the unique spatial ID assigned by SDE to identify a specific feature in the SDE. With this value, the geo-processing will be ale to identify from which feature the information comes from

SOURCE_VERSION : Identifies the SDE geo database version used in the source FID SOURCE_REPLTIME : Saves the replication date time in which the synchronization process takes effect

SOURCE_USER : Is the user that executed the geo processing

A custom application will check the columns and transfer the data as appropriate. Manual synchronization

For data not stored in geodatabases

7.4.2 Check-in/Check-out process

Manual process used only when required on a case-by-case basis, especially when the master is housed in the warehouse. Assuming that the CSW is the master repository, a custom application could manage the check-in/check-out process. At a minimum, the

(34)

application records information about what layer was checked out, what user checked out the layer and when it was checked out. This minimizes the risk of having multiple users editing the same layer at the same time.

When the user is finished editing data from the check out file, he or she simply checks the layer back in. Now the layer is available for other users to edit and they can see the changes made by the previous user.

Pros:

1. Users will continue to edit in a familiar environment

Cons:

1. Only one user can work on a selected area at one time;

2. An application needs to be built to manage the check-in/check-out process and 3. The layer may be checked out by a user for a long time and prevent other users to

update the coverage.

7.5 Security and User Access

Operational staff, database administrators, business and application support staff, and development consultants (vendors) are participants in the operational database access. The granting, controlling, and monitoring of access to the corporate information resources contained in the operational database is an important part for consistent management and protection.

The ArcGIS client/server architecture traditionally involves interaction between a user interface running on the client desktop (ArcInfo®, ArcEditor™, ArcView®, ArcGIS Engine) and centralized data source (RDBMS) managed by ArcSDE. The application logic can run on either the ArcSDE/database server or ArcGIS client.

The ArcGIS security can be achieved at four levels; application, operating system, network, and RDBMS controls:

• ArcGIS application controls are mechanisms that are implemented either through ArcGIS out-of-the-box configuration or custom application enhancement

(ArcObjects);

• Operating system controls are mechanisms that are implemented using operating system functionality and are integrated with ArcGIS through either out-of-the-box configuration or custom application enhancement (ArcObjects);

• Network controls are mechanisms that are implemented using standard networking techniques and practices; and

• RDBMS controls are mechanisms that are implemented in the RDBMS and

integrated with ArcGIS through out-of-the-box configuration or custom application enhancement (using ArcObjects).

Corporate Spatial Data Infrastructure Standards