search

OpenDroneMap / WebODM

User-friendly, commercial-grade software for processing aerial imagery. 🛩
https://www.opendronemap.org/webodm/
GNU Affero General Public License v3.0
2.85k stars 953 forks source link

Orthomosaic not loading onto mapviewer #762

Closed isaacmichael closed 4 years ago

isaacmichael commented 4 years ago

What's your browser and operating system?

Chrome 78 windows 10 whatsmybrowser.org/b/9CW93JR

What is the problem?

orthophotos are not being displayed on the map in WebODM. Instead, the page becomes unresponsive and does not load even with extended periods of time. It simply has the loading symbol on the top left and refuses to load completely for some reason.

What should be the expected behavior?

Normally, I would be able to view the map, DSM, DTM, and now plant health, but none of them would like to load.

How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing?

Please include multiple screenshots of the problem!

If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed) I used the preset DSM and DTM parameters. the file is 619 photos as far as I know, I haven't done anything to trigger this problem besides the update that included the new plant health functions, but it is occurring on both of my machines.

Something interesting is that it will load the orthomosaic in the 3d viewer and when you go from the 3d viewer directly to the 2d viewer, it doesn't get stuck in a loading loop at all, it just doesn't ever attempt to load the file even if you switch to other map views (ortho, plant health, Terrain).

Here is a photo, simply showing that it is stuck in a loading sort of loop instead of displaying the map https://drive.google.com/file/d/18RL70Om2cUQN2B9yJco-Zzp3kzLtXR4I/view?usp=sharing

dmbworld commented 4 years ago

Exactly the same problem here and noticed it about 11 hours ago. Additionally clicking on "Contours" reports "Cannot retrieve information for task ............... Are you are connected to the internet?". On the server side one CPU is stuck at 100% and this server is essentially idle apart from running the WebODM engline with only one user. Unfortunately cannot yet identify which process this is and that is probably because it's running WebODM under Docker. Observation: During the startup of this new version there was an indication of converting all existing TIF files to GeoTIF or something along those lines. All previously working tasks will function exactly as described above and will NOT load any Orthophoto layer in 2D mode.

pierotofy commented 4 years ago

Thanks for the report :pray:

A few questions for both:

isaacmichael commented 4 years ago

This datasets was made after the update if that's what you mean. Sure, I'll make sure and archive my datasets soon. My computer has 32gb of ram

dmbworld commented 4 years ago

The upgrade of all the existing TIF files completed successfully. (warnings were seen concerning 520.. and I can't remember what the exact detail was as it flew by) I can download all the assets and view all the files. I have rerun one of the many tasks and all assets are downloaded successfully. When selecting 2D the server side immediately goes to 100% on one of the CPUs and stays at that level until WebODM is halted and restarted. Looks to me like a server side sending problem. I have 32GB

pierotofy commented 4 years ago

Thanks for the info! Could you share the all.zip file (even privately) for troubleshooting this?

For sending the link to the file in private: https://masseranolabs.com/contact/

dmbworld commented 4 years ago

I'll check what data is possible to share. In the meantime this warning comes up on the server when selecting a task to view in 3D: WARNING Not Dound: /api/projects/9/tasks/"task key here removed for security"/assets/entwine_pointcloud/ept.json For ALL tasks viewed A private link has been sent through the contact form.

pierotofy commented 4 years ago

For some reason I didn't receive the link; could you try again? Or just send it to: support [-at-] masseranolabs.com

dmbworld commented 4 years ago

Link sent again to support [-at]......

pierotofy commented 4 years ago

Got it, thanks!

pierotofy commented 4 years ago

Problem seems related to a memory overallocation when requesting tiles that are outside of the minimum zoom level.

PR coming soon.

dmbworld commented 4 years ago

Yep, had overlooked the very large rise in memory from 2.2G to around 12G with this WebODM release when using the same task on an earlier version. I'm ready to test when the PR has gone through.

webodm commented 4 years ago

I've started experiencing this same issue, when I updated the Webodm version to the latest.

I will wait for the PR. Thanks

diegoaces commented 4 years ago

I've started experiencing this same issue, when I updated the Webodm version to the latest. I use docker image on digitalocean droplet for view only. The processing node is WebODM Lightning.

diegoaces commented 4 years ago

@pierotofy I hope this record helps determine the problem, thanks. My docker logs -f <CONTAINER> says:

ERROR Internal Server Error: /api/projects/1/tasks/17cd6150-1786-4dc1-b0b0-3d5894454686/orthophoto/tiles/1/0/1.png Traceback (most recent call last): File "rasterio/_io.pyx", line 707, in rasterio._io.DatasetReaderBase._read File "rasterio/shim_rasterioex.pxi", line 133, in rasterio._shim.io_multi_band File "rasterio/_err.pyx", line 182, in rasterio._err.exc_wrap_int rasterio._err.CPLE_OutOfMemoryError: rasterio.cpp, 1111: cannot allocate 2416115716 bytes

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 126, in _get_response response = self.process_exception_by_middleware(e, request) File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 124, in _get_response response = wrapped_callback(request, *callback_args, callback_kwargs) File "/usr/local/lib/python3.6/site-packages/django/views/decorators/csrf.py", line 54, in wrapped_view return view_func(*args, *kwargs) File "/usr/local/lib/python3.6/site-packages/django/views/generic/base.py", line 68, in view return self.dispatch(request, args, kwargs) File "/usr/local/lib/python3.6/site-packages/rest_framework/views.py", line 495, in dispatch response = self.handle_exception(exc) File "/usr/local/lib/python3.6/site-packages/rest_framework/views.py", line 455, in handle_exception self.raise_uncaught_exception(exc) File "/usr/local/lib/python3.6/site-packages/rest_framework/views.py", line 492, in dispatch response = handler(request, *args, kwargs) File "/webodm/app/api/tiler.py", line 301, in get url, x, y, z, indexes=indexes, tilesize=tilesize, nodata=nodata File "/webodm/src/rio-tiler/rio_tiler/main.py", line 94, in tile return utils.tile_read(src, tile_bounds, tilesize, kwargs) File "/webodm/src/rio-tiler/rio_tiler/utils.py", line 501, in tile_read return _tile_read(source, bounds, tilesize, **kwargs) File "/webodm/src/rio-tiler/rio_tiler/utils.py", line 472, in _tile_read resampling=Resampling[resampling_method], File "rasterio/_warp.pyx", line 980, in rasterio._warp.WarpedVRTReaderBase.read File "rasterio/_io.pyx", line 358, in rasterio._io.DatasetReaderBase.read File "rasterio/_io.pyx", line 710, in rasterio._io.DatasetReaderBase._read rasterio.errors.RasterioIOError: Read or write failed. rasterio.cpp, 1111: cannot allocate 2416115716 bytes

pierotofy commented 4 years ago

A fix has been pushed; please update and see if the problem is resolved? :pray:

dmbworld commented 4 years ago

Orthomosaic now loads and memory is stable however new problem observed or some repeat of the volume calulation problem. I'll open a new ticket for that.

isaacmichael commented 4 years ago

map view is working for me.

diegoaces commented 4 years ago

all ok thanks!