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 11 and Table 12. The ows:DatasetSummary is replaced by core:Layer.

The components of the core:Layer are described and discussed in the following.

Every Layer is available in one or more layer coordinate reference systems. In order to indicate which layer CRSs are available, every named Layer shall have at least one AvailableCRS element that is either stated explicitly or inherited from a parent Layer. The root Layer shall include a sequence of zero or more AvailableCRS elements listing all CRSs that are common to all subsidiary layers. A child layer may optionally add to the list inherited from a parent layer. Any duplication shall be ignored by clients.

When a Layer is available in several coordinate reference systems, the list of available CRS values shall be represented as a sequence of AvailableCRS elements, each of which contains only a single CRS name.

EXAMPLE: <AvailableCRS>CRS:84</AvailableCRS> <AvailableCRS>EPSG:26718</AvailableCRS>.

A layer may contain objects in several representations to choose from. Thus, each layer may advertise a set of ``levels of detail'' (LODs) present on that layer by referring to the LOD names as defined in the AvailableLODScheme elements of the PortrayalCapabilities section. See AvailableLODScheme for more information on LODs.

For each Layer, a server may advertise layer-specific styles (service styles), which modify the appearance of feature representations retrieved through the 3DPS AbstractGetPortrayal operation. For each layer-specific style, it provides an AvailableStyle element of type Style, which is listed in Table 13.

Each Style consists of an Identifier, a Title which may be presented to the user, an Abstract and a list of Keywords. The Abstract should give a brief narrative description of how the visualization is influenced by the style. The style identifier is used in an AbstractGetPortrayal request’s Style parameter.

If more than one available style is advertised for one Layer, the server shall declare one of those AvailableStyle items as default by settings its IsDefault property to ``true''. If only a single style is available for one layer, that style does not need to be advertised by the server and is implicitly used as the layer’s default style.

For a layer several delivery options may be available a client can choose from. Thus, each layer may advertise a set of delivery options present on that layer by referring to the delivery option names as defined in the DeliveryOption elements of the PortrayalCapabilities section; see DeliveryOption.

The Extensions component is provided as a canonical place for extensions to define layer-specific metadata and can be used, e.g., by 3DPS extension modules as a hook for operation-specific layer extensions.

The PortrayalCapabilities structure is specified in Figure 7 and Table 14, Table 15, Table 16, Table 17, Table 18, Table 19.

For selecting features to be part of a portrayal response, a server has to check the spatial relation between the request BoundingBox and the feature’s 3D geometry.

In Table 20 the three possible spatial selection methods defined by this standard are named and described.

The default selection method is ``overlaps'', which includes any feature that is partly or entirely contained in the request BoundingBox into service response.

An OverallStyle is usually a reference to a scene or view embellishment that is not treated as being bound to a specific layer, e.g., an adornment of certain features, or a special shading to be used to portray a data overlay in the 3D scene or view. For simple clients, such embellishments may result in a much improved user experience, or show additional information. However, such offerings are often implementation-specific and may be harmful to service interoperability.

A server advertises available these portrayal-wide styles through a number of OverallStyle elements, each containing an OverallStyle name, which can be used by a client within a portrayal request.

The Background parameter contains an available background as described in Table 18. If no Background is advertised, the server uses an internal default background for portrayal.

The AvailableLODScheme element describes a set of Levels of Detail (LODs) that can be provided by the advertised Layers (see Figure 6).

In this document, the term LOD refers to the concept of discrete Levels of Detail, meaning that any given geographic feature may have multiple geometric representations. These representations can be considered independent of each other, for the purpose of portrayal.

For instance, a building may be represented a) as simple box geometry, b) as a geometry with additional façade textures, c) as a group containing elements for walls, roofs, windows, doors, or d) even as a group containing the complete room interior. Each of these representations describes the same geographic feature and can therefore be stored in the same layer. However, it is not necessary that all LODs are consistently available for each feature. A client may assemble its scene graph from subsets of the same layer having different LODs and thus adjust the workload placed on the graphics pipeline.

Usually LODs are organized in one or more LOD schemes, which describe attributes of the individual LODs so a client is able to process and use them adequately. Each LOD scheme (of which there may be one or more) contains a title, abstract, unique identifier, and a full order of LOD definitions, which carry the actual numeric value or magnitude of the LODs.

This LOD value is a URI consisting of the LOD scheme’s identifier value as prefix and the actual numeric value, separated by a colon, e.g., ``CityGML:4'' for CityGML indoor building models. The prefix indicates the spectrum of possible values and how these values should be interpreted and, conventionally, is fixed per AvailableLODScheme node.

The exact meaning of individual LOD levels remains out of scope for the purposes of this standard. However, the order should, on average, reflect the complexity of members of a certain level of detail definition.

The numeric value indicates the actual level'' of detail on that ordinal scale. The scale values have a total order, which is connex (a > b or a < b or a = b) and transitive (a > b > c implies a > c), but no interval or metric may be derived from the values. For instance, CityGML:4'' is more accurate than ``CityGML:2'', but not necessarily twice as accurate.

The order of the LOD nodes within the AvailableLODScheme node is not defined, but it is recommended to use an order increasing by the LODValue, from lower to higher levels of detail.

Table 21 lists LOD names associated with well-known LOD schemes whose meaning should be preserved, i.e., no conflicting names or semantics should be introduced by a service implementation.

The AvailableLODSelection components list the LOD selection methods that a client can apply for telling the service how to interpret the requested LOD value for each layer.

Four selection methods are predefined that fit the well-known LOD-based multiple representations approach. These predefined LOD selection methods are defined in Table 22. A specific 3DPS server may define additional LOD selection methods.

A delivery option is an optional mode that affects how the implementation serves its data. For example, whether the service sends a full textured building or some down-scaled variant that looks alike from a distance may be controlled using a delivery option.

The goal of delivery options is to be able to broker the best-performing exchange mode between a client and a service instance without causing malfunction due to interoperability issues. If an implementation has special features geared towards specific clients, e.g., an optimized streaming option for terrain data, it should use the delivery option as a marker on the layers that support the feature. Clients are expected to possess a positive list of delivery options they support, and to only ask for delivery options they are ready to support.

Delivery options are a way to safeguard tweaks, optimizations, and other means necessary for performance but detrimental to interoperability. Delivery options help to establish interoperability and improve performance in more complex settings, e.g., involving multiple service instances, by making communications more transparent, predictable, and thus dependable.

Similar to the Format parameter, availability of delivery options may affect the potential for interoperability with a given client. Unlike the Format parameter, delivery options may co-exist in a single request, they may or may not not be subject to interoperability considerations, and finally, delivery options do not require (but benefit from) a shared understanding of the available options. Accordingly, some delivery options may be sensible only in specific clients, uncommon format profiles, or depend on other specific circumstances that a client does not know about.

Clients should match the service-provided list of delivery options with an internal list of desired mechanisms, and generally refrain from requesting unsupported or unwanted delivery options. Delivery options may have an impact on interoperability, but there seems to be no general way of communicating the pitfalls or benefits associated with them. This standard therefore just specifies name and identifiers, which hopefully serve to safely determine the (absence of) potential for interoperability.

The intent behind delivery options is to provide safe means of establishing interoperability. That is, it should be known in advance and not through user-observed or silent failure, if a client may communicate and portray properly data from a set or subset of service instances. MIME types, formats, and their profiles alone are not well-suited to capture the fast-paced evolution in 3D portrayal in the detail required to establish interoperability. In lieu of a commonly accepted mechanism to do that, delivery options enable safeguarding the development of improved mechanisms so that interoperability can be safely determined by machines.

The same goals could be achieved by using MIME types and parameters (e.g., RFC 2231), but while MIME has interoperability as a goal, performance or bandwidth are not generally seen as a concern for MIME. Moreover, many of the practically working approaches encompass several formats, making the reliance on MIME types artificial.

Given these considerations, the ``delivery options'' approach seems a much more workable way of addressing the current diversity of mechanisms. Interoperability may be assessed by humans and can be implanted (in a backwards-compatible manner) into clients because each delivery option is associated with multiple URIs treated as aliases, some of which may serve backwards compatibility. Thus, implementers of this standard may safely evolve their designs as long as they make breaking changes visible through delivery options.

A ViewpointHint parameter describes a meaningful camera specification, which a client can use to request a specific portrayal. For this, it suggests meaningful combinations of camera position (POC), camera look-to (POI), camera up-direction (UP) as well as a field of view angle in x-direction (FOVX).

The SupportsBoundingBoxConversion parameter is ``true'' if the service instance supports conversion of bounding boxes from the request CRS into appropriate layer CRS for query.

The Extensions component is provided as a canonical place for extensions and can be used, e.g., as a hook for operation-specific service metadata by 3DPS extension modules.

The CRS parameter defines the coordinate reference system that is considered to be in effect for the operation request and response. In particular, it is considered as the CRS for the bounding box if that is not specified explicitly. See Coordinate systems for details.

The parameter value for the coordinate reference system (CRS) is defined in Subclause 10.3 of [OWS Common] and [OGC 04-046r3]. If a 2D CRS is used, the height reference is taken from the layer’s vertical datum.

The BoundingBox parameter allows a Client to request a particular spatial subset.

It defines the coordinates of the bounding box corners in at least 2 dimensions and, optionally, the CRS in which they are specified. The CRS given is relevant only to the query and defaults to the one given with the CRS parameter.

If a 3DPS service supports a bounding box CRS other than the available Layer CRS, this capability should be advertised in the metadata document by setting the SupportsBoundingBoxConversion.

The BoundingBox data structure is defined in [OWS Common] Subclause 10.2. The units, ordering, and direction of increment of the x1, x2, and x3 axes are as defined by its CRS element.

If the BoundingBox values are not defined for the given CRS (e.g., latitudes greater than 90 degrees in CRS:84), the service shall treat this as an error. If a request contains an invalid bounding box (e.g., one whose minimum x1 is greater than the maximum x1) the service shall treat this as an error. No axis wrap-around behavior should be assumed.

The SpatialSelection parameter defines the method that a server shall use to check the spatial relation between the requested BoungindBox and the features' 3D geometries. Available methods for spatial selection are advertised in the server’s metadata document. See AvailableSpatialSelection for more details.

The Layers parameter specifies a comma-separated list of data layers to be displayed. The concept of the layer is a metaphor to the traditional (two-dimensional) cartography, with which geo objects of different classes were drawn on different transparent foils resulting in a map with an overall view of these foils.

The definition of a layer for the purposes of this standard is lent from WMS: ``basic unit of geographic information that may be requested as a map from a service''.

The Layer parameter contains a list of layer identifiers that specifies the layer to include. The order in which the layers are listed in the Layers parameter does not influence the visual appearance of the generated scene or view. However, the order of the lists in the (optional) Styles and LOD parameters shall correspond with the Layers list. Each entry in the Layers list shall refer to a layer identifier as described in the service metadata.

The Layers parameter can be empty, which means not to constrain the output to any specific set of layers. A service receiving an empty Layers parameter could a) serve all data available, b) serve only a subset of the data, or c) serve no data at all.

The Styles parameter lists the visual styles in which each layer is to be rendered. There is a one-to-one correspondence between the values in the Layers parameter and the values in the Styles parameter: The Styles list shall contain one Style identifier for each Layer in the Layers parameter; the order shall be the same. Thus, the Styles list shall have the same length as the Layers list.

A client may request the default style for a layer using an empty value. If several layers are requested with a mixture of named and default styles, the Styles parameter shall include empty values between commas (as in STYLES=style1,,style2,,'') to represent default Styles. If all layers are to be shown using their default styles, a request shall contain either multiple comma-separated values one for each layer (as in STYLES=,,,'') or a single empty value (``STYLES='').

Each data layer in the list of Layers is rendered using the corresponding style in the same position in the Styles list. Each style name shall be one that was defined for or inherited by this layer as specified in the service metadata. (In other words, the client may not request a layer in a style that was only defined for a different layer.)

If a service advertises several styles for a layer and the client sends a request for the default style, the choice of which style to use as default shall be indicated in the service metadata, see Table 13.

Currently, the 3DPS only supports service-defined styles, advertised by identifier in the service metadata. Thus, styling of features may not be transparent to a client. Therefore, it is recommended to include a detailed style description in the service metadata. In case of user styles included in the GetScene request, the client has full control over the styling.

EXAMPLE: Layers=dtm,vegetation,buildings&Styles=orthophoto,,textured

The Background parameter tells the server which background to apply to creating the 3D portrayal. It contains of the background identifiers advertised in the service metadata document.

The parameter LODs specifies for each layer which Level of Detail (LOD) to choose from when accessing the service’s data repository. The parameter value is a list of names referring to the available LODs as specified in the service metadata’s PortrayalCapabilities and Contents sections, see AvailableLODScheme.

The length of the LODs list shall be equal to the length of the list in the Layers parameter. The order of the LODs list entries shall correlate with the Layers list entries, meaning that LOD n shall be selected from layer n.

In conjunction with the LOD parameter, the LODSelection parameter may be used for telling the service how to interpret the LOD value for each requested layer. The selection methods offered by a 3DPS service are advertised in the service metadata. See AvailableLODSelection for more details on LOD selection methods.

The OverallStyles parameter specifies, which styles to apply to the overall 3D scene or view. It contains a list of identifiers of OverallStyles as described in the service metadata; see OverallStyle.

If no OverallStyles are specified in the service request, a service implementation should not apply or deliver any. If the combination of styles requested cannot be delivered, the service should make an effort to prioritize the first-mentioned overall styles, or return an exception.

The DeliveryOptions parameter specifies a list of delivery options requested by the client. The client is expected to be prepared to properly handle each of the delivery options. See DeliveryOption for details.

This list is to be interpreted as a request, i.e., failure to use a specific delivery option is not to be treated as an error. The reason is that it is hard to foresee, properly describe, and implement the constraints that might hold for a particular delivery option, e.g., a terrain streaming method might have legal constraints depending on the effective legislation. It is not, in full generality, possible for a client to only ask for delivery options that will work for the service instance. A more mundane case might be a delivery option that is only available for a part of the layers being requested. Treating this as an error would preclude forming such a request.

However, requesting a delivery option that is not advertised for any of the layers being requested, or not at all, should be treated as an error with the DeliveryOptionNotDefined exception code.

The Exceptions parameter specifies the behavior of the service upon detecting an error, e.g., an invalid request or an internal server error. The default value is ``text/xml''. The value shall be one of the MIME types offered in the service metadata document.

If the Exceptions parameter is set to blank'' (i.e., the character sequence comprised of `b', `l', `a', `n', `k'), then the service shall, upon detecting an error, return a document of the MIME type specified in the format parameter whose content is uniformly off'', i.e., a response document with a valid structure according to the requested format and with no or no useful content. This silent mode is useful if the client is not prepared to process service exceptions. For example, the client may be a generic client that understands the format expected but not OGC exception reports.

Accordingly, the service may issue an HTTP status code of 200 (OK) or 204 (no content) instead of an error code (see AbstractGetPortrayal exceptions).

The Extensions parameter carries ancillary informatino to be sent from client to server.

A ResourceId parameter shall be part of each core:GetResourceById operation request.

The OutputFormat parameter specifies the expected output format. While the output format may be determined by the resource identified with the resource identifier, specifying the output format works in cases where that is not the case (e.g., multiple representations of one resource) but not vice versa. The format, even if not necessary for resource selection, should be used for validation.

The AvailableFormat element provides information about data formats in which the advertised Layers are available.

AvailableFormat items advertise available encodings of scene data returned by the GetScene operation as ows:MimeType as per [OWS Common] Subclause 10.5.

Table 29 specifies canonical MIME types. These MIME types shall be advertised and recognized by a service implementation if the formats represented by them are supported, even if more qualified alternatives exist.

Annex D describes the X3D profiles and nodes that are appropriate for use by a service that returns X3D. It highlights the use of the X3D Geospatial component, which is important to support, as it allows for combination of content from different services.

Styles usually affect the symbolization of features, e.g., the materials can be replaced by another material, including diffuse color, reflection properties, and transparency as defined in the style. Styling can also take the feature attribute values as input for distinguishing features of different categories by color. Styling may also apply different symbols to point and line features including geometric primitives, billboards, textures, and complex 3D prototypes. The size of these symbols may be scaled according to feature attribute values. It is recommended to use the Symbology Encoding (SE) and Filter Encoding (FE) as basis for defining service styles (see [OGC 05-077r4] and [OGC 09-026r2]), and extend the capabilities for styling 3D objects (see [OGC 09-042]).

The SupportsArbitraryOffset component specifies whether the server allows a client to request arbitrary offset parameters. The element’s default value is ``false''.

A color layer contains a color value for each pixel, e.g., RGB or RGBA color data. Alpha values are required for storing a transparent background. For color layers, standard image encodings provide good compression results.

A depth layer encodes for each pixel the distance to the visible surface. Unit of measure shall be meter (#m) as defined by GML3 [OGC 03-105r1]. This representation abstracts from computer graphical details and the distance values can be used without additional computation in an application. Also, depth images represent a major means to compose multiple images generated from the same camera position and by the same projection.

Object identifiers (object-ids for short) are distinct numeric values assigned to all the features in the 3D geo database provided by the 3DPS. An ObjectId layer contains an object-id for each pixel and allows a client application, e.g., to determine all the pixels that show a specific feature or to retrieve feature information based on the object-id.

For a 3DPS service, object-ids shall be unique over all provided data Layers and even over multiple GetView requests, due to facilitating consistent interaction across multiple 3D views. The object-id basically refers to the graphical representation of a feature and does not necessarily equal to the feature’s identifier. It is rather left to a specific 3DPS service how to determine and assign unique object-ids to all features. Object-id value ``0'' is reserved for pixels that do not represent a feature (e.g., pixels representing the sky) or for which no object-id could be determined.

A normal layer describes for each pixel the direction of the surface normal visible at that pixel. A normal layer might be used, e.g., for computing good camera positions of client-side computation of image effects. The normal layer contains the value ``0'' for a pixel that does not represent any surface point (e.g., sky or transparent background).

A mask layer contains a value of 1'' for each pixel that covers a scene object and 0'' otherwise. For example, Mask layers provide information about unused image space or support client-side altering of the scene background.

The image layers specified in this View Extension represent a fundamental subset of view-related data. However, image layers are not limited to the specified ones. A 3DPS service can implement and advertise additional image layers in the service’s metadata document together with available encodings and formats.

Image layer encodings can differ in

Image layer encodings/formats shall be advertised as (parameterized) MIME types in the service’s metadata document.

The View Extension suggests representing image layer data in colors and encoding them by appropriate standard image formats. Alternative encodings/formats are possible.

In the following, default encodings for the suggested image layers are described. Table 36 provides an overview of the corresponding MIME types describing these default encodings. A MIME type parameter ``mode'' shall be used for adjusting the required bit depth.

For alternative service-specific data encodings, a MIME type parameter ``encoding'' should be used for identifying the data encoding and format.

EXAMPLE: A 3DPS service-specific MIME type for a normal layer encoding could be ``image/png;mode=24bit,encoding=two-component'' which specifies the representation of normal vectors by two components only.

Per default, depth values shall be represented by float values. They shall be encoded as colors by converting the float value into a Byte array and assigning these Bytes to the color components. The endianness shall be BGR for 24-bit encoding or ABGR for 32-bit encoding. Due to the direct storage as color components, resulting depth images possess very little pixel-to-pixel coherence, and should not be stored in lossy image formats.

Per default, object-ids shall be represented by unsigned integer values. They are encoded as colors by converting the object-id integer value into a Byte array and assigning these Bytes to the color components. The endianness shall be BGR for 24-bit encoding or ABGR for 32-bit encoding. This does not specify the internal endianness of the image format used to encode the colors, rather the mapping of bytes to properly decoded and separated color components.

Per default, normal layers encode normalized normal vectors in world space by encoding each vector component (X,Y,Z) as color component (B,G,R) of a 24-bit color image. A surface normal shall be encoded as 24-bit RGB color value in the following way:

A 3DPS consumer requesting a normal layer encoded in this default format, shall decode this data the other way round, by multiplying with 2 and subtracting 1 and assigning the value to the x, y, and z components of a normal vector.

Mask values 0 and 1 shall be color-encoded as follows: white shall be used for mask value 0'', i.e., for pixels that do not cover a scene object; the color black shall be used mask value 1'', i.e., for pixels that do cover scene objects. Mask layers could be encoded in any image format, but formats capable of 1-bit content should be preferred for coding efficiency.

For retrieving good visual results from the 3D portrayal service, the near and far clipping planes restricting the viewing frustum have to be set appropriately. The NearPlaneHint and FarPlaneHint parameters provide a hint on such values.

The SupportsMultipleViews parameter is a flag that signals if a 3DPS service supports responding multiple views or multiple image layers by a single GetView response as HTTP multipart/mixed message (see MIME multipart response).

The mandatory Width and Height parameters specify the size in integer pixels of the 3D view that shall be generated. The image CS (see Image coordinate system) applies to the image. Width-1 specifies the maximum value of the x-axis in the image CS, and Height-1 specifies the maximum value of the y-axis in the image CS.

If the request is for an image format, the returned picture, regardless of its MIME type, shall have exactly the specified width and height in pixels.

The mandatory Projection parameter specifies a projection to apply for generating the 3D view(s). A projection contains the specification of the virtual camera and projection parameters as defined in 3D projections, Table 39 and Table 40.

The ImageLayers parameter contains a list of references to one or more image layers as advertised by the 3DPS in it’s service metadata, e.g., one of those listed in Table 35.

The mandatory Formats parameter specifies a list of image formats as ows:MimeType, see Subclause 10.5 of [OWS Common]. The length of this list shall be equal to the length of the list in the ImageLayers parameter. The order of the list shall correlate with the list in the ImageLayers parameter, meaning that format n shall be applied for encoding the data of image layer n. Each entry in this list shall refer to a MIME type as described in the service’s metadata (see Table 42).

The optional Qualities parameter specifies a list of integers, which describe the visual quality of the output for each requested image layer and format . Values are between 0 and 100. Empty values are possible and refer to the default value (100). If the list is empty, the default value is applied for all of the requested image layers.

The Qualities parameter is mainly useful for COLOR images; for other image layer types, the compression algorithms can generate invalid data. Additionally, the Qualities parameter is only useful for output formats that support image compression. If a requested output format does not support different qualities, the 3DPS shall ignore the parameter for this format.

The value of the optional BoundingBox parameter is a list of comma-separated real numbers as described in Subclause 10.2.3 of [OWS Common]. The units, ordering, and direction of increment of the X and Y axes are as defined by the request’s CRS parameter.

The mandatory Layers parameter shall be a comma-separated list of Layer identifiers as advertised in the service metadata’s Contents section.

The Styles parameter shall be a comma-separated list of Style identifiers as advertised in the service’s metadata Contents section.

The Portrayals parameter lists one or multiple items of Portrayal type (see Table 46) and shall be encoded in conformance to the following grammar (using EBNF, Extended Backus-Naur Form notation [ISO/IEC 14977]):

The Portrayal components are encoded as follows:

URL encoding according to [RFC 1738] is required for parameter values.

EXAMPLE: The encoding of the parameterized MIME type image/png;mode=32Bit'' is image%2Fpng%3Bmode=32Bit''.

The Projection parameter (which is a component of a Portrayal) shall be encoded as comma separated list of tuple values. The size of this tuple shall be the same as the number of the parameters of this projection plus one (the preceding Projection Identifier). The order of the projection’s parameter values shall be the same as in the service metadata. For optional projection parameters (see Table 39 and Table 40) the values can be empty. In this case, the service has to use default values, ignore parameters, or compute values.

Example: An example XML-encoded FeatureInfo response is:

A GetFeatureInfo operation response may look like this encoded in text/html: