(if: ... ) test results

[mmd-osm]

General remarks:

Unfortunately, the available documentation on new features is not very comprehensive at this time, making the overall testing activities quite ineffective. There's much more implemented right now than what is covered in the test cases below, but I don't feel like reverse engineering all of the new source code to get started with testing 😄

Update: documentation is avaialble now. Test cases will be updated soon to match current syntax.

Test 1: Ways with single node only

way(if:count_members()==1)({{bbox}});
out center;

-> ok

Test 2: Relations without tags / member

Test 2a: (global), without bbox

rel(if:count_tags()==0);
out;

rel(if:count_members()==0);
out;

-> result not conclusive: no result, no error message returned

Test 2b: adding bbox

rel({{bbox}})(if:count_tags()==0);
out;

-> result ok

Test 3: omitting [..] for tags, multiple (if: ...) in one query

way[maxheight][maxwidth](if:maxheight > 2)(if:maxwidth > 2);
out geom;

-> no error message/parsing error returned

Similar: is_num(layer) -> no error message!

Test 4: Comparing tags within same query

[bbox:{{bbox}}];

way[maxheight][maxwidth]
   (if:is_number(t[maxheight]) && 
       is_number(t[maxwidth]) &&
       t[maxheight] > t[maxwidth]);
out geom;

-> test ok

Test 5: Nodes with at least one tag

[bbox:{{bbox}}];

node(if:count_tags()>0);
out geom;

-> test ok

Test 6: Count way's nodes

[bbox:{{bbox}}];

way(if:count(nodes)>1);
out geom;

-> no result, does not seem to work

Test 7: Invalid layer tag

[bbox:{{bbox}}];

node["layer"](if:!is_num([layer]) || ([layer] < -5 || [layer] > 5));
out;

-> test ok
(some layer tags have multiple values "1;0" -> not numeric)

Test 8: unknown function

[bbox:{{bbox}}];

node["addr:housenumber"]
  (if:is_odd(["addr:housenumber"]));
                         out;

-> ok. Error message shown: parse error: Function "is_odd" not known

Test 9: Error messages

way[name](if:count(memb)==1)({{bbox}});
out center;

Error message: "For the attribute "type" of the element "eval-count" the only allowed values are "nodes", "ways", "relations", "deriveds", "tags", or "members" strings. "

What is eval-count? Those internal names are only meaningful in the context of Overpass XML. For Overpass QL, they are rather confusing.

Other examples of difficult to understand error messages in Overpass QL context:

• set-prop must have exactly one evaluator substatement.
• For the statement "set-prop" in mode "keytype"="tag", " "the attribute "k" must be nonempty.

make test min(demo);
out;

static error: Element "eval-min" cannot be subelement of element "make".

What is meant by eval-min / subelement? Again, these terms are only meaningful for Overpass XML.

Test 10: convert statement

Not sure what the convert statement is good for. It is currently handled by parse_make. Is convert.cc / convert.h / create_convert_statement obsolete and the code should be removed?

  if (token.good() && *token == "convert")
    return parse_make< TStatement >(stmt_factory, from, token, error_output, "convert");
  if (token.good() && *token == "make")
    return parse_make< TStatement >(stmt_factory, from, token, error_output, "make");

Test 11: Deviating tags

I'd like to find Objects where certain Keys have the same value. Irish streets normally have two names, one in Irish and one in English. In osm the have three tags for that, name, name:en and name:ga. I'd like to find all objects having all three tags where name doesn't match with name:en or name:ga.

https://help.openstreetmap.org/questions/43298/compare-values-with-overpass

[timeout:300]
[bbox:51.08282186160976,-12.8759765625,55.986091533808384,-1.86767578125]
[out:csv(::id, ::type, name, "name:en", "name:ga")];

( node[name]["name:en"]["name:ga"](if:(t[name] != t["name:en"]) && (t[name] != t["name:ga"]));
  way[name]["name:en"]["name:ga"] (if:(t[name] != t["name:en"]) && (t[name] != t["name:ga"]));
  rel[name]["name:en"]["name:ga"] (if:(t[name] != t["name:en"]) && (t[name] != t["name:ga"]));
);
out;

-> ok

Test 12: Multipolygons that have more than one member with the role 'outer'.

Don't know how to express this. Osmium-filter gets this via the following query: @relation and "type"="multipolygon" and (@members[@role=="outer"] > 1)

How would I express this in Overpass QL?

https://help.openstreetmap.org/questions/53447/finding-multipolygons-with-more-than-one-outer-way-overpass

[drolbr]

Thank you for the tests.

Test 2 is addressed in 736950e
Test 3 is addressed in 890a930
This brings two syntax changes: constants now need quotation marks and tag evaluation now needs a function name "t", e.g. t[maxheight]>4.

Test 6 is a bigger problem: the correct syntax would be "count(members)". However, "count(nodes)" has a well-defined semantics - it would count the nodes in the input set:

node({{bbox}})[name="Karlsplatz"];
way({{bbox}})(count(members) > count(nodes));
out geom;

(finds all ways that have more members than there are nodes named "Karlsplatz").

Hence, we cannot print an error message here.

I will address test 9 after the other tests because there might get more instances of the problem to the surface with additional syntax.

ad Test 10: the convert statement is far from obsolete. "make" and "convert" solve two very different jobs. "make" produces always one derived element. "convert" produces one derived element per input element.

ad Test 11: the non-equal operator != is already implemented.

ad Tests 6 and 12: Maybe it would be better to have a separate syntax like "members" or "count_members" for the "count" job related to a single object. This could have a single optional argument that represents a role filter.

The other tests are marked as "ok".

[drolbr]

For test 9, the error message has been fixed.

I am aware that further confusing error messages exist. 441ebd2 is a blueprint how to fix them. The check should be close to the actual list to avoid that the code could get inconsistent on later changes.