TPLAN - грешки при Tplan

Програмно обезпечаване на Геодезията.
kgmgeo
Мнения: 44
Регистриран на: Пет Дек 28, 2007 3:11 pm

Мнение от kgmgeo »

Не е зле да публикуваш и KOR файла, за да имаме пълната картинка.
Лично аз съм си правил следният много тъп номер (и докато се усетя изхабих много нерви): Когато работиш с локални координати, ако въведеш малки числа за координатите на дадените точки и обърнеш мрежата на юг, или запад, ..... и в един момен е възможно координатите на новите точки да почнат да стават отрицателни и TPLAN-а гърми. :) Виж да не е нещо такова. Щото си работил с локални координати, ТПЛАНА ти казва за отрицателен диагонален елемент, а и почва да гърми от 4-5 точка. Виж кор файла. Възможно е да е това (както казах аз един път брах ядове така :D )
Успех!

Красимир Колев
Мнения: 141
Регистриран на: Пон Ное 23, 2009 8:58 am
Местоположение: София

Мнение от Красимир Колев »

Сложил съм 10000.000,10000.000 Не е от отрицателни координати. Довечера ше пусна КОР файла :)

Красимир Колев
Мнения: 141
Регистриран на: Пон Ное 23, 2009 8:58 am
Местоположение: София

Мнение от Красимир Колев »

Колев забавя, но не забравя ;) Ето координатите, които получих :)

ОБЕКТ:
Par korsys 1970 nzon 9 Xo 0 Yo 0
Номер Клас X Y Клас H Mx My Rxy Mh
пт1 6 10000.000 10000.000 6 500.0000 0.0 0.0 0.000 0.00
пт2 6 10000.000 10017.960 6 499.8477 0.0 0.0 0.000 0.00
пт3 6 10017.271 9998.112 6 501.6119 0.0 0.0 0.000 0.00
пт4 6 10014.917 9995.052 6 500.2766 0.0 0.0 0.000 0.00
пт5 6 10011.586 9995.118 6 500.2011 0.0 0.0 0.000 0.00
пт6 6 10008.799 9993.212 6 500.1672 0.0 0.0 0.000 0.00
пт7 6 10005.084 9999.512 6 500.2176 0.0 0.0 0.000 0.00

dodimitrov
Мнения: 73
Регистриран на: Пет Авг 22, 2008 10:45 am
Местоположение: София

Мнение от dodimitrov »

В този случай наистина не може да се справи с матрицата. Това не е първи пример и проблема не е в данните, нито в схемата: стоим на дадена; ориентираме към дадена; висящ полигон от няколко точки напред; смятаме; к'вото се получи; фърляме; забравяме.
Програмата е написана и оптимизирана да решава безпроблемно големи задачи и сложни конфигурации на измерванията, дори се справя с отделни несвързани звена (отделни мрежи в едно изравнение). Не би следвало да гледаме критично на случаи, които се изчисляват с няколко "палави" движения повече.
Спънката идва от пренасянето/изчисляването на ор. ъгли или т. нар. предварително ъглово изравнение на мрежата. Тази операция в win версията се извършва по строг параметричен начин, а не както в DOS версията итеративно. По този начин се печели страшно много време за обработка, също така има и др. предимства. Дефакто цялата мрежа се изравнява като ъглова - без дължините. Какъв му е точно проблема не мога да кажа точно, защото се появява срвнително рядко, но явно трябва да се знае, че "и това го има в зара".

Дотук темата и коментарите са плява: безобиден проблем, много отговори, светкавично решение... Направи ми впечатление следното нещо, което според мен е много ВАЖНО и доста колеги не му обръщат внимание. Казано е "локална височинна система", а котите са от порядъка на 500м. :!: Това не е локална система. При такива коти корекциите за надм. височина ще са значителни и ще започнат да влияят още от 100-ия метър нататък. Win версията на тплан нанася тези корекции независимо от вида на плановата КС, а не както при DOS - ако не може да нанесе едната не нанася и другата. Локални КС обикновено се ползват за постигане на по-висока точност, но в комбинация с истински коти (и средна надм. вис. >500м) нещата при изравнението леко се изкривяват, ако не се внимава. И вместо да се повиши точността, се случва обратното.
Има, разбира се, възможност да се работи в лок. КС и истински коти. Постига се като се увеличат полуосите на елипсоида със стойност близка до ср. надм. височина на обекта: Редактиране->Параметри на изравнение->Опции->Ho=500(да речем). Работейки в Софийска или 1970г. следва Ho=0, защото корекците за проекция и за надм. вис. са с обр. знак и леко се компенсират, а и те са заложени при опр. на координатите на дадените точки. По темата има какво още да се изяснява, но много се отклоних.
Надявам се да съм бил полезен на автора, въпреки че отдавна сигурно си е решил проблема.

Красимир Колев
Мнения: 141
Регистриран на: Пон Ное 23, 2009 8:58 am
Местоположение: София

Мнение от Красимир Колев »

Благодарско на Митака за обяснението :). Един бърз въпрос към него. В този случай (Локална височинна система и кота на дадена точка 500.00), нанасят ли се корекции за надморска височина ?

dodimitrov
Мнения: 73
Регистриран на: Пет Авг 22, 2008 10:45 am
Местоположение: София

Мнение от dodimitrov »

Бърз отговор: ДА
Но така като гледам разстоянията в мрежата са много малки и корекциите са пренебрежимо малки. Може би след 100-150м ще започне да редуцира видимо.

Rum Tum Tugger
Мнения: 161
Регистриран на: Вто Юни 09, 2009 4:34 pm

Мнение от Rum Tum Tugger »

Аз пък имам следният проблем. Отново съвсем малко ходче. Отново локална мрежа. Вкарвам си dpi то, въвеждам си две точки дадени, както колегата преди това, с координати в зависимост от разстоянието между тях. Плановата мрежа си я смята без проблеми. Давам обновяване на регистъра и на една от точките въвеждам кота. Пускам предварителна обработка на измерванията, предварителна обработка на нивелачна мрежа. Минават. Като пускам параметрично изравнение на нивелачна мрежа обаче забива. Не че не се справям с този проблем, но ми е интересно да чуя мнения, още повече, че пишат специалисти по TPLAN, които са наясно със поведението на системата и очакванията към нея още при програмирането й.

dodimitrov
Мнения: 73
Регистриран на: Пет Авг 22, 2008 10:45 am
Местоположение: София

Мнение от dodimitrov »

Дай да видим данните (*.kor + файл с измервания). Какво точно се случва и защо така. Няма как по друг начин да се даде какъвто и да било адекватен отговор.

Rum Tum Tugger
Мнения: 161
Регистриран на: Вто Юни 09, 2009 4:34 pm

Мнение от Rum Tum Tugger »

Ето, изрових един случай:
Obekt : WYZ2
7 25 3 3 0 1 5 0 5 30 3 5
NT hr HZ V SD
130001 1.615
110005 1.300 47.3743 100.5010 108.821
110009 1.300 78.8663 102.8792 4.404
*

Една станция само. KOR файл не вкарвам. Задавам си ръчно дадените точки. Слагам локална система и примерно за ЛТ1 слагам координати 1000, 1108.82, а за РТ5 1000, 1000. ако изпищи, че има разлика в разстоянията редактирам. Но с плановите изчисления ядове нямам. След тях давам обновяване на регистъра и за РТ9 слагам кота. Предварителна обработка на измерванията, предварителна обработка на нивелачна мрежа минават. Параметрично изравнение обаче забива. Значи пробвах да въвеждам Ho, както си писал по-горе, пак забива. След като задам репера повтарям и плановите изчисления - на ПИНМ пак забива.

Красимир Колев
Мнения: 141
Регистриран на: Пон Ное 23, 2009 8:58 am
Местоположение: София

Мнение от Красимир Колев »

dodimitrov написа:Бърз отговор: ДА
Но така като гледам разстоянията в мрежата са много малки и корекциите са пренебрежимо малки. Може би след 100-150м ще започне да редуцира видимо.
Много благодаря :)

dodimitrov
Мнения: 73
Регистриран на: Пет Авг 22, 2008 10:45 am
Местоположение: София

Мнение от dodimitrov »

Не си разбрал идеята за Ho. Стойността й няма никакво отношение към котите и височинните изчисления. Тази стойност влияе на корекциите за надморска височина на измерените разстояния. Демек ползва се за да се неутрализира тази корекция при локалните планови системи, като същевременно се работи с истински коти.
При твоя проблем решението е ясно. Дори ако си се загледал в резюмето там си пише какво става. Няма свръх измервания в мрежата - няма как да има изравнение. Ако след изпълнение на ПИНМ обновиш регистъра - ще ти напляска котите.
Хубаво е да се чете по-внимателно. Ако програмата не забие, по смисъла на windows, а само спре, то причината задължително я има на екрана или в *.lis файла.

Rum Tum Tugger
Мнения: 161
Регистриран на: Вто Юни 09, 2009 4:34 pm

Мнение от Rum Tum Tugger »

Това ми е ясно, че няма свръх измервания. Затова и предполагах от къде са проблемите. Искаш да кажеш, че ако дам обновяване на регистъра след ПОНМ или ПИНМ ще напляска котите? Е обновяване на регистъра след ПОНМ наистина не ми беше идвало на акъл да пробвам. Аз просто си взимах котите изчислени при ПОНМ и си ги ползвах по-нататък. И някак си... Мисля си, че една програма трябва да има някаква степен на дуракоустойчивост. Не съм програмист, но съобщения за грешка е далеч по-добро от забиване на програмата. Това разбира се е лично мое мнение.

Незнайко1
Мнения: 182
Регистриран на: Пон Май 12, 2008 5:32 pm

Мнение от Незнайко1 »

Ползвай COORD.exe за предварителните обработки, удобно е, ама и то няма контрол на входа това му е недостатък :(
Рано е да закъсняваш, късно е да подраняваш.

Публикувай отговор