turf.dissolve pegs cpu and does not return

[jim-greene-l2]

The enclosed javascript file contains a feature collection of 9 tabblocks.

turf.dissolve works instanstaneously if one of the tabblocks is removed. Otherwise it does not return and the cpu is running at 100+%

The code will run with the good 8 tabblocks as-is. Comment line 57 to avoid filtering the one other tabblock that causes the issue.

We are able to load the feature collection into geojson.io and visualize and select all 9 of the component features (see image below)

This is running with turf 7.2.0, node version 20.16, on RHEL 8.10

vm_app_user@oocii001-l2-stg:ahero$ grep turf package.json
    "@turf/turf": "^7.2.0",

vm_app_user@oocii001-l2-stg:ahero$ node -v
v20.16.0

vm_app_user@oocii001-l2-stg:ahero$ cat /etc/redhat-release
Red Hat Enterprise Linux release 8.10 (Ootpa)

turftest.txt

[jim-greene-l2]

We would love a fix, but a workaround test of the features before calling dissolve would help us too. We're desparate to get beyond this because it does not return or crash.

[smallsaucepan]

Hi @jim-greene-l2. Have some good news for you, in the form of a workaround. Hopefully it's acceptable.

I was able to process all polygons successfully by first calling Turf truncate on the FeatureCollection. A call with 14 decimal places precision seemed to work. 6 decimal places is about 11cm.

If that's of use to you as a workaround, please give it a try.

import { truncate } from "@turf/truncate";
...
fc = truncate(fc, { precision: 14 });

We'll leave the issue open as there is definitely a problem occurring, though not 100% sure why just yet. We will look into the root cause when we can.

If the workaround doesn't work for you, sing out and we'll provide what details we can to help you try other approaches.

[smallsaucepan]

Some further detail for identifying the root cause. The call to polyclip.union isn't returning if the provided data for the 1st, 3rd, and 4th polygons are included:

fc.features = fc.features.filter(
  (f) =>
    f.properties.id === "340110103022053" || // Poly 1
    // f.properties.id === "340110103022061" ||
    f.properties.id === "340110103022092" || // Poly 3
    f.properties.id === "340110103022057" || // Poly 4
    // f.properties.id === "340110103022066" ||
    // f.properties.id === "340110103022042" ||
    // f.properties.id === "340110103022095" ||
    // f.properties.id === "340110103022062"
);

Unioning poly 1 with 3, or poly 1 with 4, works ok. Combining poly 1 with 3 AND 4 hangs. This may have something to do with how poly 3 and 4 are being merged.

Curiously poly 3 and 4 share a point:

[-75.16514555077853, 39.22267171331341]

Altering this point slightly e.g. to 39.22267171331342 in one of the polygons allowed the union to work.

The truncate workaround mentioned above is a more accessible way to nudge the coords slightly to jar them out of whatever alignment is causing polyclip to have issues.

[jim-greene-l2]

Thank you. Truncate is a lot simpler and more elegant than what we had scrambled together!

[smallsaucepan]

Once #2997 is merged, we can refactor dissolve to use the new clipper2 based @turf/union (rather than calling the underlying clipping library directly).