Isobands creating overlapping bands [5.0.4]

[jpoynton]

Isobands has produced overlapping bands/polygons using 5.0.4

See https://jsfiddle.net/jpoynton/wmsx4y2e/ for example. Points in the example are colour coded so that green meet criteria for first break and purple meet criteria for second break with red being outside the breaks.

[stebogit]

@jpoynton this is an interesting case, indeed it seems the MarchingSquare algorithm is failing to map the correct intermediate contours.
I know it might have some issue sometime but this is a new one. I'll look into it as soon as I can find some time, hopefully this weekend.

Out of curiosity, have you tried with a previous version of Turf?

[jpoynton]

@stebogit have observed similar in 4.7.x with similar but different data. As I was just starting out with Turf thought it was my issue with wrong grid cell size I sampled at, so changed the grid size and made the issue go away.

[stebogit]

That's even more interesting @jpoynton. Would you please post the data not showing the issue so I can test it?
Glad you found a workaround.

[jpoynton]

@stebogit - increased the grid size from 0.25 mile to 0.5 mile and the polygons are fine - https://jsfiddle.net/jpoynton/wmsx4y2e/2/. For fun also reduced grid to 0.1 mile - https://jsfiddle.net/jpoynton/wmsx4y2e/3/

[Eh2406]

We should re-test when/if #1801 lands.

[smallsaucepan]

PR mentioned above was superseded by PR #2527, now merged, so we should be good to retest this.

[smallsaucepan]

This is still happening in 7.1.0. I believe it's because adjacent points with exactly the value of a break "blur" the bands. The reason it only happens at higher sampling densities (at 0.1 or 0.25, but not 0.5 miles) is that it's only then you're getting more than one adjacent 5 between a 6 and a 4.

This looks ok, even though technically the 5s are being encompassed by both bands.

<- 5-10 band ->
              |
   7 -- 6 -- 5 -- 4 -- 3
            |
            <- 0-5 band ->

In this case though, because it's only the last 5 before a 4 or 6 that matters, one band encompasses more points than it should.

<--- 5-10 band ->
                |
7 -- 6 -- 5 -- 5 -- 4 -- 3
         |
         <- 0-5 band ————>

Unsure if this is a bug or a grey area in expectations in marchingsquares. What do you think @stebogit?

[stebogit]

@smallsaucepan I'm not entirely sure adjacent isobands should share the values, otherwise we'd get the issue you mentioned. I think the first limit is included while the second is not, which you can express as [0-5), [5-10) (or maybe it's the opposite, but the logic is equivalent).

However, there might also be an issue with the input data itself. I believe the MarchingSquare algorithm applies to inputs representing linear surfaces sampled/projected on a horizontal plane, which means the z-value of contiguous points must be linear.
Looking at the original example(s), in which I understand green > purple > red, the isobands are a bit off where I'd argue the z-value can't go from green to red without "clearly" passing from purple:

Using your representation it would be something like this (notice the 3 next to a 5):

<--- 5-10 band ->
                |
7 -- 6 -- 5 -- 3 -- 4 -- 3
         |
         <- 0-5 band ————>

In this case I think the MarchingSquare algorithm makes its best guess to handle an unexpected (impossible?) situation.

[smallsaucepan]

We might be looking at different things. The example I'm working from is the 21x21 grid that shows the below overlapping bands. Note there are no bands being skipped e.g. from red straight to green.

What I'm speculating is that marchingsquares is including the same point in multiple bands, and when there are two adjacent points equal to the break value, the bands overlap like @jpoynton observed.

In the 0-5 band, the points a and b are detected as where the value rises above the upper threshold i.e. 5.

In the 5-10 band, it's points c and d that are considered where the value drops below the lower threshold i.e. also 5.

Change the break to 5.01 and the overlap disappears because there's no ambiguity which band 5s are in:

If it's this function doing the deciding, then with a threshold of 0 and a bandwidth of 5, 5 is "in bounds". With a threshold of 5 and a bandwidth of 5, 5 is also in bounds.

[smallsaucepan]

Did some more experimenting and have raised an issue over on the marchingsquares library: RaumZeit/MarchingSquares.js#32