[osm-hu] Fix pontok

[Kolesár András]

Az RTKLIB csúnyán elvérzik, amikor zavaró tényezők miatt nem tud kihozni 
fix megoldást. Emiatt lomb alatt durva hibákkal terhelt zajos nyomvonalat 
ad, míg a u-blox saját RTK megoldása sokkal szebbet. Nem a két frekvencián 
múlik, egy frekvenciás antennával is sokkal jobb az F9P, mint az RTKLIB 
megoldása.

Emiatt sajnos az RTKLIB alapú utófeldolgozás nem tud kihozni olyan jó 
eredményt, mint amit a belső RTK motor hozott volna ki, ha nem lenne lyuk a 
mobilhálózatban. Ezen felül amíg nincs bázisadatod, menet közben nem 
tudhatod, hogy float vagy fix lesz-e a megoldás. Ez baj, mert ha float, 
akkor nem használható arra, amire szánod, hacsak nem fér bele néhány 
deciméteres lötyögés. Ortofotó illesztőponthoz nem jó.

Üdv:
András

2020. május 28., csütörtök 10:10:11 UTC+2 időpontban Gergely Matefi a 
következőt írta:
>
>
> On Wed, May 27, 2020 at 5:22 PM Samat <sam... at gmail.com <javascript:>> 
> wrote:
>
>> On Wed, 27 May 2020 at 16:53, Gergely Matefi <gergel... at gmail.com 
>> <javascript:>> wrote:
>>
>>> Hobbylistámon szerepel, hogy 
>>> átalakítsam utófeldolgozásos "nem-valósidejű kinematikára". Azaz terepen 
>>> naplózni a UBX üzeneteket, és utólag (otthon) korrelálni a 
>>> referenciaállomásokról érkező bázisjelekkel, és helyreállítani a 
>>> nagypontosságú lokációs adatokat. OSM szerkesztésre ez így is tökéletesen 
>>> megfelelne.
>>>
>>
>> Ez jogos. Az utófeldolgozásnak megvan az az előnye is, hogy míg real-time 
>> adatokat küldő bázisból kevés van, addig az órás vagy napi adatokat utólag 
>> letöltésre kínálóból jóval több.
>> Az RTKlib nem jó erre?
>>
>> Samat
>>
>
> Elvben működnie kell majd, az rtklib-ben az rtkpost kifejezetten erre 
> szolgál. Csak össze kell rakni a teljes toolchaint, hogy ne kézzel kelljen 
> mindent. Szeretnék egyszerre valósidejű hagyományos helymeghatározást, és 
> utófeldolgozásos RTK alapú helymeghatározást. Ehhez a kütyü kimenetéről 
> szét kell választani a szöveges formájú NMEA üzeneteket és a binárisan 
> küldött nyersadatokat, letárolni, otthon a korrekciós adatokat 
> összevadászni a webről, adott esetben az optimális bázis automatikus 
> kiválasztásával, időablak egyeztetéssel, szükség szerint kivágással. Aztán 
> toolokat lefuttatni, és valahogy értelmezhetővé tenni, hol mekkora 
> pontosságot sikerült elérni.
>
> És persze kell majd hozzá némi terepi gyakorlat is, mire kell vigyázni, 
> hogy valóban sikerüljön a nyersadatokból nagypontosságú végkimenentet 
> előállítani
>
> Az is elgondolkoztató, hogy mitől stabilabb az F9P belső RTK algoritmusa, 
> mint az M8T külső rtklib-bel. Okozhatja-e ezt a kétfrekvenciás vétel, vagy 
> az rtklib-et is lehetne jobban tuningolni
>
> Üdv,
> Gergő
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20200528/018cbf66/attachment.htm>