Оффтоп (Move your mouse to the spoiler area to reveal the content) Такое дело техники "пахнет" ст. 146 УК РФ.
Оффтоп (Move your mouse to the spoiler area to reveal the content) свято чту УК, в отношении Leica - особо... ::good:: (Добавление)
Забавно... Взгляните на мой screenshot LGO GPS Proc. Там пересечения продолжительностью более двух часов. На всякий случай сделал экспорт в Rinex файл по Вашей инструкции, для каждой точки в отдельности. Архив лежит тут (http://www.at-geotech.com/RINEX_rev1.zip) (Добавление) Кстати, никто так и не прокомментировал на этот счет.
Что-то у Вас опять с каталожными координатами какая-то чепуха: 7.47м в плане и 1.37м по высоте – явный перебор. А треугольник померен вполне прилично, так что разбирайтесь с системами координат и если у Вас не отменили секретность, то… В этом случае можно будет что-то сказать.
длины линий и превышения ну никак не сходятся. замыкание треугольника - ОК, свободное уравнивание - ОК +1 разбирайтесь с каталогом и СК _cat - каталожные, без суффикса - из наблюдений.
сори за невнятный комментарий... длинА линии между исходными - по каталожным координатам и по вектору не сходятся.
В общем, незнаю актуально ещё или нет, но координаты точек после обработки и уравнивания получаются следующие: NAME - NORTHING - EASTING - HEIGHT - N - E - HT DAGTASH - 4452711.123 - 368934.414 - 112.248 - 0.0000 - 0.0000 - 0.0107 ISBM-01 - 4456422.541 - 367657.571 - 57.743 - 0.0003 - 0.0002 - 0.0108 SEYIDHEMID - 4454039.068 - 365421.217 - 65.018 - 0.0000 - 0.0000 - 0.0107 За высоты не ругайте, все-таки балтийская система и элепсоидальные высоты вещи разные. А в остальном свё красиво получается. Измерения хорошие, даже с перестраховкой. Только в следующий раз в названии файлов избегайте точек (.) иначе файлы эфемерид и др. файлы действительно могут быть не опознаны программой.
После Вашего поста, задача стала намного актуальнее. Если не для уважаемого Re-Maker, то для меня (и не только!), уж точно. Весьма интересные результаты. Потому и вопросы: 1. В какой программе Вы уравнивали? 2. У Вас уравнялся треугольник при фиксации обоих опорных пунктов? 3. Какая невязка в координатах? 4. Не могли бы Вы привести результаты уравнивания при фиксации одного пункта (по очереди). Вот мои ответы, возможно, Вам будет интересно: 1. «Уравнивал» в «Pinnacle». 2. Типа «уравнялся». 3. Subnet New Network\New Solution : Control Tie Analysis : There are warnings Verifying data Testing fixed points SEYIDHEMID - DAGTASH Distance = 3759 m. Tolerance (horizontal) = 0.00876 m. (e=0.005m., a=1PPM) Tolerance (vertical) = 0.01376 m. (e=0.01m., a=1PPM) dPlane = 7.47134m. dPlane(PPM) = 1987.65269 dPlane/T = 853 1:503 dU = 1.36642m. dU(PPM) = 363.51853 dU/T = 99.31 1:2751 dLength = 5.68447m. dLength(PPM) =1512.27776 dLength/T = 648.99 1:661 Кстати, вот результаты свободного уравнивания треугольника: Loop length = 10960 m. Loop misclosure components : NEU dN = 0.0007m. dN/T = 0.04 1:15796425 dE = 0.0065m. dE/T = 0.33 1:1678593 dPlane = 0.0066m. dPlane/T = 0.33 1:1669196 dU = 0.0166m. dU/T = 0.36 1:658532 4. При фиксации DAGTASH: Point Coordinates Sigmas(mm) # Name Northing(m) Easting(m) Ortho H (m) s(N) s(E) s(U) DAGTASH 4452711.164 368934.370 110.000 0 0 0 ISBM-01 4456426.087 367655.457 53.521 1.6 1.4 3.6 SEYIDHEMID 4454045.543 365417.642 60.472 1.4 1.1 3.3 При фиксации SEYIDHEMID: DAGTASH 4452704.647 368937.990 108.631 1.4 1.1 3.3 ISBM-01 4456419.571 367659.070 52.131 1 0.9 2.1 SEYIDHEMID 4454039.027 365421.261 59.100 0 0 0 Ну, и глупость при фиксации обоих пунктов: DAGTASH 4452711.164 368934.370 110.000 0 0 0 ISBM-01 4456426.087 367655.457 53.521 5258.4 4668.1 12006.5 SEYIDHEMID 4454039.027 365421.261 59.100 0 0 0 Очень интересно узнать алгоритм Ваших действий. (Добавление) Кстати, ещё одна глупость. Если разъединить опорные (отключить вектор DAGTASH-SEYIDHEMID), то результаты «уравнивания» будут следующими: DAGTASH 4452711.164 368934.370 110.000 0 0 0 ISBM-01 4456421.395 367658.206 52.052 2200.7 1890.8 4635.7 SEYIDHEMID 4454039.027 365421.261 59.100 0 0 0
При выше озвученной фиксации я получил практически те же результаты DAGTASH Опорные 368937.98312 4452704.64623 108.68701 ISBM-01 Усредненные 367659.06761 4456419.56551 52.12746 SEYIDHEMID Опорные 365421.26100 4454039.02700 59.10000 Дальше экспериментировать не стал поскольку согласен с В части проверки каталога
В настоящий момент в Интернет доступ ограничен, потому также ограничусь сразу напрашивающимся вопросом: Почему все используя одни и те же замеры и одни и те же каталожные координаты получаются РАЗНЫЕ результаты?
Re-Maker, не фиксируя каталожных, при свободном уравнивании треугольника - у всех все ПРАКТИЧЕСКИ (оговариваю что не до мм) одинаково. Почему разные? Ну так программы-то разные... И о разных рез-тах при фиксации двух пунктов и вовсе говорить не приходится, поскольку на грубые ошибки, разное ПО (да и одно ПО при разных методах уравнивания) отреагирует по-разному. Ну не должно их быть!... До уравнивания после обработки векторов: DAGTASH 4452700.515 368940.166 108.139 ISBM-01 4456415.445 367661.249 51.482 SEYIDHEMID 4454034.899 365423.438 58.229 Ничего не фиксировано, свободное уравнивание: DAGTASH 4452700.519 368940.165 108.148 ISBM-01 4456415.441 367661.250 51.473 SEYIDHEMID 4454034.899 365423.439 58.227 С зафиксированым SEYIDHEMID до уравнивания: DAGTASH 4452704.646 368937.990 108.138 ISBM-01 4456419.570 367659.071 51.481 SEYIDHEMID 4454039.027 365421.261 59.100 После уравнивания: DAGTASH 4452704.648 368937.987 108.147 ISBM-01 4456419.570 367659.072 51.475 SEYIDHEMID 4454039.027 365421.261 59.100 PS. Trimble Geomatics Office 1.63 PPS. Coordinate System Coordinate System : UTM Zone : 39 North Datum : WGS 1984 Ellipsoid Name : World Geodetic System 1984 Geoid Model : EGM96 (Global) Site : Not selected Ellipsoid Ellipsoid Name : World Geodetic System 1984 Flattening 1/f : 298.257 Semi Major Axis : 6378137.000m Поперечная проекция Меркатора Projection Projection Origin False Origin Latitude : 0°00'00.00000"СFalse Northing : 0.000m Longitude : 51°00'00.00000"ВFalse Easting : 500000.000m Height : N/A False Elevation : N/A Scale Factor : 0.99960000
любые. В данном случае - в вашем "каталоге". Какой-то из двух пунктов неправильный. Или оба... Проверяйте выписку, проверяйте пересчет 42-UTM...
Доброго дня всем Это ошибки эфемерид. Вот что пишет LGO v7.0 RUS Error Orbit: Недоп. эфемериды для выч. коорд. ИСЗ R02 между 11/09/09 09:59:45 и 11/09/09 10:29:45. Error Orbit: Недоп. эфемериды для выч. коорд. ИСЗ R03 между 11/09/09 06:29:45 и 11/09/09 06:59:45. Error Orbit: Недоп. эфемериды для выч. коорд. ИСЗ R07 между 11/09/09 05:29:45 и 11/09/09 05:59:45. Error Orbit: Недоп. эфемериды для выч. коорд. ИСЗ R08 между 11/09/09 06:59:45 и 11/09/09 07:29:45. Error Orbit: Недоп. эфемериды для выч. коорд. ИСЗ R13 между 11/09/09 06:29:45 и 11/09/09 06:59:45. Error Orbit: Недоп. эфемериды для выч. коорд. ИСЗ R21 между 11/09/09 09:59:45 и 11/09/09 10:29:45. ....
Уважаемый Re-Maker, в данном случае, это мелкие ошибки, практически не влияющие на результат. У Вас совсем другие проблемы: грубая ошибка в каталожных координатах.
Каталожные координаты мне выдали в соответствующем государственном органе, а пересчет Пулково 42 в UTM 39N я сделал в PHOTOMOD GeoCalculator 4.4. Может я там что напортачил? Но что? Там если даже захотеть ничего испортить нельзя. Если грубая ошибка при пересчете, вряд ли я получил бы координаты в ожидаемой местности, скорее всего "попал" бы в Индийский океан :)
тоже люди работают, им свойственно ошибаться. Покажите им результаты свободного уравнивания или просто длину вектора между исходными, не совпадающую НА СЕМЬ МЕТРОВ с расстоянием, вычисленым по каталожным координатам... (Добавление) Уверены ли вы, что откопали тот пункт, что в каталоге, а не соседний - некогда ненайденый, вместо которого установили и определили новый, в конце концов?...
Уверен. После того, как получил координаты в Pulkovo42, преобразовал их в UTM и вынес в натуру с помощью GPS1200. Таким образом я и нашел оба ГГС.
Ищите третий поблизости, получайте координаты, измеряйте вектор хотя бы на определяемый пункт, а лучше и на два первых... ("база" на новом каталожном пункте, объезжаете три старых (два каталожных и определяемый) - тогда хоть будет что с чем сравнить для локализации ошибки... И, все-таки, меня по-прежнему смущает пересчет в UTM... Ну ладно, для публикации. Но для себя-то зачем? ввести в контроллер параметры СК-42 и в ней работать проще было бы... не говоря уж о том, что для постобработки вообще безразлично, какая СК выбрана в контроллере - важно, что в ПО обработки... А в процессе "выноса" (поиска) насколько точно лейка вам указала пункты? Вы искали в режиме RTK или в автономном (как навигатором)?
