Copyright © 2015 Open Geospatial Consortium.
83 The following example return the image code embedded in the JSON as base64 encoding
{ id: 15,
box: [-180,-90,180,90], title: Example data fragment,
author: ACME Corp., img:{
format: imagegif, data: iVBORw...kJggg==
} }
The following example return the image code embedded in the JSON as base64 encoding
{ id: 16,
title: Example data fragment, author: ACME Corp.,
img: { href=?service=WMSrequest=GetMapformat=imagegif
} }
This encoding ideas reproduce some suggestion coming from: http:json-
schema.orglatestjson-schema-hypermedia.html .
Another possibility is return GeoJSON vectors and relies on the ability of the map brower to present the information to the client. For example Leaflet map client is able to render
GeoJSON on the screen.
10.2.3 JSON for WMS GetFeatureInfo response
GetFeatureInfo response format was left open to the implementations. This was done to make it simple. Since in WMS the data model associated with the features that are
represented in the map is not exposed at least in the general case with no SLD support, we cannot rely on the feature type concept. In this case the capability of the JavaScript
language and JSON of being able to allow for any set of properties can play in our advantage.
It is important that we support both FeatureInfo reports coming from any kind of features including grid coverages. In a general implementation, information can be provided not
just about the features were the I,J point is contained but also from its surroundings. In fact some WMS implementations have a “distance” parameter to specify the radius of the
circle where the server look inside for features to return information about them see support for the vendor specific parameter “buffer” in geoserver 2.7
http:docs.geoserver.orgstableenuserserviceswmsvendor.html.
84
Copyright © 2015 Open Geospatial Consortium.
We propose a special use of GeoJSON to respond to GetFeatureInfo. The GeoJSON will contain a collection of features where each one will represent a feature in the original
data. In the “geometry” part, we return a GeoJSON point when the feature was covering or touching the I,J position or a GeoJSON string formed by two 2 vertices that goes from
the CRS values of the point where the place I,J where pointing and a point that is in the interior or the border of the returned feature. In the “properties” part we could return the
properties of this feature.
{ type: FeatureCollection,
features: [
{ type: Feature,
geometry: {
type: Point, coordinates:
[-47.314159, 45.3141519], },
id: 20245062, properties:
{ COMID: 20245062,
FDATE: 1999-11-24T06:00:00Z, LENGTHKM: 5.415,
REACHCODE: 16060014044574 }
} ]
}
Please note that we recommend that features are well identified. We are not recommending returning the full geometry description because we assume that this is the
work of a WFS GetFeature operation using identifiers recovered by the GetFeatureInfo request.
Recommendation 28: In WMS 1.4 include a encoding for GetFeatureInfo responses based on GeoJSON but replacing the geometry part by maker of the position of the query and the position of
