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

Are basic and advanced search compatible? #10

Open
m-mohr opened this issue Apr 19, 2024 · 7 comments
Open

Are basic and advanced search compatible? #10

m-mohr opened this issue Apr 19, 2024 · 7 comments

Comments

@m-mohr
Copy link
Collaborator

m-mohr commented Apr 19, 2024

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
Copy link
Contributor

@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
Copy link
Collaborator Author

m-mohr commented Jun 12, 2024

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
Copy link
Contributor

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
Copy link
Collaborator Author

m-mohr commented Jul 18, 2024

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
Copy link
Contributor

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
Copy link
Collaborator Author

m-mohr commented Jul 18, 2024

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
Copy link
Contributor

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?

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

2 participants