Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

search response does not include datetime when null #158

Open
duckontheweb opened this issue Feb 5, 2023 · 5 comments
Open

search response does not include datetime when null #158

duckontheweb opened this issue Feb 5, 2023 · 5 comments

Comments

@duckontheweb
Copy link

Description

The STAC Spec requires that Items have a datetime property even when the value of that property is null. However, in the return value of the search function removes the datetime property when it is null, resulting in an invalid STAC Item.

Steps to reproduce

  1. Start up the development server
  2. In a psql console, add an item with start_datetime and end_datetime values and a null datetime value:
    SELECT *
    FROM create_item('
    {
      "type": "Feature",
      "stac_version": "1.0.0",
      "id": "datetime_range_test",
      "properties": {
         "start_datetime": "2009-10-15T00:00:00Z",
         "end_datetime": "2010-03-01T23:59:59.999999Z",
         "datetime": null
       },
       "geometry": {
         "type": "Polygon",
         "coordinates": [
           [
             [-101, 36],
             [-101, 37],
             [-102, 37],
             [-102, 36],
             [-101, 36]
           ]
         ]
       },
       "links": [],
       "assets": {},
       "collection": "pgstac-test-collection"
    }
    '::jsonb);
  3. Use the search function to fetch the Item and examine the properties:
    SELECT "search" -> 'features' -> 0 -> 'properties'
    FROM search('{"ids": ["datetime_range_test"]}');

The resulting properties JSON is missing the datetime property:

{
  "end_datetime": "2010-03-01T23:59:59.999999Z",
  "start_datetime": "2009-10-15T00:00:00Z"
}
@bitner
Copy link
Collaborator

bitner commented Feb 7, 2023

Per the spec in the section you linked to "null is allowed, but requires start_datetime and end_datetime from common metadata to be set."

My reading of that and the implementation in pgstac is that an item must EITHER have datetime OR BOTH start_datetime and end_datetime. If there has been a change in the spec or I have been reading that wrong, please reopen this issue, but I am going to close it now.

@bitner bitner closed this as not planned Won't fix, can't repro, duplicate, stale Feb 7, 2023
@duckontheweb
Copy link
Author

Per the spec in the section you linked to "null is allowed, but requires start_datetime and end_datetime from common metadata to be set."

My reading of that and the implementation in pgstac is that an item must EITHER have datetime OR BOTH start_datetime and end_datetime.

Maybe @m-mohr can clarify this, but my understanding of the spec is that datetime must be present even if it has a null value. The JSON schema here seems to back this as well: datetime is required in all cases, but may be null if both start_datetime and end_datetime are present.

So, the expected properties for the example above would be:

{
  "end_datetime": "2010-03-01T23:59:59.999999Z",
  "start_datetime": "2009-10-15T00:00:00Z",
  "datetime": null
}

@m-mohr
Copy link

m-mohr commented Feb 7, 2023

Yes, datetime must always be present, either as null (then provide start and end) or as datetime.
null != not present

@bitner bitner reopened this Feb 7, 2023
@bitner
Copy link
Collaborator

bitner commented Feb 7, 2023

OK, that is different than how I had read that. Reopening this ticket.

@drnextgis
Copy link
Collaborator

drnextgis commented Apr 14, 2024

In this case, the item is being ingested with the datetime property stripped. Below is the function call stack:

       create_item
            |
 items_staging_triggerfunc
            |
   content_dehydrate
            |
      content_slim
            |
      strip_jsonb
            |
   jsonb_strip_nulls

@bitner what do you believe would be the preferable approach: refraining from stripping the datetime field if it's null during the ingestion stage, or dynamically adding it to the search results when an item lacks datetime? The former might impact the size of the database, while the latter could potentially affect search performance. Are there any alternative approaches that I might have overlooked?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants