getfeatureinfo json result not following geojson schema

[pindge]

geojson featurecollection schema is available here: https://geojson.org/schema/FeatureCollection.json

output from integration test

{
   "type": "FeatureCollection", 
   "features": [
      {
           "type": "Feature", 
           "properties": {
               "data": [{"time": "2022-01-10 02:01:24 UTC", "bands": {"coastal_aerosol": 241, "blue": 197, "green": 59, "red": 12, "red_edge_1": 50, "red_edge_2": 38, "red_edge_3": 39, "nir": 10, "nir_narrow": 14, "water_vapour": 30, "swir_1": 39, "swir_2": 35, "aerosol_optical_thickness": 204, "scene_average_water_vapour": 6376, "SCL": {"Sen2Cor Scene Classification": "water"}}, "band_derived": {"ndvi": -0.09090909090909091, "ndvi_expr": -0.09090909090909091, "rgb_ndvi": -0.09090909090909091, "ndvi_delta": -0.09090909090909091}}], "lon": 124.5812626857451, "lat": -14.191015964373287, "data_available_for_dates": ["2021-12-21", "2021-12-26", "2021-12-31", "2022-01-05", "2022-01-10"], "data_links": ["https://sentinel-cogs.s3.us-west-2.amazonaws.com/sentinel-s2-l2a-cogs/51/L/XE/2022/1/S2B_51LXE_20220110_0_L2A/S2B_51LXE_20220110_0_L2A.json"]}
       }
   ]
}

https://www.jsonschemavalidator.net/ returns check failed, whereas example from https://docs.geoserver.org/stable/en/user/tutorials/GetFeatureInfo/geojson.html passes schema validation

[alexgleith]

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?

[SpacemanPaul]

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.

[pindge]

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
}
}
}
]
}

[SpacemanPaul]

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

[SpacemanPaul]

So GeoJSON compatibility would just require a geometry section on the end right? (A point would be the easiest).

[alexgleith]

just require a geometry section on the end right

It'll require a geometry object for each feature returned.

And for what it's worth, GSKY returning x and y properties is not helpful at all! haha, that's not geojson!

[SpacemanPaul]

Luckily GSKY is dead and buried now and we no longer need be constrained by it.