Режим проектирования. Как правильно учитывать СКО измерений на малых расстояниях?

Часто выполняем исполнительные съёмки ж/б колонн на небольших по размерам перекрытиях. Ориентирование делаем обратной засечкой от заранее закрепленных в плите дюбелей.
Вот и решил оценить точность засечек по двум часто применяемым схемам.
Файл с примером прилагаю.
2612-2615 - опорные дюбеля;
1 и 2 - станции.
Каково же было моё удивление, когда СКО положения п.1 оказалось меньше, чем для п.2!
Ведь в засечке на станции 1 пункт 2614 расположен на расстоянии менее 2м. Честно говоря, я был уверен, что измерение на него вообще мало что дает.
Однако, СКО п.1 с учётом измерения на п.2614 получается 0,3мм, а без учёта - 1,9мм. Причём, что интересно, размер эллипса растёт в поперечном направлении по отношению к линии 1 - 2614.
Думаю, это происходит из-за того, что программа "думает", что я выполнил измерение на п.2614 с угловой точностью 3". В реальности (на таких микроплечах) это далеко не так из-за ошибок установки прибора и целей.
Попытался в классах точности задать ошибки центрирования - результат нулевой. Действительно, в справке указано:
"Расчет допустимых расхождений линейных измерений, которые выполнены два или более раз, выполняется с учетом настроек опций Ошибки центрирования инструмента и Ошибка центрирования цели, м (Геодезическая библиотека/Классы точности/ вкладка Плановые сети)."
В настройках инструмента опция "допуски в зависимости от расстояний" тоже, видимо, не влияет на расчёты в режиме проектирования.
Как же всё-таки правильно учесть ошибки центрирования на малых плечах и их влияние на ошибки угловых и линейных измерений? Быть может следует вручную создать несколько классов точности в зависимости от длин измеряемых направлений?

P. S. Пара сопутствующих вопросов:
1) Для наглядности вставил в проект подложку - план расположения колонн. Изначально это чертеж dwg. Насколько я понял, Кредо не делает импорт чертежей в dwg. Пришлось делать png через виртуальный принтер. Чтобы достигнуть более-менее приемлимого качества растра, пришлось раздуть разрешение до 4000х5000 пикселей. В итоге файл gds4 стал весить 80мб!
Зато после архивирования - всего 160 кб. Интересно, кто скачает проект, скажите: он у вас открылся с подложкой?
Возможно, есть более цивилизованный путь формирования подложки из dwg?
2) Правильно ли я понял, что в режиме проектирования назначать измерениям длины и углы можно "с потолка"? Главное, чтоб измерение было обозначено?
Будут ли в режиме проектирования учитываться измерения полным приёмом? несколькими приёмами? В смысле, будут ли эти данные влиять на величину эллипсов?

 

в режиме проектирования надо делать так.

Правильно поняли

С подложкой. Кредовские проекты очень хорошо сжимаются.

Будут

 

Тогда давайте попробуем определиться как это правильно реализовать.
Разобъём длины плеч на диапазоны (как в настройках инструмента):
от 0 до 2м; 2-4м; 4-6м; 6-8м; 8-10м; 10-15м; 15-20м; 20-30м.
Рассмотрим 1-й диапазон (0-2м).
Ошибку центрирования прибора (лазерный отвес) примем 1мм, ценрирования цели (мини-призма Лейка) - 2мм. Ошибкой наведения на цель пренебрегаем.
Как оценить суммарное влияние двух ошибок на углы и расстояния? Видимо, придется вспомнить молодость и засесть за учебники))) Или подскажете?

 

Извиняюсь, кажется я прогнал порожняк: если речь об обратной засечке, то какая же тут ошибка центрирования прибора? Стало быть остается только ошибка центрирования цели.
Влияние на угол на расстоянии до 2м можно упрощенно оценить так:
arctg(e/l)=arctg(0,002/2)=206"
Тогда влиянием угловой СКО прибора можно пренебречь в виду относительной малости - 3".
Аналогичный расчёт можно проделать для остальных диапазонов расстояний.
СКО дальномера можно сложить с ошибкой цели: 1+2=3мм.

Вот такие черновые соображения. Что скажете? Буду рад, если ткнете носом в формулы более строгого расчёта.

 

А с нолями не напутал ? Многовато что то 3.5 минуты. У меня 3.5 секунды получилось. или 0.0000174532925181711 радиан.

 

Не думаю.
arctg(0,001)=0,0573градуса
Умножаем на 3600 секунд в одном градусе и получаем 206".

Кажется, вспомнил (или только кажется... в нете сейчас некогда рыться). Формула суммарного влияния ошибок:
m² = m₁² + m₂² +...+ m_n²
Если так, то получим следующее:

 

=ГРАДУСЫ(ATAN(РАДИАНЫ(0.002/2))) а так не ?
по моему в екселе надо внутри формулы еще переводить. Щас потренируюсь на кошках синусах.
З.Ы. Точно надо

tan α= (ΔY/ΔX)

α = arctan (ΔY/ΔX) не ?

 

vovkaf, в какой версии DAT делаете предрасчёт?

 

Таки-да, шоб я так жил!

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

Ни в коем разе, шоб Вы были здоровы!
Эксель по умолчанию все углы (в том числе обратные тригонометрические функции) считает в радианах.
В Вашей формуле вот присутствует лишнее преобразование в радианы:
=ГРАДУСЫ(ATAN(РАДИАНЫ(0.002/2)))
Оно и вносит сумятицу.

 

vovkaf, А вы с синусами попробуйте. 90 градусов без перевода в радианы синус взять.
Интерееесно

 

Ohr, без обид, но Вы путаете длинное с кислым.
Если Вы напишете =SIN(90), то получите синус 90 радиан. Как я писал выше, по умолчанию (без доп. перевода) все угловые значения Эксель принимает в радианах. Поэтому, если Вы хотите получить синус 90 градусов, то Вам таки придется предварительно перевести их в радианы:
=SIN(РАДИАНЫ(90)) или так: SIN(90*ПИ()/180).
Если же Вы хотите получить значение обратной тригонометрической функции, например арктангенс, то по умолчанию (без доп. переводов) получите значение в радианах.
Ну и на всякий случай напомню, что значения самих тригонометрических функций (тангенс, синус и т. п.) - величины безразмерные.
Теперь вернемся к моему примеру:
0,002/2 - это отношение противолежащего катета (ошибка установки цели) к прилежащему (расстояние до цели), т. е. по определению тангенс угла. Мне нужно узнать сам угол, поэтому я запишу: =ATAN(0,002/2) и получу угол в радианах. Затем его можно перевести в градусы, а затем и в секунды. Окончательно запишем: =3600*ГРАДУСЫ(ATAN(0,002/2))
Вы же написали: РАДИАНЫ(0,002/2). По сути, Эксель это поймет так: перевести в радианы угол 0,001 градусов!

 

А причем тут без обид ? Ок понял.

 

Приятно иметь дело со здравомыслящим и адекватным собеседником (без тени иронии).

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

Ohr, кстати, Вы меня немного просветили. До этого я не знал о существовании в Экселе функций прямого перевода из радианов в градусы и обратно. Пользовался школьными формулами.
Вообще, раз уж мы затронули эту тему, в Экселе для меня лично затруднительно работать с представлением углов в градусах/минутах/секундах. Если, например, нужно внести в таблицу данные в таком виде, то я не вижу другого варианта, кроме как разбивать такие значения на три отдельных ячейки, затем переводить в градусы и десятичные доли, затем в радианы и только затем обрабатывать. А если нужно сделать обратный перевод? Тот ещё геморрой! Может, кто подскажет более короткий путь?
По той же причине, когда мне понадобилось сделать исследование прибора на практическое значение СКО гор. угла, я перевел углы на приборе в грады (гоны) и в таком виде передал в Эксель и обработал. И только лишь окончательный результат перевел обратно в более привычные секунды. Вот так, дёшево и сердито!

 

Никакого геморроя. Пишется за пару минут. Алгоритм придумал то ли я то ли кто то из группы еще в политехе курсе на 2
Если не лень, можно потом "СЦЕПИТЬ"

 

Ohr, спасибо. Алгоритм в принципе ясен. Примерно так и представлял. Мне просто не очень понравилась идея с тремя ячейками. Громоздко, что ли.
А что скажете о другом примере (в приложении)? Там вроде удалось организовать формат ячейки для прямого отображения градусов/минут/секунд.
Непонятно только, как выполнить обратную задачу: ввести в ячейку значение в градусах/минутах/секундах.

 

Прикольно. Сейчас заниматься некогда но можно сделать формулу вычленяющую из ячейки значения после определенных символов, и затем преобразовать так же в градусы и десятичные, и для операций отобразить так же как это сделано тут.
В примере кстати еще функции "direct","gradus","Dist" прописаны.
З.Ы. Смотрю на него и все больше и больше нравится. Функцией реализован дирекционный угол. Удобно не надо с румбами соображать.

 

Все эти функции прописаны макросами VBA. Я в них, увы, не силен. Но решение ОГЗ, по-моему, несложно организовать и штатными функциями Экселя. Меня заинтересовало другое: возможность описания формата ячейки для представления угла в виде градусы/минуты/секунды.
Впрочем, предлагаю, если интересно, перенести обсуждение этой занятной темы в личку, дабы не затереть основную.
Я ведь жду, что придет Дед Мороз (например, ЮС) и окончательно разрулит мои сомнения по поводу правильного проектирования коротких сетей .

 

Надеюсь, что это версия 4.12. Дело в том, что учёт ошибок центрирования появился уже в 4.11 "с копейками", где шёл процесс отладки и в поставку эти версии вроде бы не шли, но вдруг...

Параметры ошибок центрирования задаются для класса измерений. В Вашем проекте класс сети задан "Тахеом. ход", однако для этого класса ошибки центрирования заданы нулевыми:

Кроме того, для учёта ошибок центрирования необходимо поставить "галочку" в "Детальный расчёт точности измерений":

И ещё. Для предварительного расчёта точности сети вовсе не обязательно вводить реальные углы и расстояния. Достаточно ввести любое число там, где предполагается выполнять те или иные измерения (линейные, угловые или и то и другое):

Пример исправленного проекта в приложении.

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

Если задан учёт ошибок центрирования, то, в зависимости от точности центрирования и расстояния программа рассчитывает вероятную ошибку измерения угла и добавляет её к априорной (паспортной) точности прибора. В результате этого все угловые измерения получают разные (индивидуальные) веса.
При уравнивании сети или хода в соответствие с весами происходит распределение поправок. Чем короче расстояние, тем меньше вес угла и тем большая поправка в него. То есть в короткое направление наибольшая поправка, что незначительно отразится на координатах и наоборот, в длинное направление наименьшая поправка, что также в меньшей степени скажется на ошибках расчёта координат.
В результате, при уравнивании ходов с очень разными длинами сторон, учёт ошибок центрирования позволяет распределить поправки более справедливо, что зачастую даёт лучшую оценку сети или хода в целом.

 

Уважаемый ЮС, даже если бы Вы ограничились этим:

, моя благодарность не знала бы границ!

Вот так и знал, что где-то есть хитрая заковыристая птица, которую я не поставил. Ох, и любит Кредо-Диалог расставлять эти галочки, да ещё в самых неожиданных местах.

Оффтоп

ЮС, не хотите сообщить свой номер кошелька вэбмани (или что-то вроде того)? Я бы Вам хоть бутылку коньяка выставил . А что, по объёму ликбеза, который Вы среди меня провели, было бы вполне логично!

Уважаемый X-Y-H, ну почему у нас нет рядом с кнопкой "Нравится" кнопки "Ахр@неть, как нравится!!!"? (Шутка юмора, надеюсь я не нарушил Правила.)

Теперь я, наконец, увидел адекватную оценку точности! Оказалось, что измерение со станции 1 на т.2614, которая расположена на расстоянии <2м, всё-таки даёт хотя бы небольшое уточнение ориентирования (значения СКО 2,6 и 1,9мм соответственно при довер. коэфициенте 1,0). А вот дополнительное (четвертое) измерение со станции 2 на т2613 дает практически не ощутимый прирост точности.

ЮС, осталось уточнить маленькую деталь. Заметил, что теперь программа реагирует как на ошибку центрирования цели, так и ошибку центрирования прибора. Оно, конечно, логично: откуда Кредо может знать, выполняю ли я обратную засечку или ориентирование на задние точки (с центрированием прибора на станции). Но, по моим соображениям, коль скоро в данном случае речь идёт о засечке, то ошибка центрирования явно лишняя. Поэтому я её обнулил. А как быть, если в сети встречаются разные типы ориентирования? Может быть тогда всё-таки логично создать 2 класса точности?