Limitations (Inconsistencies) of the operators in the STAC Query Extension

[m-mohr]

I think there are some limitations due to how the operators (e.g. "eg", "lt", "startsWith") are defined:

            eq:
              description: Find items with a property that is equal to the specified value. For strings, a case-insensitive comparison must be performed.
            neq:
              description: Find items that *don't* contain the specified value. For strings, a case-insensitive comparison must be performed.
            gt: 
              type: number
              description: Find items with a property value greater than the specified value.
            lt:
              type: number
              description: Find items with a property value less than the specified value.
            gte:
              type: number
              description: Find items with a property value greater than or equal the specified value.
            lte:
              type: number
              description: Find items with a property value greater than or equal the specified value.
            startsWith:
              type: string
              description: Find items with a property that begins with the specified string. A case-insensitive comparison must be performed.
            endsWith:
              type: string
              description: Find items with a property that ends with the specified string. A case-insensitive comparison must be performed.
            contains:
              type: string
              description: Find items with a property that contains with the specified string. A case-insensitive comparison must be performed.
            in:
              type: array
              items:
                type: string
              description: Find items with a property that matches one of the specified strings. A case-insensitive comparison must be performed.

Here's the example from the spec with the mentioned inconsistencies:

        eo:cloud_cover:
          lt: 50
        providers:
          eq: 'Planet'
        published:
          gt: '2018-02-12T00:00:00Z'
          lte: '2018-03-18T12:31:12Z'
        pl:item_type:
          startsWith: PSScene
        product:
          in:
            - foo
            - bar
            - baz

Problems I see at the moment:

• lt, lte, gte, gt can not be used with (temporal) strings. That means I can't search for all timestamps newer or older than x. Interestingly, the example (see below) contains this use-case for the published field, but officially it's not allowed.

• in only works on strings. Why can I not search in a array of integers for example?

• The example uses the eq operator for searching in the providers array. How would that work?

• There's no way to search in objects (e.g. find provider with name abc or find band with name B4).

• Probably a bit nit-picking, but for in it says:

  Find items with a property that matches one of the specified strings

  Is it really "one of" (i.e. exactly one must match)? Or is it really an "any of" (i.e. at least one must match)?

cc @hgs-truthe01 @matthewhanson @joshfix

[m-mohr]

I think we should solve this as follows:

• lt, lte, gte, gt can not be used with (temporal) strings. That means I can't search for all timestamps newer or older than x. Interestingly, the example (see below) contains this use-case for the published field, but officially it's not allowed.

I'd simply allow temporal strings by allowing type: string, format: date-time in addition.

• in only works on strings. Why can I not search in a array of integers for example?

I'd simply allow integers, too.

• The example uses the eq operator for searching in the providers array. How would that work?

Remove the providers entry from the examples. We can't search on providers at the moment.

• There's no way to search in objects (e.g. find provider with name abc or find band with name B4).

Don't tackle this yet, wait for CQL.

• Probably a bit nit-picking, but for in it says:

  Find items with a property that matches one of the specified strings

  Is it really "one of" (i.e. exactly one must match)? Or is it really an "any of" (i.e. at least one must match)?

I think this must the any of and can simply be changed.

[m-mohr]

All urgent issues haven been fixed.