Invalid geoJSON from Contours plugin

Running WebODM on a Debian 10 VM with the Contours plugin enabled. I’ve generated an assembly with DTM and DSM turned on, but when I try to preview the contours, I see “Invalid GeoJSON Object”. When I go straight to export, I get a django response “error”: “Invalid task output (cannot find valid key)”. Any ideas where I’ve gone wrong?

1 Like

Are you running the WebODM for Ubuntu native install, or Docker install?

I can’t reproduce the behavior locally on Linux+Docker with current/latest:

docker images
REPOSITORY                   TAG       IMAGE ID       CREATED        SIZE
opendronemap/webodm_webapp   latest    e075d13aaf35   2 days ago     1.62GB
redis                        latest    a10f849e1540   6 days ago     117MB
opendronemap/nodeodm         latest    b4c50165f838   8 days ago     1.77GB
opendronemap/webodm_db       latest    e40c0f274bba   8 months ago   695MB


1 Like

*Correction from earlier: running Debian 9, not 10.
I am running the latest docker image.

Here is the WebODM task screen:

And here is what I’m getting when I try to preview:

Thanks for your help!

1 Like

have you tried building contours in QGIS to see if there is an issue with the DSM/DTM?

2 Likes

I was able to download a GeoTIFF of the DSM/DTM and use QGIS to extract contours from the depth gradient, if that’s what you mean.

1 Like

Yes, So I assume ODM extracts the contours from the same DSM or DTM whichever you choose and there is no issue with it since it extracts fine in QGIS. I would be curious to see if changing the settings on the contours in regards to interval and simplify if that is successful.

1 Like

I’ve tried a few different contour settings. I’d be curious to see anyone elses assembly params that are working with the contours plugin, maybe I am missing something?

1 Like

You’re tracking the “latest” branch/tag, but you’ve not updated in months.

Does your debian allow you to install topgrade? If so, you can use that to fully upgrade your sysrtem, including Docker images automatically.

You can also update WebODM as documented on GitHub via:
./webodm.sh update

1 Like

I’ve updated via ./webodm.sh, restarted, and rerun my assembly (Just to be certain), but I am still running into the same problem. Do you know of where I might find a more conclusive output for the error?

1 Like

It should print error info to a console if you start webodm with ./webodm.sh start.

If you can grab that and paste the output here it might help.

Here’s what I have:

webapp      | /usr/local/lib/python3.9/dist-packages/rio_tiler/reader.py:385: AlphaBandWarning: Alpha band was removed from the output data array
webapp      |   warnings.warn(
worker      | INFO Executing grass script from /webodm/app/media/tmp/tmppkudboh8_grass_engine: /usr/bin/grass78 -c /webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif location --exec python3 /webodm/coreplugins/contours/calc_contours.py dem_file=/webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif interval=0.25 format=GeoJSON simplify=1.0 epsg=4326
worker      | [2022-05-06 14:55:10,790: INFO/ForkPoolWorker-77] worker.tasks.execute_grass_script[d884992c-82ef-45e4-b235-c4ee4a8adcd7]: Executing grass script from /webodm/app/media/tmp/tmppkudboh8_grass_engine: /usr/bin/grass78 -c /webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif location --exec python3 /webodm/coreplugins/contours/calc_contours.py dem_file=/webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif interval=0.25 format=GeoJSON simplify=1.0 epsg=4326
worker      | ERROR Could not execute GRASS script /webodm/coreplugins/contours/calc_contours.py from /webodm/app/media/tmp/tmppkudboh8_grass_engine: Starting GRASS GIS...
worker      | Creating new GRASS GIS location <location>...
worker      | Cleaning up temporary files...
worker      | ERROR: MAPSET PERMANENT - permission denied
worker      | ERROR: MAPSET PERMANENT - permission denied
worker      | Executing <python3 /webodm/coreplugins/contours/calc_contours.py dem_file=/webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif interval=0.25 format=GeoJSON simplify=1.0 epsg=4326> ...
worker      | ERROR: MAPSET PERMANENT - permission denied
worker      | Execution of <python3 /webodm/coreplugins/contours/calc_contours.py dem_file=/webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif interval=0.25 format=GeoJSON simplify=1.0 epsg=4326> finished.
worker      | Cleaning up temporary files...
worker      | ERROR: MAPSET PERMANENT - permission denied
worker      | [2022-05-06 14:55:11,453: ERROR/ForkPoolWorker-77] worker.tasks.execute_grass_script[d884992c-82ef-45e4-b235-c4ee4a8adcd7]: Could not execute GRASS script /webodm/coreplugins/contours/calc_contours.py from /webodm/app/media/tmp/tmppkudboh8_grass_engine: Starting GRASS GIS...
worker      | Creating new GRASS GIS location <location>...
worker      | Cleaning up temporary files...
worker      | ERROR: MAPSET PERMANENT - permission denied
worker      | ERROR: MAPSET PERMANENT - permission denied
worker      | Executing <python3 /webodm/coreplugins/contours/calc_contours.py dem_file=/webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif interval=0.25 format=GeoJSON simplify=1.0 epsg=4326> ...
worker      | ERROR: MAPSET PERMANENT - permission denied
worker      | Execution of <python3 /webodm/coreplugins/contours/calc_contours.py dem_file=/webodm/app/media/project/12/task/f5448c44-215d-4881-aba3-2fff57775804/assets/odm_dem/dsm.tif interval=0.25 format=GeoJSON simplify=1.0 epsg=4326> finished.
worker      | Cleaning up temporary files...
worker      | ERROR: MAPSET PERMANENT - permission denied
1 Like

Can you try again after today’s update?

I’ve been waiting for a chance to update in between users running assemblies. Now that I have, however, I’m still getting the same exact error.

1 Like

Can you please paste the output of:

docker images
1 Like
[email protected]:~# docker images
REPOSITORY                   TAG                 IMAGE ID            CREATED             SIZE
redis                        latest              1ca2c2a1b554        4 days ago          117MB
opendronemap/nodeodm         latest              68f6459baf57        6 days ago          1.77GB
opendronemap/webodm_webapp   latest              ebb42bdf5ab5        9 days ago          1.63GB
opendronemap/webodm_db       latest              e40c0f274bba        8 months ago        695MB
[email protected]:~# 
1 Like

Do you have a standard user in the Docker group you can try to run with? Not sure running the whole stack as root is supported or a good idea.

Have you tested other known-good datasets like Brighton Beach (what I used above) to ensure it works properly at all in your installation?

I can’t reproduce this failure with any dataset I have locally.