Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split-merge fails creating submodels in server #1010

Closed
x-ancin opened this issue Jul 19, 2019 · 3 comments
Closed

Split-merge fails creating submodels in server #1010

x-ancin opened this issue Jul 19, 2019 · 3 comments

Comments

@x-ancin
Copy link

x-ancin commented Jul 19, 2019

How did you install OpenDroneMap? (Docker, natively, ...)?

Using Docker in a linux server

What's your browser and operating system? (Copy/paste the output of https://www.whatismybrowser.com/)

Command line via PuTTy

What is the problem?

When I run ODM in a local machine it works fine with and without splitting the dataset, using

docker run -it --rm -v G:/test:/datasets/code opendronemap/odm --project-path /datasets

or

docker run -it --rm -v G:/test:/datasets/code opendronemap/odm --project-path /datasets --split 10 --split-overlap 3

As long as I have the data in a local folder (either hard drive or USB external disk), it does everything as expected

But when I run it on the server, it works only without the split command:

docker run -it --rm -v /my-server/Project folder:/datasets/code opendronemap/odm --project-path /datasets
Works fine, but as soon as I add
--split 10 --split-overlap 3

to the code, I get the following error:

[INFO] running /code/SuperBuild/src/opensfm/bin/opensfm create_submodels >/var/www/data/44a86e01-7ff1-4848-a6b6-711097026c96/opensfm
Traceback (most recent call last):
File “/code/SuperBuild/src/opensfm/bin/opensfm”, line 34, in
command.run(args)
File “/code/SuperBuild/src/opensfm/opensfm/commands/create_submodels.py”, line 37, in run
meta_data.load_clusters_with_neighbors())
File “/code/SuperBuild/src/opensfm/opensfm/large/metadataset.py”, line 154, in >create_submodels
os.symlink(src_relpath, dst)
OSError: [Errno 95] Operation not supported
Traceback (most recent call last):
File “/code/run.py”, line 56, in
app.execute()
File “/code/stages/odm_app.py”, line 93, in execute
self.first_stage.run()
File “/code/opendm/types.py”, line 376, in run
self.next_stage.run(outputs)
File “/code/opendm/types.py”, line 357, in run
self.process(self.args, outputs)
File “/code/stages/splitmerge.py”, line 65, in process
octx.run(“create_submodels”)
File “/code/opendm/osfm.py”, line 21, in run
(context.opensfm_path, command, self.opensfm_project_path))
File “/code/opendm/system.py”, line 76, in run
raise Exception(“Child returned {}”.format(retcode))
Exception: Child returned 1

It seems like it opensfm has problems read/writing the submodels folder. I am added to the docker user group, but I do not have sudo rights when I run the command.

What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.

The expected behavior is that ODM creates the submodel folders, and processes the dataset in chunks, so then I can extract each submodel's orthophoto and DSM to work with smaller tif files afterward

How can we reproduce this? (What steps did you do to trigger the problem? What parameters are you using for processing? If possible please include a copy of your dataset uploaded on Google Drive or Dropbox. Be detailed)

Run ODM with --split on a server disk

@x-ancin
Copy link
Author

x-ancin commented Jul 22, 2019

I have been going back and forth with the server admin, and I think we have found the problem:
Symlinks has issues when running on a cifs file system, which requires adding the mfsymlink flag to the mount command, and that is why I was getting the error. After adding the mfsymlink flag, the process works fine. I am running a bigger dataset now to make sure, but it seems like it is fixed now.

@smathermather
Copy link
Contributor

Yes, this makes perfect sense. The heavy use of symlinks is a definite gotcha for the file system.

Piero -- do you still consider this a bug, or should we request x-ancin adds something to the docs, if they can?

@smathermather
Copy link
Contributor

I don't think this is a bug but a file system issue. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants