Launch update — September 29, 2026: SkyView Desktop launches October 12, 2026. Approximately 50 pilots will field-test it in a private beta before launch. Pre-launch Desktop access requires beta approval and an assigned SkyView license. Ask about beta access or view SkyView plans.
Commercial mapping weeks are not one flight. They are three pads on Tuesday, a stockpile yard on Wednesday, and a corridor reflight that lands before the first two are even cleaned. The industry default still treats each of those as a separate cloud upload race: dump imagery, wait on someone else's queue, hope the meter does not punish the second pass.
That is the wrong shape for a multi-flight week. If you want to batch process drone maps desktop — reconstruct several jobs on the machine you already paid for, then upload finished deliverables when they are actually ready — that is the SkyView Desktop wedge. SkyView Desktop launches October 12, 2026. View plans at pilotledger.com/#pricing.
Multi-flight weeks break on logistics, not on photogrammetry
The capture is local. The hard drive is local. Then the habit kicks in: push every flight into a cloud processor because that is how the last subscription was sold. Three flights means three upload windows. A CRS fix on flight two means another upload loop while flight three sits on an SD card. Plant LTE and hotel Wi-Fi become the critical path for work your desktop GPU could have started overnight.
You do not need a vendor queue to prove you flew. You need a local processing lane that can take the next flight without treating bandwidth as the first deliverable.
Same processing-first story as process drone maps on your own hardware: reconstruct locally, keep intermediates on the machine you own, upload finished products when the client handoff actually needs them.
What "batch" means here (and what it does not)
In this post, batch is an operations word, not an invented panel name. It means:
- Several flight datasets on one workstation — pad A, pad B, corridor C — processed as local reconstruction jobs instead of serial whole-job cloud uploads.
- Process before you upload — finish reconstruction (and cleanup) on-hardware, then move finished deliverables when you choose.
- No per-map cloud processing fee as the default meter — SkyView's wedge is local hardware processing with subscription framing, not a credit burn every time you re-run flight two because the toe was wrong.
What this post will not invent: named "Batch Queue" buttons, concurrent-job counts, overnight scheduler labels, or accuracy percentages we have not verified in Ask Mav for this article. The claim is the processing path — local hardware, multiple flights before upload, no per-map cloud processing fee — not a screenshot of a feature panel.
The desktop path for a multi-flight day
SkyView is Pilot Ledger's desktop processing lane. Front door: process on your hardware. No per-map cloud processing fee. Raw imagery does not have to leave the machine for processing to start. Finished deliverables can be uploaded and shared when you choose.
A practical multi-flight pattern looks like this:
- Land the cards — pull each flight onto local storage with clear job names and CRS notes.
- Reconstruct locally — run each flight as a desktop job. Overnight capacity on your own machine beats three daytime upload races.
- Clean where it matters — classification, surface checks, and re-exports stay on-hardware. When bare earth matters, local point cloud classification is a separate desktop step. When elevations matter, keep DSM/DTM and cut-and-fill work local too — those posts own those roots; this post's root is batch process drone maps desktop before upload.
- Upload what you ship — send finished orthos, surfaces, or shareable views when the client needs them. Ortho web viewing is tiled (Client Ortho Tiles in the Browser, No 2GB Download). Gaussian splats remain a desktop GPU visual after reconstruction — useful for walkthroughs, not a substitute for a controlled map product when the deliverable is the map.
The product claim this post leans on is simple: batch process drone maps desktop-first so a multi-flight week does not become a multi-upload tax.
Field pattern: three flights, one machine
Tuesday pads. Two commercial pads, same crew, same afternoon. Process both locally overnight. Hand the superintendent two labeled surfaces in the morning — not two tickets stuck behind a vendor queue.
Wednesday yard. Stockpile inventory that needs a clean base. Iterate the toe on your hardware. Re-running a local job is cheaper than re-uploading the whole cloud because a loader moved.
Corridor reflight. Small dataset, tight deadline. Local reconstruction starts when the card lands. Upload the finished corridor product when QA passes — not the raw frames "just in case the cloud is faster."
That is the difference between "we process maps" and "we can clear a multi-flight backlog without treating every SD card as an upload tax."
SkyView Desktop launch
Process on your own hardware, then use PilotLedger to manage the job and deliver finished work.
Pilot Ledger quoting, jobs, and pay are a short second beat — why pilots stay after the maps are done. Quote the multi-pad week, schedule the corridor reflight, invoice when the package ships. They are not the H1. Lead with CRM on a batch-processing post and you are selling the wrong door.
Before the October 12 launch
If you want to batch process drone maps desktop — several flights reconstructed on your hardware, finished deliverables uploaded when they are ready, no per-map cloud processing fee as the default meter — view SkyView plans for the October 12, 2026 launch at pilotledger.com/#pricing. Processing first. Clear the backlog on your machine, then ship.