Подскажите в каком документе указана максимально возможная длина обрабатываемого вектора. Искал в руководстве пользователя ТВС 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.
Оффтоп (Move your mouse to the spoiler area to reveal the content) Миша, мне кажется, что не лишним было бы тут напомнить, что 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
Оффтоп (Move your mouse to the spoiler area to reveal the content) Знаю человека, который натурально замутил в этом пакете VRS. Были у меня планы освоить эту штуку, а потом как-то по левому краю проплыло, сидел на grafnet/nav, поддержка TTC прекратилась, и для меня началась эпоха PosPac, где все есть и не надо изобретать велосипед. Хошь сеть любого масштаба (со всеми erp-файлами), PPP, хошь VRS, хошь траверсный ход, кинематика любой частоты с/без ins. А так да, на ттс возлагали надежды..
Точно. TTC – это бывший GeoGenius от Террасат. Потенциально была очень интересной программой, но количество багов в программе просто зашкаливало. Например, теоретически можно было сгенерировать RINEX для виртуальной станции. На практике, ничего не меняя, получались совершенно разные RINEX, если вообще получались. Последнее было чаще. Валера Луповка в своё время на форуме НАВГЕОКОМ подробно описывал свои эксперименты мытарства с этой программой. Меня забавляла оценка точности, выдаваемая программой. Даже для демки короткой линии (десятки метров) выдавала СКО координат прядка нескольких сотых миллиметра. Просто повезло.
В контексте данного топика ещё можно сказать, что кручин (от слова крутить) в программах становится все меньше и меньше. Производитель все больше отстраняет юзера от влияния на работу KF в современных версиях GN/GN (PosGnss), PosPac, Enertial Explorer. Раньше как: оборудование чудило на борту, сидишь, колдуешь, обрабатываешь кусочками, чтобы сохранить работу. Допуски крутишь, окно сглаживания расширяешь, кол-во итераций меняешь. Ща ваще примитивизируют. Не получилось - переделывай. До сих пор храню дистрибутивы софта с 2004 года. И хотя тот софт ГЛОНАСС не кушает, им чертовски кайфово управлять.
