Incorrect `complete {rel(br);};` result

[zstadler]

TL;DR

When using complete {rel(br);}; the result set of an iteration is different than the input set of the next iteration.

Problem Description

The following query is an attempt to find circular relation references in an area.:

[out:csv(::count)];
rel (area:3606195356);
out count;
complete {
  rel(br);
};
out count;

Note: The out count lines are used to demonstrate the problem.

The final result of contains 21227 relations, more that the initial 20859 relations contained in the area:

@count
20859
21227

A supposedly-equivalent "loop unrolling" query is:

[out:csv(::count)];
rel (area:3606195356);
out count;
rel(br);
out count;
rel(br);
out count;
rel(br);
out count;
rel(br);
out count;
rel(br);
out count;
rel(br);
out count;

The final result of that query includes just 6 relations:

@count
20859
389
9
8
6
6

Additional Analysis

The output set of a complete iteration is different that the input set for the next iteration, as can be seen in this query:

[out:csv(::count)];
rel (area:3606195356);
out count;
complete {
  out count;
  rel(br);
  out count;
};
out count;

Given the output of the "loop unrolling" query, the expected output should show that the output set size of each command is equal to the input set of the next command:

@count
20859
20859
389
389
9
9
6
6
6
6

However, the actual output is:

@count
20859
20859
389
21227
389
21227

1. The input set for the first iteration has 21227 elements. Same as the output set of the previous statement.
2. The output set of the first iteration has 389 elements. Yet, the input set for the second iteration has 21227 elements
3. The output set of the second iteration has 389 elements. Yet, the output set for the complete statement has 21227 elements

[mmd-osm]

The implementation of complete looks more like the query below. In every iteration, the statement inside "complete" is being executed on the current inputset. Any new results will be added to the inputset. If no new candidates were added in an iteration, then "complete" terminates. There's an upper bound in place to prevent infinite loops.

I don't think your use case is a particular good fit for "complete". My recommendation is to stick to your hand-unrolled version.

[out:csv(::count)];

rel (area:3606195356) -> .step1;
.step1 out count;

(.step1 ;rel(br);) -> .step2;
if (step1.count(relations) != step2.count(relations)) {
  .step2 out count;


  (.step2; rel(br);) -> .step3;
  if (step2.count(relations) != step3.count(relations)) {
    .step3 out count;

    (.step3; rel(br);) -> .step4;
    if (step3.count(relations) != step4.count(relations)) {
      .step4 out count;
    }
  }
  // continue... IIRC up to 256 steps by default
}        

[zstadler]

Thank you for the clarification. It seems like the complete statement was build for a continuous expansion intent.

Is there a way to perform a continuous reduction intent in Overpass QL?
For example, performing rel(br); without the implicit union operation of complete.

[mmd-osm]

I think we can abuse complete a bit and combine the repeated rel(br) recursion with another query that is simply trying to find adjacent highways:

[out:csv(::count)];
rel (area:3606195356) -> .a;

way(4949723);
complete(32) {
  
  rel(br.a)->.new_a;
  .new_a out count;
  
  if (a.count(relations) != new_a.count(relations)) {
    way[highway](around:0);
    .new_a -> .a;
  }
  else {
    node(99999999999);  // does not exist
  }
};

Returns:

@count
396
11
9
8
6
6

[zstadler]

Thanks!