Звездочет сей прислан гидрографическим департаментом поверить астрономические пункты на берегах Каспийского моря, определенные в прошлом году каким-то не совсем дошлым звездочетом. (c) В ссылке https://www.ngs.noaa.gov/PC_PROD/ADJUST/adjust_all.zip заменить all на v643: https://www.ngs.noaa.gov/PC_PROD/ADJUST/adjust_v643.zip
Премного! А то ж я в https://geodesist.ru/threads/prostranstvennaja-obratnaja-zasechka.85241/page-2#post-968975 тыркаюсь!
Еще нужен пример и конвертер gama2bbook. Я считал Саблинскую базисную сеть с помощью ADJUST, но такой пример пойдет только как раскрашенный цветной html на github . Невооруженным глазом читать перфокарты это не для средних умов. Еще бы SVG картинки грамотно сварганить для мануала GAMA: азимуты, углы и fs, bs, from_dh, to_dh, left_dh, right_dh - все это без картинок тоже не воспринять.
Без высот геоида и УОЛ, можно будет сразу сравнить с ручным методом коррелат (как ее изначально и считали). Буду искать.
Раз есть CREDO_DAT, посчитайте заодно и эклектику из этой статьи --- Сообщения объединены, , Оригинальное время сообщения: --- пдф не захотел присоединяться
Туда же: * https://www.gsi.ru/art.php?id=94 * http://www.geoprofi.ru/Services/Doc...fd831ae?True&usg=AOvVaw2KJOOQgphXFTgbhFdwlCAP Вопрос только где найти "Материалы для триангуляции первого класса в европейской части СССР. Приложение к II части LXXIII тома записок Корпуса военных топографов. М., 1924."?
https://search.rsl.ru/ru/record/01008848276 Очень редкая книга с очень интересной и непростой историей, я как-то тут на форуме про нее писал. Обратите внимание, что по каталогу РГБ она называется "в европейской России", а вот как ее название перевирали и переправляли советские библиографы - это отдельная песня. Все измеренные горизонтальные углы базисной сети я тоже тут уже выкладывал, а вот с азимутами в статье наврано совершенно безбожно, часть ИГД взята из системы 1910 года и смешана с системой 1932 года. --- Сообщения объединены, , Оригинальное время сообщения: --- Рабочие файлы для ADJUST, созданы вручную, возможны ошибки. Сможет ли gama-g3 получить те же результаты - покажет время.
Посмотрел "sablino1910_bbook.txt". Да уж, "bbook2gama" ещё можно попробовать намутить, а вот за "gama2bbook" даже браться не буду.
Забыл сказать спасибу за тестовые данные. Я тут правку в код внёс (gfortran на размер массива взбрыкнул), а проверить было не на чем. Результаты идентичны. Спасибу.
С 1910 годом справились. Теперь если поменять в afile ИГД 1910 года Код: CA00040005 13654499500001 CC 0001 --- 59461534900N030192477850E0000000E на 1932 год (Саблино B=59°35'40.36"N, L=30°46'52.33"E, азимут Саблино-Бугры A=317°02'50.62) то получится и 1932 год (углы-то естественно никто заново не переизмерял!) Далее можно вычислить координаты Гаусса-Крюгера (с центральным пулковским меридианом) и скормить это gama-local и CREDO_DAT. Далее надо отказаться от редуцированной длины базиса Саблино-Бугры 12676.38206 метра добавив высоты концов и дать ADJUST самостоятельно сделать редукцию исходной измеренной длины. Я пока так и не понял как сделать то же самое в gama-g3, не вычисляя заодно и саму исходную нивелировку по 500 пролетам :) Хороший ответ будет тем кто считает что альтернативы КРЕДО нет.
Модифицировал ADJUST под чтение файла-проекта. Теперь не надо каждый раз вводить все имена файлов, достаточно указать файл-проект при запуске: Код: adjust sablino1910.ADJUST Да, дока пока плачет. Не могу до конца разобраться, что происходит с именами файлов внутри "шарманки".
Входной namelist для ADJUST, положите все 3 файла в 1 папку и если у вас линукс то запуcкайте так Код: adjust < sablino1910_ADJUST.txt или Код: wine adjust.exe < sablino1910_ADJUST.txt с официальной откомпилированной версией. --- Сообщения объединены, , Оригинальное время сообщения: --- Пока gama-g3 в недоделанной стадии именно этот конвертер и нужен для валидации. Его же всегда можно будет использовать и как backend с вебсервисом, еще туда и EGM2008 для полей <geoid> присобачить (при эллипсоиде GRS80/WGS84).
Определенное непонимание возникло у меня о связи XML элементов <dh> и пары <distance>+<z-angle> в gama-local. Отдельно нивелировка adj="z" и уравнивание в плане adj="xy" работают на ура, а вот попытка объединить их в единый adj="xyz" путем замены <dh> на соответствующую пару <distance>+<z-angle> проваливается. Единственный имеющийся пример для gama-local с <z-angle> использует его совместно с <s-distance>, но меня интеренсует именно комбинация с <distance>.
Выложи. Надо пощупать. Тема интересная. Мы явно чего то не понимаем. PS: Когда я поставил adj="xyz" с <s-distance> у меня тоже расчёт пошёл в разнос.
Еще раз перечитал мануал на MOVE3 и заодно ADJUST по причине отсутствия внятного руководства для gama-local. У MOVE3 есть таблица, в каких случаях автоматически выбирается 1D, 2D или 3D варианты уравнивания. Вообще, по идее, логической разницы между adj="xyz" и gama-g3 быть не должно но фактически они в gama очень разные. В gama-g3 для "классики" (то есть без GPS векторов) обязательно должны быть заданы приближенные координаты всех вычисляемых точек (как и в ADJUST), что делает ее применение практически обоснованным только для 1 класса, а adj="xyz" в gama-local должна по недокументированной внутренней логике разбиваться на совместную adj="z" и adj="xy". Вот эта логика как раз и не очевидна. В примере <s-distance>+<z-angle> преобразуется в <distance> и <dh>, я и предположил что и из <z-angle>+<distance> обязан получиться <dh>, но похоже это не так. Надо изучать запутанные исходники.
Мне логика тоже это подсказывала. Но на самом деле всё не так. Корректировки в расстояния при "xyz" я никаким образом объяснить не смог. PS: Как выгадаю время, обязательно займусь сравнением результатов "xy" и "xyz".
GNU Gama - программа для кнопкодавов. Заменил элемент <distance> на <s-distance>=<distance>/sin(<z-angle>) и все заработало! Как будто не было времен когда <s-distance> измерить было невозможно.
Это понятно. Но непонятно, почему это проблема для GNU Gama. Такой навороченный парсер, что в него даже ненавистный мне тип 'auto' ввели на каком то там релизе, решает чорт пойми что, и тут бац, на пустом месте! Продолжаю сравнение "xy" vs "xyz" на простейших примерах. Результат пока не радует. Некоторые задачи с <s-distance> в режиме "xy" вообще не решает.
