OpenGIS® Specifications

*

Level 1 - includes test cases covering all requirements to be satisfied by a minimally conformant KML document;
*

Level 2 - as for Level 1, plus test cases addressing recommended requirements;
*

Level 3 - as for Level 2, plus test cases covering suggested constraints that are informative in nature.

CityGML models both complex and georeferenced 3D vector data along with the semantics associated with the data. In contrast to other 3D vector formats, CityGML is based on a rich, general purpose information model in addition to geometry and appearance information. For specific domain areas, CityGML also provides an extension mechanism to enrich the data with identifiable features under preservation of semantic interoperability.

This standard is used by a number of OGC Web Services, including the Web Feature Service [http://www.opengeospatial.org/standards/wfs], the Catalogue Service [http://www.opengeospatial.org/standards/cat] and the Styled Layer Descriptor Standard [http://www.opengeospatial.org/standards/sld].

Clients and servers with interfaces that implement the OpenGIS® Web Feature Service Interface Standard[http://www.opengeospatial.org/standards/wfs] read and write GML data. GML is also an ISO standard (ISO 19136:2007) [www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32554 ].
See also the GML pages on OGC Network: http://www.ogcnetwork.net/gml .

Part 1 “Common Architecture" supplies the common feature model for use by applications that will use the Simple Features data stores and access interfaces.

Part 2 provides a standard SQL implementation of the abstract model in Part 1. (Note: The OpenGIS® Simple Features Interface Standards for OLE/COM and CORBA are no longer current and are not provided here.)

The corresponding standard for the Web is the OpenGIS® Web Feature Service Interface Standard [link to http://www.opengeospatial.org/standards/wfs].

SLD addresses the need for users and software to be able to control the visual portrayal of the geospatial data. The ability to define styling rules requires a styling language that the client and server can both understand. The OpenGIS® Symbology Encoding Standard (SE) [http://www.opengeospatial.org/standards/symbol] provides this language, while the SLD profile of WMS enables application of SE to WMS layers using extensions of WMS operations. Additionally, SLD defines an operation for standardized access to legend symbols.

The protocol contains descriptions of both the sensor data and the sensor system itself. It is scalable, consistent, unambiguous, and usable with any sensor system incorporating any number sensors and actuators. It supports the precise spatial and temporal alignment of each data element. It also supports the registration, discovery and understanding of sensor systems and data, enabling users to ignore irrelevant data. It can adapt to highly dynamic and distributed environments in distributed net-centric operations.

The sensor system descriptions use common models and metadata and they describe the physical and semantic relationships of components, thus enabling sensor fusion.

This is one of the OGC Sensor Web Enablement (SWE) [http://www.opengeospatial.org/ogc/markets-technologies/swe] suite of standards.