Расширение возможностей полевого кодирования в Кредо Дат (и

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

Так, прекрасно задуманная система полевого кодирования КРЕДО III, не получила полного развития из-за своей привязки к КредоДАТ, в котором невозможно получить никаких примитивов, кроме окружности. Многие заявленные команды не реализованы. Практически, линию можно только начать, завершить и замкнуть на начало… В результате работа с кодами весьма неудобна. Особенно заметна «проблема узлов контуров»: Часто на один пикет сводится несколько контуров, например с углом здания соединяются забор и край газона… Да и кодирование простого стыка заборов не так уж просто… А уж разводка коммуникаций…
Во-первых, мешает ограничение, связанное с длиной строки кодов в инструменте, обычно это 16 знаков, а иногда и меньше... Между тем, полный код линейного объекта, со всеми командами и параметрами, в стандартном формате занимает, как правило, более 8 разрядов, а в более удобном компактном на каждое измерение может приходиться лишь один код. То есть несколько кодов одновременно не введешь… Разработчики советуют для каждого кода делать отдельное измерение, но ведь это не выход…
Во-вторых, при съемке весьма затруднительно с ходу представить себе, и все время держать в голове, какую линию с чем сводить. А просто сказать: «Соединяй дальше вон с тем пикетом» нельзя. «Джамп» не реализован.

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

Как это сделано?

Раскрыть Спойлер Свернуть Спойлер

Да просто. Если разработчик предлагает осуществлять дополнительные измерения, то что нам мешает сделать программку, которая бы генерировала (фальсифицировала) на каждый код запись о сделанном измерении? А если это есть, то почему бы не реализовать и ссылки на измерения? Не в тахеометре, и не в ДАТ, а между ними, в выгруженном на компьютер протоколе тахеометра? А потом загрузить модифицированный протокол, и Кредо, или другая программа, все просчитает – прорисует… По сути, работать так можно с любой кодовой системой, не только Кредовской…
Протокол используется .rdf. У кого не «Никон» - всегда можно конвертировать через известный «Редактор измерений» А. Китанина, например…

Итак, как это все выглядит на практике.

Раскрыть Спойлер Свернуть Спойлер

При съемке дополнительные коды вводятся в поле комментариев. Желательно все дополнительные точки кодировать как нерельефные.

Если нам нужно ввести несколько кодов для одного пикета, то мы пишем первый код в строку кодов, для второго вызываем комментарий, и пишем туда: «*0», и далее код, для третьего – создаем еще комментарий, опять «*0», код и ...

Далее – относительная ссылка.
Числа от 0 до 6 после дескриптора «*» означают ссылку на пикет, сдвинутый назад на данное число. Так «*0», как мы уже видели – на текущий, «*1» - на прошлый, «*2» - на позапрошлый и т.д.
То есть, если в поле кода запись «штакетник » (706), то введя в поле комментария «*5706», (или «*5штк», если хотите) мы дадим команду нарисовать штакетник от данного пикета, до пикета, определенного пятью измерениями ранее.

Ну и наконец, абсолютная ссылка. То есть команда соединить объект на данном пикете, с пикетом номер такой-то. Имеет вид «*9N(номер пикета)(код)», где N-число знаков в номере пикета. Например, команда «*93346706» («*93346штк») будет означать «провести забор на пикет №346» (в номере пикета три знака, потому после девятки тройка), а «*92457064138» - «направить штакетник, обозначенный №4 (четвертый из одновременно снимаемых), на пикет №45, и там закончить. Дополнительная точка без отметки.»

Ссылки действуют только в пределах станции. Что они нам дают? Хотя бы то, что при стандартном кодировании нам бы пришлось начинать от узла ситуации все проходящие через него линии, и завершать на пикетах снятых впоследствии. В лучшем случае, нам бы пришлось бегать по каждому линейному объекту «от начала к концу», нарезая круги, а в худшем, при сложной ситуации, кодирование станет практически невозможным, так как определение «начал-концов» всей взаимосвязи контуров, будет очень трудным. А так – хождение самое обычное, что даем, то и пишем…

Как проходит камеральная обработка?

Раскрыть Спойлер Свернуть Спойлер

Протокол сохраняем в текстовом формате.
Предлагаемая утилита – шаблон Excel «Фальсификатор.xlt».
1. Если щелкнуть по значку – будет создана книга «Фальсификатор2.xls», открытая на листе «Импортируй».
2. Загружаем протокол через меню Данные – Импорт внешних данных – Импортировать данные, далее – следуя указаниям «Мастера импорта»: Формат – «С разделителями» ; Разделитель – запятая; Если настройки точности представления данных импортируются с прибора, то столбцам С-Н стоит задать тип «текстовый», размещение – по умолчанию.
3. Копируем столбцы А-Н на то же место листа «Вставляй».
4. Переходим на лист «экспортируй», и сохраняем файл как CSV (разделители – запятые). На все запросы жмем «Да».
5. Закрываем файл, без повторного сохранения. Переименовываем расширение на .rdf, и готово. Хотя, может потребоваться в протоколе командой текстового редактора «Правка – Заменить все» заменить все точки с запятыми на запятые…

Все.

Вместо протокола вида:

Раскрыть Спойлер Свернуть Спойлер

SS,13,1.550,8.49,61.1500,359.5210,12:33:46,618,
CO,*07020118,
SS,14,1.550,17.79,46.5005,359.4015,12:34:26,618013,
SS,15,1.550,26.44,42.5440,359.5810,12:34:57,702,
CO,O/S Msr:15 1.55 26.44 42.5240 359.5810
SS,16,1.550,26.63,30.1540,359.2430,12:35:19,702013,
CO,*07100118,
SS,17,1.550,11.79,25.0005,359.0925,12:36:03,710,
CO,O/S Msr:17 1.55 11.79 25.5050 359.0925
SS,18,1.550,3.41,0.1420,358.2730,12:36:25,710,
CO,*16181118,
SS,19,1.550,9.17,230.2305,359.4235,12:36:57,710,
CO,*9137100138,
CO,O/S Msr:19 1.55 9.17 229.4120 359.4220
SS,20,1.550,6.17,14.4525,358.2830,12:37:54,0,
CO,O/S Msr:20 1.55 6.17 16.4715 358.2825
SS,21,1.550,5.97,34.2635,359.0710,12:38:07,618,
SS,22,1.550,13.53,34.5910,359.3335,12:38:34,618,
CO,*92146181138,
SS,23,1.550,8.74,82.5515,359.1125,12:39:29,400,
SS,24,1.550,14.01,92.0750,359.3635,12:40:11,
CO,O/S Msr:24 1.55 14.01 92.1720 359.3635
SS,25,1.550,16.57,108.0115,359.3640,12:41:17,
SS,26,1.550,27.08,119.5925,359.2820,12:43:14,

получаем

Раскрыть Спойлер Свернуть Спойлер

SS,13,1.55,8.49,61.15,359.521,0.523449074,618
SS,13a,1.55,8.49,61.15,359.521,0.523449074,7020118
SS,14,1.55,17.79,46.5005,359.4015,0.523912037,618013
SS,15,1.55,26.44,42.544,359.581,0.524270833,702
CO,O/S Msr:15 1.55 26.44 42.5240 359.5810,,,,,,
SS,16,1.55,26.63,30.154,359.243,0.524525463,702013
SS,16a,1.55,26.63,30.154,359.243,0.524525463,7100118
SS,17,1.55,11.79,25.0005,359.0925,0.525034722,710
CO,O/S Msr:17 1.55 11.79 25.5050 359.0925,,,,,,
SS,18,1.55,3.41,0.142,358.273,0.525289352,710
SS,18a,1.55,11.79,25.0005,359.0925,0.525034722,6181118
SS,19,1.55,9.17,230.2305,359.4235,0.525659722,710
SS,19a,1.8,14.41,267.022,0.2905,0.517777778,7100138
CO,O/S Msr:19 1.55 9.17 229.4120 359.4220,,,,,,
SS,20,1.55,6.17,14.4525,358.283,0.526319444,0
CO,O/S Msr:20 1.55 6.17 16.4715 358.2825,,,,,,
SS,21,1.55,5.97,34.2635,359.071,0.526469907,618
SS,22,1.55,13.53,34.591,359.3335,0.526782407,618
SS,22a,1.55,17.79,46.5005,359.4015,0.523912037,6181138
SS,23,1.55,8.74,82.5515,359.1125,0.527418981,400
SS,24,1.55,14.01,92.075,359.3635,0.527905093,
CO,O/S Msr:24 1.55 14.01 92.1720 359.3635,,,,,,
SS,25,1.55,16.57,108.0115,359.364,0.528668981,
SS,26,1.55,27.08,119.5925,359.282,0.530023148,

и загружаем его в КредоДАТ…

Буду очень признателен, если кто протестирует это хотя бы камерально. То есть берется файл тахеометра, абрис, и в файл подставляются соответствующие коды, затем - прогон...

 

Идея кодирования заключается в том, что бы все замыкания получить в поле. В противном случае контура проще замкнуть при отрисовке, а не докодировать файл.

 

Так в чем вопрос-то? Вы весь пост читали, или только последний абзац?
Утилита и предназначена для работы в поле. Ничего докодировать дома не надо.
Просто я не прошу никого хватать ее и бежать в поле, снимать с кодированием по моей системе. А хочется узнать, нет ли незамеченных автором "подводных камней".

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

 

Нужен маленький ХЕЛП в самой утилите.или подсказки на листах чтоб не рыскать по теме.

 

Верщагин, если используешь 8-значные коды - отобьешь желание работать с кодами вообще, особено на Никоне
Главное назначение кодов, ну скажем в моей практике, раскида сьемки по слоям и соеденение основных линий. И использую максимум 3х значные. Служебные коды пользую крайне редко. Один раз сделал полную сьемку по всем правилам кодировки - заняло гораздо больше времени - вешник простаивал. И главное, что все равно потом камералить пришлось :) То есть полная кодировка - не оптимальное решение. Нужно сочетать с фотографиями, ну и абрсами если нельзя без етого обойтись.
Если инетерсно могу прислать ДОС-овскую SDRmap, она решает кодировку лучше всех программ что я знаю.

 

Да, собственно распечатать пост с раскрытыми спойлерами, больше и сказать нечего.

Если про собственно кредовскую систему кодирования, то прицепляю статью с описанием (надеюсь, авторы не возражают). С сайта она вроде бы исчезла. Только надо иметь в виду, что реально реализованы только команды "первого десятка", да и то без сплайна..
(Добавление)

Почему же, по-моему именно на Никоне работать с длинными цифровыми кодами весьма удобно. Трехзначные же коды, конечно, представляют топографу наибольшие удобства работы, по сравнению любыми другими методами работы в поле. Разумеется, при использовании специального классификатора. (Имеется в виду, когда при вводе кода, или выборе "Угол забора направо" из библиотеки, такая же надпись потом появляется в специальном слое в проекте).
Но ведь надо как-то стремиться к использованию полного кодирования...
К тому же, в данном случае, я предполагаю, что кодирование и ведение крайне упрощенного абриса делает вешечник, и сообщает данные по рации оператору тахеометра...
И полевое кодирование, конечно же, не означает абсолютного отказа от зарисовок и фотографий.

Разговор получается продолжением "зимней" темы про особенности полевого кодирования (опять без дела сижу, и время потрепаться есть... )

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

Программу было бы интересно посмотреть. Если можно, прицепите, или вышлите на Е-майл ("Написать письмо через форум" из профиля). Только, извините уж, лучше с русским пояснением...

 

Спасибо, Верещагин! Материал пошел для учета при постановках для CREDO_DAT4.

 

О! Четвертый будет? Вот это радует.
Спасибо.
И за отзыв тоже спасибо. Действительно, польщен.

 

Только сейчас заметил.
Seditor, однако, для конвертации в *.rdf в данном случае не подходит.
Не передает комментарии.

 

Цифровой код - источник ошибки. Там в никоне есть вверху такая голубенькая кнопочка, по английски "mode" она выводит на экран 10 "горячих" кодов, которые разумеется леко меняются. все-таки хоть английскими буквами, но кодировка надежнее вводится.
Но если много служебных, то таки да проще цифирью писать. Потом павда журнал надо вести что есть каждая цифирь значит... Дерзай Верещагин! ;)

 

10 "быстрых" кодов для реальной работы совершенно недостаточно. Достоинство Никона - библиотеки кодов, но там невозможно вводить служебные коды, только характеристики пикетов. Да и практически быстрее ввести несколько цифр, чем пройти по нескольким директориям библиотеки... А вот ввод букв в "Никоне" - наихудший из возможных при полноцифровой клавиатуре...