Add option to 'compact' GeoJSON result into single feature

[frankinspace]

Currently when a time series is requested as GeoJSON output, the result is structured as a FeatureCollection where each feature in the collection is the same feature at different time steps. Each feature also includes it's own distinct geometry.

I propose that we have an option that would allow the user to instead get back only a single Feature where the properties of that feature contain all the fields requested by the user but as a list instead of a single value.

This would save a lot on the size of the returned GeoJSON object for long time series results which would help with both egress cost and individual request latency.

Example:

{
    "status": "200 OK",
    "time": 458.179,
    "hits": 3,
    "results": {
        "csv": "",
        "geojson": {
            "type": "FeatureCollection",
            "features": [
                {
                    "id": "0",
                    "type": "Feature",
                    "properties": {
                        "reach_id": "73282400171",
                        "time_str": "2023-07-28T22:10:37Z",
                        "wse": "211.178",
                        "slope": "-0.0007516914999999999"
                    },
                    "geometry": {
                        "type": "LineString",
                        "coordinates": [...]
                    }
                },
                {
                    "id": "1",
                    "type": "Feature",
                    "properties": {
                        "reach_id": "73282400171",
                        "time_str": "2023-09-08T15:40:49Z",
                        "wse": "82.082",
                        "slope": "-1.0184e-06"
                    },
                    "geometry": {
                        "type": "LineString",
                        "coordinates": [...]
                    }
                },
                {
                    "id": "2",
                    "type": "Feature",
                    "properties": {
                        "reach_id": "73282400171",
                        "time_str": "2023-09-29T12:25:52Z",
                        "wse": "206.49349999999998",
                        "slope": "-0.0007833485000000001"
                    },
                    "geometry": {
                        "type": "LineString",
                        "coordinates": [...]
                    }
                }
            ]
        }
    }
}

Would instead become:

{
    "status": "200 OK",
    "time": 458.179,
    "hits": 3,
    "results": {
        "csv": "",
        "geojson": {
            "type": "FeatureCollection",
            "features": [
                {
                    "id": "0",
                    "type": "Feature",
                    "properties": {
                        "reach_id": ["73282400171", "73282400171", "73282400171"],
                        "time_str": ["2023-07-28T22:10:37Z", "2023-09-08T15:40:49Z", "2023-09-29T12:25:52Z"],
                        "wse": ["211.178", "82.082", "206.49349999999998"],
                        "slope": ["-0.0007516914999999999", "-1.0184e-06",  "-0.0007833485000000001"]
                    },
                    "geometry": {
                        "type": "LineString",
                        "coordinates": [...]
                    }
                }
            ]
        }
    }
}

In practice we would have to use the geometry from one of the entries in the database but I don't think it is too important which one is chosen.

@torimcd @cassienickles interested in your thoughts on this.

[frankinspace]

General consensus is yes, this feature is useful. Users want to retain ability to choose which return format is returned

[frankinspace]

Consider 'compact' instead of 'compress' as the name of the variable because compress is generally associated with compression algorithms like zip or bz.

Also, need to add documentation section describing how we handle the 'properties' object for features returned from hydrocron. The GeoJSON RFC specifies that 'properties' can be any valid JSON object (https://datatracker.ietf.org/doc/html/rfc7946#section-3.2). So, it is up to us to describe to end users how that object is structured.

[nikki-t]

@frankinspace - Do you think we should return a compact response for cases where the Accept header is application/geo+json? Reading the RFC it seems like this might still be valid GeoJSON? If so it might be nice to allow the user to return the compact version of GeoJSON.

[frankinspace]

Good idea, yes agreed. I was thinking we would wait to make compact the default when we update to v2 of the API because it's technically a breaking change to the API (changing the format/schema of the returned object would break clients).

But, since the application/geo+json is a new feature I think we can start with compact being the default, then transition the json response to default to compact with the V2 upgrade