Människor som är nya i GPR-Arrays kanske tror att array-data betyder mer av samma sak. Även om detta delvis är sant, finns det andra detaljer som, om de övervägs, kan underlätta följande stadier av laddning, bearbetning och tolkning av sådan data. Denna not syftar till att ge några tips om datainsamlingsprocessen och den efterföljande hanteringen av insamlad data.
Datavolym och densitet:
Ett litet 3D-projekt kan innehålla cirka 5 GB rådata totalt. Inte en stor fil med moderna standarder och lätt nog att överföra med ett minne. Men ur ett datasäkerhets- och bearbetningsperspektiv är det inte klokt att lägga all denna data i en enda fil. Varför? Billiga minnesenheter är benägna att filkorruption under överföring, och detta kan vara särskilt problematiskt om data finns i en enda fil och påverkas på något sätt som inte omedelbart märks av operatören.
Därför rekommenderar vi att dela upp även små projekt i flera parallella strängar (om möjligt). Dessutom är datavolymen linjär mot punktavståndet, där halva punktavståndet betyder dubbel datavolym. Det är vanligtvis inte till någon fördel att samla in data med en högre densitet än halva arraykanalavståndet. Därför motsvarar en array med 8 cm kanalavstånd ett punktavstånd på 4 cm.
Navigering (i data):
Figur 2 ovan visar ett ganska litet projekt, vad gäller råradardata (ca 4.5 GB), men tolkningen av ett projekt som detta innebär att navigera från en km-skala ner till några meter, vilket sätter en hel del hög efterfrågan på bearbetningsprogramvaran som används.
positionering:
Positionering är överlägset en av de största diskussionspunkterna när det gäller insamling av matrisdata. Användningen av RTK-GPS med hög precision är den mest bekväma och effektiva positioneringsmetoden och av dessa skäl prioriteras framför användningen av totalstationer. Denna bekvämlighet blir emellertid ineffektiv i områden där signalen avbryts, t.ex. av trädtäcke, höga byggnader eller andra överliggande hinder. I slutändan är det själva undersökningsmiljön som avgör vilken positioneringsmetod som ska användas. För beskrivningarna som följer är det viktigt att notera att endast RTK-fix är tillräckligt och att eventuell förlust av RTK-fix kommer att orsaka extra arbete i datahanteringen.
Ibland är det möjligt att rädda ett projekt med dålig positionering; Men om projektet är stort med en hög andel positioneringsfel kan det vara mer ekonomiskt att göra en ny undersökning med bättre positionering än att lägga ner värdefull tid på att försöka fixa det. En annan viktig faktor som senare kan underlätta bearbetningen är valet av positioneringstäthet vid datainsamling, eftersom för hög densitet kan orsaka extra arbete. Om du inte har tillräcklig kontroll över positioneringsprocessen är det inte klokt att distribuera till fältet för datainsamling.
Skarpa svängar under datainsamling:
När man samlar in data i fält är det fullt möjligt att flytta arrayen på ett sätt som ger en skarp sväng, eller radie, längs den insamlade strängen. Det är dock en bra idé att tänka på vad den här typen av manöver kommer att göra med den efterföljande datahanteringen. Såsom illustreras i figur 3 resulterar en sådan radie i data som sträcks avsevärt längs den yttre omkretsen, samtidigt som den komprimeras längs den inre omkretsen. Hur detta kan påverka den slutliga bilden beror på hur data samlades in. Till exempel, om punktavståndet är inställt på 4 cm under datainsamling och 8 cm under interpolering, kan det fungera, men interpolering till samma bin-storlek som punktavståndet kommer definitivt att påverka data. Därför är det viktigt att överväga sådana faktorer när du planerar en undersökning; om sådana vändningar är oundvikliga, strukturera undersökningen så att data som samlas in vid dessa punkter inte är den viktigaste för den övergripande undersökningen.
Hål i data
Vad händer med områden som inte täcks av radardata? Tja, modern mjukvara erbjuder en viss möjlighet att interpolera data till sådana tomma utrymmen, men ibland kan det vara ett bättre val att tillämpa regularisering. Oavsett vilken teoretisk funktion som används, om de tomma utrymmena är för stora, kan ingen programvara fixa det, och dessa områden kommer att vara oanvändbara för tolkning. En annan mindre uppenbar fråga är att interpolations/binning-funktionen tar upp minnesutrymme på bearbetningsdatorn, men i vilken utsträckning är beroende av den valda bearbetningsmjukvaran. Ett projekt som det som visas i figur 4 kan vara svårt att bearbeta på grund av de mycket stora, ofyllda och stängda ytorna. Naturligtvis, om du väljer att bearbeta genom att manuellt definiera de områden som ska interpoleras ('chunking'), kan det alltid vara möjligt, men det är ganska gammalmodigt.
Figur 5 visar ett projekt med 4.5 GB rå radardata, samma som projektet som visas ovan i figur 2. Layouten för detta projekt är dock mycket bättre när det gäller datahantering, eftersom det är lätt att navigera, har inga skarpa svängar och inte heller hål i data.
Ta bort
Även med den bästa planeringen kan ett verkligt projekt innehålla data som är mindre än optimala. När man hanterar datavolymerna från ett modernt GPR-array-system är det därför alltid tillrådligt att bli av med problematiska data så tidigt som möjligt. Nästa anteckning i denna serie kommer att behandla ämnet data QA/QC och kommer att diskutera användbara verktyg för val och hantering av dataimport.
För att ladda ner den här artikeln klicka här.
Om du vill veta mer, utforska Raptor sida och Kondor sida
