Adapting ratio endpoint processing

[FabiKo117]

• filter param can be null or empty (needs an adaption in the ohsome-filter library as well) - done with PR upgrade filter library to version 1.2 #38

• filter2 param has to be defined - throws exception if param is null or empty

• marking types-keys-values code handling /ratio requests as deprecated

• needs issue Unfitting response for missing filter2 parameter #28 to be fixed

[tyrasd]

this needs some unit tests to check if the behaviour for empty filters is correct. While testing I discovered that an empty filter2 with a share ratio request does not work because the API internally converts such a query to something like (<filter1>) or () (see screenshot below), which is not a valid filter syntax.

[FabiKo117]

You found this behavior with a /share request? The resource "/share" is not supported anymore since the release 1.0 from what I know.

edit: Ok I think you've used /ratio :D
Can you link the exact URL that you've used for this test?

[FabiKo117]

Ok I could reproduce it. Working on it now.

[tyrasd]

sorry, I meant it happens in a ratio request (as you can see in the screenshot) 😅 . here is an example request and output:

$ curl "localhost:8082/elements/count/ratio?bboxes=8.6906,49.3994,8.6962,49.4032&filter=building=*&filter2="
{
  "timestamp" : "2020-08-27T16:38:17.077418",
  "status" : 400,
  "message" : "Invalid filter syntax. Please look at the additional info and examples about the filter parameter at https://docs.ohsome.org/ohsome-api. Detailed error message: line 1, column 18: whitespaces, not, (, KEY_STRING (a-z, 0-9, : or -), \", id, type or geometry expected, ) encountered.",
  "requestUrl" : "http://localhost:8082/elements/count/ratio?bboxes=8.6906,49.3994,8.6962,49.4032&filter=building=*&filter2="
}

identified issues have been resolved, will review again

[tyrasd]

I would have preferred if the filter2 parameter was not optional for ratio requests, so that users don't by mistake send complex, long-running queries if they just alter an existing /count/ query to a /count/share/ one without thinking to add the filter2 parameter (I know I would probably often make this mistake). It would still be possible to leave the filter2 parameter empty to do the "compare against all OSM data" use case. But if you prefer it this way @FabiKo117 I am willing to accept it as is.

[FabiKo117]

Ahh yeah I get that point. If someone is just playing around with the endpoints using the same set of parameters, defining filter2 as being non-optional for /ratio would avoid that issue with requesting too much data unintentionally. We can switch that restriction yes.