STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

Open Geospatial Consortium, Inc.
Date: 2009-09-02
Reference number of this document: 09-102
Version: 0.9.0
Category: OGC® Best Practice
Editor: Cyril Minoux

DGIWG WMS 1.3 Profile and systems requirements forinteroperability for use within a military environment

See Copyright statement on next page
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.

Warning
This document defines an OGC Best Practices on a particular technology or approach related to
an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC
Standard. It is subject to change without notice. However, this document is an official position of
the OGC membership on this particular technology topic.

Document type:
Document subtype:
Document stage:
Document language:i

Best PracticeNA
Approved as OGC Best PracticeEnglishSTD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

Copyright © 2009, DGIWG
The companies and/or organizations listed above have granted the Open Geospatial Consortium,
Inc. (OGC) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute thisdocument and to modify this document and distribute copies of the modified version.

ii

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009DGIWG WMS 1.3 Profile and systems requirements for interoperability for use within amilitary environment

Document Identification:
Date:
Author:
Editor:File Name:Distribution:
Usage:
Copyright:

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile
July 1st, 2009
S05 Data Access Service project teamCyril Minoux, France
STD-08-054-ed1.3-DGIWG_WMS1.3_Profile_corrected.doc
PublicDGIWG Standard(C) Copyright DGIWG, some rights reserved - (CC) AttributionYou are free:
to copy, distribute, display, and perform/execute the work
to make derivative works
to make commercial use of the work
Under the following conditions:(By:) Attribution. You shall give the original author (DGIWG) credit.
For any reuse or distribution, you shall make clear to others the license terms of this work.
Any of these conditions can be waived if you get permission from the copyright holder DGIWG.
Your fair use and other rights are in no way affected by the above.
This is a human-readable summary of the Legal Code (the full license is available from Creative
Commons <http://creativecommons.org/licenses/by/2.0/>).

iii

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

Contents
Page
i. Preface .................................................................................................................................... 5ii.

Submitting organizations ...................................................................................................... 5iii. Document contributor contact points .................................................................................. 5
iv. Revision history ..................................................................................................................... 5v.

Future work ........................................................................................................................... 7

vi. Forward .................................................................................................................................. 7
1

Executive summary ............................................................................................................... 82

Introduction ........................................................................................................................... 9

2.1
Scope ............................................................................................................................... 9
2.2
Structure .......................................................................................................................... 9
2.3
Delimitation ..................................................................................................................... 9
2.4
Conformance ................................................................................................................... 9
2.5
Intended audience ............................................................................................................ 93
References .............................................................................................................................. 94

Terms and definitions.......................................................................................................... 10

5

4.1
Abbreviations ................................................................................................................ 10
Web Map Service standards restrictions and extensions (Normative) ........................... 11

5.1
Service’s limits configuration........................................................................................ 11
5.2
Layers’ visibility configuration ..................................................................................... 12
5.3
Layer’s portrayal ........................................................................................................... 12
5.4
Supported Coordinate Reference Systems .................................................................... 13
5.5
GetMap supported output formats ................................................................................. 14
5.6
Layers’ transparency ..................................................................................................... 15
5.7
Multidimensional data ................................................................................................... 15
5.8
Structure and granularity of the layers .......................................................................... 16
5.9
Legend support .............................................................................................................. 175.10 GetFeatureInfo operation specification ......................................................................... 17
6
Requirements for systems publishing data as WMS (Normative) .................................. 19
6.1
Layers’ visibility configuration ..................................................................................... 19
6.2
Layer’s portrayal ........................................................................................................... 19
6.3
Structure and granularity of the layers .......................................................................... 20
6.4
Metadata support ........................................................................................................... 20
6.5
GetMap request responsiveness..................................................................................... 22
6.6
GetFeatureInfo operation specification ......................................................................... 22
7
Recommendations ............................................................................................................... 23
7.1
Web Map Service extension and restriction recommendations ..................................... 23
7.2
Recommended systems requirements ............................................................................ 24
7.3
WMS Client recommendations ..................................................................................... 28
8
Future Work directions ...................................................................................................... 29
9Annex A : Portrayal standards references (from [DGIWG T03]) .................................. 32iv

STD-08-054-ed1.3-DGIWG_WMS1.3_Profilei.

August 27 2009

Preface

The Defence Geospatial Information Working Group (DGIWG) submitted this document to the
OGC for consideration as an OGC Best Practice. The OGC Membership approved release of thisdocument as an OGC Best Practice on August 25, 2009.
The document defines a profile of OGC WMS 1.3 implementation specification standard[WMS1.3], a list of normative system requirements and a list of non-normative
recommendations.

ii.

Submitting organizations

Canada, France, Great Britain, New Zealand, Norway, Sweden.

iii.

Document contributor contact points

All questions regarding this document shall be directed to the editor or the contributors:
PersonOrganization

Phone

Email

Alan Ramunas

Canada Department of National
Defence D Int IM

Cyril MinouxDélégation Générale pour l’Armement +33 1 46 cyril.minoux@dga.defense.gouv.fr
19 60 55
DGA/DET/CEP/ASC/EN

Rebecca Tucker

DGC Standards

icg-standards3c2@icg.mod.uk

Mark Stevenson

NZDF

mark.stevenson@nzdf.mil.nz

Ronald Kvalsund Norvegian Military Geographic
Service
Lars Schylberg

iv.

5

GeoSE

Revision history

ramunas.ad@forces.gc.ca+47 23ronald.kvalsund@fmgt.mil.no09 23 90lars.schylberg@saabgroup.com

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

Date

Release

EditorPrimary clauses
modified

Description

06/04/2007

0.1

Cyril Minoux

All

Initial version submitted to nations
for review during the April 2007
Technical Panels

20/04/2007

0.2

Cyril Minoux

All

Review of the clauses, discussions
and comments at the April 2007
Technical Panels by the S05
meetings participants (CAN, FRA,
GER, NOR, NZ, SWE)

13/11/2007

0.3

Cyril Minoux

All

Review of the clauses, discussions
and comments at the November 2007
Technical Panels by the S05
meetings participants (CAN, FRA,
GER, NZ, SWE, USA)

19/11/2007

0.4

Cyril Minoux

WMS-Cache

Added some references

Date

Release

Editor

10/04/2008

0.5

Cyril Minoux

All

Full restructuring and cleaning of the
document ; incorporating allcomments gathered from themeetings, and from inputs from
Canada (2008-02-01) and from
Germany (2008-01-28)

18/04/2008

0.6

Cyril MinouxAll

Update on specific technical elementsfrom FRA inputs.

23/04/2008

0.7

Cyril Minoux

All

Review of the 18/04/2008 updates,
discussions and comments at the April
2008 Technical Panels by the S05
meetings participants (CAN, FRA,NOR, NZ, SWE)

09/06/2008

0.8

Cyril Minoux

Portrayal

Integration of S01 / S05 discussions
outcome10/07/2008

0.9

Cyril Minoux

All

Technical finalization of open items toensure best service andinteroperability while taking into
account the maturity of theimplementations. Provision ofanalysis for future evolutions of the
profile.

16/07/2008

1.0

Cyril MinouxAll

Editing of the document to DGIWG
standard layout.

29/10/2008

1.1

Cyril Minoux

All

Processing of comments received
from the Letter Ballot

04/11/2008

1.2

S05 Team

All

Finalization following resolving ofcomments at the DGIWG TechnicalPanel meetings

06/11/2008

1.3

S05 Team

All

Finalization

Primary clauses
modified

Description

6

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

Date

Release

EditorPrimary clauses
modified

August 27 2009

Description

01/07/2009

1.3
Cyril Minoux
corrected

3.3.1
3.5.3
4.4.1

Merging of corrigendum (Technical
Report TCR-09-206) to produce thebody of the OGC Best Practice
document

7/9/09VariousCarl Reed

Various

Ready for posting for e-vote as BP

8/27/09

1.3

Carl Reed

Various

Ready for posting as official BP.

v.

Future work

This document provides a number of recommendations and future work directions that can bevaluable to take into account by the software industry, the Open Geospatial Consortium, andDGIWG, in order to enhance the quality of the service provided by this technology. Once
supported by the wider community, these features could serve as a basis for the next version of
the DGIWG WMS Profile.
These include for example the capability of tuning the compression ratio to the requirement of theclient, or vector data portrayal specifications. See § 8 Future Work directions.

vi.

ForwardAttention is drawn to the possibility that some of the elements of this document may be thesubject of patent rights. The Open Geospatial Consortium Inc. shall not be held responsible for
identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any
relevant patent claims or other intellectual property rights of which they may be aware that might
be infringed by any implementation of the standard set forth in this document, and to provide
supporting documentation.

7

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

1

August 27 2009

Executive summary

This document specifies requirements for systems providing maps using OGC Web Map Service.
The document defines a profile of OGC WMS 1.3 implementation standard [WMS1.3], a list of
normative system requirements and a list of non-normative recommendations. The Defence
Geospatial Information Working Group (DGIWG) performed the work as part of through the S05
Web Data Access Service Project of the Services & Interfaces Technical Panel.
This development of this WMS 1.3 profile is in response to a number of requirements expressedby the military geospatial community for disseminating and accessing geospatial data forbrowsing and visualizing geospatial information (items 8.1, 8.2, 8.6, 12.1, 12.2, 18.1 of the[DGIWG Requirements Matrix]), possibly via a portal (items 8.5, 18.3 of the [DGIWG
Requirements Matrix]), and also provide support to overlay data and produce a basic Recognized
Environmental Picture (item 11.8 of the [DGIWG Requirements Matrix]).
Web Map Services [WMS1.3] can be used to cover these requirements. They are implemented bya number of vendors, and are more and more involved in a number of initiatives from NATO
(CoreGIS) or the European Union (GMES). However, several nations, including Canada, Norway
and France, have identified interoperability issues in either experimental or operational
environments. Indeed, these specifications have been written to cover a wide range ofcommunities of interest and use-cases. The purpose of this work is to standardize further Web
Map Services on a number of items that are important for the military community, in a way that
ensures interoperability.
To ensure the ability of implementing this profile, existing constraints among submittingorganizations and vendors have been taken into account, in order to distinguish between
normative specifications, recommendations and future work directions. Normative specifications
include both extensions/restrictions of WMS and system requirements specifications in order toenable interoperability by appropriate configuration of existing software. System requirements
specifications are intended to be applied in the design and fielding of systems having services
compliant to the profile. They come along with a rationale and conformance tests which provide
guidelines for testing compliance of implementations.
Tests are categorized for the convenience of testing organization, so that they can tune the levelof testing they perform, depending on the criticality and on the resources and time available forthis task. Tests of type 1 consist of checking configuration as declared by the service
GetCapabilities response. Tests of type 2 consist of checking that requests do not raise
exceptions, and that the response has the awaited characteristics. Tests of type 3 involve humanexpertise in checking that the response matches a quality level compliant with an operational use
of geospatial information.
Recommendations and future work items identify possible enhancements for this technology,
which can be reported to the Open Geospatial Consortium and the Software Industry in general,in order to enhance the quality of the service provided by this technology in their future baseline.

8

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile2

August 27 2009

Introduction

2.1 ScopeThis document is a military profile of the OGC Web Map Service 1.3 implementation standard[WMS1.3].
2.2 Structure
The document is structured in four parts:- A set of normative specifications which comprise an ISO 19106-compliant profile of the
OGC Web Map Service Implementation Standard version 1.3.0 [WMS1.3] ;- A set of system requirements specifications which include content beyond the scope of a
profile but relevant to achieving interoperability in an operational context ;- A set of Recommendations ;- A set of Future Work directions.
2.3 Delimitation
This document only addresses the Web Map Service and presupposes the existence of web-like
connectivity and the ability to use the HTTP protocol. Connectivity issues and standardization ishandled by working groups in charge of information systems and security.
2.4 Conformance
Web Map Services conformant to this profile shall be conformant to the OpenGIS® Web Map
Service Implementation Standard version 1.3.0 [WMS1.3] and to the normative clauses of section
5 (Web Map Service standards restrictions and extensions (Normative)of this document. Operational systems conformant to this document shall be conformant to both
section 3 and section 6.)
2.5 Intended audience
DGIWG Member Nations and any organization interested in providing / consuming Web Map
Services to / from DGIWG Member Nations.
3 References
The following normative documents contain provisions that, through reference in this text,
constitute provisions of this document. For dated references, subsequent amendments to, or
revisions of, any of these publications do not apply. For undated references, the latest edition of
the normative document referred to applies.
Tag[WMS1.3][DGIWG
Requirements
Matrix][DGIWG T03]

Description
OpenGIS® Web Map Service Implementation Specification – version 1.3.0 – date
2006-03-15 – Ref. 06-042“Matrix of Geospatial Activities for Operational Scenarios” from“DGIWG Technical Vision & Development Strategy 6.0.3” – IDON –Ref. TVD-Final-06-002-ed6.0.3-TVDS – 05 December 2006
“T03 DGIWG Portrayal Roadmap” – version 1 – May 2. 2007 - Marlene Meyer,
Daniel Gleason, Nicolas Lesage, Brian Parish, Ian Greasley, Marie-Lise Vautier

9

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

4 Terms and definitions
Coverage [ISO 19123] Feature that acts as a function to return values from its range for any
direct position within its spatial, temporal, or spatiotemporal domain.
4.1
CRS
ECWP
HTTP
KVP
JPIP
OGC
XML
WMS

Abbreviations
Coordinate Reference System
ECW streaming protocol
Hypertext Transfer Protocol
Keyword Value Pair
JPEG 2000 streaming protocol (Annex 9 of the JPEG 2000 specification)
Open GIS Consortium, also referred to as OpenGIS®
Extensible Markup Language
Web Map Service – cf [WMS1.3]

10

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 20095

Web Map Service standards restrictions and extensions (Normative)

5.1

Service’s limits configuration

ID
Normative Clause
3.1.1 If the WMS Service implements the LayerLimit parameter itshould not be less than 20.
See [WMS1.3] § 7.2.4.3.

3.1.2 The MaxWidth and MaxHeight shall be greater or equal to 800
pixels.
See [WMS1.3] § 7.2.4.3.

Rationale. Conformance testing.
Operational requirements : On the provider side, be able tolimit the consumption of hardware resources. On the client side,
enable the capability of overlaying a sufficient number of layers
to set up a useable environmental picture.
Test type 1 : check that the value of <LayerLimit> in the responseto the GetCapabilities request is not less than 20
Test type 2 : check that GetMap requests involving <LayerLimit>
layers are processed appropriately
Test type 3: check that any combination of up to <LayerLimit>
layers is processed appropriately
Operational requirements : On the provider side, be able tolimit the consumption of hardware and network resources. On theclient side, many portals and clients are going to use tiling, hence
only small areas (256x256 pixels or so) are going to be updated
when the screen is scrolled. Reasons for raising the limit to 800 is
to enable simple WMS clients to access a map of sufficient area
without tiling (e.g. your client application has crashed and you
send an HTTP GetMap request in some web browser).
Test type 1 : check the value of MaxWidth and MaxHeight in the
response to the GetCapabilities request
Test type 2 : check that GetMap requests involving MaxWidth x
MaxHeight output are processed appropriately

11

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

5.2

Layers’ visibility configuration

ID
Normative Clause
3.2.1 All layers published by the service shall be subsettable andresizable
See [WMS1.3] § 7.2.4.7.5

5.3

August 27 2009

Rationale. Conformance testing.
Operational requirements : enables the client to benefit fromservice-oriented data dissemination.
Test type 1 : check the value of the <noSubsets> < fixedWidth><fixedHeight> parameters of each layer declared in the
GetCapabilities document.
Test type 2 : check that GetMap requests involving subsetting
and resizing the original data is processed appropriately

Layer’s portrayal

ID
Normative Clause
3.3.1 The WMS service shall be able to render elevation andbathymetric coverage data in at least the following two styles- “shaded” : shaded terrain rendering- “hypsometric” : hypsometric rendering

Rationale. Conformance testing.
Operational requirements : Provide the client with common /standard rendering of elevation data
Test type 1 : check the value of the <style> parameter of eachlayer declared in the GetCapabilities document
Test type 2 : access to an elevation or bathymetric layer and test
the result of the “style=shaded” and “style=hypsometric” styles.

12

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

5.4

August 27 2009

Supported Coordinate Reference Systems

ID
Normative Clause
3.4.1 The service shall support the following Coordinate Reference
Systems, and use the following associated keywords 1) todesignate them in its responses, and 2) to process the clients’requests
Coordinate Reference System
Keyword
WGS84 geographic longitude, then latitude,
expressed in decimal degrees ………………… CRS:84
WGS84 geographic latitude, then longitude,
expressed in decimal degrees………………… EPSG:4326
World Mercator projection…………………… EPSG:3395
See [WMS1.3] Annex B.3 and 6.7.3.3, 7.2.4.6.7
3.4.2 Among the following Coordinate Reference Systems, the service
shall support all those which validity zone overlaps data
published by the service.. For each of these Coordinate Reference
Systems, the following associated keywords shall be used 1) todesignate them in its responses, and 2) to process the clients’requests
Coordinate Reference System
Keyword
UTM projections over WGS84 (north zones)… EPSG:32601 to
EPSG:32660
UTM projections over WGS84 (south zones)… EPSG:32701 to
EPSG:32760
UPS projection over WGS84 (north zone)…… EPSG:32661
UPS projection over WGS84 (south zone)…… EPSG:32761

Rationale. Conformance testing.
Operational requirements : WGS84 and Mercator are the mostcommonly used CRS which have worldwide validity zone.
Mercator used by the Navy.
Test type 1 : check that these keywords are declared in the
GetCapabilities document
Test type 2 : check that GetMap requests using these keywords
on any layers published by the service are processed
appropriately

Operational requirements : The UTM projections are the mostcommonly used CRS which have local validity zone. Used by the
Ground forces.
Test type 1 : check that these keywords are declared in the
GetCapabilities document
Test type 2 : check that GetMap requests using these keywords
on any layers published by the service are processed
appropriately.

See [WMS1.3] § 7.2.4.6.7

13

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

5.5
ID
3.5.1

3.5.2

3.5.3

3.5.4

August 27 2009

GetMap supported output formats
Normative Clause
The service shall support PNG output.

The service shall not include gamma-correction, color-balance,and colorimetric profile in the PNG output, in order toaccommodate the widest range of web browsers.

The service shall support JPEG output.

The service shall support GIF output.

Rationale. Conformance testing.
Operational requirements : PNG is a compressed format that
supports transparency
Test type 1 : check the value of the <format> parameter of eachlayer declared in the GetCapabilities document
Test type 2 : send a GetMap request with “format=image/png”
and check that the request is processed appropriately
Operational requirements : Some browsers seem to haveproblems with gamma-correction, color-balance and colorimetricprofile options.
Test type 2 : send a GetMap request with “format=image/png”
and check the characteristics of the output
Operational requirements : JPEG is a lossy-compression
format that provides better compression ratios than PNG on
imagery at the expense of non supporting transparency.
Test type 1 : check the value of the <format> parameter of eachlayer declared in the GetCapabilities document
Test type 2 : send a GetMap request with “format=image/jpeg”
and check that the request is processed appropriately
Operational requirements : Support for transparency is key tothe interoperability of WMS services ; however, in an early
JWID exercise, many clients were using a browser which did nothandle PNG transparency properly. The purpose is to account forsuch limitations.
Test type 1 : check the value of the <format> parameter of eachlayer declared in the GetCapabilities document

14

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

ID

5.6

Normative ClauseAugust 27 2009

Rationale. Conformance testing.
Test type 2 : send a GetMap request with “format=image/gif”
and check that the request is processed appropriately

Layers’ transparency

ID
Normative Clause
3.6.1 Layers shall be transparent at places where there is no significant
data before being rendered into the output image.

3.6.2 Whenever the output format enables transparency and the client
sets TRANSPARENT=TRUE in the GetMap request, the service
shall set the background of its request transparent.

Rationale. Conformance testing.
Operational requirements : Allows to overlay vector data or
incomplete raster data on other data, e.g. an image and be able tosee this image through it.
Allows visibility of underlying data if there are incomplete
coverages.
Test type 1 : check the value of the <opaque> parameter of eachlayer declared in the GetCapabilities document
Test type 2 : 1) send a GetMap request at the bounds of existingdata on a coverage layer and check that PNG and GIF outputs
sets transparent pixels outside of the available data
2) send a GetMap request on a vector layer and check that PNG
and GIF outputs sets transparent pixels outside of the features
3) send a GetMap request on a vector layer on top of a coverage
layer (imagery, terrain elevation or raster map) and check that thecoverage layer is visible.
Operational requirements : While the service won’t be able toproduce transparent output when the client requests JPEG output,
it is expected to do so when the client requests PNG, GIF or
JPEG2000 output.

See [WMS1.3] § 7.2.4.7.4
Tests : see clause 3.6.1

5.7

Multidimensional data

15

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

ID
Normative Clause
3.7.1 Services publishing coverages containing georeferenced data
whose values depend not only on a 2D spatial extent but also onother dimensions parameters (for example, date or depth, …)
shall allow the user to specify the additional dimension
parameters required to produce a 2D still-image in formats
compliant with clauses #3.5.x.
For dates or periods of time, the TIME parameter shall be usedby the service. For depth (in the sea or in the ground) or height(in the atmosphere), the ELEVATION parameter shall be used by
the service.

August 27 2009

Rationale. Conformance testing.
Operational requirements : The purpose of this clause is to ask
services to provide still-image output even for temporal /multidimensional data. (This does not forbid them to provide also
animated GIF or MPEG output).
The following initiatives show the interest of using non-animatedoutput, but instead issue one request per date of interest ; itenables more control over the temporal dimension ; it simplifies
the display of the output ; it avoids video-compression artifacts.
http://demo.communitymapbuilder.org/demo/mapbuilder-lib1.5rc1/examples/timeSeries/index.html
http://worldkit.org/wmstimenav/
http://demo.geomatys.fr/seagrid/demo/ifremer/

See [WMS1.3] § 6.7.5, 6.7.6, 6.7.7
Test type 1 : check that multidimensional data layers are able tooutput formats as specified in § 5.5
Test type 2 : send GetMap request changing dimensionalparameters values, and check that the result is appropriate

5.8Structure and granularity of the layers

ID
Normative Clause
3.8.1 Services shall not use hierarchical layers.
See [WMS1.3] § 7.2.4.8

Rationale. Conformance testing.
Operational requirements : Most client and service
implementations do not support a hierarchical structure of thelayers. Avoid interoperability problems. This capability is notwell enough specified in the OGC standard.
Test type 1 : inspect the GetCapabilities document and check that
there are no “child” layers involved.

16

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

5.9

August 27 2009

Legend support

ID
Normative Clause
3.9.1 Each vector data layer's style shall have an associated legend,available as an image in one of the following formats : PNG, GIF
or JPEG.
This legend shall be accessible online at the URL specified by
LegendURL.
See [WMS1.3] § 7.2.4.6.5

Rationale. Conformance testing.
Operational requirements : Users need legends in order tounderstand the content of the map, especially as long as vector
data portrayal is not standardized.
Test type 1 : inspect the GetCapabilities document and check that
there is a link to an online available image file containing alegend.
Test type 2 : browse the layer and check that the legend isconsistent with the display

5.10 GetFeatureInfo operation specification
ID
Normative Clause
3.10.1 All layers publishing vector data shall be queryable
See [WMS1.3] § 7.2.4.7.2

3.10.2 All layers publishing coverage data shall be queryable
See [WMS1.3] § 7.2.4.7.2

Rationale. Conformance testing.
Operational requirements : WMS would not provide enoughservice for vector data dissemination if it is not possible for endusers to request attributes of depicted features.
Test type 1 : check the value of the <queryable> parameter of
each layer declared in the GetCapabilities document of services
publishing vector data
Test type 2 : send GetFeatureInfo requests on each layer ofservices publishing vector data
Operational requirements : WMS would not provide enoughservice for coverage data dissemination if it is not possible for
end-users to request values at a specific point.
Test type 1 : check the value of the <queryable> parameter of
each layer declared in the GetCapabilities document of services
publishing coverage data

17

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

ID

Normative Clause

3.10.3 The service shall support at least one of the following mime-type
for the INFO_FORMAT parameter :- text/xml- text/html,- image/png

August 27 2009

Rationale. Conformance testing.
Test type 2 : send GetFeatureInfo requests on each layer ofservices publishing coverage data
Operational requirements : allows a browser to pop-up awindow and display the content of the response
Test type 1 : check the value of the<Request/FeatureInfo/Format> parameter of each layer declaredin the GetCapabilities document
Test type 2 : check that GetFeatureInfo requests using thedeclared output format are processed appropriately
Operational requirements : provide a level of services similar
3.10.4 The response of the service shall contain :- the attributes of the designated objects in case of a to the one of GIS readers.
vector layer- the measures at the designated location in case of a
Test type 2 : check that GetFeatureInfo responses containcoverage layer
appropriate information
Operational requirements : On vector layers, there may be
3.10.5 If the server implements a limit on the number of features on
which information is requested (FEATURE_COUNT parameter several features overlapping or intersecting each-other. If serversof the GetFeatureInfo request) then this limit must be greater
only support the default value of FEATURE_COUNT (which isthan or equal to 1001) then it might be difficult for a client to retrieve the expected
information.
See [WMS1.3] § 7.4.3.6
Test type 2 : check the GetFeatureInfo behavior at a specificlocation on a test dataset
See [WMS1.3] § 7.4.3.5

18

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

6

August 27 2009

Requirements for systems publishing data as WMS (Normative)

6.1 Layers’ visibility configuration
ID
Normative Clause
4.1.1 The WMS service must be configured to serve requests that range
from at least 4x to at least 0.25x the native scale(s) or
resolution(s) of the underlying datasets, and match commonlyused scales such as [1/5000 1/10k 1/25k 1/50k 1/100k 1/250k
1/500k 1/1M 1/2M 1/4M 1/5M 1/10M]
The limits implemented by the service shall be documented using
the MinScaleDenominator and MaxScaleDenominator elementsof the GetCapabilities document.
See [WMS1.3] § 7.2.4.6.9

Rationale. Conformance testing.
Example a compliant service would serve- VMap0 layers or 1M raster maps from 4M to 250k
- VMap1 layers or 250k raster maps from 1M to 50k- VMap2 layers or 50k raster maps from 250k to 10k- 5m imagery or elevation data from 1m pixel-resolution to 20m
pixel-resolution
Operational requirements : enables the client to browse thedata comfortably. Enables the provider to put limits on the
hardware requirements. Limits matching commonly used scales
favors consistent behavior (appearance / disappearance) acrossnational services. Guarantee a visibility window. Outside of thatwindow, data might not be consistent.
Test type 1 : check the value of the <MinScaleDenominator><MaxScaleDenominator> parameters of each layer declared in the
GetCapabilities document, and compare it with the equivalentscale of the original data as declared by its metadata.

6.2

Layer’s portrayal

ID
Normative Clause
4.2.1 The default style for ground terrain elevation data shall be“shaded”. The default style for bathymetric data shall be“hypsometric”.

Rationale. Conformance testing.
Operational requirements : Provide the client with common /standard rendering of elevation data
Test type 2 : access to an elevation or bathymetric layer and test
the result of the default style (“style=”)19

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

6.3

Structure and granularity of the layers

ID
Normative Clause
4.3.1 WMS services publishing VMap datasets shall use the featureclass name (e.g. ‘aerofacp’) as the WMS-“name” of the layer andthe feature class description (e.g. ‘Airport Point’) as the WMS“title” of the layer.

6.4

August 27 2009

Rationale. Conformance testing.
Operational requirements : avoid disparities across nations.
Test type 1 : inspect the GetCapabilities document and check that
there are one layer per feature class with appropriate naming
schemeMetadata support

A metadata layer is a WMS layer , which responds to GetMap requests by displaying the extent of each dataset used to constitute the layer ; andwhich responds to GetFeatureInfo requests by providing the metadata available for the dataset which extent contains the requested I,J point of the
GetFeatureInfo request.

Consider a layer publishing the “roadl” features class,extracted from VMap Type 1 databases.

The libraries used to set up the layer may have been
produced at difference times and by different producers,
and may have different metadata information. (Note : inthe example, we depict an irregular tiling schema).

20

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

The metadata layer as defined above would allow the user to extract metadata of the data he currently is viewing on it’s screen.

ID
Normative Clause
4.4.1 Each layer shall have at least one <MetadataURL> thatreferences a WMS layer called “metadata layer”
The following convention shall be used :“url-of-the-wms-service#layer-name”(e.g. “http://localhost:8080/cgi-bin/mywms#roadl_metadata”).
The type attribute should be set to “WMS”. The <Format> childelement should have blank content.

Rationale. Conformance testing.
Operational requirements : Users may need to know about thedate and accuracy of the data that is presented on screen by aparticular layer.
Note : COTS natively support the publication of suchinformation, which is not fundamentally different frompublishing vector data. It requires work on the configuration of
the service and on the data integration (metadata extraction andpublication within a database)See [WMS1.3] § 7.2.4.5
Test type 1 : inspect the GetCapabilities document and check that
there are “metadata” layers along with data layers
Test type 2 : browse the metadata layer and check that its display
and its behaviour regarding GetFeatureInfo is conformant.

21

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

6.5

August 27 2009

GetMap request responsiveness

ID
Normative Clause
4.5.1 When requested on the local host machine, the WMS services
shall respond to any GetMap request in a manner conformant tothis profile within 1 second per layer.

Rationale. Conformance testing.
Operational requirements : ensure sufficient responsiveness for
operational use.
Test type 2 : connect on localhost, send a hundred GetMap
request sequentially on random locations on some layers, andmeasure the time elapsed between the request and the response.

6.6

GetFeatureInfo operation specification

ID
Normative Clause
4.6.1 In the case of a vector layer, the response shall produce humanreadable output.
For example, response to GetFeatureInfo on FACC-based data
should use “name” and DFDD-based data should use “shortname” or “name”.

Rationale. Conformance testing.
Operational requirements : the average end-user is unlikely to
be familiar enough with FACC- or DFDD-codes to interpret themwithout support.
Test type 2 : check that GetFeatureInfo responses do translatefeature-dictionary codes into human-readable descriptions

22

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

7

Recommendations

7.1

Web Map Service extension and restriction recommendations

ID
Recommendation
5.1.1 Output format : PNG
The PNG output should be interlaced

5.1.2 The service should support the “image/png8” and “image/png24”
values for the FORMAT parameter.
Upon receiving a request specifying “image/png8”, the server
should encode the output image as an 8-bit color-indexed RGBA
PNG.
Upon receiving a request specifying “image/png24”, the server
should encode the output image as a 32-bit truecolor RGBA
PNG.
5.1.3 Output format : JPEG
The JPEG output should be interlaced

5.1.4 Output format : JPEG2000
The service should support JPEG2000 output
The service should embed georeferencing in the JPEG2000
output using the GMLJPEG2000 standard

August 27 2009

Rationale.
Operational requirements : Allows for progressive displayingof the map, which can increase the ease of use of the client
software.
This clause is not normative at this time, but should be in a
subsequent version, as soon as it is supported and implemented
by nations’ vendors
Operational requirements : using color-indexed allows for asmaller output file, but does not cover all the cases (e.g. truecolor
imagery data).
Note : 8-bit color-indexed RGBA PNG output means a colorindexed file using a palette of 256 RGBA colors. (referred to as“PNG alpha-palette image” in
http://www.libpng.org/pub/png/pngintro.html )Test type 2 : send a GetMap request on an imagery layer / vs a
raster map layer, and check asking for PNG output
Operational requirements : Allows for progressive and displayof the map, which can increase the ease of use of the client
software.
This clause is not normative at this time, but it should be in a
subsequent version, as soon as it is supported and implemented
by nations’ vendors
Operational requirements : JPEG2000 allows better lossycompression ratios than JPEG, and also allows losslesscompression.
This clause is not normative at this time, but it should be in a

23

STD-08-054-ed1.3-DGIWG_WMS1.3_ProfileID

Recommendation

5.1.5 Output format : JPEG and JPEG2000
The service should allow the client application to specify thecompression quality by an optional QUALITY parameter ranging
from 0 to 100

5.1.6 The recommended GetFeatureInfo format is text/xml.

August 27 2009

Rationale.
subsequent version, as soon as it is supported and implemented
by nations’ vendors
Operational requirements : enable the client application or agiven deployment to tune the quality of the display depending on
the network bandwidth in order to make a compromise between
quality and responsiveness.
This clause is not normative at this time, but it should be in a
subsequent version, as soon as it is supported and implemented
by nations’ vendors
Operational requirements : The benefit of providing
XML+XSL instead of HTML output is to satisfy therequirements of clients that are processing the XML output intheir own way
Conformance to this clause is considered an asset for the
implementation which supports it.
Test type 1 : check the value of the<Request/FeatureInfo/Format> parameter of each layer declaredin the GetCapabilities document
Test type 2 : check that GetFeatureInfo requests using thedeclared output format are processed appropriately

7.2

Recommended systems requirements

ID
Recommendation
5.2.1 Layers’ portrayal
When implementing styles that will be used to publish vector andcoverage databases as WMS layers in a military environment,
vendors should remain as close as possible to existing militaryconventions.

Rationale
Operational requirements : The closer the software is toportrayal standards already in use, the easier it will be for
operational users to read the map. It will also enforce thecapability of the implemented styles to depict and make use of
the whole information contained in vector or coverage databases.

24

STD-08-054-ed1.3-DGIWG_WMS1.3_ProfileID

Recommendation
Examples : layers publishing vector data using the FACC could
have a default style named "geosym" implementing MIL-PRF89045 or MIL-PRF-89045A.
Layers publishing S-57 vector data could have a default style
named “S52” implementing S-52.

A list of existing portrayal standards applicable to military maps
are referenced in annex A. Some of them are for hardcopy maps
specifically or for specific scales or productions, so all symbols
may not be applicable to WMS layers. However they constitutevaluable sources for developing styles suitable to a wider rangeof data layers.
5.2.2 Layers’ portrayal : default style
The default style should enable the map to be readable onscreen,and explicit <Name> and <Title> should be associated to thestyle.
Examples : layers publishing vector data using the FACC could
have a default style named "geosym" implementing MIL-PRF89045 or MIL-PRF-89045A.
Layers publishing S-57 vector data could have a default style
named “S52” implementing S-52.
5.2.3 The service should configure separate WMS services for :• imagery data
• raster map data
• terrain elevation data
• coverage data other than terrain elevation data
• vector data
5.2.4 Datasets and datasets collection containing imagery, raster,terrain, or coverage data that have been produced using consistentproduction processes (with respect to the targeted audience)

August 27 2009

Rationale
Test type 2 : Configure VMap Level 0, 1 or 2 data layers andcompare the output of GetMap requests using style=”geosym” on
a WMS client with the output on a Command and Control
System or a GIS that has been assessed to implement MIL-PRF89045(A).
Configure S-57 data layers and compare the output of GetMap
requests using style=”S52” on a WMS client with the output on asystem or a GIS that has been assessed to implement S-52.

Operational requirements : Clients’ ease of use

Operational requirements : On the provider side, avoid having
as many services as datasets. On the client side, avoid having toolong a list of layers within one service, and also too many
services.
Test type 1 : inspect the GetCapabilities document and check thatno layer of a given type is published along with other layers ofdifferent type.
Operational requirements : Simplify the end-users’ interaction
with the data access services, by abstracting non-significant
differences (without hiding them : differences between datasets

25STD-08-054-ed1.3-DGIWG_WMS1.3_ProfileID

Recommendation
should be published through a single layer.

5.2.5 Vector databases that have been produced using consistentproduction processes (with respect to the targeted audience)
should be published through a single WMS service, publishing
one WMS layer per feature class

August 27 2009

Rationale
within one layer are still accessible through the metadata layer –see § 5.9).
Examples :1) Raster map providers may create two layers, one layer for“legacy raster maps” and one layer for “up-to-date raster maps
created from rasterized MGCP data”, but they are encouraged to1) merge all datasets from a series within a single layer2) merge series that are consistent in terms of accuracy andproduction date within a single layer2) Imagery providers who have produced consistent 15m, 5m and1m imagery within a few months, are allowed to publish them as
one single layer, switching from one resolution to anotherdepending on the display-scale of the client.
Test type 1 : inspect the GetCapabilities document and themetadata of each layer, and check that there are not many small
datasets with similar metadata
Operational requirements : Enable the end-users’ to interact byspecifically selecting the layers that meet their requirements.
Examples :You would, for example, set up two different services for MSD
data and VMap data, and for VMap data you would publish one
layer for roadl, builtupa, watrcrsl, etc.
Also, if you produce VMap1 data from a generalization of
VMap2 data, both can be considered as consistent, and you canembed both VMap1 roadl and VMap2 roadl features under thesame roadl feature, switching from one source to the otherdepending on the current display-scale of the client.
Test type 1 : inspect the GetCapabilities document and check that
there are one layer per feature class with appropriate naming
scheme + one metadata layer

26

STD-08-054-ed1.3-DGIWG_WMS1.3_ProfileID
Recommendation
5.2.6 Additional metadata layers
Additional (more than one) metadata layers may be referenced
through the <MetadataURL> element and may be published by
the same service, in order to provide color-coded overlays
providing quality informations.
The following convention should be used :“url-of-the-wms-service#layer-name”(e.g. “http://localhost:8080/cgi-bin/mywms#roadl_horiz_acc”).
5.2.7 The XML response to a GetFeatureInfo request with
INFO_FORMAT=text/xml should embed a reference to an
online-accessible stylesheet hosted by the service provider, whichshall be able to transform the XML output into an HTMLwebpage.

August 27 2009

Rationale
Operational requirements : It could be useful to inform the user
on locations where the accuracy is high / ok / or low

Operational requirements : The benefit of providing
XML+XSL instead of HTML output is to satisfy therequirements of both- clients that intend to simply display the content of the response
in a web-browser popup window- clients that are processing the XML output in their own way
Conformance to this clause is considered an asset for the
implementation which supports it.
Test type 1 : check the value of the<Request/FeatureInfo/Format> parameter of each layer declared

5.2.8 In case the number of features matching a GetFeatureInfo request
exceeds the maximum number of features specified by
FEATURE_COUNT, the server should print a sentence in the
response stating “The number of features you pointed to exceeds<FEATURE_COUNT>. Showing information on the first<FEATURE_COUNT> ones.”in the GetCapabilities document
Test type 2 : check that GetFeatureInfo requests using thedeclared output format are processed appropriately
Operational requirement
Without this notification, the end-user has no way of knowing
whether there are exactly or more than <FEATURE_COUNT>features where he pointed to27STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

7.3 WMS Client recommendations
ID
Recommendation
CR1 Layers’ visibility
Client applications should implement appropriate widgets
behaviour making use of the Min- and MaxScale of each layer toinform the user what layers are actually involved in the current
display of the mapping context

CR2

CR3

GetMap Output formats
The client application should make use of interlaced output
formats in order to increase the GUI responsiveness
GetFeatureInfo specifications
Client applications should be able to issue and support text/xml,
text/html, and image/png queries / responses for the
GetFeatureInfo operation. In case of a text/xml exchange, theclient application should use the referenced stylesheet if it isreferenced and accessible

August 27 2009

Comments
Client behaviour could be specified as follows :“the list of layers shall only contain the layers of the web map
context that are currently displayed on screen, based on the Minand MaxScale associated with each layer”
or“In the list of the layers, a different font shall be used for thosethat are currently displayed on screen and those that are currently
not displayed on screen”
or“In the list of the layers, those that are currently not displayed onscreen shall be stroke”

Operational requirements : Given the wide range ofinterpretation among vendors, part of the interoperability issues
shall be handled by asking the client to be open to a variety ofpossible interaction formats.
In the meantime, clause #16-4 promotes the transition towards aunique interoperable behaviour that meets several usecases.

28

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

8

August 27 2009

Future Work directions

ID
FW1

FW2
FW3

FW4

FW5

FW6

FW7

Item description
Product download
It is suggested that non-subsettable or non-resizable layers should be accessed throughanother way than WMS. Product download seems to be the most appropriate foraccessing such unprocessed data
In the case of a product download, a DGIWG-nations' approved standard format should
be used, should be packaged as a zip or tar.gz file, and should be accessible at an URL
via HTTP and FTP.
Include portrayal specifications based on the output of the DGIWG Portrayal
Projects
Output format : PNG
Check if any implementation supports the capability to adjust the characteristics of theoutput PNG format to the strict requirements of the data to be transported. This could
be useful to save bandwidth without degrading the information. Specifications could be: “Color-indexed PNG should be generated when all layers returned by the WMS arecolor-indexed and the union of the colormaps of the layers can fit into a single
colormap. Grayscale PNG should be generated when all layers returned by the WMS
are grayscale. Truecolor PNG should be generated in any other case. The number ofbits per sample or the number of bits of the colormap should be the strict minimum that
supports the map's dynamic range.”
Output format : PNG
The PNG output should be interlaced
This clause is not normative at this time, but it should be in a subsequent version, as
soon as it is supported and implemented by nations’ vendors
The JPEG output should be interlaced
This clause is not normative at this time, but it should be in a subsequent version, as
soon as it is supported and implemented by nations’ vendors
Output format : JPEG2000
The service should support JPEG2000 output
The service should embed georeferencing in the JPEG2000 output using the
GMLJPEG2000 specification
JPEG2000 allows better lossy-compression ratios than JPEG, and also allows losslesscompression.
This clause is not normative at this time, but it should be in a subsequent version, as
soon as it is supported and implemented by nations’ vendors
Output format : JPEG and JPEG2000
The service should allow the client application to specify the compression quality by anoptional QUALITY parameter ranging from 0 to 100
Enables the client application or a given deployment to tune the quality of the display
depending on the network bandwidth in order to make a compromise between quality
and responsiveness.
This clause is not normative at this time, but it should be in a subsequent version, as
soon as it is supported and implemented by nations’ vendors
1) OGC should consider standardization of an optional compression-quality parameter

29

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

ID

Item descriptionthat could allow the client or the deployment to adjust its requirements to the networks
capabilities.
e.g. some software allows specification of formats like this in HTTP POST XML
requests : <Format>image/jpeg; Quality=50</Format>
some other software allows to specify an optional “QUALITY=50” parameter in HTTP
GET key-value-pair encoded requests.
2) To address specifically low bandwidth networks, nations may need to consider
alternative technologies (JPIP, ECWP), which would then be dealt with in anotherprofileFW8 Multidimensional data handlingspecify the keywords to use for dimension parameters : e.g. PRESSURE for humidity
measures, flight levels…
in order to avoid disparities across nations
FW9 FACC/DFDD-based vector data publication
would it be relevant to merge all feature classes that contain the same information but
have different geometries under the same layer ? e.g. have a layer named ‘aerofac’ andtitled as ‘Airport’, which would contain both aerofacp and aerofaca features.
FW10 Advanced portrayal features : on-the-fly image equalization
1) it is interesting for clients that image services perform on-the-fly imagery
equalization on the current viewing-area2) if automatic equalization is performed on the area specified by the BBOX parameter,client applications using tiling (e.g. openlayer-based portals) will join 256x256 tiles
that have been equalized independently from each other, which will result in weird
transitions between the tiles Î automatic equalization performed on the BBOX is notsuitable3) one could think about a specific parameter (EQ_BBOX) through which the client
specifies the bounding box on which the equalization should be performed, which canbe larger than the BBOX parameter. However this disables the tiled-client’s ability tocache its tiles : each time I move, the EQ_BBOX will move, so I cannot reuse the tiles
that I have in cache. Î on-the-fly equalization does not seem compliant with tilingclient that make use of cache
Conclusion :1) on-the-fly service-side equalization can be interesting for non-tiled clients2) the service should be able to disable this specific feature Î a standard
parameter to enable / disable this feature is desirable (Î OGC)
3) tiled-client application should not use this feature, and instead perform
radiometric equalization on their own, applying their algorithm on thedownloaded tiles
if on-the-fly service-side equalization is enabled, it can be performed on the area
specified by the BBOX parameter
FW11 Metadata layers
assess the nations’ requirements and level of support and for additional metadata layers
publishing quality informations in the form of color-coded overlays
FW12 Legends
standardize the look-and-feel / graphical chart of the image containing the legend, sothat we can dynamically produce a legend corresponding to the current map context of
the user, by concatenating all the legend-images in an HTML popup
It could be useful to standardize legends for MIL-PRF-89045(A), S-52, Stanag 2525, orS100, S101, S102, and AML in the future.

30

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

ID
Item description
FW13 Service’s responsivenessuse interoperability trials (DGIWG, NATO CWID, OGC OWS) in order to evaluate
what could be an acceptable normative specification on this matter, for both theproviders and the end-users
FW14 GetFeatureInfo specifications
specify further the desirable output of a GetFeatureInfo on METOC coverages. e.g. if
the measure depends on the height in the atmosphere, the output could provide agraphic depicting the values depending on the ELEVATION parameter.
FW15 GetFeatureInfo specifications
when it is assessed that the support of clause [5.1.5] and [5.2.4] is mature enough, 1)
restrict the scope of the profile to save complexity on the client side2) specify further the XML response
FW16 GetFeatureInfo : FEATURE_COUNT
the ideal behaviour, which is implemented in standalone GIS, would be to provide
information on only one feature at a time, and to highlight the selected feature. One
way of providing a similar user-interface would be to require WMS services to provide
a SVG along with the features attributes, and to require the WMS clients to make useof this SVG
FW17 Other output formats
Does the community have requirements to mandate other output formats, like pdf, svg,
kml ?

31

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

9

August 27 2009

Annex A : Portrayal standards references (from [DGIWG T03])

NATO Standardization Agreement (STANAG) 3675, Symbols for Land Maps, Aeronautical
Charts, and Special Naval Charts for Joint Operations at Scale 1:250,000
Owner: NATO Inter-Service Geographic Working Party (IGEOWP)
Content: Topographic and aeronautical symbols.
Related standards: Symbols for special naval charts reference IHO INT 1 (see below).
MIL-STD-2402, Mapping, Charting, and Geodesy Symbols for Graphic Products
Owner: US National Geospatial-Intelligence Agency (NGA)
Content: Map/chart symbols for NGA hardcopy products.
Related standards: Hydrographic symbols are based on IHO INT 1 (see below).
MIL-DTL-89045A, Geospatial Symbols for Digital Display (GeoSym) ®
Owner: US National Geospatial-Intelligence Agency (NGA)
Content: Map symbols to portray feature/attribute data contained in NGA standard Vector Product Format (VPF) products. GeoSym v1.0 can be seen as both a register of portrayal catalogues(set or portrayal rules) and a register of symbols involved in those portrayal catalogues. It is sectioned to be dependent on product specifications. The portrayal rules are linked to the data
through their feature catalogues, even if this relationship is ensured through FACC codes.
GeoSym shares this principle with the ISO 19117 and IHO S-52 standards. GeoSym has dependencies on VPF (contains components to support Geosym) which may not be relevant orpresent in future standards like GML.
Related standards: Hydrographic symbols are based on IHO S-52 (see below).
MIL-STD-2525B, Common Warfighting Symbology
Owner: US Department of Defense, Symbology Standards Management Committee (SSMC)
Content: Military units, equipment, facilities, battlefield tactical graphics, METOC, Signals
Intelli-gence (SIGINT) symbols, and symbols for Military Operations Other Than War(MOOTW).
Related standards: METOC symbols are derived from World Meteorological Organization(WMO) symbols.
NATO Allied Publication APP-6A, Military Symbols for Land Systems
Owner: NATO Joint Symbology Panel
Content: Generally derived from MIL-STD-2552B (see above). For command & control
systems, APP 6A is a standard which applies to C2 users. There is rationalisation activity under
way in UK.
American National Standards Institute (ANSI-INCITS 415-2006) American National
Standard for Information Technology - Homeland Security Mapping Standard – Point
Symbology for Emergency Management
Owner: US Federal Geographic Data Committee (FGDC)
Content: Symbols for incidents, natural events, operations, and infrastructure for emergency response.
Related standards: Meteorological natural events symbols are derived from World MeteorologicalOrganization (WMO) symbols.
World Meteorological Organization (WMO) Weather Symbols
32

STD-08-054-ed1.3-DGIWG_WMS1.3_Profile

August 27 2009

Owner: World Meteorological Organization (WMO)
Content: Symbols for weather phenomena.
Special Publication S-52, Colour and Symbol Specification for ECDIS
Owner: International Hydrographic Organization (IHO)
Content: Internationally standardized symbols for Electronic Navigation Charts (ENC) used inElectronic Chart Display and Information System (ECDIS).

33