SDLC STANDARDS

WEB MAPPING DEVELOPMENT STANDARDS

Version 3.2                March 2007

This page contains the published standards for the Ministry's approach to Web Mapping Application Development Standards.

Table of Contents 

VERSION CONTROL

1.      Introduction
1.1    Purpose
1.2    Audience
1.3    Scope/Exclusions
1.4    Assumptions
1.5    Definitions
1.5.1    Standards
1.5.2    Web Mapping Application
1.5.3    Internet Mapping Framework
1.5.4    Simple Application
1.5.5    Complex Application
1.5.6    Mature Application
1.5.7    Open Geospatial Consortium
1.5.8    Web Map Service
1.5.9    Web Feature Service
1.5.10    Geography Markup Language
1.6    Other Standards
1.7    Contacts
1.8    Exceptions
 
2.      Pre-development Tasks
2.1    Application Design Session

3.      Application Environments
3.1    Internet Mapping Framework
3.1.1    IMF for ArcIMS
3.1.2    IMF for OpenGIS
3.2    Application Parameters

4.      Data Sources
4.1    Sources for ArcIMS
4.2    Sources for WMS
4.3    Sources for WFS
4.4    Other Data Sources
4.5    AXL Files for ArcIMS
4.6    Shape Files
4.7    Performance of Data
4.7.1    ArcIMS Layers
4.7.2    WMS Layers

5.      Development Rules
5.1    General
5.2    Application Index
5.3    IMF for ArcIMS XML files
5.4    IMF for OpenGIS XML files
5.5    Application Pages
5.6    Coding Style
5.7    Extensions

6.      Application Interface Components
6.1    IMF for ArcIMS
6.1.1    Site Configuration
6.1.2    Tabs
6.1.3    Tools
6.1.4    Layer Configuration
6.1.5    Theme Configuration
6.1.6    Print Configuration
6.1.7    Edit Configuration
6.2    IMF for OpenGIS
6.2.1    Site Configuration
6.2.2    Tabs
6.2.3    Tools
6.2.4    Map Configuration
6.3    Helper Applications

7.      Application Delivery
7.1    General Tasks
7.2    Application Delivery
7.3    Migration to Test
7.4    Migration to Production

8.      Application Maintenance

VERSION CONTROL

This section of the document records the various versions or releases of this document.

[TOC]

1.     Introduction

The intent of this document is to describe the standards and guidelines which apply when developing web mapping applications for the Ministry. These standards also apply to other Ministries and government agencies that plan on utilizing our infrastructure to deploy web mapping applications (WMA). This document is not intended to be an 'all inclusive' guide to web mapping application configuration but rather will focus on development standards specific to the Ministry.

1.1     Purpose

This document outlines the standards that must be followed when building application systems for the Ministry.

1.2     Audience

This document is directed at those who will be designing, developing and maintaining Web Mapping Applications for the Ministry. This includes external contractors, consultants, and business partners, as well as Ministry employees.

1.3     Scope/Exclusions

The scope of this document covers all web mapping application development. The document also includes a description of the application quality assurance process to assist with client expectation management through the application delivery and migration process. Application delivery standards are mentioned but the details are documented within other standards documents.

This document is to be read in conjunction with other appropriate standards and the system development life cycle.

1.4     Assumptions

It is assumed that the audience has a working knowledge of the Internet Mapping Framework (IMF), and Web Services.

1.5    Definitions

The following definitions apply throughout this document.

1.5.1    Standards

A standard is a specific statement of the rules and constraints governing the naming, contents, and operations of software and hardware. A standard must be followed. There is a contractual obligation on the part of the vendor/developer to adhere to all relevant standards.

There are 2 types of standards defined in this document - Government and Ministry. A Government standard is a standard that has been designated by the Common Infrastructure Technology Services (CITS) of the Ministry of Labour and Citizens’ Services or alternatively by the Chief Information Officer of the Province of British Columbia (CIO). Sometimes government standards are open to interpretation, multiple standards are provided, or are still to be determined (TBD). For this reason the Ministry will clarify the standard specific to its requirements.

It is acknowledged that there are times when a standard just cannot be followed. These exceptions must be approved in writing by the Head of Architecture of the Ministries’ Information Management Branch (IMB).

1.5.2    Web Mapping Application

Web Mapping Applications (WMA) have a Web based component that displays just spatial or spatial and attribute information through a Web browser. The WMA may be defined as either simple or complex. Web Mapping Applications may derive their data from various data sources.

1.5.3    Internet Mapping Framework

The Internet Mapping Framework (IMF) is the standard tool kit for use in the development of web mapping applications. The tool kit has been developed in partnership with Moxi Media Inc. (http://www.moximedia.com). Moxi Media hold the rights and licenses this tool kit to agencies and businesses outside of the BC Provincial Government.

There are two versions of the IMF. The IMF for ArcIMS and the IMF for OpenGIS. The IMF for ArcIMS uses ESRI's ArcIMS. The IMF for OpenGIS uses a WMS and/or WFS. Unless otherwise specified, the term IMF will refer to either or both versions.

The following is a description of each frame in the IMF web interface.

titleFrame
Contains the organization's banner and title. A title document script is available for BC Government sites that can be called with different title arguments for use without creating custom title documents for each site. Other organizations can create their own title documents and put it in this frame. This frame fills the width of the web site, and can be set to any height.

tabFrame
Displays tab buttons with commands appropriate to the particular application. The tabs are configured using the techniques described in a later section. The number of tabs used is up to the site designer. This frame fills the width of the web site, and the height is set to the height of the tallest tab.

toolFrame
Displays map tool buttons appropriate to the particular application. The map tools are configured using the techniques described in a later section. The number of map tools used is up to the site designer. The tool frame contains JavaScript functions that can be called from other frames. This frame fills the width of the web site and the height is set to the height of the tallest tool.

hiddenFrame
This frame is very thin or invisible, and is used for dispatching JavaScript commands to other frames. It is initially filled with a blank white document so it matches the color of the frame beside it (if it is seen at all, browser dependent). This frame is designed to be 0 pixels wide and 26 pixels tall.

mapFrame
Displays the map image. The map image generated from the map server is sized to fit the size of this frame automatically. If the browser is resized, the next map requested will be the correct size. The map frame communicates to other frames and contains JavaScript functions that can be called from other frames. This frame fills the available space left after the other frames are created.

dataFrame
This frame is multi-use. It is used to display information about the web site, show reports, accept input from the user to set visible themes, and many other things. The index map and map legend are also displayed here. This frame scrolls if necessary. The width of this frame is fixed, but can be set by the site developer.

statusFrame
The currently active map tool is displayed in this frame, as well as the name of the active layer if the identify tool is active. This helps the user remember what's going to happen when they click the map.

1.5.4    Simple Application

Simple web mapping applications are those applications that do not have Java components. This kind of application is deployed by the vendor on the delivery application server.

1.5.5    Complex Application

Complex web mapping applications are those applications that have J2EE components. This will require that the application is built and deployed. This kind of application is deployed by the vendor on the delivery application server.

1.5.6    Mature Application

Mature applications will be defined as applications that have been in delivery, test and/or production, for a period exceeding 12 months, and have not been subject to any upgrades or maintenance.

1.5.7    Open Geospatial Consortium

The Open Geospatial Consortium, Inc. (OGC) is a nonprofit, international, voluntary consensus standards organization that is leading the development of standards for geospatial and location based services.

1.5.8    Web Map Service

The OGC Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information. This International Standard defines a "map" to be a portrayal of geographic information as a digital image file suitable for display on a computer screen. A map is not the data itself. WMS-produced maps are generally rendered in a pictorial format such as PNG, GIF or JPEG.

1.5.9    Web Feature Service

The OGC Web Map Service allows a client to overlay map images for display served from multiple Web Map Services on the Internet. In a similar fashion, the OGC Web Feature Service allows a client to retrieve and update geospatial data encoded in Geography Markup Language (GML) from multiple Web Feature Services.

1.5.10    Geography Markup Language

The OGC GML (Geography Markup Language) is an XML grammar for the encoding geographic information including geographic features, coverages, observations, topology, geometry, coordinate reference systems, units of measure, time, and value objects.

1.6    Other Standards

The Ministry has a number of other standards pertaining to application development and the System Development Life Cycle (SLDC).  Below are some of the standards that should be read with this document.

For a complete list of Ministry standards, visit the All Standards Page at:
http://srmwww.gov.bc.ca/imb/3star/alpa_standards.html
These standards include references to applications that require security.

Other relevant standards can be viewed at:

1.7    Contacts

All inquiries regarding these standards should be directed to the Business Analyst assigned to the project.

1.8    Exceptions

The following conditions will apply for all exceptions:

• All exceptions to the standards are to be identified in the Application Design Document prepared at design time.
• The exception must be specified on the Delivery Check List.
• Notification of an approved exception must be provided to the delivery technician prior to the delivery date.
• Exceptions must be approved in writing by the Head of Architecture of the Ministries’ Information Management Branch (IMB).

[TOC]

2.1    Application Design Session

It is suggested that a member of the Application Architecture Group be invited to the initial design white board session. This will allow for the facilitation of functions that may or may not be in compliance with these standards.

[TOC]

3.    Application Environments

The following sections are to used to determine what component versions an application needs to run on and comply with. For the latest versions of infrastructure components, contact your Business Analyst.

3.1    Internet Mapping Framework

3.1.1    IMF for ArcIMS

NOTE: There are variations to the deployed IMF. These are summarised below:

3.1.2    IMF for OpenGIS

3.2    Application Parameters

Some or all of the following application parameters may be requested prior to the application delivery This will allow for the deployment of applications without modification to the code on the delivery server.

[TOC]

4.    Data Sources

Data sources used by any application, must be existing data sources as defined below.

4.1    Sources for ArcIMS

All application development must utilize a common map service. Layers not visible in this service, can be added at the request of the business area.

4.2    Sources for WMS

Updates to this list can be obtained from http://openmaps.gov.bc.ca

4.3    Sources for WFS

Web feature server (WFS) data sources are not presently supported.

4.4    Other Data Sources

Other remote WMS or WFS data sources may be included in an application, but permission must be requested through the exception process above.

4.5    AXL Files for ArcIMS

Applications must use the standard map service.

If an exception has been granted, the development rules below will apply.
An AXL file:

• The file must be well formed
• The file must be validated with the DTD and the DTD refrence removed after validation.
• The file must contain a comment header.
• Must not contain any spatial joins.
• Use only production warehouse data sources, unless there is an operational component..
• All raster image files must be served through WMS.
  
• The Config, Environment, Screen dpi must be set to 72. This ensures that printing is to scale.
• All layers within the WMA must have a minimum and maximum scale dependency set.
• All layers must be turned off, with the exception of one layer that covers the full extent of the map. A suggestion for the one layer would be the NTS Grid. (This is to allow for the testing of a service, independently of the application). If more than one SDE data source is used, one layer is required for each data source.
• Individual layer names must match the English name as defined by the custodian in the layer file library. A matching id field must exist using the name, with the exception that the name must not include spaces or special characters. Spaces are to be replaced using underscore. i.e.
  <LAYER type="featureclass" name="Airphoto Centres (1996)"id="Airphoto_Centres_1996" ...> The matching layer-config.xml file will use the "name" attribute as the key field.
• The file must not generate any errors.

4.6    Shape Files

Shape files are not supported.

4.7    Performance of Data

The following performance criteria must be met for any new or existing data layers. The summary results of exercising of layers, can be viewed at:
http://srmgww.bcgov/landinfobc/imb/aas/imf/server/stats/index.html
NOTE: The performance of layers will be measured in the delivery environment only against production databases.

4.7.1    ArcIMS Layers

Map Services:

• The total request time may not exceed 10 seconds.
• The total processing time may not exceed 10 seconds.
• The AXL parse time may not exceed 1 second.
• The output time may not exceed 2 seconds.

To manually exercise the layers, the following scripts may be used:
HTML Script:
http://<appserver>/imf5/imfTestService.jsp?server=<server>&service=<service>&ms=200 or
Tabular Script:
http://<appserver>/imf5/imfTestService_all_colon.jsp?server=<server>&service=<service>&ms=200
(This will list only layers where the image creation time exceeds 200ms)

4.7.2    WMS Layers

Map Services:

• Average Request Time may not exceed 1 seconds.
• Maximum Request Time may not exceed 6 seconds.

Individual Layers:

• Average Request Time may not exceed 2 seconds.
• Maximum Request Time may not exceed 4 seconds.

Total Time (single group request):

• Average Request Time may not exceed 2 seconds.
• Maximum Request Time may not exceed 4 seconds.

Label Cache (single group request):

• Average Request Time may not exceed 2 seconds.
• Maximum Request Time may not exceed 4 seconds

[TOC]

5.    Development Rules

5.1    General

• Mature Applications will be subject to the standards in place when any changes are made to the application. Changes to the environment will be communicated to the business area, thorough the Business Analyst.
• Mature Applications will be decommissioned if there are any software versions that are no longer supported. Sufficient notice will be provided.
• An application must use the standards in place when the contract is signed. If a newer standard is in place when the application is delivered, that standard may be used, but by mutual agreement.
• Applications delivered after 6 months of the contract being awarded will be subject to the standards in place when the delivery takes place.
• Developers will be required to provided their own infrastructure and software to support their development of Web Mapping Applications. Developers may use the Ministry's IMF and map services remotely to test their applications.
• Updates, modifications or any changes made to an application, will be subject to a complete new delivery, based on the current standards at that time.
  

5.2    Application Index Page

Every WMA must be called from an index page. The index page must meet corporate Web page design specifications and include a script to open the map in a seamless window.

5.3    IMF for ArcIMS XML Files

• All XML files must be well formed.
• All XML files must be valid XML, based on the following DTD or Schema definition.
• When a file has been validated, the reference must be removed from the file.

5.4    IMF for OpenGIS XML Files

• All XML files must be well formed.
• All XML files must be valid XML, based on the following Schema definition.
• When a file has been validated, the reference must be removed from the file.

5.5    Application Pages

All pages within an application framework, must use the same stylesheet as used by the IMF. The style sheets for each type of IMF can be found at:

5.6    Coding Style

All files delivered as part of an application, shall have headers, with the following information:

5.7    Extensions

• No extension/s to the Internet Mapping Framework will be allowed.
• No other files may be added to the core IMF.
• Modifications to core files may be allowed, but will evaluated dependant on the nature of the request, and the effects on the core.

If an exception has been approved, the following conditions for extenstions will apply.

• The extension will form part of a single delivery ie it will not be part of another application and/or delivery.
• The extension will be written to comply with the Java Development Standards.
• The extension will be written so that other applications may use its functionality.
• The extension will have an interface or stub so that it can be tested on its own.
• The extension may not refer back to a calling application, unless it has been designed to do so. If it is designed to do so, it must be able to accommodate multiple applications.
• The extension jar files are to be placed in \imf5x\imf-web\WEB-INF\lib\.
• The extension will have documentation defining its purpose and how it is to be integrated into other applications.
• The documentation must be delivered as part of the extension, and viewable from a web page or url.
• The extension will be written to comply with the version of the current Internet Mapping Framework in production.
• The business area requesting the extension will be responsible for its maintenance.
• The business area requesting the extension will be responsible for its upgrades to newer versions of the Internet Mapping Framework.

6.    Application Interface Components

6.1    IMF for ArcIMS

6.1.1    Site Configuration

The application site configuration file will consist of:

• A single file called site-config.xml unless more than one are used. If more than one are used, the name of each file will include the relevant theme i.e. site-config-<theme>.xml.
• The file must be validated against the schema definition.
• The file must not contain duplicate elements already defined in the IMF core.
• Only tabs and tools that are relevant may be included.
  

Tabs and Tools that can be used in the site-configuration can be found below.

6.1.2    Tabs

Listed below is a list of common tabs that are available to any application.
Tab graphics defined in the IMF, may not be used for any other task or function.
Note: The order of tabs is important.

Tutorial is no longer a Mandatory tab. Additional business specific help, may be added.

6.1.3    Tools

Tools must be grouped into logical groupings, separated by a space.
Tool graphics defined in the IMF, may not be used for any other tool or button.
Note: The order of the tools or buttons are important.

NOTE: The e-mail tool is not supported. The html mailto: function may however be used as an alternative.

6.1.4    Layer Configuration

The application layer configuration file will consist of:

• A single file called layer-config.xml unless more than one are used. If more than one are used, the name of each file will include the relevant theme i.e. layer-config-<theme>.xml. A matching site-config-<theme>.xml file will exist for each layer-config-<theme>.xml.
• The file must be validated against the schema definition.
• The file must use layer names that match those defined in the AXL file.
• The file must include only the attributes that are usable to the client.
• The layer name attribute must be used as the key field when associating with the AXL file. The id attribute must not be used.
• Each layer must have a reference to metadata. This following layer attribute will automatically build the url if a metadata record exists with the same layer name as defined in the corresponding lookup table:
  metadata-handler="$IMF/ext/bcgov/common/metadata-handler.jsp"
  

The following url syntax may be used to generate a layer-config.xml file for the standard map service.
http://delivery.webmaps.gov.bc.ca/imf5/imfUtilCreateLayerXml.jsp?server=<mapserver>&service=<servicename>

6.1.5    Theme Configuration

The application theme configuration file will consist of:

• A single file called theme-config.xml.
• The file must be validated against the schema definition.

6.1.6    Print Configuration

The application print configuration file will consist of:

• A single file called print-config.xml.
• The file must be validated against the schema definition.
• A shared print-config.xml file exists for all applications. This file can be located at $IMF/config/print-config.xml.
• Additional templates may be added to this file, through the delivery process.

6.1.7    Edit Configuration

Not supported at this time, but will be added if needed.

6.2    IMF for OpenGIS

6.2.1    Site Configuration

The application site configuration file will consist of:

• A single file called site.xml unless more than one are used. If more than one are used, the name of each file will include the relevant theme i.e. site-<theme>.xml.
• The file must be validated against the schema definition.
• The file must not contain duplicate elements already defined in the IMF core.
• Only tabs and tools that are relevant may be included.
• The application must use the standard index map service:
  <INDEX-MAP-CONFIG-XML url="$IMF/sites/index/index.xml"/>
  

Tabs and Tools that can be used in the site configuration can be found below.
A sample site.xml file can be found here.

6.2.2    Tabs

Listed below is a list of common tabs that are available to any application.
Tab graphics defined in the IMF, may not be used for any other task or function.
Note: The order of tabs is important.

6.2.3    Tools

None of the following tools are compulsory, but most are recommended.
Some tools should however not be used unless that tools is usable i.e. You can only use the Identify tool if the layer is set to can-identify="true".
Tool graphics defined in the IMF, may not be used for any other task or function.
Note: The order of the tools or buttons are important.

6.2.1    Map Configuration

The application map configuration file will consist of:

• A single file called map.xml unless more than one are used. If more than one are used, the name of each file will include the relevant theme i.e. map-<theme>.xml. A matching site-<theme>.xml file will exist for each map-<theme>.xml.
• The file must be validated against the schema definition.
• The file must use layer names as defined in the data dictionary.
• The file must include only the attributes that are usable to the client.
• The file must include meaningful attribute names.

A sample map.xml file can be found here.

6.3    Helper Applications

Applications may use the extension, "Spatial Overlay Engine". (This feature is only available with IMF for ArcIMS). If this is used, the following default configuration file may be used:
http://srmapps.gov.bc.ca/apps/soe/xml/lrdw_lureport_layers.xml

[TOC]

7.     Application Delivery

7.1    General Tasks

Application migrations from delivery to test, test to production must all be booked through the application delivery calendar by the Business Analyst and be, at a minimum, two weeks apart. Any exceptions must be negotiated and approved by the Information Management Branch before being scheduled in the delivery calendar.

7.2    Application Delivery

• The system development life cycle must be followed during application development, delivery and migration.
• Prior to delivery, the Business Analyst will be responsible for providing a completed application delivery checklist.
• All deliveries need to be scheduled in the application delivery calendar by the project Business Analyst.
• Application deliveries should include a minimum of index page, site and layer configuration file.
• Any Java application with a web mapping component, must be delivered as a single application.
• All applications must adhere to the Web Mapping Delivery Standards.
• Once a delivery has been completed, the appropriate technical staff should be notified, so that the QA of the application can be started.
• Any subsequent delivery of the application, will be subject to another QA.
• The application may not proceed to test until all items identified in the QA have been addressed.

7.3    Migration to Test

• All migrations to test need to be scheduled in the application delivery calendar by the project Business Analyst.
• The business area representative has reviewed the application and signed off on the migration either in writing or via e-mail.
  

7.4    Migration to Production

• All migrations to production need to be scheduled in the application delivery calendar by the project Business Analyst.
• The business area representation has reviewed and accepted the User Acceptance Test plans as executed by the test users.
• All required application functionality in the IMF tool kit is available in the production environment.
• Business area signs off on migration to the production environment, either in writing or via e-mail.

[TOC]

8.     Application Maintenance

An allowance must be made in each development contract for annual maintenance.

[TOC]