Максимальная длина вектора в ТВС

Подскажите в каком документе указана максимально возможная длина обрабатываемого вектора. Искал в руководстве пользователя ТВС 3.60, но ничего не нашёл. В руководстве ТГО указано что не более 2000км (при использовании точных эфемерид). Но ТГО и ТВС два разных продукта (юридически), поэтому нужен официальный документ для TBC, для заказчика.
Если не трудно, укажите источник и нужную страницу. Спасибо.

 

Для чего заказчку вообще эти данные (просто цифра). Надеюсь пользователь отчётливо понимает то что, максимальная длинна в бумажке не означает того что запихнув любые данные в ТБЦ он получает любой результат и больше ни за что не отвечает, помохав у заказчика руководством перед носом (инструкция разрешает же). Возможно этих ограничений нет в ТБЦ, может Михаил подаскажет. Я максимально 1500 обрабатывал или около того.

 

Заказчики китайцы. Вязали сеть от пунктов IGS. Расстояние не больше 300км. Заказчик утверждает что векторы больше 150км надо считать в Бернес или аналогичных. Чтобы не переделывать, нужно ткнуть заказчиков в офф. документ.

 

В тго было ограничение тоесть он физически не считал вектора 2000 км и более, поэтому это указали в руководстве, вроде всё логично.
Если в ТБЦ нет этих ограничений, то как это указать в характеристиках да и какой в этом смысл если нет специальных ограничений, разрешено всё что не запрещено. Заказчик пусть докажет что этой программой нельзя обрабатывать вектора в 2000 км, или любую другую цифру на выбор.
И если обрабатывали не дальше 300 км, почему интересует цифра именно в 2000 км? Если интерполировать эти требования, то предоставив эти данные, заказчик может сказать а дайте бумажку на 3000 км, и так пока вы по его требованию не обсчитаете в бернесе))))))))))
Если не оговорено в договоре в каком ПО обрабатывать, то пусть сами доказывают что нельзя в ТБЦ, есть результат и его можно проверить (а то нельзя и всё докажите что можно, бред) тем же бернесом, вопрос вроде как из пальца достали.

 

Число "2000" в ТГО стояло в настройках обработки по-умолчанию и могло быть изменено. Вообще-то допустимость и разумность использования "длинных" векторов определяется предрасчетом точности и требованиями "ТЗ" (Инструкций), а не возможностями программ!

 

Для обсуждения обработки длинных векторов есть отдельная тема. Вектор в 300 км от пункта IGS это нормально. Отвечайте пожалуйста по теме.

 

По теме спросите Михаила Караванова, может он вкурсе.
Но я думаю что таких данных нет.

 

До боли жутко знакомая проблема...

Заказчик, конечно, имеет полное право утверждать что-либо исходя из личных умозаключений...
Но все-таки как он поясняет свои требования?
На основании каких документов? (хотя в таком случае часто ответ "я точно знаю что надо так" )

Кстати, вы так и ни слова не сказали о требованиях к точности результатов!

Советы будут просты и легко реализуемы:

• Надеюсь ваши измерения были нормальной продолжительности (для 300км больше 4ч) включая GPS+ГЛОНАСС и при обработке использовались точные (хотя бы rapid) эфемериды.
• Сделайте планирование сеансов для каждого вектора (именно вектора, а не станции, т.е. в планировщике учитываются координаты обеих станций на концах вектора)
  • Выведите графики PDOP и кол-ва спутников, что докажет возможность проведения измерений (надеюсь сами-то вы это сделали на этапе проектирования сети и планирования полевых работ
• Надеюсь измерения были продолжительными (для 300км больше 4ч) и при обработке использовались точные (хотя бы rapid) эфемериды.
• Надеюсь так же, что при привязке использовалось несколько станций IGS (>3), тогда при уравнивании расфиксируйте ближайшую и сравните ее координаты, полученные через вашу станцию, с каталожными по SOPAC на конкретную дату. Если всё ОК, то результаты в отчет. Если нет - у вас проблема.
• Обработайте файл измерений на вашей базе по PPP (продолжительность сеанса НЕ МЕНЕЕ 2ч)
  • Ищите приятеля с GrafNav или нечто подобным
  • Отправьте на сервис обработки (AUSLIG например)
  • Если всё ОК, то результаты в отчет. Если нет - у вас проблема.
• Напишите служебную записку, что если уж в старинном Trimble Geomatics Office было ограничение в 2000км, то уж в наисовременнейшем супер-пупер Trimble Business Center явно всё будет еще круче (ну типа почти здоровьем клянитесь ) и для него 300км ваще тьфу (что так и есть при соблюдении первой ремарки).

Из личного опыта:

• в середине 90-х в древнем Trimble GPSurvey обрабатывали суточные сеансы (только по GPS) Москва-Красноярск - разлет 24 векторов (по 2 в месяц за год) составил всего 12см
• лет 5-6 назад нерадивые сотрудники хорошего клиента случайно про...ли утеряли CD с сырыми измерениями на базовых станциях в регионе, где ни при каких условиях нельзя было повторить измерения (аэросъемочные залеты). Пришлось в GrafNav привязывать траекторию от шести станций IGS (ближайшая 1'380км). Но потом случилось чудо и CD с базами нашелся. Разница в координатах центров от 4 локальных баз (самая дальняя 50км от траектории) составила максимум 3см (три)!
• Наконец, почитайте достаточно старую, но вполне актуальную для вас статью Static Baseline Accuracies as a Function of Baseline Length, Observation Time and the Effect of using the Precise Ephemeris может она вас натолкнет на дополнительные соображения.

 

Максимально в tbc считались вектора до 4500 км, делал сеть в Танзании и подвязывался к пунктам - International GNSS Service (IGS) в Индии и к Мальдивам. Дату брали по 8-12 часов с 15-30 секундным интервалом, точные финальные эфемериды забирал по мере их появления(через неделю примерно).Приборы были R-8 and GR-3.
Базовые станции по 24 часа, забирал с - http://sopac.ucsd.edu/index.shtml, там же и точные координаты на соответствующую эпоху.Затем те же файлы отправлял в OPUS или Canadian Spatial Reference System (CSRS) Precise Point Positioning (PPP).Результаты полученные в TBC и результаты присланные после обработки как правило в пределах 2-5 см. Результаты приходят в форматах UTM and WGS84(географические). Высота всегда еллипсоидальная, соответственно надо затем работать с моделью геоида EGM2008-1".Как правило после предоставленных отчетов у заказчиков претензий не возникало.

 

Андрей, у меня нет официальных данных от Trimble, в которых бы была явно указана максимальная длина обрабатываемого в TBC вектора. Скорее всего таких документов нет.
В личной переписке мне когда-то была указана цифра 1000 км в качестве максимальной длины, для которой TBC получает фиксированное решение. Но я встречал проекты TBC и с длинами 2000 км fixed, которые были прекрасно согласованы с результатами Bernese и других методов.
(Возможно, tmn72 захочет поделиться информацией по этому поводу)

Согласен с Геннадием по вопросу использования бесплатных программ на основе PPP-алгоритма. Думаю, близость решений от PPP сервисов и от пунктов IGS в TBC должны убедить самых придирчивых заказчиков. Напомню, что помимо OPUS, CSRS и пр. есть еще сервис Trimble RTX-PP (www.trimblertx.com) предназначенный для обработки данных от приемников Trimble.

 

Spoiler

Миша, мне кажется, что не лишним было бы тут напомнить, что fixed в TBC это совсем не тот fixed, что был раньше. И введён он был исключительно для отчётности. Т.к. многие инструкции (там, а не здесь) требуют fixed решения.
Ты это можешь объяснить гораздо лучше, чем я.
В TGO при решении длинных векторов требовалось ручками положить нужные файлы параметров ориентации Земли (*.erp) в определённую папочку. Я практически не обрабатывал измерения в TBC, поэтому могу и ошибаться. Но я не помню, чтобы для обработки в TBC требовались файлы *.erp.

 

Андрей Мороз, на оф. бумажки не натыкался. Но если автоматически подгружать автоматически IGS, то в программе стоит ограничение в 30 миль (48 км). Ограничение можно обойти, но намёк Тримбла понятен :)

 

Новые данные по максимальным длинам базовых линий в TBC
http://trimble.club/tbc-fiksiruiet-bazovyie-linii-do-6000-km/

Теперь новый процессор (с TBC вер 4.00) помимо файлов точных эфемерид подгружает файлы параметров вращения Земли *.ERP и файлы дифференциальных кодовых смещений *.BSX

 

Еще одна статья с описанием возможностей нового процессора TBC

 

А точно в TGO? Может в Trimble Total Control?
Вроде в нем рекомендовалось считать длинные вектора.

 

Spoiler

Знаю человека, который натурально замутил в этом пакете VRS. Были у меня планы освоить эту штуку, а потом как-то по левому краю проплыло, сидел на grafnet/nav, поддержка TTC прекратилась, и для меня началась эпоха PosPac, где все есть и не надо изобретать велосипед. Хошь сеть любого масштаба (со всеми erp-файлами), PPP, хошь VRS, хошь траверсный ход, кинематика любой частоты с/без ins. А так да, на ттс возлагали надежды..

 

Точно. TTC – это бывший GeoGenius от Террасат.

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

Просто повезло.

 

В контексте данного топика ещё можно сказать, что кручин (от слова крутить) в программах становится все меньше и меньше. Производитель все больше отстраняет юзера от влияния на работу KF в современных версиях GN/GN (PosGnss), PosPac, Enertial Explorer. Раньше как: оборудование чудило на борту, сидишь, колдуешь, обрабатываешь кусочками, чтобы сохранить работу. Допуски крутишь, окно сглаживания расширяешь, кол-во итераций меняешь. Ща ваще примитивизируют. Не получилось - переделывай. До сих пор храню дистрибутивы софта с 2004 года. И хотя тот софт ГЛОНАСС не кушает, им чертовски кайфово управлять.