-
Notifications
You must be signed in to change notification settings - Fork 45
search response does not include datetime when null #158
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
Comments
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. |
Maybe @m-mohr can clarify this, but my understanding of the spec is that 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
} |
Yes, datetime must always be present, either as null (then provide start and end) or as datetime. |
OK, that is different than how I had read that. Reopening this ticket. |
In this case, the item is being ingested with the
@bitner what do you believe would be the preferable approach: refraining from stripping the |
This issue is still relevant to us, what's the plan to move forward? |
Description
The STAC Spec requires that Items have a
datetime
property even when the value of that property isnull
. However, in the return value of thesearch
function removes thedatetime
property when it is null, resulting in an invalid STAC Item.Steps to reproduce
psql
console, add an item withstart_datetime
andend_datetime
values and anull
datetime
value:search
function to fetch the Item and examine the properties:The resulting
properties
JSON is missing thedatetime
property:The text was updated successfully, but these errors were encountered: