katastr AT fsv.cvut.cz
Předmět: Katastr nemovitosti a DTM
List archive
- From: "Martin Forejt" <martin AT geus.cz>
- To: "Katastr nemovitosti" <katastr AT fsv.cvut.cz>
- Subject: Re: [Katastr] Metody výpočtu volného stanoviska
- Date: Tue, 26 Apr 2016 19:58:14 +0200
- List-archive: <http://mailman.fsv.cvut.cz/pipermail/katastr>
- List-id: Katastr nemovitosti <katastr.fsv.cvut.cz>
MNČ je obecně definována tak, že "součet čtverců oprav musí mít minimální
hodnotu", tedy i Helmertova transformace je výpočtem založeným na MNČ.
Záleží tedy pouze na tom, na základě jakých podmínek výpočtete odchylky,
třeba právě pro případ, kdy jsou měřeny pouze směry a tedy dojde k "protínání
zpět ze směrů" s nadbytečným počtem měření a díky nadbytečným měřením lze
nějakým způsobem aplikovat MNČ.
Obecně by to mělo být tak. že pokud porovnáte výsledné souřadnice stanoviska
z různých výpočetních metod, měl by být výsledný rozdíl v poloze mezi
různými metodami výpočtu minimální - z hlediska přesnosti KN zanedbatelný. V
dnešní době se pohybujeme v takových podmínkách, že použité měřické metody
jsou o řád přesnější (1 až 2 cm) než požaduje KN (známých 0,14 m), na
výsledné souřadnice volného sanoviska má tedy mnohem větší vliv to, na jaké
body se připojumeme, než použitá metoda výpočtu.
To bude asi i případ Vámi popisovaného rozdílu, kdy asi za připojovací body
sloužily jiné podrobné body a nějaký bod byl poněkud "ulítlý". Jde tedy spíš
o to identifikovat, který připojovací bod způsobil takový rozdíl - při hrubé
chybě opravdu mohou různé výpočetní metody dávat větší rozdíly ve výsledcích.
Ovšem i rozdíl 7 cm v poloze je pořád více méně v intencích přesnosti KN ;-)
Každopádně bych víc věřil metodám MNČ, protože většinou zavádějí do výpočtu
všechna dostupná nadbytečná měření a vazby, které může nějaký přibližný
výpočet pominout. Ovšem Helmertova transformace není přibližným výpočtem,
pokud pomineme, že obecná MNČ metoda může vzít do zpřesnění výpočtu i body,
kde není měřená délka (ale netuším, jak to Vámi zmíněné programu konkrétně
aplikují).
Jako programátora by mne ale docela zajímal takový praktický případ, kdy
došlo k Vámi popisovanému rozdílu a to hlavně z hlediska konfigurace
připojovacích bodů. Pokud byl rozdíl 7 cm v kontrolně vypočtené délce na
orientaci proti změřené, musel být takový i minimální rozdíl mezi oběma
metodami výpočtu v poloze výsledného bodu.
Tedy ostatní délky na ostatní připojovací body musely dávat na druhou stranu
měnší rozdíly - to prostě vychází z definice MNČ - nemohou být všechny
odchylky v kontrolních délkách na všechny orienatce větší - to by opravdu
znamenalo chybný výpočet. Tedy bych to viděl tak, že MNČ metoda na tom jednom
bodu "nechala" větší odchylku, protože byl proti ostatním s nějvětší chybou v
poloze a k ostatním "neseděl".
Nejpravděpodobnější ale je, že připojovácí body měly "nešikovnou"
konfiguraci. Například pokud jsou připojovací body jen na jednu stranu od
stanoviska a třeba ještě v přímce, tedy třeba určované stanovisko je vrcholem
rovnostranného trojúhelníku, kde připojovací body jsou přibližně v přímce na
protilehlé straně, tak bude rozdíl mezi MNČ a Helmertovou transformací
pravděpodobně odpovídat rozdílu mezi podobnostní (se změnou měřítka) a
shodnostní (beze změny měřítka) transformací. V takovém případě dává Vámi
uvedený příklad smysl a může dojít k takovému rozdílu. Ovšem i když dá MNČ
větší rozdíly, tak nejpravděpodobnější správná poloha stanoviska bude spíše
blíže té hodnotě z výpočtu MNČ.
Tedy základem pro takový rozdíl s největší pravděpodobností není zvolený
způsob výpočtu, ale to že připojovací body nemají vhodnou konfiguraci a navíc
jejich poloha má nižší přesnost. Metodu výpočtu volného stanoviska předpisy
pro KN nepřikazují, ale konfiguraci připojovacích bodů myslím ano (ne pro
jedno stanovisko, ale mám pocit, že pro celou zaměřovanou změnu - nejsem
ÚOZI). Tedy bych řekl, že Vámi zmíněný větší rozdíl u metody MNČ správně
poukazuje na to, "že se něco děje", zatímco Helmertova transfomace to nějak
"rozmydlila", že to vypadá skoro OK ;-)
MNČ nemůže být a není metoda zavrženíhodná ;-) Jak vyplývá z výše napsaného,
jakýkoliv algoritmus výpočtu nezachrání špatně zvolenou konfiguraci
připojovacích bodů. Hlavně MNČ funguje samozřejěm tím lépe, čím je více
nadbytečných měření a tím lze snadněji objevit, kde dochází ke ztrátě
přesnosti či k hrubé chybě, případně který připojovací bod má chybně určené
souřadnice a je lepší ho z výpočtu vyřadit. Ideální je pak rozvnou využít
vyrovnání všech stanovisek zakázky v rámci geodetické sítě (v jakkoliv
jednoduché konfiguraci ), tam má obecná metoda MNČ největší přínos, jak pro
přenost, tak pro hledání hrubých chyb.
S přáním hezkého dne Martin Forejt
----- Původní zpráva -----
Odesilatel: Samer <samer AT centrum.cz>
Příjemce: katastr AT fsv.cvut.cz
Datum: 13/04/2016 09:29
Předmět: [Katastr] Metody výpočtu volného stanoviska
Dobrý den,
mám dotaz, který se týká vypočtu volného stanoviska při vyhotovení
geometrického plánu.
Program Kokeš používá při výpočtu vol.stanoviska defaultně vyrovnání MNČ,
tuto volbu ale lze změnit a vybrat transformace (Helmertovou).
Program Groma zase používá MNČ pokud jsou zadané pouze směry, a podobnostní
(či shodnostní) transformace, pokud se zadají i délky.
Naše zkušeností ukazují, že MNČ má větší dopoustné odchylky než transformace.
To znamená, že pokud se zadají v dialogu pro výpočet stejná měřená data
(úhly/délky), tak při použití transformace uvádí program mezní odchylku
měřené délky orientace – například 14 cm, ale při MNČ 21 cm.
Jinými slovy při vypočtu MNČ může určité měření projít bez nahlášení
překročení odchylky, ale při přepnutí na volbu Transformace naskočí hláška o
překročení odchylky.
A já bych se chtěl zeptat, vzhledem k předchozímu, je metoda MNČ
akceptovatelná pro práce v katastru nemovitostí, anebo lze ji klasifikovat
jako nevyhovující respektive zavrženíhodná?
Bunni
_______________________________________________
Katastr mailing list
Katastr AT fsv.cvut.cz
http://mailman.fsv.cvut.cz/mailman/listinfo/katastr
- [Katastr] Metody výpočtu volného stanoviska, Samer, 04/13/2016
- Re: [Katastr] Metody výpočtu volného stanoviska, Martin Forejt, 04/26/2016
Archivace běží na MHonArc 2.6.19+.