GetPathMapInfo WAMI Services: Dissemination Services for Wide Area Motion Imagery - Best Practice

Copyright © 2012 Open Geospatial Consortium 113 ValueAllValue ValueBasicValue ValueGeospatialValue AllowedValues Meaning A comma-separated ordered list of zero or more names of sections of metadata to be returned. If not set or empty, it means do not send metadata with image data. Shall be optionally implemented by both client and server. When specified, the Disposition parameter needs to be set to allow multipart documents. Meaning Parameter Operation

25.5.5 Response

The response from a GetPathMaprequest bears the exact same format as the GetMap response. There are additional attributes and elements within the XML part for each map that focus on the specified path. Otherwise both are identical in structure.

25.5.5.1 XML Response schema

See [WAMI XSD] element “ExceptionReport” for requests with errors. See [WAMI XSD] element “IS_PathMap” for normal applicationxml result content.

25.5.5.2 Exceptions An error in a GetPathMap request may generate the following exceptionCodes:

1. MissingParameterValue 2. InvalidParameterValue 3. OptionNotSupported 4. NoApplicableCode

25.6 GetPathMapInfo

This request returns metadata on a sequence of one or more maps that were rendered by the path. The request is identical in input and output to a GetPathMap request. However, instead of returning one or more images, it returns one metadata stream comprising of information on those images. There are a few minor differences in GetPathMap and GetPathMapInfo. The Metadata parameter is optional. o An empty Metadata parameter i.e. Metadata= is the same as Metadata=All. o At least Metadata=All must be implemented. o The value to this parameter shall be a comma-separated ordered list of zero or more names of sections of metadata to be returned. If not set or empty …Metadata=..., it means Metadata=All. Copyright © 2012 Open Geospatial Consortium 114 o Besides All, implementing additional parameters is completely up to the server implementation. o This parameter shall be implemented by both client and server. o Contents of metadata are up to a vendor implementation. o The vendor may choose to have zero metadata elements. In that case, if the client requests for metadata, the metadata element in the response shall be empty. The Format parameter takes a MIME type of text[whatever]. Support for applicationxml is required. The response to a GetPathMapInfo request is not multi-part. Transparent and Bgcolor parameters are not required. A server may choose not to implement the GetPathMapInfo request. If the server has implemented GetPathMapInfo, the capabilities response shall reflect so.

25.6.1 Request Parameter Summary

A table of the request parameters for GetPathMap is provided below. Table 29: GetPathMapInfo request parameter summary Parameter name KVP Example Optionality and multiplicity Definition, format and use Service Service=IS Mandatory, one The value shall be IS Request Request=GetPathMapI nfo Mandatory, one The value shall be GetPathMap Version Version=1.0.2 Mandatory, one Version number of service. Shall be implemented by both client and server. Accept Languages AcceptLanguages=en- US Optional, zero or one Please refer to [WAMI OVERVIEW] Exceptions Exceptions=XML Optional, zero or one Sets the format of the exception. Format Format= applicatonxml Mandatory, one Output format of the maps. Shall be implemented by both client and server. CRS CRS=EPSG:4326 Mandatory, one The coordinate reference system of the requested maps. Shall be implemented by both client and server. Metadata Metadata=All Optional, zero or one A comma-separated ordered list of zero or more names of sections of metadata to be returned. If not set or empty, it means do not send metadata with image data. Shall be optionally implemented by both client and server. Options.OPT ION_NAME Options.jpeg_qualit y=75Options.jpeg_y uv=420 Optional, zero or one Vendor specific options for this request. Extends the request. Default: Options=. Shall be optionally implemented by both client and server. Path Path=URL EncodedXML Mandatory, one Specifies the tracks to be rendered by the service. Shall be implemented by both client and server.

25.6.2 XML Encoding schema

See [WAMI XSD] element “IS_GetPathMapInfoRequest” Copyright © 2012 Open Geospatial Consortium 115

25.6.3 Request Parameter Details

Parameters match those of GetPathMap where required above. 25.6.4 Response 25.6.4.1 XML Response schema See [WAMI XSD] element “ExceptionReport” for requests with errors. See [WAMI XSD] element “IS_PathMapInfo” for normal applicationxml result content.

25.6.4.2 Exceptions

An error in a GetPathMapInforequest may generate the following exceptionCodes: 1. MissingParameterValue 2. InvalidParameterValue 3. OptionNotSupported 4. NoApplicableCode 26 Supporting Band Combinations and Bit-Depths Source data can be 1-band, for instance, luminance and IR data, 3-band, for instance, RGB data or have more than 3-bands such as multi-spectral data. While single multi-spectral WAMI sensors may not be currently available, this specification needs to keep them in mind. Sensors may collect source data at any specific bit-depth. Some of the popular bit-depths at which image file format store pixels for a band are unsigned 8-bit u8, unsigned or signed 16-bit s16, u16, unsigned or signed 32-bit s32, u32, 32-bit floating point f32, and 64-bit floating point f64. If data is captured in 10, 11, 12, or 14-bit space, it is generally stored within a 16-bit number for ease of processing. Many formats, such as TIFF, NITF, JPEG2000 support storing higher bit depth than 8-bits per band. A WAMI service may have support the dissemination of images with higher band count as well as higher bit-depths per band. As an example, consider a collection C, with 7-bands, from B1 to B7. Assume that each band is s16. A collection service can state that: The collection C is being served with B1, B3, and B4 at such and such collection ID. The collection C is being served with B1, B2, and B3 at such and such collection ID. The collection C is being served with B4, B5, and B6 at such and such collection ID. The collection C is being served with B7 at such and such collection ID. And so on… Copyright © 2012 Open Geospatial Consortium 116 Bit-depths can be supported via either the Options or the Format parameters in GetMap. Source bit-depth information can be conveyed via the AOI’s metadata. Output image bit-depth can either be part of Options parameter, for instance Options.Jpeg.BitDepth=12 , or using the Format parameter, for instance Format=imagejpeg; bitDepth=12 or Format=imagetiff; bitDepth=u16 provided of course, GetCapabilities returned that as one of the supported Options and Formats. The authors recommend that the default Format=imagejpeg or Format=imagetiff should be browser-friendly and generate 8-bit data. Conversion from a higher to lower bit-depth is completely up to the vendor implementation. It is also recommended that the output image be visually acceptable because the authors believe that a down-sampled image is used for visualization and the original bit-depth is used for image processing. Support for band-combinations, higher bit-depths, high-to-low bit-depth transformation, and techniques used in that transformation are completely up to a vendor implementation. Copyright © 2012 Open Geospatial Consortium 117 27 Section 4: Video Service The name of this service is VS or Video Service. A Video Service serves a client a requested area of interest AOI from a collection of WAMI data and delivers it as a video stream or file of a known format. Italso provides metadata about the same AOIas part of the video stream. The video stream delivered is in a standard and known format. At least one video stream must be supported. At least one video stream must be MISB compliant to follow the MISP. To find out collections are being served by a service, or to get information about a collection, use a Collection Service or CS. See Collection Service Specifications version 1.0.2 for more. 28 VS data model

28.1 Client Resources, Bandwidth, and Latency