Are basic and advanced search compatible?

[m-mohr]

Are basic and advanced search compatible? Can they be implemented at the same time?

I'm not sure yet because in basic OR needs to be separated by comma, but in advanced the comma is not mentioned at all. There space is used.

Also how to handle the differences in POST?

[rhysrevans3]

@m-mohr sorry I've been away at a conference so haven't had a chance to look at this. But yes I think you're right in their current implementation they're not compatible. I think the simplest solution would be to add commas to the advanced search.

For POST could the advanced terms be separate into a list for example:

q = hello world AND foo, bar

q = [hello world, AND, foo, bar]

This would mean that AND & OR would need special treatment. We could then probably do away with"". But I'm not 100% sure how to handle ().

[m-mohr]

This seems pretty weird. I think keeping them separate makes more sense. They can be in the same extension, but I think it could be made clear that they are not compatible. The basic one is compatible with Records, the more advanced one is an addition from STAC...

[rhysrevans3]

Ah I didn't think of that as an option. That sounds like a great idea. Would this use a flag to differentiate between the two or use completely separate parameters?

[m-mohr]

The alternative would be to "ditch" Advanced and replace it with a CQL-based version, which would be better aligned with the OGC ecosystem, especially OGC API - Features - Part 9. I didn't think this though yet. We'd need to check how well CQL2 would work for such a case.

[rhysrevans3]

I did look at CQL2 but it's my understanding that it doesn't allow wildcards in property names which I think is needed for a direct mapping from the current Advanced query syntax. There might be a way around this using a combination of CQL and basic free-text but I haven't looked into that yet.

Do you know if there's any chance of OGC switching from a list of strings to just a string? A list of strings for a free-text seems a bit odd to me.

[m-mohr]

We would just reuse the grammar for expressing CQL, but we could freely define that for example the property name is * or anything else.

I don't see a big chance, but you can try to lobby for it here: https://github.com/opengeospatial/ogcapi-features/issues
But then there's still the issue with the comma?!

[rhysrevans3]

I thought that would probably be a long shot.

Just to make sure I'm understanding what you're saying: the q parameter for advanced search would then be a like the a CQL-json/CQL-text in the filter extension?

Alternately could it be an extension to the filter extension which either allows wildcard property names like * or allows an another filter-lang like the Lucene Query Syntax that Advanced free-text was following?