what is the format for the advanced POST request ?

[vincentsarago]

It's not clear to me what's the format for the POST request body

in https://github.com/stac-api-extensions/freetext-search?tab=readme-ov-file#http-post, nothing is mentioned. The example shows a simple string 🤷

For the Basic spec we have:

• GET: string (e.g. EO,Earth Observation)
• POST: List[string] (e.g. ["EO","Earth Observation"])

for the Advanced we have

• GET: string (e.g. climate AND model, climate OR model, (quick OR brown) AND fox)
• POST: ?

[m-mohr]

I only worked on Basic, which is aligned with OGC API - Records.

Advanced was developed by Cedadev, so they need to clarify.
My understanding is that it's indeed the same string for GET and POST.

But looking at #10, there are various challenges with basic and advanced anyway.
They are not quite compatible, which this example also shows.
So you'd usually implement either Basic or Advanced, I guess.

[vincentsarago]

🙏 @m-mohr yeah I've looked at #10 and IMO they are should not be compatible

[m-mohr]

My way forward would be to talk to OGC and make sure Basic is still aligned (it moved recently to OGC API - Features - Part 9) and then pitch the idea to use CQL Text/JSON for advanced free-text search instead of our own flavor. That's likely not ideal for cedadev and their use of Advanced, but I'm not sure whether we should go forward with yet another textual representation of logical expressions for Advanced Free Text Search.

[vincentsarago]

😬 at one point this will just overlap too much with the filter extension.

I'm only looking from the stac-fastapi POV to be honest, so right now I'll just assume the format is of type string

[m-mohr]

Yeah, it is somewhat similar, but the filter extension doesn't quite allow that in an easy way.
It's just annoying that there's a need for so many different lexers/parsers to read all these test "languages".
If there's a way to express the advanced free-text search in CQL2, we should probably explore it.

[rhysrevans3]

Can confirm the POST for the advanced is the same string as GET.

I did look at if the advanced search could be implemented using the filter extension but I don't believe CQL allows wildcards so I couldn't make an exact mapping. But maybe a in combination with basic it could be done. I'm happy for the advanced search to be removed from this extension so basic's integration isn't held up.

An advanced extension can be written if we can't find a way with CQL.