Не е зле да публикуваш и KOR файла, за да имаме пълната картинка.
Лично аз съм си правил следният много тъп номер (и докато се усетя изхабих много нерви): Когато работиш с локални координати, ако въведеш малки числа за координатите на дадените точки и обърнеш мрежата на юг, или запад, ..... и в един момен е възможно координатите на новите точки да почнат да стават отрицателни и TPLAN-а гърми. Виж да не е нещо такова. Щото си работил с локални координати, ТПЛАНА ти казва за отрицателен диагонален елемент, а и почва да гърми от 4-5 точка. Виж кор файла. Възможно е да е това (както казах аз един път брах ядове така )
Успех!
TPLAN - грешки при Tplan
-
- Мнения: 141
- Регистриран на: Пон Ное 23, 2009 8:58 am
- Местоположение: София
-
- Мнения: 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
ОБЕКТ:
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
-
- Мнения: 73
- Регистриран на: Пет Авг 22, 2008 10:45 am
- Местоположение: София
В този случай наистина не може да се справи с матрицата. Това не е първи пример и проблема не е в данните, нито в схемата: стоим на дадена; ориентираме към дадена; висящ полигон от няколко точки напред; смятаме; к'вото се получи; фърляме; забравяме.
Програмата е написана и оптимизирана да решава безпроблемно големи задачи и сложни конфигурации на измерванията, дори се справя с отделни несвързани звена (отделни мрежи в едно изравнение). Не би следвало да гледаме критично на случаи, които се изчисляват с няколко "палави" движения повече.
Спънката идва от пренасянето/изчисляването на ор. ъгли или т. нар. предварително ъглово изравнение на мрежата. Тази операция в win версията се извършва по строг параметричен начин, а не както в DOS версията итеративно. По този начин се печели страшно много време за обработка, също така има и др. предимства. Дефакто цялата мрежа се изравнява като ъглова - без дължините. Какъв му е точно проблема не мога да кажа точно, защото се появява срвнително рядко, но явно трябва да се знае, че "и това го има в зара".
Дотук темата и коментарите са плява: безобиден проблем, много отговори, светкавично решение... Направи ми впечатление следното нещо, което според мен е много ВАЖНО и доста колеги не му обръщат внимание. Казано е "локална височинна система", а котите са от порядъка на 500м. Това не е локална система. При такива коти корекциите за надм. височина ще са значителни и ще започнат да влияят още от 100-ия метър нататък. Win версията на тплан нанася тези корекции независимо от вида на плановата КС, а не както при DOS - ако не може да нанесе едната не нанася и другата. Локални КС обикновено се ползват за постигане на по-висока точност, но в комбинация с истински коти (и средна надм. вис. >500м) нещата при изравнението леко се изкривяват, ако не се внимава. И вместо да се повиши точността, се случва обратното.
Има, разбира се, възможност да се работи в лок. КС и истински коти. Постига се като се увеличат полуосите на елипсоида със стойност близка до ср. надм. височина на обекта: Редактиране->Параметри на изравнение->Опции->Ho=500(да речем). Работейки в Софийска или 1970г. следва Ho=0, защото корекците за проекция и за надм. вис. са с обр. знак и леко се компенсират, а и те са заложени при опр. на координатите на дадените точки. По темата има какво още да се изяснява, но много се отклоних.
Надявам се да съм бил полезен на автора, въпреки че отдавна сигурно си е решил проблема.
Програмата е написана и оптимизирана да решава безпроблемно големи задачи и сложни конфигурации на измерванията, дори се справя с отделни несвързани звена (отделни мрежи в едно изравнение). Не би следвало да гледаме критично на случаи, които се изчисляват с няколко "палави" движения повече.
Спънката идва от пренасянето/изчисляването на ор. ъгли или т. нар. предварително ъглово изравнение на мрежата. Тази операция в win версията се извършва по строг параметричен начин, а не както в DOS версията итеративно. По този начин се печели страшно много време за обработка, също така има и др. предимства. Дефакто цялата мрежа се изравнява като ъглова - без дължините. Какъв му е точно проблема не мога да кажа точно, защото се появява срвнително рядко, но явно трябва да се знае, че "и това го има в зара".
Дотук темата и коментарите са плява: безобиден проблем, много отговори, светкавично решение... Направи ми впечатление следното нещо, което според мен е много ВАЖНО и доста колеги не му обръщат внимание. Казано е "локална височинна система", а котите са от порядъка на 500м. Това не е локална система. При такива коти корекциите за надм. височина ще са значителни и ще започнат да влияят още от 100-ия метър нататък. Win версията на тплан нанася тези корекции независимо от вида на плановата КС, а не както при DOS - ако не може да нанесе едната не нанася и другата. Локални КС обикновено се ползват за постигане на по-висока точност, но в комбинация с истински коти (и средна надм. вис. >500м) нещата при изравнението леко се изкривяват, ако не се внимава. И вместо да се повиши точността, се случва обратното.
Има, разбира се, възможност да се работи в лок. КС и истински коти. Постига се като се увеличат полуосите на елипсоида със стойност близка до ср. надм. височина на обекта: Редактиране->Параметри на изравнение->Опции->Ho=500(да речем). Работейки в Софийска или 1970г. следва Ho=0, защото корекците за проекция и за надм. вис. са с обр. знак и леко се компенсират, а и те са заложени при опр. на координатите на дадените точки. По темата има какво още да се изяснява, но много се отклоних.
Надявам се да съм бил полезен на автора, въпреки че отдавна сигурно си е решил проблема.
-
- Мнения: 141
- Регистриран на: Пон Ное 23, 2009 8:58 am
- Местоположение: София
-
- Мнения: 73
- Регистриран на: Пет Авг 22, 2008 10:45 am
- Местоположение: София
-
- Мнения: 161
- Регистриран на: Вто Юни 09, 2009 4:34 pm
Аз пък имам следният проблем. Отново съвсем малко ходче. Отново локална мрежа. Вкарвам си dpi то, въвеждам си две точки дадени, както колегата преди това, с координати в зависимост от разстоянието между тях. Плановата мрежа си я смята без проблеми. Давам обновяване на регистъра и на една от точките въвеждам кота. Пускам предварителна обработка на измерванията, предварителна обработка на нивелачна мрежа. Минават. Като пускам параметрично изравнение на нивелачна мрежа обаче забива. Не че не се справям с този проблем, но ми е интересно да чуя мнения, още повече, че пишат специалисти по TPLAN, които са наясно със поведението на системата и очакванията към нея още при програмирането й.
-
- Мнения: 73
- Регистриран на: Пет Авг 22, 2008 10:45 am
- Местоположение: София
-
- Мнения: 161
- Регистриран на: Вто Юни 09, 2009 4:34 pm
Ето, изрових един случай:
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, както си писал по-горе, пак забива. След като задам репера повтарям и плановите изчисления - на ПИНМ пак забива.
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
- Местоположение: София
-
- Мнения: 73
- Регистриран на: Пет Авг 22, 2008 10:45 am
- Местоположение: София
Не си разбрал идеята за Ho. Стойността й няма никакво отношение към котите и височинните изчисления. Тази стойност влияе на корекциите за надморска височина на измерените разстояния. Демек ползва се за да се неутрализира тази корекция при локалните планови системи, като същевременно се работи с истински коти.
При твоя проблем решението е ясно. Дори ако си се загледал в резюмето там си пише какво става. Няма свръх измервания в мрежата - няма как да има изравнение. Ако след изпълнение на ПИНМ обновиш регистъра - ще ти напляска котите.
Хубаво е да се чете по-внимателно. Ако програмата не забие, по смисъла на windows, а само спре, то причината задължително я има на екрана или в *.lis файла.
При твоя проблем решението е ясно. Дори ако си се загледал в резюмето там си пише какво става. Няма свръх измервания в мрежата - няма как да има изравнение. Ако след изпълнение на ПИНМ обновиш регистъра - ще ти напляска котите.
Хубаво е да се чете по-внимателно. Ако програмата не забие, по смисъла на windows, а само спре, то причината задължително я има на екрана или в *.lis файла.
-
- Мнения: 161
- Регистриран на: Вто Юни 09, 2009 4:34 pm
Това ми е ясно, че няма свръх измервания. Затова и предполагах от къде са проблемите. Искаш да кажеш, че ако дам обновяване на регистъра след ПОНМ или ПИНМ ще напляска котите? Е обновяване на регистъра след ПОНМ наистина не ми беше идвало на акъл да пробвам. Аз просто си взимах котите изчислени при ПОНМ и си ги ползвах по-нататък. И някак си... Мисля си, че една програма трябва да има някаква степен на дуракоустойчивост. Не съм програмист, но съобщения за грешка е далеч по-добро от забиване на програмата. Това разбира се е лично мое мнение.