You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched the existing issues and did not find a duplicate.
This is a bug report, not a usage question (questions belong in Discussions).
What happened?
I was porting the CSF algorithm from R to RustGIS and ran some tests to check for errors.
However, RustGIS returns the following error (see image).
Claude explained: "RustGIS delivers the layer to the plugin as GeoJSON within WebAssembly memory, which has a 512 MB limit. With 583 million points, this is unfeasible—which is likely what caused the 'unreachable' error you encountered."
Is there any way to resolve this issue?
Or is it impossible to change how RustGIS functions in this regard?
Steps to reproduce
I added the 19.8 GB point cloud and performed the processing using the CSF plugin.
Expected behavior
Perform the processing in the same way as it is done in R or Python.
How are you running RustGIS?
Desktop app (downloaded release)
Version
v0.5.0
Operating system, browser and graphics
w10 RTX2070
Sample data
I can send the point cloud, but it is 20 GB.
If necessary, I’ll upload it to Drive and share the link.
Thanks for sharing the plugin. I tested it with synthetic point clouds: it worked with 25 and 10,000 points, but reproduced your exact error with 500,000 points. There’s no need to upload the full 20 GB cloud yet.
WebAssembly plugins have a 512 MB memory limit, including on desktop. Memory exhaustion is a plausible cause, though this error alone doesn’t confirm it.
For clouds this large, a desktop process plugin that reads the original file directly would be a more suitable approach. RustGIS supports these, but the plugin would need adapting.
The attachment contains the compiled plugin but no source code. Could you share the source so we can investigate where it fails?
Thanks, @arielsrossi. I checked the new attachment, but it appears to be the same package as before—it contains the compiled plugin rather than its source. Could you zip the project folder containing Cargo.toml and the .rs files? You can leave out the target folder. That should let us trace the error we reproduced.
Thanks, @arielsrossi, I’ve confirmed the memory problem in our test case. With 500,000 points, the plugin runs out of memory while reading the incoming data, before CSF starts. Doubling the test limit lets CSF finish, but it then runs out of memory while building the output layers. Changing the cloth settings won’t fix that input/output bottleneck.
I also found a separate issue: RustGIS supplies longitude/latitude coordinates, but the plugin uses them alongside the original heights without converting them to matching distance units. That can affect the classification even when the tool finishes.
For a cloud this large, the best route is a desktop process plugin that reads the original LAS/LAZ file directly, uses consistent coordinate units, and manages memory across both processing and output. Large-cloud tiling would also need care at tile boundaries. Raising the WebAssembly limit alone won’t be sufficient for this case, although it's still something RustGIS needs to do.
Activity
Mavrick-F commentedon Nov 2, 2026
Thanks for sharing the plugin. I tested it with synthetic point clouds: it worked with 25 and 10,000 points, but reproduced your exact error with 500,000 points. There’s no need to upload the full 20 GB cloud yet.
WebAssembly plugins have a 512 MB memory limit, including on desktop. Memory exhaustion is a plausible cause, though this error alone doesn’t confirm it.
For clouds this large, a desktop process plugin that reads the original file directly would be a more suitable approach. RustGIS supports these, but the plugin would need adapting.
The attachment contains the compiled plugin but no source code. Could you share the source so we can investigate where it fails?
arielsrossi commentedon Nov 3, 2026
Here is the source code.
csf-ground-0.1.1.zip
Mavrick-F commentedon Nov 3, 2026
Thanks, @arielsrossi. I checked the new attachment, but it appears to be the same package as before—it contains the compiled plugin rather than its source. Could you zip the project folder containing
Cargo.tomland the.rsfiles? You can leave out thetargetfolder. That should let us trace the error we reproduced.arielsrossi commentedon Nov 3, 2026
Here is the text file containing the source code
csf-ground-0.1.1-source.txt
Mavrick-F commentedon Nov 3, 2026
Thanks, @arielsrossi, I’ve confirmed the memory problem in our test case. With 500,000 points, the plugin runs out of memory while reading the incoming data, before CSF starts. Doubling the test limit lets CSF finish, but it then runs out of memory while building the output layers. Changing the cloth settings won’t fix that input/output bottleneck.
I also found a separate issue: RustGIS supplies longitude/latitude coordinates, but the plugin uses them alongside the original heights without converting them to matching distance units. That can affect the classification even when the tool finishes.
For a cloud this large, the best route is a desktop process plugin that reads the original LAS/LAZ file directly, uses consistent coordinate units, and manages memory across both processing and output. Large-cloud tiling would also need care at tile boundaries. Raising the WebAssembly limit alone won’t be sufficient for this case, although it's still something RustGIS needs to do.