​​



TUSAGA-Aktif Sistemi Düzeltme Parametreleri



TUSAGA-Aktif Sistemi Düzeltme Parametreleri


TUSAGA-AKTİF SİSTEMİ İLETİŞİM YAPISINDA KULLANILAN

NTRIP VE RTCM FORMATLARI

                                                           

GNSS Veri Değişimi İçin Uluslararası Standartlar

 

Konum belirleme uygulamalarında GNSS verisinin değişimi için geliştirilmiş 2 temel standart kullanılmaktadır. Bunlardan ilki özellikle diferansiyel ya da rölatif konumlamada ölçü sonrası değerlendirme çalışmaları ile veri arşivleme için geliştirilmiş, gerçek zamanlı veri iletimi için uygun olmayan RINEX (Receiver INdependent EXchange) formatıdır. İkincisi ise gerçek zamanlı uygulamalar için geliştirilmiş olan RTCM formatıdır. Bu standartların dışında gerçek zamanlı uygulamalar için GPS/GNSS alıcıları ile diğer cihazlar (örneğin PDA) arasın-da veri iletimi için NMEA formatı kullanılmaktadır.

Genel olarak GNSS alıcısı üreten birçok firma kendine özgü veri formatını geliştirmekte ve korumaktadır. Üretici firma tanımlı bu veri formatları çoğunlukla alıcı markasına bağımlı “binary” formatta olup, bazı firmalar tarafından “ASCII” formatta da geliştirilmektedir. Bazı durumlarda GNSS alıcısı üreten firmalar, değişik modeldeki alıcılar ve uygulamaya yönelik olarak farklı veri formatları da oluşturabilmektedirler.

RTCM formatı; GNSS veri değişimi için geliştirilmiş uluslararası standartta gerçek zamanlı uygulamalarda kullanılmaktadır. Özellikle farklı marka ve modeldeki alıcılardan oluşabilen GNSS/CORS ağlarının birlikte çalışması ve entegrasyonu ile bu ağlardan mobil kullanıcılara (gezici alıcılara) iletilen gerçek zamanlı verilerin bir protokol ve veri formatında gönderilmesi, kullanıcılar tarafından da bunların kabul edilebilir olması gerekmektedir. Bu nedenle uluslararası bir standart olarak geliştiren RTCM, başta DGNSS olmak üzere günümüzde RTK uygulamalarında etkin olarak kullanılan bir veri formatıdır.

Aşağıdaki Tabloda karşılaştırmalı olarak genel özellikleri verilen RINEX, RTCM ve NMEA gibi formatların yanında uluslararası anlamda bilinen CMR/CMR+, RTCA, SP3, BINEX gibi farklı içerik ve nitelikteki uluslararası standart formatlar da bulunmaktadır. Bunların dışında üretici firma tanımlı daha birçok veri formatı da geliştirilmiştir.

 

GNSS Verisi İçin Gerçek Zamanlı İletim Mekanizmaları

GNSS bilgilerinin gerçek zamanlı iletimi ve teslimi için üç temel bileşen bulunmaktadır. Bu bileşenler kullanılan “veri iletişim linkleri (data communications link)”, “veri iletim protokolleri (transmission protocol)” ve “veri formatları (data format)” dır.

Üretici firma tanımlı özel veri formatlarının dışında günümüzde uluslararası standart olarak kabul edilmiş RTCM, NMEA ve CMR/CMR+ gibi formatlar bulunmaktadır. Bu formatlar anlamlı GNSS bilgilerini “bit” dizileri şeklinde içeren ve bu bilgilerin belli bir sözleşme ile iletimini sağlayan dosya yapısındadırlar. Veri iletim protokolleri ise ilgili formattaki GNSS bilgilerini içeren dosyaların bir ağ üzerinde güvenilir akış kontrol mekanizmalarını sağlayarak, veri iletimini yönetirler. Günümüzde GNSS verileri için geliştirilmiş NTRIP ve RTIGS gibi veri iletim protokolleri bulunmaktadır. Tüm bu bilgileri bir yerden diğer bir yere taşıma aracı olarak ise veri iletişim linkleri (telekomünikasyon sistemleri) kullanılmaktadır. Genel anlamda veri iletişim linkleri de tek yönlü ve çift yönlü olmak üzere 2 türdedir.

 

Veri İletim Protokolleri

Günümüzde GNSS verilerinin internet üzerinden yayınlanması ve dağıtımı amacıyla geliştirilmiş 2 standart protokol bulunmaktadır. Bunlardan “Networked Transport of RTCM via Internet Protocol (NTRIP)”, gerçek zamanlı olarak internet-radyo teknolojisini geliştirip desteklemek amacıyla Almanya Federal Kartografya ve Jeodezi Dairesi (BKG) tarafından geliştirilmiştir. “Real-Time IGS (RTIGS)” ise Uluslararası GNSS Servisi (IGS) tarafından geliştirilme süreci devam eden diğer bir protokoldür. Bu internet protokolleri, ilgili veri formatındaki GNSS bilgilerini içeren dosyaların bir ağ üzerinde güvenilir akış kontrol mekanizmalarını sağlayarak, veri iletimini yönetirler. Başka bir ifadeyle GNSS verilerinin internet üzerinden nasıl yayınlanacağını tanımlayan protokollerdir.

NTRIP protokolü RINEX, BINEX, SOC veri formatlarının, DGNSS/RTK uygulamaları için RTCM formatı ile yayın efemerislerinin, yörünge ve saat düzeltmelerinin, havacılık uygulamalarında RTCA düzeltmelerinin (EGNOS-WAAS-MSAS ile) ve diğer GNSS veri formatlarının kontrollü olarak akışını sağlar.

                 NTRIP iletişimi

 

Veri Formatları

1947 yılında Amerika’da kurulan The Radio Technical Commission for Maritime Services (RTCM), günümüzde tüm dünyadan çeşitli devlet kurumlarının, üretici firmaların ve servis sağlayıcı diğer kurumların oluşturduğu bağımsız bir organizasyon olarak başta denizcilik uygulamaları olmak üzere, farklı disiplinler ve uygulayıcılara da hizmet eden bir kuruluştur. Özellikle deniz ve hava navigasyonun da DGNSS’ in etkin kullanımı için kurum içerisinde RTCM SC-104 Komitesi’nin oluşumu sağlanmıştır. Bu komite GPS/ GNSS uygulamaları için RTCM veri formatının geliştirilmesi çalışmalarını yürütmektedir. Diferansiyel GNSS uygulamalarında düzeltme verilerinin gerçek zamanlı iletimi için RTCM 2.x ve RTCM 3.x uluslararası standartlarının oluşturulması ve gelişimi, ilgili bu komisyon tarafından gerçekleştirilmektedir

Gerçek zamanlı veri iletimi için kullanılan RTCM “binary” yapıdadır. Ancak RTCM 2.x sürümlerinin verimsiz format yapısı nedeniyle yüksek bant genişliği gerektirmesi özellikle RTK uygulamaları için sıkıntılar yaratmıştır. Bundan dolayı RTK uygulamalarında daha etkin bir bant genişliğinin kullanımı için RTCM 2.x sürümlerine alternatif olarak Compact Measurement Record (CMR) veri formatı daha kompakt bir yapıda geliştirilmiştir. CMR daha düşük “baud” hızında GNSS verisinin aktarımı için uygundur. CMR formatı geliştirilerek CMR+ formatı elde edilmiştir. Birçok GNSS alıcı üreticisi CMR/ CMR+ formatlarının kullanımını ürünlerinde sağlamaktadır. RTCM 2.x sürümlerindeki bant genişliğinin kullanımındaki sıkıntılar RTCM 3.x sürümleri ile giderilmiş ve daha etkin bir bant genişliğinin kullanımı sağlanmıştır.

 

RTCM 2.x (x:0, 1, 2, 3) Sürümleri ve Özellikleri

RTCM 2.0, 1 Ocak 1990 tarihinde DGPS uygulamalarında kod düzeltmelerinin kullanımı için 1,2,3,6,16 ve 59 nolu temel mesaj türleri ile tanımlanmıştır. RTCM 2.0 sürümü ağ-RTK yapısında çalışan referans istasyonlarında veri ve bilgi iletimini desteklemediği için, Geo++ firması tarafın-dan GNSS/CORS ağlarında alan düzeltme parametrelerinin (FKP) yayınlanması için 59 nolu mesaj türü kullanılmıştır.

1992 yılında RTCM 2.0’ ın revize edilmesi ve taşıyıcı faz gözlemlerinin iletimi için taşıyıcı faz iletişimi çalışma grubunun kurulmasıyla, taşıyıcı faz verisi için standartların değiştirilmesi önerildi. 1994’ de RTCM 2.0, RTK mesajlarını içerecek şekilde güncellenerek, RTCM 2.1 sürümü geliştirildi. RTCM 2.1, düzeltilmemiş RTK faz ve kod ölçüleri (18, 19) ile RTK faz ve kod düzeltmelerini (20, 21) içermektedir. RTCM 2.2 sürümü ise 1998 yılından itibaren diferansiyel GLONASS düzeltmelerini içeren 31 nolu mesaj türü ile kullanılmaya başlanmıştır. 31 nolu mesaj türü, DGPS düzeltmeleri bakımından 1 nolu mesaj türüne eşdeğerdir. Buna karşın 18, 19, 20, 21 nolu mesaj türleri bir önceki sürüm olan RTCM 2.0 ile tam anlamıyla uyumlu değildir. RTCM 2.3 sürümü ise 2001 yılında, anten tanımlaması ve anten seri numaraları içeren 23 nolu mesaj, referans istasyonu anteni ARP koordinatları ile isteğe bağlı anten yüksekliği bilgilerini içeren 24 nolu mesaj ile tanımlanmıştır. Bu mesaj türlerinin dışında RTK’yı, radio-beacon yayınlarını, Loran-C’nin kullanımını vb. geliştirmek için pek çok yeni mesaj türü de geliştirilmiştir.

RTCM 2.3, birçok ticari alıcıya adapte edilebilmekte ve hala DGPS veya tek baz RTK (single-base RTK) uygulamaları için yaygın olarak kullanılmaktadır. Buna karşın, RTCM 2.3’ ün belli sınırlamaları vardır. İlk olarak, her bir kelime 24 bit veri ve 6 bit eşlik (parity) ile 30 bitlik bir kelime yapısı oluşturmaktadır. 30 bitlik bir kelime yapısı mesajın verimsiz olarak kodlanması nedeniyle bant genişliğinde (bandwidth) fazla yer kaplamaktadır. İkinci olarak, eşlik hesabı önceki kelimenin bit’lerini içermektedir. Sonuç olarak her mesaj, sonra gelecek bir kelimeden bağımsız değildir. Bunların dışında, RTCM 2.3’ün yapısı, GPS L2C ve L5, GALILEO ve COMPASS gibi gelecekteki GNSS sistemlerine yeni sinyaller yerleştirmek için yeterli esneklikte değildir. Bundan dolayı RTCM 2.3 kullanılarak, yeni ağ-RTK konseptleri uygulanamayabilir.

 

                         RTCM 2.x veri formatı sürümleri gelişimi

 

           RTCM 2.x (x:0,1,2,3) veri formatı sürümlerinin mesaj tür ve içerikleri

RTCM 3.x (x:0, 1) Sürümleri ve Özellikleri

RTCM 3.0 Formatı Mesaj Yapısı

RTCM 2.x sürümlerindeki veri yapısından kaynaklanan olumsuzları gidermek ve özellikle RTK uygulamalarını geliştirmek ve ağ-RTK’yı desteklemek için RTCM 3.x sürümünün ilki olan RTCM 3.0 tasarlanmış ve 2004 yılında yayınlanmıştır. RTCM 3.0, gelişmiş veri yapısı ve veri iletimi süresince kullandığı etkin bant genişliği nedeniyle özellikle RTK uygulamaları için büyük yarar sağlamıştır. RTCM 3.0, RTCM 2.x sürümleri ile karşılaştırıldığında bant genişliği ihtiyacını önemli ölçüde azaltmaktadır. Bunun yanı sıra üretici firma tanımlı veri formatlarından da daha az bant genişliği kullanmaktadır.

RTCM 3.0 Formatı Mesaj Türleri ve İçerikleri

RTCM 3.0 veri formatı esnek ve işlevsel bir yapıya sahiptir. Mesaj türleri farklı grupların altında düzenlenmiştir ve bu gruplardaki farklı mesaj türleri benzer bilgiler içerir. RTCM 3.0 sürümü, RTCM 2.x sürümlerindeki sınırlamaları ortadan kaldırsa da her iki veri formatı birbiri ile uyumlu değildir.

RTCM 3.1 Formatı Ağ-RTK Mesaj Türleri ve İçerikleri

Tüm dünyada oluşumu ve kullanımı giderek yaygınlaşan, ağ-RTK ilkesi ile çalışan GNSS/CORS ağları için RTCM 3.1 sürümü geliştirilmiş ve RTCM SC-14 Komitesi tarafından 2006 yılında onaylanarak hizmete sunulmuştur. GNSS/CORS ağlarının kullanımda sistematik hataların modellenmesi ve yüksek doğrulukta konum bilgisinin elde edilebilmesi için RTCM 3.1 formatı mesaj türleri oldukça önemlidir. Günümüzde GNSS/CORS ağları ile konum belirlemede etkin olarak kullanılan VRS, FKP ve MAC olarak bilinen üç veri hesap ve aktarma tekniği bulunmaktadır. RTCM 3.1 formatı, GPS/GLONASS yörünge bilgileri ile MAC tekniği için ağ-RTK uygulamalarında kullanılacak yeni mesaj türleri içermektedir.

VRS tekniğinin kullanımında ağ düzeltmeleri RTCM 2.3’de mesaj türü 18-19, RTCM 3.0’da ise mesaj türü 1001-1002-1003-1004 ile kodlanarak gezici alıcılara gönderilmektedir. FKP tekniğinde düzeltme parametreleri kullanıcılara SAPOS tarafından geliştirilmiş, RTCM 2.3’daki özelleştirilmiş mesaj türü olan 59 ile gönderilmektedir. Leica Geosystems ve Geo++ firmalarının birlikte geliştirdiği MAC tekniği ise RTCM 3.0 formatına dayalı bir tekniktir. GNSS/ CORS uygulamalarında MAC tekniğinin kullanımı için geliştirilmiş beş yeni mesaj türü tanımlanmıştır. Bunlar Tabloda görülmektedir.

 

RTCM 3.1 Formatı Ek Mesaj Türleri ve İçerikleri

RTCM 3.1 formatı için Mayıs 2007 ve Ağustos 2007 tarihlerinde iki kez çeşitli mesaj türleri eklenerek geliştirme çalışmaları ilgili özel komite tarafından yapılmıştır. Mayıs 2007 tarihinde yapılan düzenleme ile datum transformasyonu parametreleri ve projeksiyonlar için 1021-1022-1023-1024-1025-1026-1027-1028 mesaj türleri tanımlanmış ve onaylanarak kabul edilmiştir. Ağustos 2007 tarihlerinde onaylanan ikinci düzenleme ile 1030-1031-1032-1033 nolu dört yeni mesaj türü daha ek olarak kabul edilmiştir. 1030 ve 1031 mesaj türleri ağ-RTK uygulamalarında VRS, FKP ve MAC teknikleri için ilave bilgiler tanımlamaktadır. 1032 mesaj türü 1005 ile benzer özellikler taşıyarak, ECEF X,Y,Z olarak referans istasyonu ARP koordinat bilgilerini içerir. 1033 mesaj türü ise 1007 ve 1008 mesaj türlerinin birleştirilmiş şeklidir. Alıcı tanımı ve seri numarası ile anten tanımı ve seri numarası bilgilerini içerir.

                 RTCM 3.0 mesaj grupları, alt grupları, mesaj türleri ve içerikleri

 

                 RTCM 3.1 Ağ-RTK mesaj grupları, alt grupları, mesaj türleri ve içerikleri

                        RTCM 3.1diğer mesaj grupları, alt grupları, mesaj türleri ve içerikleri

 

 

TUSAGA-Aktif Sistemi Düzeltme Parametreleri

Hızla değişen ve gelişen GNSS konsepti ile birlikte, özellikle gerçek zamanlı konum belirleme uygulamaları kapsamında DGNSS ve RTK teknikleri, birçok kullanıcı ve disiplin tarafından ölçme ve navigasyon amaçlı uygulamalar için tercih edilmektedir. Bugün birçok ülkede gerek ulusal, gerekse yerel ölçekte kurulan ağ-RTK yapısındaki GNSS/CORS ağları ile birlikte bu kullanım önemli ölçüde artmıştır.

 

Uygulama çeşitliliği ile birlikte, kullanıcı sayısının da önemli ölçüde arttığı gerçek zamanlı konum belirleme uygulamaları için GNSS verisinin iletimi de belli mekanizmaların kullanımını ve uluslararası standartların oluşumunu sağlamıştır. Bu bağlamda bu çalışmada GNSS verisinin gerçek zamanlı iletimi için kullanılan mekanizmalardan veri formatları, veri iletim protokolleri ve veri iletişim linkleri tartışılmıştır. Özellikle DGNSS ve RTK uygulamaları için standart RTCM veri formatı ve sürümleri üzerinde durulmuş, RTCM 2.x ve RTCM 3.x sürümlerinin mesaj yapısı tartışılmış, verimlilik, bant genişliği ve esneklik bakımından karşılaştırmaları yapılmıştır. RTCM 2.x sürümünün dezavantajlarına karşın yapı, verimlilik ve uyum bakımından daha esnek ve etkili olan RTCM 3.x’ in avantajları ve son gelişmeler üzerinde durulmuştur. NTRIP veri iletim protokolü kısaca açıklanmıştır.

 

Günümüzde GPS ve GLONASS sistemlerinin etkin kullanımının yanında yakın bir gelecekte GALILEO ve COMPASS sistemlerinin devreye girmesiyle gerçek zamanlı GNSS veri iletiminde önemli gelişmeler olacaktır. Bunun yanı sıra RT-PPP tekniğinin de yakın bir gelecekte etkin olarak kullanımının sağlanması beklenmektedir. Varolan RTCM 2.x ve RTCM 3.x sürümlerinin yeni GNSS sinyallerinin kullanımıyla birlikte RTCM SC-104 standartlarında yeni sürümlerin geliştirilmesi beklenmektedir. Ancak RTCM SC-104 formatının kullanım istatistikleri göstermektedir ki, RTCM 2.x hala DGNSS’e dayalı kod ölçüleri için etkin olarak kullanılmakta iken, RTCM 3.x ise RTK servislerinde taşıyıcı faz ölçülerine dayalı uygulamalar için günümüzde yaygın olarak kullanılmaktadır.

 

TUSAGA-Aktif Sistemi Ana kontrol ve yedek kontrol merkezinden VRS CMR+, VRS RTCM3.1, SAPOS FKP 2.3, RTCM3Net (MAC) ve DGPS olmak üzere uluslar arası standartlarda 5 adet düzeltme yayınları yapılmaktadır.

TUSAGA-Aktif Sistemi; RTCM (The Radio Technical Commission for Maritime Services) Komitesi tarafından standartları belirlenen; FKP (Flachen Korrectur Parameter), VRS (Virtual Reference Station) ve MAC (Master Auxiliary) düzeltme bilgilerinin tamamını NTRIP protokolü gereğince yayınlamaktadır. Sistem; FKP düzeltme bilgilerini RTCM 2.3 standardında, VRS düzeltme bilgilerini RTCM 3.1 ve CMR+ standartlarında, MAC düzeltme bilgilerini de RTCM3Net standardında ve DGPS düzeltme bilgilerini RTCM 2.1 standardı ile göndermektedir. 

Yayınlanan düzeltme verileri içeriğinde; FKP ve DGPS yöntemleri sadece GPS, VRS ve MAC yöntemlerinde ise GPS ve GLONASS uydu sinyalleri kullanılmaktadır.

 

  1. FKP Alan Düzeltme Tekniği

Literatürde FKP (Flachen Korrectur Parameter) olarak bilinen alan düzeltme yaklaşımında tüm CORS ağı kullanılarak her bir sabit istasyonda atmosferik düzeltmeler ve/veya taşıyıcı faz düzeltmeleri hesaplanmaktadır. Böylece:

-Düzeltmeler gezici tarafından kullanılabilmektedir (birçok değişik enterpolasyon modelleri ile).

-Çift / tek yönlü iletişim yeterli olmaktadır.

- Kullanıcı sayısında bir sınırlama söz konusu olmamaktadır.

FKP yaklaşık konumu bilinen referans istasyonu ile gezici arasındaki uzaklığa bağlı hata terimlerinin hesabına olanak vermektedir. Burada sadece gezicinin koordinatları ve uydu bilgilerine gereksinim bulunduğundan konum belirlemesi, tüm ağ ile ilgili hesaplardan bağımsız olarak gerçekleştirilebilmektedir. Gezici, ağ düzeltmesini sabit istasyonların birinden alır. Çift yönlü haberleşmede bu istasyonu merkez olarak belirler. Tek yönlü haberleşmede kullanıcı, kendisine yakın olan bir istasyonu kendi seçmek durumunda olduğundan, tek yönlü haberleşme hemen hemen kullanılmamaktadır. Yayın formatı RTCM 2.3 dür.

SAPOS (FKP): (Flachen Korrectur Parameter-Alan düzeltme parametreleri), düzeltme bilgilerini RTCM 2.3 standardında,

 

  1. VRS Tekniği

VRS (Virtual Reference Stations) uygulamasında ön koşul, CORS ağındaki kontrol merkezi ile gezici arasındaki iki yönlü iletişimdir. Gezici, yaklaşık koordinatlarını kontrol merkezine göndermekte ve merkez de tüm ağ bilgilerini kullanarak söz konusu gezici konumu için VRS referans verilerini oluşturmaktadır. Merkezde oluşturulan VRS düzeltmeleri, genellikle RTCM ile geziciye gönderilmektedir. VRS yönteminde tüm ağdan oluşturulan düzeltmeler, gezicinin hemen yakınında oluşan sanal bir referans İstasyonu üzerinden yayınlanmaktadır. Oluşturulan bu sanal istasyon diferansiyel GPS ( DGPS) teknolojisi ile oluşturulmaktadır. Oluşturulan bu sanal istasyondan da double-differenced (çiftli farklar) alınarak düzeltmeler hesaplanabilmektedir. Yayın Formatları CMR+, RTCM 2.3, RTCM 3.0. dür.

 

VRS ve FKP yöntemlerinin avantaj ve dezavantajlarını özetlersek; VRS metodunun avantajı, server’daki tüm ağ bilgisini kullanarak karmaşık iyonosferik ve troposferik modellemeye olanak vermesidir. Buna karşılık, FKP yönteminin “artık iyonosferik etki”yi modellemede çok sınırlı olanakları vardır. FKP yönteminde atmosferik modeli hesaplamak için gezici sadece iki istasyondaki veriyi kullanabilir. VRS yönteminde çift yönlü haberleşme olmasına rağmen, yayın (FKP) formatında ve haberleşme sadece ağdan geziciye doğru tek yönlüdür. Ancak GSM ve GPRS gibi mevcut altyapıyı kullanan çift yönlü haberleşme her zaman tercih edilmektedir. Çift yönlü haberleşmeyle, ek bilgileri de karşılıklı olarak göndermek olanaklıdır.  Ayrıca GSM ve GPRS sisteminin kullanılması faturalama olanaklarını çok basite indirgemektedir. VRS yönteminin diğer bir avantajı ise, yukarıda belirttiğimiz gibi, VRS oluşturma aşamasının her sürecinde uyuşumlu troposferik modelleme yardımı ile, troposferik hataların elimine edilmesidir. FKP yönteminde gezici ve server arasındaki uyuşumlu olmayan troposferik modelleme tehlikesi vardır. VRS yönteminin sıkı sık bahsedilen dezavantajı büyük alanlarda haraket edilerek yapılan RTK çalışmalarında tek bir aramanın yeterli olmayacağıdır. VRS yönteminde ilk aranan yere göre düzeltmeler optimize edilmiştir. Eğer gezici daha sonra kilometrelerce uzağa gitmişse, bu yeni konum için düzeltmeler çok uygun olmayabilir. Ancak bu etki, yukarıda değinildiği gibi gezicinin kilometrelerce uzağa gitmesinden kaynaklanmaktadır. Gezici, bu olası problemi gidermek için (yeniden aramanın dışında) ek bilgiler kullanabilir. Trimble GPSNet server VRS çözümü, özel olarak tasarımlanmış RTCM mesajı 59 ile ek bilgiyi (FKP) göndermektedir. Bu mesaj 59 bilinen bir mesajdır. FKP’ler, VRS gezici konumu için optimize edilmekte ve ağ çözümünden türetilmektedir. Bu şekilde GPSNet’den VRS veri dizisi alan bir gezici, her iki yöntemin avantajlarından da faydalanmaktadır. İlk gezici konumuna göre optimize edilmiş veri dizisini alır; buna ek olarak geliştirilmiş gezici çalışması çerçevesinde yerel etkileri lineer FKP modeli ile düzeltir.

VRS: (Virtual Reference Station-Sanal Referans İstasyonları), düzeltme bilgilerini RTCM 3.1 ve CMR+ 3.1 standartlarında,

 

  1. MAC Düzeltme Tekniği

MAC (Master Auxiliary Concept- Ana Yardımcı İstasyon Yöntemi) RTCM 3.x ağ formatının temelini oluşturan düşünce, bir alt ağ ölçü verilerinin sıkıştırılmış olarak geziciye gönderilmesi ve gezicinin farklı hata kaynakları için kendi ağ hesaplarını yapmasını sağlamaktır. Ancak bunun bir dezavantajı, genellikle ağın sadece bir alt bölümüne ait verilerin gönderiliyor olmasıdır. RTCM 3.0 ağ önerisinin diğer bir dezavantajı ise, sadece belirli bir zamana ait ionosferik ve geometrik hataların gönderilmesidir. Gezici doğrudan server veri dizisini almaya başladığında, sistematik etkilere ait hemen bir bilgi sahibi olamamaktadır. İyonosferik ve özellikle troposferik modellerde, parametrelerin saptanması için zaman gerekmektedir. İyi bir model duyarlığına ulaşmak için 15 dakika veya daha uzun bir zaman gereklidir. Ancak bu süre içerisinde sistematik hatalar gereken güvenli düzeyde modellenebilmektedir. RTCM 3.xağ yöntemi, ağ server’ınde oluşturulan komple filtre durumunu kullandırmamaktadır. Sadece server’da elde edilen belirsizlikleri (ambiguity) kullanmakta ve bunları taşıyıcı faz ölçmelerinden çıkarmaktadır (Carrier Phase). Diğer bir deyişle, MAC tasarımı, ana istasyondaki kod ve taşıyıcı faz verileri ile dış istasyonların taşıyıcı faz verilerini, belirsizlikler önceden ayıklanmak suretiyle gönderecek şekildedir. Bu veriyi alan gezici aşağıdakileri gerçekleştirir:

- Geometrik ve iyonosferik etkilerin basit enterpolasyonu,

- Ağ serverinin ağ bilgilerini RTCM 3.0 ağ önerisi formatına çevirmeden önceki tüm hata kaynaklarını içeren kompleks modele benzer bir model oluşturulması. Ancak RTCM 3.x ağ yöntemi için gerekli band genişliği, VRS ve FKP çözümüne göre çok daha büyüktür. Bir örnek vermek gerekirse, 12 uydunun izlenmesi durumunda VRS metodu RTCM 3.0 için saniyede 2472 bitlik bir band genişliğine gereksinim duyar. Buna karşılık RTCM 3.0 ağ önerisi 8‐ istasyonlu bir ağ için 9661 bit, 32 istasyonluk bir ağ için ise 34712 bitlik bir band genişliği gerektirecektir. Aynı şekilde tüm modellemeler gezicinin üstünde yapıldığından gezicilerin bellek işlemcilerinin güçlü olması da gerekir. Yukarıda belirtilen nedenlerle veri iletişimindeki hacmi küçültmek için CORS ağındaki bir istasyon master ve diğerleri de yardımcı istasyonlar olarak seçilmektedir. MAC, master istasyona ait tüm düzeltme ve koordinatları ile yardımcı istasyonlara ait düzeltme ve koordinat farklarını yayınlamaktadır. MAC yeni bir teknik olmayıp aslında FKP’ye benzerlik arz etmektedir. CORS ağı için belirlenen iyonosferik ve geometrik hatalar ile düzeltmeler, koordinatlar ve farkları, MAC tarafından gezicilere iletilmekte ve gezicilerde de çoklu‐baz hesabı yapılmaktadır.

MAC: (Master Auxiliary Concept-Ana Yardımcı İstasyonlar), düzeltme bilgilerini RTCM 3.1NET standardında yayınlamaktadır.

***Bu bilgilendirme; 31.03.2014 tarihli Makam Oluru ile Harita Dairesi Başkanlığına gönderilen 2014/1480-1 sayılı İç Denetim Raporunun 3 Nolu Bulgusunun bir nolu önerisi gereği yapılmaktadır”