GPS Processing в LGO

Тема в разделе "GNSS-измерения", создана пользователем Re-Maker, 15 сен 2009.

Страница 2 из 3
  1. Matador

    Matador Форумчанин

    16 сен 2009 #21
    Оффтоп
    Такое дело техники "пахнет" ст. 146 УК РФ.
     
  2. SergKo

    SergKo Форумчанин

    16 сен 2009 #22
    Оффтоп
    свято чту УК, в отношении Leica - особо... ::rolleyes24.gif:: ::good::

    (Добавление)
     
  3. Re-Maker

    Re-Maker Форумчанин

    16 сен 2009 #23
    Забавно...
    Взгляните на мой screenshot LGO GPS Proc. Там пересечения продолжительностью более двух часов.

    На всякий случай сделал экспорт в Rinex файл по Вашей инструкции, для каждой точки в отдельности. Архив лежит тут (http://www.at-geotech.com/RINEX_rev1.zip)
    (Добавление)
    Кстати, никто так и не прокомментировал на этот счет.
     

    Вложения:

    • GPS_Proc.jpg
      GPS_Proc.jpg
      Размер файла:
      76,4 КБ
      Просмотров:
      654
  4. В.Шуфотинский

    В.Шуфотинский Модератор Команда форума

    16 сен 2009 #24
    Что-то у Вас опять с каталожными координатами какая-то чепуха: 7.47м в плане и 1.37м по высоте – явный перебор. А треугольник померен вполне прилично, так что разбирайтесь с системами координат и если у Вас не отменили секретность, то… В этом случае можно будет что-то сказать.
     
  5. SergKo

    SergKo Форумчанин

    16 сен 2009 #25
    длины линий и превышения ну никак не сходятся.
    замыкание треугольника - ОК, свободное уравнивание - ОК

    +1 разбирайтесь с каталогом и СК

    _cat - каталожные, без суффикса - из наблюдений.
     

    Вложения:

    • screenshot.jpg
      screenshot.jpg
      Размер файла:
      28,2 КБ
      Просмотров:
      813
  6. SergKo

    SergKo Форумчанин

    17 сен 2009 #26
    сори за невнятный комментарий...
    длинА линии между исходными - по каталожным координатам и по вектору не сходятся.
     
  7. unknownuser963

    unknownuser963

    17 сен 2009 #27
    В общем, незнаю актуально ещё или нет, но координаты точек после обработки и уравнивания получаются следующие:

    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

    За высоты не ругайте, все-таки балтийская система и элепсоидальные высоты вещи разные. А в остальном свё красиво получается. Измерения хорошие, даже с перестраховкой.

    Только в следующий раз в названии файлов избегайте точек (.) иначе файлы эфемерид и др. файлы действительно могут быть не опознаны программой.
     
  8. SergKo

    SergKo Форумчанин

    17 сен 2009 #28
    ::dispute:: DAGTASH и SEYIDHEMID, вообще-то, ИСХОДНЫЕ и не должны были бы измениться... ::cool24.gif::
     
  9. В.Шуфотинский

    В.Шуфотинский Модератор Команда форума

    18 сен 2009 #29
    После Вашего поста, задача стала намного актуальнее. Если не для уважаемого 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
     
  10. VLee

    VLee Форумчанин

    22 сен 2009 #30
    При выше озвученной фиксации я получил практически те же результаты

    DAGTASH Опорные 368937.98312 4452704.64623 108.68701
    ISBM-01 Усредненные 367659.06761 4456419.56551 52.12746
    SEYIDHEMID Опорные 365421.26100 4454039.02700 59.10000

    Дальше экспериментировать не стал поскольку согласен с
    В части проверки каталога
     
  11. Re-Maker

    Re-Maker Форумчанин

    23 сен 2009 #31
    В настоящий момент в Интернет доступ ограничен, потому также ограничусь сразу напрашивающимся вопросом: Почему все используя одни и те же замеры и одни и те же каталожные координаты получаются РАЗНЫЕ результаты?
     
  12. SergKo

    SergKo Форумчанин

    23 сен 2009 #32
    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
     
  13. Re-Maker

    Re-Maker Форумчанин

    28 сен 2009 #33
    Какие грубые ошибки?
     
  14. SergKo

    SergKo Форумчанин

    28 сен 2009 #34
    любые. В данном случае - в вашем "каталоге". Какой-то из двух пунктов неправильный. Или оба...
    Проверяйте выписку, проверяйте пересчет 42-UTM...
     
  15. VLee

    VLee Форумчанин

    29 сен 2009 #35
    Доброго дня всем

    Это ошибки эфемерид.

    Вот что пишет 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.
    ....
     
  16. В.Шуфотинский

    В.Шуфотинский Модератор Команда форума

    30 сен 2009 #36
    Уважаемый Re-Maker, в данном случае, это мелкие ошибки, практически не влияющие на результат. У Вас совсем другие проблемы: грубая ошибка в каталожных координатах.
     
  17. Re-Maker

    Re-Maker Форумчанин

    1 окт 2009 #37
    Каталожные координаты мне выдали в соответствующем государственном органе, а пересчет Пулково 42 в UTM 39N я сделал в PHOTOMOD GeoCalculator 4.4. Может я там что напортачил? Но что? Там если даже захотеть ничего испортить нельзя. Если грубая ошибка при пересчете, вряд ли я получил бы координаты в ожидаемой местности, скорее всего "попал" бы в Индийский океан :)
     
  18. SergKo

    SergKo Форумчанин

    1 окт 2009 #38
    тоже люди работают, им свойственно ошибаться. Покажите им результаты свободного уравнивания или просто длину вектора между исходными, не совпадающую НА СЕМЬ МЕТРОВ с расстоянием, вычисленым по каталожным координатам...
    (Добавление)
    Уверены ли вы, что откопали тот пункт, что в каталоге, а не соседний - некогда ненайденый, вместо которого установили и определили новый, в конце концов?...
     
  19. Re-Maker

    Re-Maker Форумчанин

    1 окт 2009 #39
    Уверен. После того, как получил координаты в Pulkovo42, преобразовал их в UTM и вынес в натуру с помощью GPS1200. Таким образом я и нашел оба ГГС.
     
  20. SergKo

    SergKo Форумчанин

    1 окт 2009 #40
    Ищите третий поблизости, получайте координаты, измеряйте вектор хотя бы на определяемый пункт, а лучше и на два первых... ("база" на новом каталожном пункте, объезжаете три старых (два каталожных и определяемый) - тогда хоть будет что с чем сравнить для локализации ошибки...

    И, все-таки, меня по-прежнему смущает пересчет в UTM... Ну ладно, для публикации. Но для себя-то зачем? ввести в контроллер параметры СК-42 и в ней работать проще было бы... не говоря уж о том, что для постобработки вообще безразлично, какая СК выбрана в контроллере - важно, что в ПО обработки...

    А в процессе "выноса" (поиска) насколько точно лейка вам указала пункты?
    Вы искали в режиме RTK или в автономном (как навигатором)?
     
Страница 2 из 3
  1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie.
    Accept Узнать больше.
    Скрыть объявление
  1. Этот сайт использует файлы cookie. Продолжая пользоваться данным сайтом, Вы соглашаетесь на использование нами Ваших файлов cookie.
    Accept Узнать больше.
    Скрыть объявление