NASA-IMPACT / veda-docs

Documentation for the VEDA Project
https://nasa-impact.github.io/veda-docs
Apache License 2.0
7 stars 6 forks source link

Ocean NPP notebook is broken #132

Closed wildintellect closed 5 months ago

wildintellect commented 5 months ago

@freitagb reported there's an issue in https://nasa-impact.github.io/veda-docs/notebooks/datasets/ocean-npp-timeseries-analysis.html#the-case-study---walvis-bay-namibia

# the bounding box should be passed to the geojson param as a geojson Feature or FeatureCollection
def generate_stats(item, geojson):
    result = requests.post(
        f"{RASTER_API_URL}/cog/statistics",
        params={"url": item["assets"]["cog_default"]["href"]},
        json=geojson,
    ).json()
    return {
        **result["properties"],
        "start_datetime": item["properties"]["start_datetime"],
    }
the return statement here no longer works because the response structure from the API has changed (at least i think that's why). For example it works if i do
    return {
        **result["features"][0]["properties"],
        "start_datetime": item["properties"]["datetime"],
    }
jsignell commented 5 months ago

I can't reproduce. The notebook works fine for me on vedahub with the latest pangeo image. I looked at the docs though and it does seem like the response can potentially be either a feature or a feature collection https://staging-raster.delta-backend.com/docs#/Cloud%20Optimized%20GeoTIFF/geojson_statistics_cog_statistics_post

I guess we could genearalize that function to expect either, but it seems like the API should guarantee the schema of the response.

wildintellect commented 5 months ago

let's pass this over to the Data Service team to review then. cc @smohiudd @anayeaye

anayeaye commented 5 months ago

So is the issue here that (I've just read this issue and the notebook and haven't tried to test this yet):

Feature in = Feature out If you request cog/statistics with a feature collection you get a response that is a feature collection of the stats in each feature's properties.

Feature Collection in = Feature Collection out And if you request cog/statistics with a single feature then you get a response that is a single feature including stats in that feature's properties.

So we need to

OR are we saying that one API should always return the same format, i.e. you request with a single Feature or Feature Collection, we always return a Feature Collection?

jsignell commented 5 months ago

That's a nice summary. This was my intent:

are we saying that one API should always return the same format, i.e. you request with a single Feature or Feature Collection, we always return a Feature Collection?

But that is really a question for titiler. Normally I expect APIs to return a consistent type. But I guess as long as the input matches the output that is a reasonable pattern too. I guess I'd want to make sure that if I pass a feature collection with just one feature I still get a feature collection out. If that is the case then I can be happy.

wildintellect commented 5 months ago

@zacharyDez @vincentsarago have opinions on this?

vincentsarago commented 5 months ago

You should always get the same thing that you passed

Feature (in) -> Feature (out) FeatureCollection (in) -> FeatureCollection (out)

https://github.com/developmentseed/titiler/blob/main/src/titiler/core/titiler/core/factory.py#L488-L492 https://github.com/developmentseed/titiler/blob/main/src/titiler/core/titiler/core/factory.py#L525

If not, there is a bug!

This is tested here https://github.com/developmentseed/titiler/blob/main/src/titiler/core/tests/test_factories.py#L549-L603

jsignell commented 5 months ago

Ok. So we can't reproduce the original issue and it seems like titiler is working as expected. So it's just a documentation problem.

wildintellect commented 5 months ago

Close when the PR is merged https://github.com/NASA-IMPACT/veda-docs/pull/133