DRAFT



License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.


 

i. Abstract

The 3D Portrayal Service Standard is a geospatial 3D content delivery implementation specification. It focuses on what is to be delivered in which manner to enable interoperable 3D portrayal.

It does not define or endorse particular content transmission formats, but specifies how geospatial 3D content is described, selected, and delivered. It does not prescribe how aforementioned content is to be organized and represented, but provides a framework to determine whether 3D content is interoperable at the content representation level. More details are available in section 6.3.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, 3D, portrayal, service, geospatial, specification

iii. Preface

This document is based on two OGC discussion papers (WPVS: OGC 09-166r2, W3DS: OGC 09-104r3), which each detail a service interface to support 3D portrayal of geodata, but using two different mechanisms (image and scene-graph based). Due to considerable overlap, it was decided that, for standardization, their technical content should be merged as far as possible. This document represents the efforts by the 3D Portrayal Service SWG to merge the two proposals, retaining these two different mechanisms while providing a foundation for other potential mechanisms.

This document does not suggest any updates to the OGC Abstract Specification.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium 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.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Fraunhofer Gesellschaft
Hasso Plattner Institute at the University of Potsdam
Esri R&D Center Zürich

v. Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name Representing OGC member
Simon Thum Fraunhofer IGD Yes
Ralf Gutbell Fraunhofer IGD Yes
Benjamin Hagedorn Hasso Plattner Institute at the University of Potsdam Yes
Thorsten Reitz Esri R&D Center Zürich Yes

Other contributors::

Name Representing OGC member
Volker Coors Fraunhofer IGD, HFT Stuttgart Yes
Arne Schilling virtualcitySYSTEMS Yes
Thomas H. Kolbe Technical University of Munich Yes
Dieter Hildebrandt Hasso Plattner Institute at the University of Potsdam Yes
Jürgen Döllner Hasso Plattner Institute at the University of Potsdam Yes
Mike McCann Monterey Bay Aquarium Research Institute Yes
Jan Klimke Hasso Plattner Institute at the University of Potsdam Yes

1. Scope

This OGC® document specifies a standard service interface for web-based 3D geodata portrayal supporting a) delivery of geometric 3D scene data and b) server-side 3D scene rendering. It is applicable to 3D geodata stores that want to target a range of portrayal clients, or to 3D geodata portrayal clients that want to portray geodata from a range of compatible sources.

This standard intends to enable semantic interoperability in geospatial 3D portrayal services. That is, it represents 3D geodata with potentially rich metadata and accompanying description of the technical requirements for portrayal thereof on a given client. It addresses use cases such as 3D portrayal of geodata and requesting additional information at the user’s discretion. More details about possible interoperability scenarios may be obtained from the 3DPIE report [OGC 12-075].

This standard does not define or endorse a transmission format for scenes or images. It is therefore not sufficient to enable interoperability, but to determine automatically if interoperation is possible.

2. Conformance

This OGC interface standard targets at 3DPS 1.0 implementations, i.e., 3D portrayal services and clients.

Requirements for 4 standardization target types are considered:

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site.

In order to conform to this OGC® interface standard, a software implementation shall implement the core conformance class and one or more of the scene and view conformance classes. It is also possible for a yet unspecified extension to be considered sufficient for conformance as are the scene and view extensions. Such an extension shall be accepted as an addendum to this standard, facilitate 3D portrayal and provide at least one conformance class that is dependent on the core conformance class.

Requirements URIs and conformance test URIs defined in this document are relative to http://www.opengis.net/spec/3DPS/1.0.

It has been brought to the SWGs attention that the omission of a baseline format has consequences for the testability of the service specification and hence, the definition of conformance. Namely, in the case of the scene conformance class, no single delivery format may be used to define or test conformance. However this mirrors the situation in the 3D modeling world and seems unlikely to change soon. Thus, an abstract statement of conformance to the 3D portrayal service standard is to be seen as a first step to make it easier to interoperate. A particular service instance may not work with a given client due to differences in data encoding, format provisions employed, or a focus on the image-based or scene-based conformance classes. However, a client implementation will be able to tell reliably whether and how interoperation with a given service instance is possible.

3. Normative 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.

OGC 04-046r3
Open Geospatial Consortium, OGC 04-046r3, The OpenGIS Abstract Specification, Topic 2: Spatial Referencing by Coordinates, August 2004
OGC CityGML
Open Geospatial Consortium, OGC OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard, Version: 2.0.0
OWS Common
Open Geospatial Consortium, OGC 06-121r9, OGC Web Services Common Standard, version 2.0
W3C XML 1.0
W3C Recommendation, Extensible Markup Language (XML) 1.0 (Fifth Edition), http://www.w3.org/TR/xml
IETF RFC 1738
IETF RFC 1738, Uniform Resource Locators (URL)
IETF RFC 2046
N. Fred, N. Borenstein, Multipurpose Internet Mail Extension (MIME) Part Two: Media Types, November 1998
ISO/IEC 14977
ISO/IEC 14977:1996(E), Extended BNF
ISO 19117
ISO 19117:2012, Geographic information — Portrayal
RFC 3986
IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax
RFC 2046
IETF RFC 2046, N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, Nov. 1998
OGC KML
OGC 07-147r2, OGC KML, 2008

In addition to this document, this standard includes several normative XML Schema files. Following approval of this document, these schemas will be posted online at the http://schemas.opengis.net. These XML Schema files are also bundled with the present document. In the event of a discrepancy between the bundled and online versions of the XML Schema files, the online files shall be considered authoritative.

4. Terms and Definitions

For the purpose of this document, the terms and definitions given in the above references apply. In addition, the following terms and definitions apply.

4.1 Portrayal

presentation of information to humans.
NOTE: This term is defined by [ISO 19117].

4.2 Scene, 3D scene

geometry and texture data that is to be portrayed.

4.3 View, 3D view

rendering result generated by projecting a 3D scene to a view plane.

5. Conventions

This section provides details of conventions used in the document.

5.1 Use of the terms "3D scene" and "3D view"

The term "3D scene" refers to a digital representation of geographic data that is mainly composed from 3D graphics data (mainly geometry and texture data), which is also often referred to as 3D display elements.

The term "3D view" refers to a visual representation of a 3D scene that was created by a 3D rendering system and can be directly perceived by humans.

5.2 Abbreviated terms

The following symbols and abbreviated are used in this standard;

3DPIE
 3D Portrayal Interoperability Experiment (see [OGC 12-075])
3DPS
 3D Portrayal Service
CS
 Coordinate System
W3DS
 Web 3D Service
WSC
 OGC Web Services Common
WVS
 Web View Service

5.3 UML notation

UML static structure diagrams appearing in this specification are used as described in Subclause 5.2 of [OWS Common].

5.4 Data dictionary tables

The UML model data dictionary is specified herein in a series of tables. The contents of the columns in these tables are described in Subclause 5.5 of [OWS Common]. The contents of these data dictionary tables are normative, including any table footnotes.

The "Names" column of these tables contains two names for each included parameter or association (or data structure): The first name is the UML model attribute or association role name. The second name uses the XML encoding capitalization specified in Subclause 11.6.2 of [OWS Common].

For the reader’s convenience, table rows describing inherited components are shaded.

5.5 Namespace prefix conventions

The following namespaces are used in this document (Table 1.). The prefix abbreviations constitute conventions used here, but are not normative. The namespaces to which the prefixes refer are normative, however.

Table : Namespaces used in this document.
Prefix Namespace URI Description
xsd http://www.w3.org/2001/XMLSchema XML Schema namespace
core http://www.opengis.net/3dps/1.0/core 3DPS Version 1.0 Core
scene http://www.opengis.net/3dps/1.0/scene 3DPS Version 1.0 Scene Extension
view http://www.opengis.net/3dps/1.0/view 3DPS Version 1.0 View Extension
info http://www.opengis.net/3dps/1.0/info 3DPS Version 1.0 Info Extension

6. 3D Portrayal Service Overview

6.1 Overview

The 3D Portrayal Service (3DPS) is an OGC service implementation specification targeting the delivery of 3D portrayals in an interoperable fashion. When client and service(s) involved share a common set of capabilities, it becomes possible to view and analyze 3D geoinformation from diverse sources in a combined manner.

Major use cases include navigating in the represented scene, retrieving feature information, and analyzing detailed information like simulation results or other 3D spatial information provided using the service instances. See the OGC Spatial Data on the Web Use Cases & Requirements document [OGC 15-074 R1] for additional use cases for 3D on the Web.

6.2 Historical background

In the OGC Military Pilot Project, Phase 1, (MPP-1) three-dimensional portrayal was defined as a new operation — GetView — on a Web Map Service (WMS). As three-dimensional portrayal adds complexities that are out of scope of a WMS, a new Web Terrain Service (WTS) had been defined [OGC 01-061]. Later on, the different aspects and use cases of interoperable 3D geovisualization were discussed in detail by (Altmaier & Kolbe, 2003) within the context of the Geospatial Data Infrastructure North Rhine Westphalia (GDI NRW) in Germany. With the Web 3D Service (W3DS) they proposed a new web service delivering 3D computer graphics models. Two versions of the W3DS were published as OGC discussion papers [OGC 05-019] and [OGC 09-104r1]. OGC-internally, the development of 3D portrayal capabilities led to the proposal of a Web Perspective View Service (WPVS, serving rendered image data), which was generalized and published as OGC Web View Service (WVS) discussion paper [OGC 09-166r2].

Subsequently, five service implementations of at least one of both standards, together with 5 clients (both tailored and general-purpose), were subjected to the 3D Portrayal Interoperability Experiment (3DPIE, final report published as [OGC 12-075]). It emerged that several interoperability scenarios combining both approaches were indeed possible, and that the differences between W3DS and WVS were significant but mostly reconcilable.

However, some weaknesses also emerged. For example, the problem of scaling to bigger geodata was tackled with the well-known tiling technique. Tiling does not easily translate to geometric 3D data, and, as a consequence, there is no one-size-fits-all solution. Despite this, the proposals put forward a limited but complex solution.

The 3DPS combines the essential parts of the proposed W3DS and WVS into one common interface. It intentionally does not address some features, notably tiling, to the degree previous approaches did. However the 3D Portrayal Service SWG recognizes the potential of tiling and welcomes work on standardization to support tiling orthogonally to this standard.

In particular, any kind of approach that is based on spatial index transmission format (as could be negotiated and delivered through a 3DPS implementation) will likely work well in a 3DPS service implementation and benefit from the rich metadata provided through OGC Web Services Common [OWS Common], the portable negotiation of format-specific idiosyncrasies, and the seamless transition to server-side rendering offered by 3DPS. Several such formats are standardized, e.g., [OGC KML]. At the time of this writing, multiple efforts to set industry standards that address the problem of tiling and indexing 3D geodata are also under way.

6.3 Design of this standard

For this first version of a 3D Portrayal Service standard, the goal was to find a unifying core of 3D portrayal tasks that can be standardized as [OWS Common] based requests in that they provide potential for interoperability, do not limit the possible implementations too much, and retain wiggle room for upcoming technologies. It is considered in-scope to define how instances of this specification may establish interoperability in their particular case, but it is considered out-of-scope to define a single baseline for interoperability.

For example, it was clear that new approaches that stream images from live 3D renderings as moving pictures or that provide 3D scenes as a stream of geometries could not be expected to be amenable to standardization efforts at the time.

At the same time, refinement of 3D scenes or 3D representations beyond approaches based on multiple representations were not in the base discussion papers and had to be left out due to a lack of agreement on the semantics of such approaches.

3D portrayal, in particular the scalable sort, poses specific challenges to the design of the underlying data storage and query capabilities, which are partly subject to this standard and partly have to be left to implementations, simply as there is no stable standardization target yet. Thus, it is expected that the number of actually interoperable implementations will lag behind adoption numbers, especially for the scene-based approach (as represented by the scene conformance class). Image-based portrayal, on the other hand, is easier to standardize due to well-established image formats.

This background is reflected in the standard by means of several design decisions. The standard

While these are relatively defensive design goals, the SWG believes that this set represents a good way to a useful first interface supporting interoperable service-based 3D portrayal. The goal of 3DPS is to enable actual interoperation, i.e., to automate matching 3D portrayal clients to services.

6.4 Interoperability scenarios

The interoperability scenarios that this standard enables mirror those demonstrated in the 3DPIE experiments (see OGC 12-075), namely [1]:

However, it is expected that more interoperability scenarios are enabled through this 3DPS standard.

7. 3DPS Service Model

7.1 3DPS operation types

The specified 3D Portrayal Service (3DPS) provides geometric 3D graphics data and/or rendered images. Thus, it supports two fundamental 3D portrayal schemes and associated client/server configurations.

The 3D Portrayal Service interface specifies the following operations that may be invoked by a 3DPS client and may be performed by a 3DPS service.

  1. GetCapabilities — This operation allows a client to request information about a 3DPS server’s capabilities and scene information offered.

  2. AbstractGetPortrayal (abstract) — This is the abstract operation that forms the basis of the 3DPS operations GetScene and GetView and provides common parameters.

  3. GetResourceById — This operation allows a client to request arbitrary resources, as indicated by the service.

  4. GetScene — This operation allows a client to retrieve a 3D scene represented as 3D geometries and texture data, organized as a scene graph and/or spatial index.

  5. GetView — This operation allows a client to retrieve a 3D view of a scene represented as images.

  6. AbstractGetFeatureInfo (abstract) — This is the abstract operation that forms the basis for specific GetFeatureInfo operations that allow a client to retrieve more information about portrayed features.

  7. GetFeatureInfoByRay — This operation allows a client to retrieve information about features that are selected based on a virtual ray.

  8. GetFeatureInfoByPosition — This operation allows a client to retrieve information about features that are selected based on location.

  9. GetFeatureInfoByObjectId — This operation allows a client to retrieve information about features that are selected based on object identifiers.

3DPS Overview
Figure: : 3DPS UML class diagram

Figure 1 illustrates the 3DPS structure and interface as a UML class diagram. It shows that the 3DPS inherits the GetCapabilities operation from the [OWS Common] and adds the 3DPS operations.

A client should first, during a sequence of 3DPS requests, issue a GetCapabilities request to the service to obtain an up-to-date listing of supported operations and available data. To retrieve a vector representation or image representation of the data, a client will then perform one or more GetScene or GetView requests. If the client needs non-portrayal information (attributes) of one of the features, it will issue one of the GetFeatureInfo operations, depending on service capabilities and the information that is available to the client.

7.2 3DPS service handling

The 3DPS operation requests except the GetCapabilities operation make use of the abstract core:RequestBase structure, which mimics the abstract RequestBase data structure from [OWS Common] Subclauses 9.2.

Accordingly, all 3DPS requests except GetCapabilities shall include, in addition to operation-specific parameters, the parameters described in Figure 2 and specified in Table 2:

RequestBase structure
Figure: : 3DPS core:RequestBase UML class diagram

Table : Components of core:RequestBase structure
Names Definition Data type and value Multiplicity and use
service
service
Service type identifier string, not empty
Value is fixed to “3DPS”
One (mandatory)
request
request
Operation name string, not empty
Value is operation name
One (mandatory)
version
version
Standard version for operation string, not empty
Value is fixed to “1.0”
One (mandatory)
extensions
Extensions
Container for any kind of ancillary information to be sent from client to server Extensions type Zero or one (optional)

7.3 Coordinate systems

7.3.1 Coordinate reference systems

This standard uses several coordinate reference system (CRS) types, see Table 3. The two most important CRS types are the request CRS and the layer CRS. There might also be a bounding box CRS that is different from the request CRS.

Since CRS transformation and conversion is not necessarily feasible for some given client, it is recommended for an implementation to ensure a common CRS exists that is available on every layer.

Table : 3DPS Coordinate reference system types
Name Definition
Request CRS The CRS specified after the CRS parameter of a request. It is being considered for viewpoints and bounding boxes in request parameters and as the primary CRS in the response.
Bounding box CRS A bounding box may be given with an explicit CRS specification. The bounding box CRS is either the explicitly specified CRS of the bounding box, or the request CRS.
Layer CRS The layer CRS is (one of) the CRS in which a particular layer is represented. Depending on service capabilities, data from the layer may not be requested if the request CRS is not one of the layer CRSs.
Viewpoint CRS The viewpoint CRS is the CRS in which a viewpoint is defined.

Vertical datum In addition, the issue of a vertical datum is important for 3D portrayal because it defines the third dimension. At the time of this writing, there is no agreement on how to specify a vertical datum in service interfaces, so the vertical datum is implied in many cases. To enable communicating the vertical datum assumed by a service instance, each layer that holds height data shall advertise the vertical datum as a layer CRS. This CRS is then implied in requests querying the layer.

If no such CRS is specified, the vertical datum should be considered unknown, with undefined behavior potentially ensuing.

This approach is subject to change as agreement is reached on handling vertical CRS in geospatial services.

7.3.2 Image coordinate system

An image CS is a coordinate system (CS) for a 3D view produced by a 3DPS supporting the View Extension. A 3D view is a rectangular grid of pixels. The image CS has a horizontal axis denoted x, and a vertical axis denoted y. x and y shall have only nonnegative integer values. The origin (x,y) = (0,0) is the pixel in the upper left corner of the image; x increases to the right and y increases downward. The image CS corresponds to the Map CS described in the WMS specification [OGC 06-042] clause 6.7.2.

The Width and Height parameters used in several 3DPS operation requests correspond to x and y as follows:

8. 3DPS Core

8.1 Shared aspects

8.1.1 Position2D data structure

As defined in Figure 3 and Table 4, Position2D consists of two coordinates. If any of these coordinates is missing or empty, a 3DPS shall raise an InvalidParameterValue exception with the name of the parent element (in case of XML request) or the containing parameter (in case of HTTP/GET request).

core:Position2D and core:Position3D structure
Figure: : 3DPS core:Position2D and core:Position3D structure

Table : Components of core:Position2D structure
Names Definition Data type and value Multiplicity and use
x1
X1
First position coordinate Double Origin and units specified by request CRS One (mandatory)
x2
X2
Second position coordinate Double
Origin and units specified by request CRS
One (mandatory)

8.1.2 Position3D data structure

As defined in Figure 3 and Table 5, Position3D consists of three coordinates. If any of these coordinates is missing or empty, a 3DPS service shall raise an InvalidParameterValue with the name of the parent element (in case of XML request) or the containing parameter (in case of HTTP/GET request).

Table : Components of core:Position3D structure
Names Definition Data type and value Multiplicity and use
x1
X1
First position coordinate Double
Origin and units specified by request CRS
One (mandatory)
x2
X2
Second position coordinate Double
Origin and units specified by request CRS
One (mandatory)
x3
X3
Third position coordinate Double
Origin and units specified by request CRS
One (mandatory)

8.2 GetCapabilities operation (mandatory)

A GetCapabilities operation, as required by [OWS Common], allows a 3DPS client to retrieve service and scene metadata offered by a 3DPS server.

8.2.1 GetCapabilities request

Requirement 1: http://www.opengis.net/spec/3DPS/1.0/req/service/core/getcapabilities/request/structure

A core:GetCapabilities request shall consist of a core:GetCapabilities data structure that is derived from ows:GetCapabilities as specified in [OWS Common] Subclause 7.2.1 and that is refined as specified in Figure 4 and Table 6.

core:GetCapabilities structure
Figure: : 3DPS core:GetCapabilities request UML class diagram

Table : Modified components of core:GetCapabilities request
Names Definition Data type and value Multiplicity and use
service
service
Service type identifier string, not empty
Value is fixed to “3DPS”
One (mandatory)

Sections parameter

According to [OWS Common] Subclause 7.3.3., the Sections parameter value shall contain an unordered list of zero or more names of the elements within a service metadata document that shall be returned. Table 7 lists the sections name values that are allowed; it includes the section name values specified by [OWS Common] and adds the PortrayalCapabilities Section.

Table : Meaning of allowed section name values
Section name Meaning
Service Identification Return ServiceIdentification element in service metadata document
ServiceProvider Return ServiceProvider metadata element in service metadata document
OperationsMetadata Return OperationsMetadata element in service metadata document
Languages Return Languages metadata element in service metadata document
Contents Return Contents metadata element in service metadata document
PortrayalCapabilities Return PortrayalCapabilities metadata element in service metadata document
All Return complete service metadata document, containing all elements

8.2.2 GetCapabilities response

A service metadata document shall be the normal response to a client performing a GetCapabilities request, and shall contain metadata appropriate to the specific 3DPS server. It includes metadata as defined in Subclause 7.4.2 of [OWS Common], a Contents section, and a PortrayalCapabilities section.

Requirement 2: http://www.opengis.net/spec/3DPS/1.0/req/service/core/getcapabilities/response/structure

The response to a successful GetCapabilities request shall consist of a core:Capabilities structure as defined in Figure 5, Table 8, Figure 6, Table 8, Table 10, Figure 7, and Table 12.

core:Capabilities response structure
Figure: : 3DPS core:Capabilities UML class diagram

Table : Components of core:Capabilities structure
Names Definition Data type and value Multiplicity and use
version
Version
Specification version for operation string
Value fixed to “1.0”
One (mandatory)
updateSequence
UpdateSequence
Service metadata document version, value is increased whenever any change is made in complete service metadata document, see [OWS Common] string type, not empty Zero or one (optional)
serviceIdentification
ServiceIdentification
Metadata about this specific service. The schema of this section shall be the same as for all OWSs, as specified in Subclause 7.4.4 and owsServiceIdentification.xsd of [OWS Common]. ows:ServiceIdentification as defined in [OWS Common] as defined in [OWS Common]
serviceProvider
ServiceProvider
Metadata about the organization operating this service. The schema of this section shall be the same for all OWSs, as specified in Subclause 7.4.5 and owsServiceProvider.xsd of [OWS Common]. ows:ServiceProvider type as defined in [OWS Common] as defined in [OWS Common]
operationsMetadata
OperationsMetadata
Metadata about the operations specified by this service and implemented by this service, including the URLs for operation requests. The basic contents and organization of this section shall be the same as for all OWSs, as specified in Subclause 7.4.6 and owsOperationsMetadata.xsd of [OWS Common]. ows:OperationsMetadata type as defined in [OWS Common] as defined in [OWS Common]
languages
Languages
Languages supported by this server. ows:Languages type as specified in [OWS Common], Subsection 7.4.9 as defined in [OWS Common]
contents
Contents
Information about the 3D data content offered through this service Contents type, see Table 9 Zero or one (optional)
portrayalCapabilities
PortrayalCapabilities
Information about the portrayal capabilities of this service PortrayalCapabilities type, see Table 12 Zero or one (optional)

8.2.2.1 Contents section contents

The Contents section of the service metadata document provides details about data layers that can be requested for portrayal. Its structure is derived from the OWSContents definition in [OWS Common], Subsection 7.4.8, as described in Figure 6, Table 9 and Table 10. The ows:DatasetSummary is replaced by core:Layer.