Это нигде не документировано и понять в чем проблема можно только изучая хитроумные объектно-ориентированные исходники. Как выясняется <s-distance> обязан быть в паре с <z-angle>, иначе программа его просто проигнорирует (и наоборот) и результаты вычисления будут непредсказуемые. Видно это только по HTML (в конце Rejected observations). Еще одна неочевидная фича это возможность комбинирования для <point> атрибутов fix="xy" adj="z" и подобных комбинаций. Из чтения документации этого не понять.
<description>No unknowns have been defined</description> Пожалуй самое бессмысленное сообщение об ошибке, вместо того чтобы сделать полный дамп внутренного состояния машины с детализацией всех точек, измерений и параметров.
Зенитные углы больше 180 градусов это тоже как-то некошерно, правильный валидатор должен в таких случаях ругаться. Я может туплю поздно по вечерам после работы, но нахрена у <distance> опциональные атрибуты from_dh и to_dh ? В чем тогда фактическая разница с <s-distance>, кроме того, что они в разные классы попадают ?
Ничего подобного. Всего лишь КП. Первое - наклонное, второе - горизонтальное. Или ты хочешь сказать, что атрибуты делают его наклонным?
Да. gama/lib/gnu_gama/xml/gkfparser.cpp Код: S_Distance* d = new S_Distance(ss, sc, dm); d->set_extern(ex); d->set_from_dh(df); d->set_to_dh(dt); standpoint->observation_list.push_back( d ); sigma.push_back(DB_pair(dv, false)); Код: Distance* d = new Distance(ss, sc, dm); d->set_extern(ex); d->set_from_dh(df); d->set_to_dh(dt); standpoint->observation_list.push_back( d ); sigma.push_back(DB_pair(dv, false));
То, что классы одинаковые - кто бы сомневался. А вот как они пользуются... Не буду лукавить, я лишь пролистал немного, ничего не выхватив. Из-за плюсов у меня отвращение к монитору просыпается.
Ещё один пример применения GNU Gama для уравнивания строительной сети на данном форуме: https://geodesist.ru/threads/progra...inejno-uglovyx-setej.72942/page-2#post-992493
А не проще ли использовать XSLT для представления XML GNU Gama в виде строки NGS Blue Book? Чем городить свой парсер? PS: Если бы был конкретный пример, а так, виртуально, мне самому не очень понятен gama-g3.
XML парсер есть в самой Gama, вопрос только в правильном выходном форматировании Observation*. Работаю над "классикой", а с GPS векторами примеры есть. Непонятна еще такая вещь: зачем горизонтальным углам и направлениям from_dh и to_dh ?
На самом деле, если это то, что я думаю, то мне такая модель понятна. Я сам в GNU Octave мудрил системы, в которых углы комбинировались с редукционными элементами. Как ни странно, это очень облегчало саму схему расчёта и согласования элементов (я применял медленный итерационный алгоритм).
Идея мне тоже понятна, но это уже не совсем классическая геодезия и есть сомнения что все реально реализовано (и работает). <z-angle>+<distance> тоже кое-как работает, приближенные высоты вычисляются (при этом вместо <approximate> почему-то попадают в <fixed>!), а дальше из-за невозможности редукции без <s-distance> все <z-angle> отбрасываются (Rejected). Вот такая загогулина.
Ты убиваешь просто. Мне и так не каждый раз удаётся добиться от gama чего то значительного, так ещё и такой откровенный калл. Ты кстати знал, что если определяемым точкам задать "полоумные" приближённые координаты, то на выходе получишь полную бессмысленность?
Нет, но думаю что если поднатужиться, то можно довести программу до ума. --- Сообщения объединены, 8 фев 2021, Оригинальное время сообщения: 8 фев 2021 --- Кому-то интересно в кредо на кнопки нажимать, а кому-то мозгами шевелить
