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

how to interpret pystac oneOf validation error #37

Closed
rbavery opened this issue Sep 19, 2024 · 2 comments · Fixed by #39
Closed

how to interpret pystac oneOf validation error #37

rbavery opened this issue Sep 19, 2024 · 2 comments · Fixed by #39
Labels
question Further information is requested

Comments

@rbavery
Copy link
Collaborator

rbavery commented Sep 19, 2024

❓ Question

Why is validation failing for this pystac item? I did some sleuthing and it seems like the problem might with the jsonschema itself not the STAC Item.

https://www.jsonschemavalidator.net/s/NEnpmfAn

But maybe this is a separate issue and the validator on that website does not reflect the validation we do with pystac.

My other theory is that from the examples, we don't include any that include bands only as a list of strings, though we specify in the readme that this is accepted. I'm wondering if one of raster or eo extension metadata needs to be present if any bands are specified.

here is the gist of the json I'm validating and the error.

https://gist.github.com/rbavery/7c1875b2130dc78c48489b4ba86febb1

@rbavery rbavery added the question Further information is requested label Sep 19, 2024
@rbavery
Copy link
Collaborator Author

rbavery commented Sep 19, 2024

does this section saying AnyOf the extensions need to be specified: https://gist.github.com/rbavery/7c1875b2130dc78c48489b4ba86febb1#file-pystac_validation_error_mlm-txt-L552

conflict with this section which doesn't indicate they are required?

https://github.com/crim-ca/mlm-extension?tab=readme-ov-file#bands-and-statistics

@fmigneault
Copy link
Collaborator

fmigneault commented Sep 19, 2024

We could remove the extra $comment that are considered invalid by some parsers.
Some parsers are stricter than others (Python jsonschema ignored them).

One thing to consider is that $comment are sometimes allowed and sometimes not depending on context. If they are inside an JSON object definition, it is OK (extra field ignored), but if they are under properties of a JSON object, this can be considered invalid since a schema-type definition is expected (or minimally {} for 'any').

Another thing to consider is that, because the schema is describing GeoJSON-like contents, properties are sometimes the JSON-schema object definition, and sometimes the actual field name within the GeoJSON.

For example:

{
  "$comment": "This is the JSON-object 'properties' definition.",   # OK
  "properties": {
    "$comment": "This is the STAC-Item 'properties' field.",   # NOT OK (expect schema-type)
    "properties": {
      "$comment": "This is the JSON-object 'properties' definition for the STAC Item 'properties' field.",  # OK
      "properties": {
        "$comment": "Required MLM pretraining reference.",   # NOT OK (expect schema-type)
        "mlm:pretrained": {
          "const": false
        }
      }
    }
  }
}

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

Successfully merging a pull request may close this issue.

2 participants