getfeatureinfo json result not following geojson schema about datacube-ows HOT 4 OPEN

That's a really good question. It's not GeoJSON and I don't know if the standard says what the schema should be.

It would obviously be trivial to make it GeoJSON, but we should prioritise aligning with the standard.

Another option is having another outputFormat option that is something like application:geojson that returns proper GeoJSON, perhaps?

from datacube-ows.

The standard says very little:

The server shall return a response according to the requested INFO_FORMAT if the request is valid, or issue a
service exception otherwise. The nature of the response is at the discretion of the service provider, but it shall
pertain to the feature(s) nearest to (I,J).

i.e. any valid json document pertaining to "the feature(s) nearest to (I, J)" is compliant. (Given that we serve raster, non feature-based data, the interpretation of this part of the standard is even hazier.)

Current implementation reflects the behaviour of GSKY and changing risks breaking Terria integrations. I'll have a think and discuss with the Terria team, but nothing is likely to change in the short term.

from datacube-ows.

this is output from gsky via terria https://gsky.nci.org.au/ows/dea?exceptions=XML&version=1.3.0&feature_count=101&time=2016-10-31T23%3A59%3A59.000Z&styles=fc&service=WMS&request=GetFeatureInfo&layers=hltc_low&bbox=12719121.506653327%2C-3013453.4031147882%2C12758257.26513534%2C-2974317.644632779&width=256&height=256&crs=EPSG%3A3857&query_layers=hltc_low&info_format=application%2Fjson&i=48&j=219

{
type: "FeatureCollection",
features: [
{
type: "Feature",
properties: {
x: 12726459.461369,
y: -3007797.063022,
time: "2016-10-31T23:59:59.000Z",
bands: {
LOW_swir1: 0.3680692,
LOW_nir: 0.22360356,
LOW_green: 0.07778366
}
}
}
]
}

from datacube-ows.

Very similar syntax to OWS, except OWS is much more verbose/informative and uses lat/lon coordinates.

from datacube-ows.