nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Erreur 999999 Drone2Map

janniewu

J'ai rencontré l'erreur 999999 après avoir cliqué sur "Start" pour le traitement des données. Est-ce parce que je n'ai pas pris suffisamment de photos avec chevauchement pour l'analyse ou à cause de l'emplacement où j'ai fait voler mon drone ?

De plus, les points de données sont un peu décalés. J'ai fait voler le drone sur le toit d'un bâtiment (marqué en rouge) et j'ai visé à faire voler autour de la partie blanche du bâtiment (indiquée par une flèche rouge) pour l'opération du drone et l'essai d'analyse Drone2Map. Avez-vous des solutions ou des suggestions sur ce qui pourrait poser problème ?

Je serais reconnaissant si des solutions pouvaient être fournies. Merci.

Trouver plus de publications taguées avec

Accepted answers

pal.herman.sund@geodata.no_Geodata

All red marks indicate lack of overlap. Careful planning and a reflight is probably the only possible solution. Lack of a good plan and flight + gcp's is (close to) always the reason for a processing to fail.

All comments

MarkBarker1

Hi @RyanWilkie_apca ,

Apologies for the slow response, I missed the email with your reply on this and just came across it. I tested some 10-band micasense dual camera imagery that we had in house and wasn't able to reproduce the same coordinate system issue. Granted the imagery that we have to test with is some micasense sample data so there may be some differences with your collection. If you are still able to reproduce this problem in Drone2Map 2025.2 would you be open to sharing the imagery, or a subset, with me?
Additionally if you have a processing report from the project that failed and could share it, that would also help.

Thank you,

Mark

RyanWilkie_apca

Hi Mark,
When this error occurs, and the specific CS issue happens, it's not usually consistent on the switch. About 1/4 of the time, it would be in the wrong utm (+/- up to 3 off), some times it would load to NAD83, and others which I didnt note at the time and have since forgotten.
I think part of the issue was that the drone platform was relatively new at the time (Mavic 3M) and D2M didn't/does not support true combined mutlispectral processing in one go. I still have to run 2 or 3 different processing runs, then combine in post to have it as intended. I have the 10-band micasense dual, and D2M will NOT run all ten bands in one run even if the images all have the same coordinate data and clearly overlap. When processing the tiff info I would regularly get error 999999 trying to run anything other than 4 bands of jpg layers.

MarkBarker1

Hi @RyanWilkie_apca ,

Regarding the thread issue I would reach out to technical support to see if they can confirm if there is a bug there. I am curious about what you said here, "the project defaults to a random CS". For the project coordinate system projects will default to the closest UTM zone based off your imagery's location, are you seeing something different? If so, are you defining specific image and project coordinate systems on the new project page?

Thanks,
Mark

RyanWilkie_apca

I've been battling Drone2Map processing errors for the last few months.

When iterating on error 999999, I've found that changing and lowering the thread/parallel processing count in the processing options helps. I've set my default down to 10 now and it seems to run (when I dont get other errors). Other times Ive had minor success with changing the project/image coordinate systems. Sometimes, the project defaults to a random CS. Most times for me, Changing both image and project CS to something else, then re-selecting the default (WGS 84) or whatever you're working in, then running it usually clears the 99999 error code. **about half of the time**

CodyBinkelheim

Janniewu

The points in your 4th screenshot are NOT in the wrong location. The basemap that you show in the screenshot is a 'traditional' orthophoto, with accurate locations for anything on the ground, but that tall building is clearly leaning away from you. The top of the building IS located where the blue photo points are shown.

It's very important to understand this, both for your processing and also if you are using this basemap image to do your flight planning! If you're flying a drone near a tall building and you do not plan for the proper XYZ position of your target, you may crash your drone. (this is assuming your drone is flying on its own, using GPS. I'm guessing you flew manually in this case?)

This blog may be helpful for you to understand what you are seeing in the orthophoto https://esriurl.com/3orthoTypesArcGIS although it does not discuss 3D drone flight planning. Note if you have a DJI drone and an iPad, you can use a free app from Esri to plan and control your flights https://esriurl.com/ssle

NOW - this does not answer your question about why the processing failed. The project did not complete setup, so the processing could not continue. I can see that the Z values are incorrect. This is a very common problem for drones, and the Z value you show of 33 meters must refer to height above sea level (not 33 meters above ground). At your location, the ground ~31 meters above sea level, so this is telling Drone2Map that your drone was 2 meters above ground! (see my screenshot from https://esriurl.com/map4groundelevation )

Please review this help document https://doc.arcgis.com/en/drone2map/latest/help/flight-data-geolocation.htm and look for Adjust image altitudes

Cody B.

pal.herman.sund@geodata.no_Geodata

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.