Je hebt het in WebODM verwerkt.
Hoe lever je het nu op?

Kort samengevat: WebODM schrijft acht à negen bestanden naar schijf, waarvan je klant er realistisch twee kan gebruiken. Deze pagina loopt door wat WebODM precies heeft gemaakt, welke bestanden in een oplevering thuishoren, hoe je ze openbaar maakt voor iemand zonder GIS-software, en hoe je het geheel als één adres overhandigt in plaats van zes bijlagen.

Het probleem zit niet in het verwerken. Het zit in de laatste 10 meter.

Je taak is klaar. Het WebODM-dashboard staat op groen, je pant over een prima orthofoto, er is een puntenwolk en een getextureerd model. Het ziet er af uit. Het is niet opgeleverd.

Alles wat je ziet leeft op http://localhost:8000 — een adres dat alleen bestaat op de machine die de verwerking heeft gedraaid. Je klant kan daar niet bij. Niet vanuit zijn kantoor, niet op zijn gsm, niet morgen. Zodra iemand anders dit moet zien, moet je beslissen wát er van je computer af gaat, in welke vorm, en hoe hij het opent.

Die beslissing ís het werk, en precies daar loopt het meestal mis: de piloot zipt de uitvoermap, gooit 4 GB op WeTransfer en noemt dat een oplevering.

Stap 1 — Weet wat WebODM echt heeft weggeschreven

Open je afgeronde taak en gebruik Download Assets. Dat uitklapmenu is de plattegrond van alles wat de verwerking heeft opgeleverd. Op schijf staan dezelfde bestanden in de projectmap, in deze submappen:

De groottes zijn ordegroottes voor een typische vlucht van 200 tot 800 beelden en schalen mee met je GSD. De mapnamen komen uit de uitvoerstructuur van OpenDroneMap; draai je een andere WebODM-versie, open dan Download Assets en leg de lijst naast deze tabel voordat je erop bouwt.

Stap 2 — Bepaal voor wie elk bestand bedoeld is

Drie verschillende mensen willen drie verschillende dingen uit dezelfde taak, en ze door elkaar halen is de meest gemaakte opleveringsfout:

• De klant die de vlucht heeft besteld. Wil de site zien, begrijpen wat je hebt gevonden, en het aan iemand anders kunnen tonen. Heeft een viewer en een rapport nodig. Heeft geen GIS-software en krijgt die ook nooit.
• De landmeter, architect of studiebureau na jou. Wil georefereerde data om mee te werken: de orthofoto als GeoTIFF, het DSM, soms de puntenwolk. Heeft het coördinatenstelsel expliciet nodig.
• Jijzelf, over achttien maanden. Wil de volledige uitvoer plus de verwerkingsinstellingen, zodat een herhaalvlucht vergelijkbaar is. Dat is een archief, geen oplevering.

all.zip naar die eerste persoon sturen is geen gulheid, het is je werk doorschuiven. Hij opent het, vindt een .laz die hij niet kan lezen, en mailt je met de vraag wat hij ermee moet.

Stap 3 — Maak de orthofoto openbaar voor een mens

Een GeoTIFF van 3 GB is een werkbestand, geen oplevering. Windows Fotoweergave opent hem niet. Er zijn drie realistische bestemmingen, en vaak wil je er meer dan één:

1. Houd hem interactief. De versie die je klant echt wil, is die waarin hij kan pannen en zoomen — precies zoals jij hem ziet in het kaarttabblad van WebODM. Dat betekent tegels serveren, geen bestand versturen. Zie stap 5.
2. Een Cloud Optimized GeoTIFF voor de technische ontvanger. Een COG streamt in plaats van in zijn geheel te downloaden, zodat QGIS hem opent zonder twintig minuten wachten:

   gdal_translate -of COG -co COMPRESS=DEFLATE \
     odm_orthophoto.tif ortho_cog.tif

3. Een plat beeld voor iedereen daarbuiten. Een verkleinde JPEG of PNG die op elke gsm opent, voor de mail, de rapportcover, de werfvergadering:

   gdal_translate -of JPEG -outsize 4000 0 -co QUALITY=88 \
     odm_orthophoto.tif ortho_preview.jpg

Wat je ook stuurt: vermeld het coördinatenstelsel (de EPSG-code) en de GSD in cm/pixel op papier. Een GeoTIFF zonder vermeld stelsel is een foto, geen meetproduct, en de ontvanger kan onmogelijk nagaan waar jij van uitging.

Stap 4 — Beslis wat er met de puntenwolk en het 3D-model gebeurt

De puntenwolk. odm_georeferenced_model.laz is het ruwste wat WebODM maakt en hoort bijna nooit in een klantoplevering. Vroeg een landmeter er wél om, stuur de LAZ dan met drie dingen erbij op papier: de EPSG-code, het hoogtereferentievlak, en of de wolk geclassificeerd is. Zonder die gegevens is hij onbruikbaar en komt hij regelrecht terug.

Het getextureerde model. De OBJ bestaat uit drie dingen die samen moeten blijven: de .obj, zijn .mtl, en de textuurbeelden. Stuur er één zonder de andere en je klant opent een grijze blob zonder textuur. Voor alles wat op het web moet, zet je eerst om naar glTF/GLB, of je publiceert het model in een viewer en levert de embed in plaats van de geometrie.

De algemene regel: als het openen van een bestand software vraagt die je klant niet heeft, heb je geen resultaat opgeleverd — je hebt een probleem doorgegeven.

Stap 5 — De valkuil: de deel-link van WebODM zelf

WebODM kan een taak publiek maken en geeft je dan een URL naar de kaart- en 3D-weergave. Op het eerste gezicht lost dat alles op. Twee dingen bepalen of dat klopt:

• Een lokale installatie is niet bereikbaar. Draait WebODM in Docker op je eigen machine, dan wijst de publieke link naar localhost of een LAN-adres. Op jouw scherm werkt hij perfect, op dat van je klant helemaal niet. Dit is veruit de meest voorkomende reden dat een "gedeelde" WebODM-link dood aankomt.
• Je instance blootstellen is een beslissing, geen detail. Bereikbaar maken vanaf het internet betekent je verwerkingsserver online zetten, mét de taken van je andere klanten erop. Dat is eerst een beveiligings- en vertrouwelijkheidsvraag, en pas daarna een gemaksvraag.

WebODM Lightning lost het eerste punt op — dat draait gehost, dus een publieke taaklink opent daar wél voor iedereen. Het lost de tweede helft van het werk niet op: het rapport, de foto's en de context staan nog steeds ergens anders, en je klant houdt meerdere links over.

Stap 6 — Bundel het tot één oplevering

Op dit punt heb je je keuzes gemaakt: een viewer voor de kaart, misschien een 3D-model, een rapport-PDF, een selectie beelden, eventueel een GeoTIFF voor de technische ontvanger. De laatste stap is die verzameling omzetten in één adres dat je klant kan openen, begrijpen en terugvinden.

Dat is de laag die DronePortal invult. Er wordt niets verwerkt — WebODM blijft je motor, en aan je manier van verwerken verandert niets. Wat het wél doet, is de oplevering bij elkaar houden:

• De interactieve kaart of 3D-weergave ingebed op de pagina, zodat pannen en zoomen werkt waar de klant al is
• Het kwaliteitsrapport, de beelden en eventuele downloads ernaast, niet in een aparte mail
• Eén toegangscode per project in plaats van een link per bestand
• Een adres dat volgend jaar nog werkt, terwijl een WeTransfer-link na zeven dagen dood is

De volgorde is niet toevallig: stap 1 tot 5 zijn het echte werk, en die blijven identiek of je nu iets van ons gebruikt of niet. Stap 6 gaat alleen over hoe het aankomt.

In de praktijk: de echte klikken

1. Zorg eerst voor een publieke viewer-URL. Voor WebODM zijn er twee wegen. Op WebODM Lightning deel je de taak en kopieer je de publieke link — die URL is al bereikbaar en kan er zo in. Op een zelfgehoste WebODM werkt dat niet (stap 5): publiceer het getextureerde model dan naar een insluitbare viewer zoals Sketchfab of Polycam en gebruik die link. Voor de orthofoto wil je een kaartviewer met tegels, nooit de rauwe GeoTIFF — een bestand van 3 GB is niets wat een iframe kan tonen.
2. Plak gerust de gewone pagina-URL; hij wordt bij het opslaan omgezet. Een Sketchfab-modelpagina, een Matterport-/models/-link, een Kuula-/post/-link en een Polycam-capturepagina weigeren alle vier om ingesloten te worden. DronePortal zet ze bij het opslaan om naar hun embed-vorm, dus je hoeft geen embedcode te zoeken. Eén uitzondering: skfb.ly-kortlinks worden geweigerd mét melding — plak de volledige Sketchfab-URL.
3. Dashboard → "+ Nieuw project". Kies een bestaande klant of tik naam en e-mail rechtstreeks in het formulier. Geef het project een naam en een type, en benoem de eerste eenheid. Bij opslaan maakt DronePortal de klant, het project en de eenheid aan, genereert een toegangscode van 8 tekens, en zet je meteen in het bewerkscherm van die eenheid.
4. Sectie 🗺 Viewers — één rij per viewer. Kies het type (3D Visueel, 3D Thermisch, 2D Kaart, 360° Rondgang), schrijf een label dat je klant leest, en plak de URL. Voor WebODM: de orthofoto onder 2D Kaart, het getextureerde model onder 3D Visueel. Met "+ Viewer toevoegen" doe je de volgende. Daaronder kies je de Hoofdviewer — die opent als eerste — of je laat "Automatisch (eerste viewer)" staan.
5. Sectie 📋 Documenten & media — het rapport erbij. "+ Document of link toevoegen", zet het type op Bestand en gebruik "↑ Upload" voor de WebODM-kwaliteitsrapport-PDF (pdf, jpg en png worden aanvaard). Type Link wijst naar iets wat elders staat. De labelvelden NL/FR/EN zijn de knoptekst die je klant ziet, dus vul minstens de taal van deze oplevering in.
6. Sectie 📷 Foto's — upload de selectie. Thermisch, visueel en zoom. Dit is een selectie, geen stortplaats: het zijn de beelden die je vaststellingen dragen, niet de volledige kaart.
7. Sectie Portaal — zet het open. Status op Actief, kies de taal, vul de opnamedatum in en eventueel een vervaldatum als de opdracht dat vraagt. De toegangscode staat in diezelfde sectie.
8. Geef één link door. De klant-URL is https://{jouwsubdomein}.droneportal.app/app/portaal/?code={TOEGANGSCODE}. Eén adres plus één code — geen account voor je klant, niets te installeren.

Open die link zelf in een privévenster vóór je hem verstuurt. Dat is de enige manier om te zien wat je klant ziet in plaats van wat je eigen ingelogde sessie toont.

Voor je verstuurt: een checklist

• Vluchtdatum en GSD staan op papier
• EPSG-code vermeld bij elk georefereerd bestand
• Elk bestand opent zonder specialistische software — of staat expliciet gemarkeerd als voor de landmeter
• De .obj, .mtl en texturen van het 3D-model reizen samen
• Je hebt de oplevering zelf geopend op een gsm, buiten je eigen netwerk
• Niets verwijst naar localhost of een intern IP-adres
• Het is duidelijk wat er niet in zit, zodat niemand denkt dat het nog komt
• Er is een werkende weg terug naar jou voor vragen

Vijf manieren waarop een WebODM-oplevering misloopt

1. all.zip versturen. Alles, en dus niets. De klant kan niet zien wat ertoe doet.
2. Een rauwe GeoTIFF via WeTransfer. Te groot om comfortabel te downloaden, niet te openen, en na zeven dagen weg.
3. Een deel-link naar een lokale instance. Werkt alleen op jouw machine. Je komt er pas achter als de klant het zegt.
4. Geen coördinatenstelsel. Maakt elk georefereerd bestand in de oplevering oncontroleerbaar.
5. Zes links in drie mails. Technisch volledig, praktisch kwijt tegen week twee.

Zelfde werkwijze voor andere tools: een Pix4D-project opleveren · een DJI Terra-reconstructie opleveren. Verder lezen: lokaal verwerken, professioneel opleveren en je klant ziet je puntenwolk nooit.

Veelgestelde vragen

Lees ook

• Wat is een drone-klantportaal?
• Stop met WeTransfer-links naar klanten

Klaar om te starten?

Probeer stap 6 op je volgende WebODM-opdracht

Stap 1 tot 5 blijven exact zoals ze zijn. Gratis proef, geen creditcard nodig.