Odm: La division de la fusion échoue lors de la création de sous-modèles sur le serveur

Créé le 19 juil. 2019  ·  3Commentaires  ·  Source: OpenDroneMap/ODM

Comment avez-vous installé OpenDroneMap ? (Docker, nativement, ...) ?

Utiliser Docker sur un serveur Linux

Quel est votre navigateur et système d'exploitation ? (Copiez/collez la sortie de https://www.whatismybrowser.com/)

Ligne de commande via PuTTy

Quel est le problème?

Lorsque j'exécute ODM sur une machine locale, cela fonctionne bien avec et sans fractionnement de l'ensemble de données, en utilisant

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

ou alors

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

Tant que j'ai les données dans un dossier local (soit un disque dur, soit un disque externe USB), il fait tout comme prévu

Mais lorsque je l'exécute sur le serveur, cela ne fonctionne que sans la commande split :

docker run -it --rm -v /my-server/Project folder:/datasets/code opendronemap/odm --project-path /datasets
Fonctionne bien, mais dès que j'ajoute
--split 10 --split-overlap 3

au code, j'obtiens l'erreur suivante :

[INFO] en cours d'exécution /code/SuperBuild/src/opensfm/bin/opensfm create_submodels >/var/www/data/44a86e01-7ff1-4848-a6b6-711097026c96/opensfm
Traceback (appel le plus récent en dernier) :
Fichier "/code/SuperBuild/src/opensfm/bin/opensfm", ligne 34, dans
command.run(args)
Fichier "/code/SuperBuild/src/opensfm/opensfm/commands/create_submodels.py", ligne 37, en cours d'exécution
meta_data.load_clusters_with_neighbors())
Fichier "/code/SuperBuild/src/opensfm/opensfm/large/metadataset.py", ligne 154, dans >create_submodels
os.symlink(src_relpath, dst)
OSError : [Errno 95] Opération non prise en charge
Traceback (appel le plus récent en dernier) :
Fichier "/code/run.py", ligne 56, dans
app.execute()
Fichier "/code/stages/odm_app.py", ligne 93, en exécution
self.first_stage.run()
Fichier "/code/opendm/types.py", ligne 376, en cours d'exécution
self.next_stage.run(sorties)
Fichier "/code/opendm/types.py", ligne 357, en cours d'exécution
self.process(self.args, sorties)
Fichier "/code/stages/splitmerge.py", ligne 65, en cours
octx.run ("create_submodels")
Fichier "/code/opendm/osfm.py", ligne 21, en cours d'exécution
(context.opensfm_path, commande, self.opensfm_project_path))
Fichier "/code/opendm/system.py", ligne 76, en cours d'exécution
raise Exception("L'enfant a renvoyé {}".format(retcode))
Exception : Enfant retourné 1

Il semble qu'opensfm ait des problèmes pour lire/écrire le dossier des sous-modèles. Je suis ajouté au groupe d'utilisateurs docker, mais je n'ai pas les droits sudo lorsque j'exécute la commande.

Quel doit être le comportement attendu ? S'il s'agit d'une demande de fonctionnalité, veuillez décrire en détail les modifications que vous pensez devoir apporter au code, en citant les fichiers et les lignes où les modifications devraient être apportées, si possible.

Le comportement attendu est qu'ODM crée les dossiers de sous-modèle et traite l'ensemble de données en morceaux, afin que je puisse ensuite extraire l'orthophoto et le DSM de chaque sous-modèle pour travailler avec des fichiers tif plus petits par la suite.

Comment peut-on reproduire cela ? (Quelles étapes avez-vous suivies pour déclencher le problème ? Quels paramètres utilisez-vous pour le traitement ? Si possible, veuillez inclure une copie de votre ensemble de données téléchargé sur Google Drive ou Dropbox. Soyez détaillé)

Exécuter ODM avec --split sur un disque serveur

bug

Tous les 3 commentaires

J'ai fait des allers-retours avec l'administrateur du serveur et je pense que nous avons trouvé le problème :
Symlinks a des problèmes lors de l'exécution sur un système de fichiers cifs, ce qui nécessite l'ajout de l'indicateur mfsymlink à la commande mount, et c'est pourquoi j'obtenais l'erreur. Après avoir ajouté l'indicateur mfsymlink, le processus fonctionne correctement. J'exécute maintenant un ensemble de données plus volumineux pour m'en assurer, mais il semble que cela soit corrigé maintenant.

Oui, cela est parfaitement logique. L'utilisation intensive de liens symboliques est un piège pour le système de fichiers.

Piero -- considérez-vous toujours cela comme un bogue, ou devrions-nous demander à x-ancin d'ajouter quelque chose à la documentation, s'ils le peuvent ?

Je ne pense pas que ce soit un bug mais un problème de système de fichiers. Fermeture.

Cette page vous a été utile?
0 / 5 - 0 notes