Установки координат базы и настройки проекции в SurvCE_V4

Установки координат базы и настройки проекции в SurvCE_V4

Меню установок пользовательской сетки (проекции) Grid описано на стр.48

  1. Выбираем Add User Defined.

  2. В нем заводим имя новой проекции. Не знаю насколько чувствительно ПО SurvCE_V4 к кириллице, на всякий случай будет нелишним избегать идентификации родным алфавитом и служебными символами. Так оно надежнее сохранится и работать будет.

  3. Дав имя нужной проекции выберите её тип = Transverse Mercator, (не в обиду Гауссу с Крюгером).

  4. Далее введите New Datum в котором аккуратно перепишите значения семи параметров СК42 (если МСК на ней) или СК95 (если МСК на ней).

  5. Завершив создание своего датума, возвращайтесь в меню проекции. Там Вам Датум будет уже доступен из-под кнопки Load File. Выбираете его.

  6. Остается только заполнить параметры начал топоцентрики МСК.

  7. Здесь они представлены в последовательности «задом наперед».

  8. Сначала масштаб длин на осевом меридиане (Scale Factor).

  9. Партия нас учит, что метр на осевом меридиане в МСК равен эталону, поэтому вводим 1.

  10. За поведение длины метра в проекции вне осевого меридиана, равноугольная проекция и правящая партия ответственности не несут.

  11. C. Meridian (Осевой меридиан) вводим в градусах и минутах, либо в долях градуса, это зависит от установок Units, которые мы утверждаем в более ранних меню Job. Не пробовал на Карлсоне, но в продвинутых ПО к которым я отношу Global Mapper, создатели позаботились о том, что программа сама различает тип вводимых данных, по типам разделителей. Если десятичная точка после градусов, то значит вводятся доли, если пробел или буква какая, то следом идут минуты.

  12. Смещения начал Восточное и Северное, нужно ввести в метрах, с долями в соответствующие поля: False Easting и False Northing.

Вот, собственно, и вся нехитрая наука.

К сожалению, отсутствие самого железа с установленным ПО SurvCE_V4 не позволяет мне
расписать функционал меню Add Predefined.

Предположение:

Смею предположить, что это весьма полезный импорт ранее описанных проекций или списка, который удобнее заранее создать на ПО для персональных компьютеров, с целью экспорта Карлсону вместо варенья. Оставляю факультатив расширения возможностей настроек коллекций МСК для продвинутых пользователей ПО SurvCE_V4.

Они наверняка подскажут форматы файлов импорта, которые съедобны Карлсону.

Поскольку, в тексте этой камасутры, часто встречается ссылка на общеизвестный и популярный в мире, не отягощенным обязательным «Пилорамным» ГИС окультуриванием, продукт ESRI ArC GIS, то формат описания пользовательских проекций в виде текстовых файлов *.prj, наверняка доступен в импорте.

Если мое предположение окажется верным, а проверить его можно только испытав кнопку Add Predefined в дальнейших диалогах. То при способности SurvCE_V4 принимать файлы описания проекций в формате *.prj, я готов выслать практически полную коллекцию (за малым исключением) всех МСК, всея Руси, всем желающим того.


Далее, собранная и установленная, таким «стремительным домкратом», проекция становится доступной Вам в остальных меню, где требуется явно указать её.

Это встречается и в меню установок координат базовой станции

Меню установок (конфигурации) базы

представлено на стр. 147.

Выбор способа задать координаты базовой станции по вашему предпочтению.

По Enter Grid System coordinates, вводите тип проекции (User Grid) по присвоенному вами идентификатору и координаты базы в МСК.

Либо Выбираете координаты в Lat/lon в wgs84 полученные обратным преобразованием из Grid (Которое становится возможным теперь и в калькуляторе.)

Высоты

Во внятном и доступном разуму самих создателей ПО, нет ничего проще импорта популярной модели геоида одного из мировых общеупотребительных форматов, и далее все манипуляции с ним для получения отметки в нужной системе высот сводятся к тривиальному выбору Ортометрической системы.

Можно получить решение и в проекции на эллипсоидальных высотах соответствующего референц-элипсоида , после чего пересчитать высоту с него на ортометрическую.

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

Для начала на стр. 120 нам сообщают, что

мол, сами мы не местные, и файлы геоидов такие огромные, что храним их не в контроллере, а в отдельном сухом прохладном месте. Откуда нужная часть будет извлечена и доставлена в вычислительные процессы согласно куску данных пригодного для широты и долготы Вашего объекта съемок.

Не шибко верится в два утверждения. Первое о том, что память современных гаджетов неспособна всосать 30-40 Мб геоида в распространенных форматах. Второе, что «автоматически» система связи с сервером сама вырежет нужную часть данных и вовремя прикуздрячет к RTK решению.

Кто в это верит, может работать и так.

Для более привередливых юзеров, к которым я себя причисляю, есть настройки импорта и манипуляций с геоидами.

Этому посвящены страницы 187-193

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

Я не знаю, того кому, изложенная вышеприведенным образом, методика реализации простой формулы и принципа см. рис. ниже:

покажется разумной и рациональной в исполнении автора данного раздела? Если такая категория граждан в нашей специальности есть, то у нее должны быть железные нервы.

Что до моих личных предпочтений, то я бы держал подальше «великих ученых» от написания практических рекомендаций и разработки пользовательского софта производственных задач.

А при возможности выбора полевого ПО, купил бы данную версию SurvCE_V4 исключительно в качестве альтернативы смертной казни.

Раздел настроек и использования геоидов в получении ортметрических высот в ПО SurvCE_V4 являет собой ярчайший пример того, как НЕ НАДО создавать ПО и описаний.

На том и ограничу свои исследования профпригодности этой камасутры (заслуженно названной так по прочтении раздела Geoids).

1 лайк

Спасибо большое, прочитал. Согласен с Вами в характеристиках данного ПО, но оно достаточно дешево и как правило предустанавливается на недорогие контролеры к недорогим (китайским или российским) сборкам приемников.

Это ПО позволяет делать достаточно тривиальные операции например установить приемник и запустить его как базовую станцию. Однако оно не позволяет установить координаты базовой станции в МСК, поправки с которой получаем допустим через HIVE. Таким образом я не могу использовать поправки с Hive допустим для выноса точек. Да и для обработки съемки приходится такие танцы с бубном плясать, что мама не горюй!

1 лайк

Я не знаю на каком еще языке следует писать про установки МСК.
Потратил на Вас и Карлсона полдня, расписывая, где делаются установки “User Grid”, чтобы в качестве резюме увидеть:

Сергей, не обижайтесь! Но как раз в этом и состоял мой вопрос. Может я немного не правильно выразился.

Объясню на примере. Я использую ровер, который получает поправки с базовой станции Hive. В ровере у меня установлена МСК. А координаты базовой станции HIVE допустим определены WGS84. Естественно, что координаты этой базовой станции в МСК не соответствуют координатам этой станции определенным в МСК от пунктов ГГС. В итоге я получаю съемку, смещенную на сколько то метров (в Московской области от 6 м). Тот скриншот, где показано установка координат базовой станции соответствует той ситуации, когда имеется два приемника-базовый и роверный, Базовый приемник МНОЮ устанавливается на известной точке (пункт ГГС, например), к нему подключается контролер, в котором запускается программа установки базовой станции. Устанавливаются известные координаты базовой станции. Затем контролер отключается, а базовая станция начинает вещать поправки.

А вот в ситуации, описанной выше с постоянно действующими базовыми станциями, ПО не позволяет задать в РОВЕРЕ координаты базовой станции, с которой ровер получает поправки. А вообще есть такое ПО?

Topsurv от Topcon позволял потом (после съемки) задать координаты БС и пересчитать по ним съемку. Что в принципе тоже не подходит для выноса точек, но значительно упрощает постобработку.

Александр, слово "обижайтесь" приберегите для иных...

Александр, слово “обижайтесь” приберегите для иных, манипулируемого разума человеческих организмов. На форуме геодезистов и ученых, это излюбленный прием - уводить рака за камень, переводя дискуссию в область чувственных оценок.

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

В качестве упражнения для досуга попробуйте такое занятие: Вы просите кого-нибудь Вас обидеть. И подбираете этому действию глагол русского языка. Можете экспериментировать, хоть двести лет. Результат скажу заранее. Любому действию есть название, отличное от слова “обидеть”. А это значит, что понятие обиды живет исключительно в мозгу желающего так воспринимать мир иных действий. И его право считать это обидой или нет.

В обидах нет никакой выгоды. Древним китайцам принадлежит истина: обидеться, значит выпить яду, за своего врага, и ждать как он от этого умрет.

Можете поверить, я не считаю такой метод решения проблем рациональным. И Вам не советую. А тех кто вводит в дискуссию понятия : “Обид, оскорблений, унижений, давления и т.п.” я считаю хитровыдуманными манипуляторами сознания, действующими вместо аргументов, иными способами достижения превосходства, аналогичными по неприличию переходу на личностные характеристики (а еще лысый и в очках).


Теперь о деле.

Исправлять результаты измерений в RTK путем установки других координат базы уже в камералке - это на мой взгляд бессмысленное использование режима RTK.

Решения в реальном времени и имеют пользу только тогда, когда они в нем и требуются. И единственное оправданное применение этой технологии - вынос проектных решений “в натуру”, как учила классическая геодезия, или “на местности”, как требуют сегодняшние толерастические инновации.

Во всех остальных съемочных режимах никакого выигрыша RTK перед постпроцессингом нет. Те же секунды на съемку точки в stop-n-go PP дают тот же результат по точности, при отсутствии необходимости контролировать качество приема поправки, которое порой занимает более минуты ожидания её.

Если же после RTK решений требуется еще чего-то двигать (базу или всю съемку, что равноценно), то за время этих манипуляций нет никаких проблем посчитать всю съемку заново в РР.

Мне непонятна логика компаний и организмов, готовых:

  • платить дороже за RTK опции и комплекты оборудования;
  • тратить больше времени на точке наблюдений, ловя поправку, в условиях нашего нестабильного GSM;
  • готовых ограничивать себя в удалении от базовой станции, считая невозможной работу за 100 или 200 км (что не соответствует действительности),
  • быть привязанными к манипуляциям с контроллером, который в ясный день слеп, в дождь бесполезен, а в мороз практически не работает, когда при съемке в PP контроллер вообще не нужен (обучил этому не одну сотню топографов)
    и весь этот набор неудобств, только ради одного сомнительного удовольствия - видеть на экране цифры координат и RMS решения “прямо щас” в поле.

А нужны они в 99% случаев в сухом и теплом помещении, в котором данные измерений собираются в отчеты, сводки, топопланы, описания границ, профили, модели рельефа и пр. Спрашивается зачем делать сложным то, что достигается более простым и комфортным способом?

Ну если нравятся “тяготы и лишения” профессии, как неотъемлемая часть, продолжайте использовать RTK вместо PP “при круге право и при круге лево”. У богатых свои причуды. А вкусы - категория еще более не определенная чем обиды.


Вашу потребность установок базы в нужной МСК я уже описал и показал в каких меню это делается. Повторю еще раз.

  1. Чтобы пользовательская проекция появилась в Вашем списке User Grid для использования её в любом месте (и для ровера, и для базы, и для ГИС форматов представления данных) её нужно туда прописать.

    Как это делается расписано на стр. 49 и в пошаговой инструкции которую собрали модераторы этой дискуссии (см. выше).

  2. Когда проекция есть, Вы можете её указать при выборе координат Базы.( стр. 147)

    Установить координаты базы можно двумя способами:
    а) в МСК, как user grid из списка
    б) в WGS 84, по пересчитанным из User GRID параметрам.

    Во втором случае никаких смещений базы на 6 метров не произойдет.

Вот и всё.

Откуда у Вас осталась уверенность, что установки базы Вам неподвластны, моему разуму не под силу.


Если вы пользуетесь доставкой поправки Вам по NTRIP а не прямому доступу к базе, то координаты базы нужно ввести в установках NTRIP, надеюсь с этой работой Вы способны справиться самостоятельно. Ведь моя задача была показать Вам, как настраиваются параметры МСК в Surve Карлсона, а вовсе не вести бесплатные курсы освоения контроллера. Обратитесь с этим к тем, кто Вам это железо продал. Свою часть я считаю исполненной.

Сергей, осевой меридиан при настройке системы координат в SurvCE вводится исключительно в формате ГГ.ггггггггг, независимо от выбранных параметров угловых единиц. Это не всегда удобно, но иного способа SurvCE не предлагает.

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

Привет судебным экспертам.
Да, напрямую в SurvCE нельзя задать местоположение недоступной для нас базы. Однако, зная уравненную координату базы (и соблюдая другие условия, об этом ниже), можно произвести локализацию по одной точке - по базе. В поле, перед съёмкой или выносом в натуру, это занимает буквально 1 минуту.

Отдельно обращаю внимание, что такая локализация будет корректна только в случае известных и настроенных в проекте параметров системы координат (т.е. датум + проекция), действительных для конкретного района работ и учитывающих особенности местной геодезической сети.

Кроме того, параметры системы координат должны соответствовать тем, которые использовались при уравнивании координат базы.

В SurvCE такой возможности нет. Т.е., конечно (Вы и сами об этом пишете), координаты можно задать при настройке (из того же проекта) базового приёмника, но если мы настраиваем только ровер, то в “установках NTRIP” ничего подобного не имеется.

2 лайка

Честно говоря, думал, что простые решения не требуют разъяснений, но в этом случае видимо придется с нуля таблицу умножения рассматривать с доказательствами.

Допустим, Вы работаете в RTK по NTRIP от координат базы, которая Вас не устраивает, по каким-либо соображениям (Дана в координатах отличных от МСК, согласующихся с ближайшими ГГС). В чем проблема?

Если Вы установили параметры МСК в контроллере (или ПО постпроцессинга) , как пользовательскую проекцию GRID, то полученные Вами решения от “кривых” координат базы, в случае равноточных ГНСС решений, будут ВСЕ смещены на одну и ту же величину в плане и по высоте. Оговорюсь, еще раз. Равноточными я бы считал измерения в одинаковых условиях видимости неба, а не удалении от базовой станции. Для точности ГНСС определений куда хуже наличие стены, забора или дома рядом с определяемой точкой, чем разница в длинах векторов до базы в 100 км. Длина менее критична в решении. Если вы знаете насколько база в плане или по высоте смещена установками NTRIP относительно её положения от ближних пунктов ГГС или точек, прежних определений этого региона, которым (такое тоже бывает) доверия больше чем к пунктам ГГС, то ничто не мешает ввести эти offsets одинаковыми для всех решений. Иными словами осуществить параллельный перенос всех решений на величину разностей. В результате Вы получите то, что было бы решениями от фиксированной базы с более подходящими координатами. Если Вам в поле координаты непосредственно не нужны, общий сдвиг решений можно сделать в любой ГИС. В ПО постпроцессинга (некоторых, которые мне ведомы) есть диалоги ввода смещений в каждую точку для всех видов определений, статику, кинематику и стоп-гоу. Если Вы работаете в задаче выноса проекта на местности, то смещения можно задать в ПО контроллеров, двумя способами:

  • ввести offsets в соответствующие поля антенны,

или

  • сместить начала пользовательской проекции GRID (False northing, easting) на величины обратные выявленным разностям.

И будет Вам счастье.

1 лайк

Сергей, нисколько не оспаривая предложенный метод, всё-таки замечу, что тема посвящена полевому ПО Carlson SurvCE.

Ввести поправку в высоту антенны в данном ПО проблемы не составит: опытным путём установлено, что для этого можно использовать пункт в настройках антенны, именуемый “SHMP домер” (знаю, что в описании некоторого другого ПО аббревиатура “SHMP” означает точку измерения наклонной высоты).

А вот задать отдельно смещения МСК, не вмешиваясь в настройки основной проекции (как это реализовано, например, в Magnet Field), в SurvCE можно только постфактум, выполнив пункт “Трансформация” из меню “COGO”, что не подходит в случае необходимости получения локализованных координат в реальном времени. Строго говоря, “Трансформация” - в трактовке SurvCE - не является, конечно же, инструментом преобразования параметров проекции, а только позволяет пересчитать полученные ранее координаты, но я упоминаю её из-за схожего механизма пересчёта (можно сдвинуть координаты на величины разностей между “кривым” и уравненным местоположением базы). Иная функция, подобная “Исп. Проекц./ МСК” (название из локализованной версии Magnet Field), позволяющая задать смещения в реальном времени дополнительно к основной проекции, в SurvCE отсутствует.

Поэтому роль параллельных смещений по трём осям выполняет в реальном времени, как уже было сказано, локализация по одной точке - по базе. Кроме того, метод локализации исключает, во-первых, ошибки ручного ввода смещений или false northing/easting (в SurvCE мы имеем возможность сохранить “кривые” координаты недоступной базы как точку в “сырых” данных, а уравненные координаты базы можно импортировать из файла, создаваемого в ПО постобработки); во-вторых, в SurvCE при локализации “с нуля” устраняется ситуация, когда хозяин базы (недоступной для нас) меняет, по каким-либо причинам, её координаты (я не имею в виду физический перенос фазового центра антенны).

Хоть это и не по теме вопроса, но добавлю, что в Magnet Field, дополнительно к функции “Исп. Проекц./ МСК”, есть возможность сдвинуть координаты базы также путём её (базы) калибровки; правда, в нашем случае сделать это сложнее, чем в SurvCE, из-за невозможности сохранения координат фазового центра антенны недоступной базы в виде точки (“кривые” координаты недоступной базы видны на дисплее при просмотре сырых данных, но переписывать и впоследствии вводить их в проект придётся вручную).

Вносить же изменения в параметры, условно говоря, утверждённой проекции МСК, считаю недопустимым с точки зрения повышения вероятности ошибок из-за вышеназванных и иных причин. Полагаю, координаты базы - частный случай, требующий частного, а не общего, подхода. В свою очередь, параметры проекции (и ИГД, хотя речь сейчас не о них) должны соответствовать району работ, а не какой-то “кривой” базе. Это личное мнение, основанное на собственной практике, и я его никому не навязываю.

1 лайк

Небольшое дополнение к своему предыдущему посту.
Дабы избежать ненужных разъяснений со стороны внимательных читателей форума, отмечу, что мне, несомненно, известна возможность создавать, сохранять и загружать пользовательские проекции в SurvCE и другом подобном ПО. В контексте вопроса о способах корректировки базы это означает, что можно создать проекцию с уникальными параметрами под конкретную станцию.

Тем не менее, полагаю, что:

  1. принудительное изменение МСК-координат станции (в нашем случае - недоступной) должно производиться предназначенными для этого инструментами, каковым в SurvCE является локализация;
  2. изменение с этой же целью базовых параметров проекции, действительных для определённого района работ, допустимо только в случае отсутствия в используемом ПО иной возможности корректировки местоположения базы (что для профессионального ПО маловероятно).

Игорь Борисович, в моей рекомендации нет ни слова о методе локализации (калибровки).
Если Вы им пользуетесь в качестве основного инструмента связи систем, то Вам глубоко фиолетовы координаты базы. Называйте их "кривыми ", “косыми” или “картавыми”, локализация от них никак не зависит.

Если Вы внимательно читали мой посыл, то видели, что он рекомендован в дополнение к методу Пользовательской GRID.

Если Вы используя рекомендованные параметры Grid MSK (map basic) и координаты базовой станции, которая прописана в NTRIP mount point. То есть шансы, что на пункте ГГС в данном регионе, с известными координатами МСК, вы получите разности теории и практики.

Вопрос был в том, как компенсировать эту разность, если нет возможности изменить координаты базы.

Я пояснил, что в этом случае возможны два решения:
либо компенсировать сдвиг координат шифтами (shifts by topocentric axis);
либо сдвинуть начала МСК для данного региона, как более соответствующего ГГС.

Не понимаю в чем проблема создавать десяток систем, лучшим образом удовлетворяющих соответствию.

Если это Ваши собственные наработки, кто Вам это может запретить?

Оценить это предостережение можно только формулой Жириновского: На этот счет у меня есть собственное мнение, с которым я категорически не согласен.

В чем проблема назвать пользовательскую GRID “МСК50_1_восток”, например, если там Вы сами выявили сдвиги которые лучше посадят ГНСС измерения на ГГС?.

И кто обязывает Вас за это отчитываться, как Вы этого достигли? Для геонадзора и Росреестра нет никакой практической пользы в том, если Вы выявите искажения координат каталогов ГГС, и оцените их. За это памятник не поставят при жизни. А скинуться на веночек дрогой могут. Пока что наша сегодняшняя геодезия устроена по принципу ПОДГОНА ГНСС в существующие каталоги, можно двигать любые начала СК и МСК, лишь бы оно “сидело” и сдавалось.

Изо всего Вашего потока мыслей я бы закрепил одно практичное умозаключение:

Именно так. Остальное - надуманные проблемы.

Summary

Сергей, я, как относительный новичок в GNSS (и просто как человек), не могу не относиться с уважением к знаниям и опыту других специалистов, к коим относитесь, несомненно, и Вы. Учусь до сих пор, узнавая что-то новое для себя в том числе из Ваших ответов на этом форуме.

Однако Вы, в контексте названия темы, неверно поняли не только вопрос топикстартера, но и мои посты. Кто-то (но не я) даже может подумать, что Вы в данной, конкретной теме вообще ничего не поняли. Причина непонимания мне известна, но она к SurvCE никакого отношения не имеет и поэтому обсуждению здесь не подлежит.

Надеюсь, что тот, кто хотел получить ответ на вопрос топикстартера, получил его. Впрочем, на других ресурсах всё это уже обсуждалось неоднократно.

Я не берусь обсуждать Ваши ощущения, на тему того, что я понял, а что не поняли Вы.

Тема обсуждения - Установки координат базы в проекции. Понятие проекция возникает тогда, когда Вы используете её параметры, задавая: Датум тип и начала отсчета топоцентрики. Никакого отношения методы “локализации” или “калибровки” к пользовательским проекциям не имеют.

В большинстве ПО до недавнего времени, топоцентрические координаты, результата локализации по 4м-5ти пунктам с геодезическими выводились вообще в Косой Стереографической проекции. Узнать об этом можно было только из детальной переписки с создателями ПО. О том, что Косая Стереографическая и равноугольная поперечно-цилиндрическая проекции не одно и то же по искажениям длин и углов, можно получив небольшое образование в области мат. картографии. И те, что это вовремя понял, перестали пользоваться локализацией, если объект съемки или изысканий более стройплощадки площадью в 10 кв км. Если объект шире , то в ваших “локализованных” решениях либо метр вычисленный не равен метру измеренному, при идеальном соответствии пунктам ГГС, либо решения взаимно согласуются с метрической системой, но тогда вылезает несоответствие координатам основы. Регулируется это в установках локализации стратегией применения масштаба длин на освевом меридиане. Мало кто из пользователей режима локализации задумывался о смысле этой фишки в установках. Чаще давили на кнопку - менять масштаб длин, и радовались идеальному соответствию ГНСС измерений координатам МСК ГГС. Чего на самом деле быть не должно.

Просто вся проблема таких определений в том, что завтра в этой же местности, другой “народный умелец” запузырит локализацию от других доступных ему пунктов, километров за десять-двадцать, и получим то, из за чего не “сидят” хорошие измерения разных эпох и исполнителей. Координаты другой калибровки в том же месте съедут на неопределнную величину.

В своей практике я встречал “разлеты” тестируемых координат решений до трех метров от двух разных локализаций. У одного из коллег, работавшего в приморском городе протяженностью более 60 км вдоль побережья было пять калибровок, локализованных для каждой части города. И не дай бог применить соседнюю чуть в сторону от её определения.

Во избежание этой идиотской практики применения всеми кому захотелось ГНССсить без должных знаний, я стараюсь на страницах этого форума призвать коллег отказаться от локализации, как вредного и бесконтрольного средства геодезических работ, оставляющего пагубное наследие в бездумном её применении.

Решением проблемы использования проекций (пользовательских GRID) при неизвестном качестве координат базовой станции в RTK могут быть предлагаемые методы. В этом нет никаких противоречий геометрии и геодезии. Но воинствующему дилетантизму, важен не метод или опыт корректных решений, а важно самоутверждение в праве на глупости и ошибки. Я это понимаю из ваших посланий. Наполнить сосуд который полон невозможно. Оставайтесь на своем уровне упертости. Это поможет остальным быстрее показать Вам путь из профессии, где важны детали частности в иные занятия. На вашем же опыте, от которого я пробовал Вас предостеречь убеждением.

На эту запись поступили жалобы от сообщества, поэтому она временно скрыта.

На эту запись поступили жалобы от сообщества, поэтому она временно скрыта.

1 лайк