GNU Gama

Звездочет сей прислан гидрографическим департаментом поверить астрономические пункты на берегах Каспийского моря, определенные в прошлом году каким-то не совсем дошлым звездочетом. (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 тыркаюсь!

 

Обновил: https://github.com/Geo-Linux-Calculations/adjust/releases

 

Еще нужен пример и конвертер gama2bbook.
Я считал Саблинскую базисную сеть с помощью ADJUST, но такой пример пойдет только как
раскрашенный цветной html на github . Невооруженным глазом читать перфокарты это не для средних умов.
Еще бы SVG картинки грамотно сварганить для мануала GAMA:
азимуты, углы и fs, bs, from_dh, to_dh, left_dh, right_dh - все это без картинок тоже не воспринять.

 

Дай хоть "какой то" пример (ссылку). Будет время - покумекую.

 

Без высот геоида и УОЛ, можно будет сразу сравнить с ручным методом коррелат (как ее изначально и считали).
Буду искать.

 

Раз есть CREDO_DAT, посчитайте заодно и эклектику из этой статьи

--- Сообщения объединены, 23 янв 2021, Оригинальное время сообщения: 23 янв 2021 ---

пдф не захотел присоединяться

 

Туда же:
* 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 года.

--- Сообщения объединены, 24 янв 2021, Оригинальное время сообщения: 24 янв 2021 ---

Рабочие файлы для 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

с официальной откомпилированной версией.

--- Сообщения объединены, 26 янв 2021, Оригинальное время сообщения: 26 янв 2021 ---

Пока 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" вообще не решает.