Yelken Kanat Uçuşunu IGC Verisinden Doğru Analiz Etmek

Bir yelken kanat uçuşunu yazılımla analiz etmek, GPS izini haritada çizmekten daha fazlasıdır. IGC içindeki zamanlı konum ve irtifa kayıtlarını tek bir zaman serisi olarak işleyip rotayı, yer hızını, tırmanma ve alçalma oranlarını, süzülüşleri ve termik çevirmelerini birbirleriyle ilişkilendirmek gerekir; aksi halde güzel görünen bir grafik fiziksel olarak yanlış bir hikâye anlatabilir.

Asıl mesele pilotun nereden geçtiğini görmek değil, uçuş sırasında ne olduğuna dair ölçülebilir ayrımlar yapabilmektir. Hangi bölümde ilerleme hızı arttı, hangi yükseliş gerçek bir tırmanıştı, pilot termikte ne kadar süre kaldı, termik rüzgârla nasıl sürüklendi ve iki tırmanış arasında ne kadar irtifa harcandı gibi sorular ancak veri kaynağının sınırları korunursa anlamlı cevaplanır.

IGC rotadan daha fazlasını taşır

IGC, gliding ve benzeri hava sporlarında uçuş kaydı alışverişi için kullanılan metin tabanlı bir formattır. Bir dosyada uçuşa ve recorder'a ilişkin header kayıtlarının yanında, analizin omurgasını oluşturan B record'ları bulunur. Tipik bir B record; UTC zamanı, enlem, boylam, fix validity, pressure altitude ve GNSS altitude alanlarını taşır. Recorder'ın ürettiği ek alanlar I record ile tanımlanabilir; bu nedenle parser'ın yalnızca sabit bir satır uzunluğuna güvenmesi iyi bir yaklaşım değildir.

Önce B record'larını zamana göre sıralı fix'lere dönüştürürüm. Burada fix, belirli bir UTC anında kaydedilmiş konum ve ona bağlı ölçümlerdir. Gece yarısını aşan uçuşlarda saat alanının gün değişimini doğru ele almak, bozuk veya geçersiz fix'leri ayırmak ve koordinatları dereceye çevirmek gerekir. Dosyayı parse edebilmek ile veriye güvenebilmek aynı şey değildir: IGC'deki validity işareti ve varsa recorder'a özgü kalite alanları analizden önce incelenmelidir.

Rota analizi ardışık iki fix arasındaki yatay mesafeyle başlar. Kısa uçuş mesafelerinde küresel bir mesafe hesabı yeterli doğruluğu verebilir; daha uzun veya hassas hesaplarda uygun jeodezik yöntem kullanılır. Mesafeyi zaman farkına böldüğümüzde elde ettiğimiz değer ground speed'dir. Bu ayrım kritiktir: GPS izi doğrudan airspeed ölçmez. 45 km/h ground speed gören bir algoritma, rüzgârı bilmeden kanadın hava kütlesine göre 45 km/h uçtuğunu söyleyemez.

İrtifa da tek sütunmuş gibi davranılmamalıdır. IGC çoğu kayıtta pressure altitude ile GNSS altitude'ı yan yana taşıyabilir; pressure altitude atmosfer basıncına, GNSS altitude ise uydu çözümüne ve recorder'ın uyguladığı referansa bağlıdır. Bir analiz boyunca hangi irtifa serisinin kullanıldığı açıkça seçilmelidir. İki kaynağı gelişigüzel birbirine geçirmek, özellikle climb rate hesabında yapay sıçramalar üretir.

Ham türevler gürültülüdür. İki ardışık irtifa değerinin farkını çok kısa bir zaman aralığına bölmek teoride vertical speed verir, fakat birkaç metrelik ölçüm oynaklığı bir saniyelik aralıkta büyük sahte tırmanışlar üretebilir. Bu yüzden irtifa serisine uygun bir zaman penceresiyle smoothing uygulamak veya vertical speed'i birkaç fix'i kapsayan regresyonla tahmin etmek daha kullanışlıdır. Pencere büyüdükçe gürültü azalır fakat termiğe giriş ve çıkış zamanları bulanıklaşır; smoothing ücretsiz değildir.

Termik bir irtifa artışı değildir

Popüler açıklamalardaki yaygın hata, “irtifa yükseliyorsa termiktir” kuralıdır. Bunun kaçırdığı mekanizma hava kütlesi içindeki dönerek tırmanıştır. Bir yelken kanat ridge lift, wave veya yükselen başka bir hava bölgesinde de irtifa kazanabilir; kısa GNSS veya barometrik sapmalar da tırmanış gibi görünebilir. Termiğin veri üzerindeki izi yalnızca pozitif vertical speed değil, tırmanışın rota geometrisiyle birlikte ortaya çıkmasıdır.

Yazılım bu nedenle iki sinyali eşleştirmelidir. Birincisi belirli bir süre boyunca sürdürülen pozitif net irtifa eğilimidir; ikincisi heading veya track'in sürekli değişerek daire ya da daireye yakın yaylar oluşturmasıdır. Heading burada dikkatle kullanılmalıdır: yalnız GPS konumundan hesaplanan değer aslında uçağın burnunun baktığı yön değil, yer üzerindeki track yönüdür. Rüzgâr altında çevrilen düzgün bir termik, haritada sabit merkezli bir çember yerine rüzgâr yönünde sürüklenen bir spiral dizisi gibi görünebilir.

Bir termik detector bu nedenle tek bir vertical_speed > x ifadesinden ibaret olmamalıdır. Ardışık fix'lerden track değişimini hesaplamak, değişimin aynı dönüş yönünde birikmesini izlemek, aynı aralıkta smoothed altitude eğimini denetlemek ve kısa kopmaları tolere etmek daha savunulabilir bir yöntemdir. Tam bir tur yaklaşık 360° toplam dönüş demektir; bu geometrik ilişki güvenilir bir kontrol noktasıdır. Buna karşılık “en az şu kadar m/s olan her bölüm termiktir” diye evrensel bir eşik yoktur, çünkü kanadın sink rate'i, recorder örnekleme aralığı, hava koşulları ve pilotun dönüş biçimi sonucu değiştirir.

Bir termik bölümü tespit edildiğinde başlangıç ve bitiş zamanı, başlangıç ve bitiş irtifası, net kazanım, süre ve ortalama climb rate çıkarılabilir. Örneğin 1.120 m'den 1.420 m'ye 240 s içinde çıkan bir segmentin net ortalama tırmanışı 300/240 = 1,25 m/s'dir. Bu sayı, variometer'ın anlık olarak gösterebileceği yükselen havanın gücüyle aynı şey değildir: kanadın kendi sink rate'i ve pilotun daire geometrisi kaydedilen net tırmanışa dahildir.

Termik merkezi de kesin bir noktaymış gibi hesaplanmamalıdır. Dönüşlere ait konumların merkezi kısa bir pencere için kullanışlı bir tahmin verir, fakat termik ve pilot rüzgârla sürüklendiğinde bütün fix'lerin ortalaması uzun, eğik bir bulutu tek noktaya sıkıştırır. Daha iyi görselleştirme, dairelerin zaman içindeki merkezlerini veya tırmanış fix'lerinin kendisini gösterir; amaç atmosferde sabit koordinat uydurmak değil, pilotun kullandığı yükselen hava bölgesini tanımlamaktır.

Harita ve grafik aynı zamanı anlatmalı

Harita mekânsal yapıyı, grafik ise zaman yapısını gösterir. İyi bir analizde rota track'i irtifa veya vertical speed ile renklendirilebilir; yanında altitude-time, ground-speed-time ve vertical-speed-time grafikleri bulunur. Haritada seçilen bir termik segmentinin grafikte aynı UTC aralığını vurgulaması, görselleştirmeyi süs olmaktan çıkarıp inceleme aracına dönüştürür.

Ground speed hesabında ham fix çiftleri yine yanıltıcı olabilir. GNSS konumundaki küçük sıçrama, özellikle düşük hızda, hesaplanan hızı yükseltir. Segment mesafesini daha uzun bir zaman penceresinde değerlendirmek veya hız serisini kontrollü biçimde smooth etmek gerekir. Ancak dönüşteki gerçek hız değişimini de silmemek gerekir; analizde kullanılan pencerenin örnekleme sıklığıyla birlikte görünür olması bu yüzden değerlidir.

Süzülüş segmentleri termik kadar öğreticidir. Belirgin tırmanış ve yoğun dönüş bölgeleri çıkarıldıktan sonra kalan ileri uçuşlarda başlangıç-bitiş irtifası, kat edilen ground distance, süre ve ground speed hesaplanabilir. Ground distance / height loss oranı bir uçuş segmentinin yer referanslı görünen süzülüşünü verir, fakat bunu kanadın sakin havadaki glide ratio'su diye adlandırmak doğru değildir. Rüzgâr hem kat edilen yer mesafesini hem de pilotun seçtiği rotayı değiştirir.

Görselleştirme ayrıca veri kusurlarını bulmanın en hızlı yollarından biridir. Tek fix'in yüzlerce metre yana sıçradığı bir track, dikey grafikte tek örneklik irtifa basamağı veya zaman eksenindeki boşluk, türetilmiş metriklere güvenmeden önce incelenmelidir. Algoritmanın şüpheli noktayı sessizce düzeltmesi yerine işaretlemesi daha güvenlidir; uçuş analizi ile yarışma için kayıt doğrulaması aynı görev değildir.

Bir XC uçuşunda karar veriyi sınar

Somut malzeme olarak bir XC yelken kanat uçuşundan alınmış .igc dosyasını düşünelim. Pilotun sorusu “en iyi termiğim hangisiydi?” değil, daha işe yarar bir karar sorusu olsun: ikinci tırmanıştan ayrıldıktan sonra uzun glide'a geçmek makul müydü, yoksa veri erken ayrıldığını mı düşündürüyor? Dosyayı değiştirmeden saklar, B record'larını parse eder ve her fix'e UTC, latitude, longitude, seçilmiş altitude kaynağı, hesaplanan ground speed, smoothed vertical speed ve track angle bağlarız.

Haritada rota önce kalite kontrolünden geçer. Ardından sürekli dönüş ile pozitif irtifa eğiliminin çakıştığı aday aralıklar çıkarılır. Diyelim incelenen gerçek segment 1.350 m'den 1.650 m'ye 300 s'de yükseliyor; dosyadaki bu değerler kullanıldığında segmentin net ortalaması 1,0 m/s olur. Son dakikadaki yükseliş daha zayıfsa bunu ayrı bir rolling ölçüm olarak görmek gerekir, çünkü bütün termiğin ortalaması çıkış anındaki koşulu saklayabilir.

Termikten sonraki materyal de aynı dosyadadır: çıkış fix'i, bir sonraki anlamlı tırmanışın giriş fix'i ve aralarındaki track. Yazılım bu glide için süreyi, ground distance'ı, net irtifa kaybını ve ground speed dağılımını verir. Böylece “hızlı uçtu” gibi görsel bir izlenim yerine, hangi irtifada ayrıldığı ve sonraki lift'e ulaşana kadar ne kadar yükseklik harcadığı incelenebilir.

Yine de dosya pilotun kararını bütünüyle açıklamaz. IGC kaydı çoğu durumda bulut gelişimini, görülen kuşları, güneşlenen yamacı, pilotun airspeed'ini ve o anda seçilebilen iniş alanlarının durumunu içermez. Track'ten “bir dakika daha kalmalıydı” hükmü vermek bu eksik bilgiyi yok sayar. Veri, kararın sonucunu ve çevresindeki uçuş davranışını kuvvetle gösterebilir; karar anındaki bütün bilgi setini yeniden kuramaz.

Aynı vaka termik karşılaştırmasının doğru nesnesini de gösterir. Net climb rate, irtifa kazanımı, termikte geçirilen süre ve çıkış irtifası ayrı ölçümlerdir; en yüksek ortalama climb rate'e sahip termik, en fazla toplam irtifa kazandıran termik olmayabilir. Pilot performansı inceleniyorsa bu ayrım korunmalıdır. Bir tek “thermal score” üretmek, hangi tercihin neden iyi veya kötü göründüğünü saklar.

Önce iz açıklansın, sonra yorum yapılsın

Benim tercih ettiğim sıra şudur: IGC'yi kaynağı bozmadan parse etmek, geçersiz ve kopuk fix'leri görünür biçimde ayırmak, tek bir irtifa kaynağı seçmek, türetilmiş hızları kontrollü bir pencereyle hesaplamak, ardından rota geometrisi ile vertical speed'i birlikte kullanarak uçuş fazlarını sınıflandırmak. Harita ve zaman grafikleri aynı segment kimliklerini paylaşmalıdır. Bu yaklaşım, tek bir eşikten daha fazla iş ister ama “tırmanış”, “termik” ve “iyi glide” gibi farklı iddiaları aynı sayıya sıkıştırmaz.

Otomatik detector'ı hakem değil aday üreticisi olarak kullanmak daha doğrudur. Özellikle birkaç saniyelik veri boşlukları, düşük örnekleme sıklığı veya düzensiz kayıt aralıkları varken algoritmanın segment sınırlarını saniyesi saniyesine kesin göstermesi beklenmemelidir. Detector'ın parametreleri veri seti üzerinde görünür tutulmalı ve birkaç uçuş elle harita ile altitude grafiği üzerinden kontrol edilmelidir; bir recorder için çalışan smoothing penceresini bütün cihazlara değişmez kural yapmak hatadır.

Bu öneri, kayıt yeterince sık ve tutarlı fix içerdiği sürece geçerlidir. Uzun veri boşlukları varsa, irtifa kaynağı güvenilmezse veya amaç airspeed, gerçek hava kütlesi hareketi ya da kanadın aerodinamik polarını çıkarmaksa IGC'deki GPS izi tek başına yetmez. O noktada pitot tabanlı airspeed, kalibre edilmiş pressure verisi, meteorolojik rüzgâr bilgisi veya ilgili ek sensörler gerekir.

IGC'nin güçlü olduğu alan daha nettir: uçuşun zaman ve yer üzerindeki izini denetlenebilir biçimde yeniden kurmak ve bu izden sınırlı, tanımlı metrikler üretmek. Yazılımın değeri daha fazla sayı çıkarmasında değil, ölçülen veri ile türetilen yorum arasındaki sınırı korumasındadır. Bu sınır korunduğunda aynı dosya rota incelemesine, irtifa ve hız analizine, tırmanış ve alçalma bölgelerinin bulunmasına, termiklerin karşılaştırılmasına ve sonraki uçuş için somut kararların incelenmesine gerçekten yarar.