[FR] Parallelism support

[netthier]

The sister crate over at https://github.com/mthh/contour-isobands-rs supports parallelism via the parallel feature.
Is there a technical reason this crate does not support it as well, or did just no one need it until now 🤔
(Also, in case we do end up adding it here, maybe it would make sense to merge the two crates? Seems they have some shared code, and either algorithm could be exposed via different structs. I'd imagine stuff like #14 would be useful there as well, especially considering the heightened memory usage.)

[mthh]

Thanks for bringing this up.

No, there's no technical reason for that, and having a parallel feature in this crate would indeed be a good thing.

Indeed, the improvements of #14 would certainly be useful in contour-isobands too, and I was thinking of taking them there too when I had the time.

There is code shared between the two crates. Initially I intended to dedicate ‘contour’ to the creation of isolines / contour polygons and ‘contour-isobands’ to the creation of isobands, but I've also added an ‘isobands’ function to ‘contour’, which is bound to cause confusion! (but the results of the isobands generated by ‘contour’ are not as good as those generated by contour-isobands and I might consider removing it from the former).

I've also made two crates because of the timing of their creation and licensing issues: 'contour' was made first and is licensed under MIT+Apache2.0.
Then I made 'contour-isobands', which is a direct port of https://github.com/RaumZeit/MarchingSquares.js. But MarchingSquares.js is licensed under the AGPL v3.0 (not allowing my port to be distributed under an MIT licence, I think - but my understanding of licences is limited).

[netthier]

Ah, I wasn't aware of the licensing issues. If the crate is derived from an AGPL project MIT+Apache2 wouldn't be possible, yeah. But it could be possible to add a new, alternative implementation in this crate with the cleaner isobands, taking care not to look at any AGPL code while doing so. I don't think those squares themselves are licensed as anything special.
I'll see if I can add parallelism here as well then, I think my use case would benefit from computing multiple contours in parallel.

[mthh]

But it could be possible to add a new, alternative implementation in this crate with the cleaner isobands, taking care not to look at any AGPL code while doing so

Indeed. But in the end I found the algo for isobands relatively difficult / lengthy to implement, which is why I went back to porting the isobands implementation of RaumZeit/MarchingSquares.js (which implement the cases shown on https://en.wikipedia.org/wiki/Marching_squares#Isobands).
In JS I think the turf library also started calling RaumZeit/MarchingSquares.js a some times ago, after using their own code for a while.

But if a PR comes on this repo to contribute an implementation I'd be happy to review it in order to integrating it.

I'll see if I can add parallelism here as well then, I think my use case would benefit from computing multiple contours in parallel.

Great!

On the subject of possible optimisations, I saw that https://github.com/onthegomap/maplibre-contour implements the same algorithm as this crate, but that they say they only make one pass on the matrix of values to calculate the various thresholds that are requested (if there are several), whereas here we make one pass on the matrix of values per threshold (https://github.com/onthegomap/maplibre-contour/blob/7e14836afd0671dc29f8aebd13ba66a7662b400b/src/isolines.ts#L219).

However, this requires some changes to the structure of the code.