Обильные фильтруации

Posted on 10.12.2016
by Ночной косильщик

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

Буду фильтровать. Начну с фрагмента снимка SRTM:

Ну а хули елозить-то? Фильтровать — так фильтровать. К великой моей печали, вы в просьбах своих нихуя не говорите о предпочтительных способах фильтрации. Что-ж, поэкспериментируем, дабы никто не ушел обиженным.

Начнем с DTM-фильтра, в основе которого лежит статья Георга Фоссельмана. Технология фильтрации основана на предположении о том, что резкий перепад значений высоты на незначительном пространстве DEM-растра свидетельствует не об особенностях рельефа, а о наличии объектов местности, искажающих ЦМР. Проще говоря, если на левом пикселе высота десять метров, а на правом тридцать, то скорее всего на местности в данных точках вы вместо обрыва/карьера увидите стену леса, здание или другую нерельефную ебанину. Фильтр просматривает растр скользящим окном заданного радиуса и отделяет области с уклоном выше указанного. При соответствующих настройках, этот фильтр позволяет не только отделить неестественные превышения, но и разделить растр на слои равнин и уклонов.

На демке с территорией города Шахты, алгоритм фильтрации сбоит на терриконах и отвалах. Впрочем, на таких масштабах уместнее использовать вместо SRTM растры ASTER GDEM. На моем фрагменте все работает прекрасно. Вот вам равнины:

А вот уклоны свыше тридцати градусов:

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

Чаще всего подобные искажения возникают за счет растительности. Отделить ее от рельефа практически невозможно. Но если на плакорах с этим можно почти смириться (нужно только забыть про разницу в возрастах, бонитетах, наличие дорог, лугов, болот и полей, ветровалы, бобров, пожары, рубки и усыхания), то получить детальную ЦМР для склонов долин обычно затруднительно. Да чего объяснять-то? Каждый из вас наверняка видел такую взаимосвязь растительности и рельефа:

Но хватит, уже про DTM. Вы можете подумать, что у меня нет чувства такта. Фильтр комочков (Filter clumps — да простят меня профессиональные переводчики) отсеивает связанные пикселы с единым значением, превышающие заданную площадь. Например, вот области в которых соприкасается не менее тридцати пикселов с единым значением высоты:

Мажоритарный фильтр (majority filter) делит растр на сегменты указанного размера. В каждом из них вычисляется значение большинства пикселов, которое впоследствии экстраполируется на всю область. В результате имеем следующее:

Исходный SRTM в приближении:

Результат работы мажоритарного фильтра в том же экстенте:

Для понимания, на рисунке ниже черные изолинии с SRTM наложены на красные изолинии с отфильтрованного растра. Результат налицо:

Морфологический фильтр, точнее фильтры. Спешу огорчить всех натуралистов. Умойтесь, к геоморфологии эти фильтры не имеют никакого отношения, даже несмотря на их специфические наименования. Базовых морфологических фильтров два: дилатация и эрозия. Кроме того, активно используются фильтры замыкания и размыкания. В первом применяется сначала дилатация, затем эрозия, во втором — наоборот. Нихрена не понятно? Не проблема. Вот вам иллюстрированная классификация. Основана на лучших моих художественных скиллах вкупе с простейшим графическим редактором:

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

Красные линии — горизонтали с растра дилатации, черные — горизонтали SRTM:

При эрозии происходит обратный процесс. Однородные области увеличиваются в размере за счет подавления шума между ними.

Красные изолинии с растра эрозии на фоне черных горизонталей SRTM

Это размыкание

с горизонталями

А это замыкание

с горизонталями

Все, хватит про морфологические фильтры. Это банально и скучно. Самое время испить из фрактальной реки и вспомнить про богов алеатики. Дамы и господа! Леди и джентельмены! Мудачье! Специально для вас, Карл Гаусс со своим фильтром!

— ээээээ, а где растр то?

А не будет растра. Ибо визуально после применения фильтра различия почти не отличить. Суть фильтра в отсеивании областей с заданным стандартным отклонением. Что-бы вы не расстраивались вот вам картинка с изолиниями (standart deviation = 1):

Фильтр Ли. Это к китайцам не имеет никакого отношения, просто я в душе не ебу, как перевести «Multi direction lee filter» на адекватный русский язык. Более того, я с трудом понимаю что это вообще такое, а для чего это — не понимаю вообще. Но раз уж зашла речь про фильтрацию, грех не рассказать про эту хрень.

Фильтр разделяет растр на три дочерних: результат фильтрации, растр минимума стандартного отклонения и растр направления минимума стандартного отклонения.

Результат фильтрации визуально от оригинала не отличим:

Минимальное стандартное отклонение. Тут все почти просто, если найти мануал, объясняющий значение прилагательного «минимальное». Результирующий растр в псевдоцветах выглядит так (чем краснее, тем выше стандартное отклонение):

Слой изолиний в той же палитре:

Но самое интересное — направление минимума стандартного отклонения. Я воздержусь от комментариев, лучше покажу вам результат и выпью своего пива.

Изолинии по растру направления минимума стандартного отклонения на фоне изолиний SRTM (черные линии):

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

Изолинии из результата фильтрации (50-й ранг) на фоне изолиний SRTM:

На этом все.

Э, да я смотрю вас не наебешь. Действительно, а как же дивергенция градиента значений растра? Вообще физический смысл лапласиана достаточно условен, типа значений концентрации градиента. Но в нашем случае ситуация проще. Фильтр Лапласа выделяет контуры на растре. В итоге имеем следущее:

Да прибудет с нами псевдоцвет растра итогов применения фильтра Лапласа!

Ну и горизонтали, само-собой. Хотя, это все-таки не горизонтали, а просто изолинии.

Хотя, конечно, проще всего использовать простой фильтр. Особенно, если вы хотите строить горизонтали.

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

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

Векторная отмывка

Posted on 14.11.2016
by Ночной косильщик

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

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

Возьмем модифицированный фрагмент MODIS Blue Marble Next Generation с повышенной яркостью и контрастом для основы:

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

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

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

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

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

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

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

Пивопровод на ХБК

Posted on 10.05.2016
by Ночной косильщик

В поселке ХБК сто четыре жилых дома, которые необходимо подключить к пивопроводу. Само собой, сделать это необходимо с минимальными издержками на прокладку труб и дальнейшее их обслуживание.

Для проектирования пивопроводной сети, откроем в QGis карту OpenStreetMap с помощью плагина QuickMapServices или его старого аналога OpenLayersPlugin:

Приблизим интересующий нас район, и создадим полигональный шейп-файл:

Обведем контуры поселка:

Теперь, требуется загрузить контуры домов, нуждающихся в подключении. В нашем случае самым простым решением будет импорт зданий из базы геоданных OpenStreetMap с помощью сервиса Overpass turbo. Мы для этих целей воспользуемся плагином QuickOSM, загрузив полигональные объекты со значением «building=apartmens». В OSM полигонального типа нет, модуль выполняет эту конвертацию за нас:

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

Прежде всего, получим вершины графа, путем извлечения центроидов полигонов:

Если бы мы располагали графическими картами в качестве исходного материала, то пришлось бы их отсканировать, затем привязать, затем оцифровать. Это конечно дольше, но мы бы расставили точки более сложным образом. Центроиды полигонов хорошо применять только в случае простых полигонов, на сложных это приводит к погрешности:

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

Преобразуем полигональную триангуляцию в сеть линий. С помощью команды «split» плагина Networks разобьем сеть на отдельные линии. Мы получили граф, достаточный для роутинга. Если нам потребуется кратчайшим образом связать между собой две его вершины, достаточно будет просто использовать модуль RoadGraph:

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

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

Раскрасим слой ребер по градиенту возрастания длины ребра.

Ребер у нас много, поэтому выведем длину каждого из них в качестве подписи:

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

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

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

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

Метод Бенфорда в оценке достоверности данных

Posted on 13.09.2015
by Ночной косильщик

Друзья мои! Вы несомненно знаете больше меня о последних мировых новостях и потому разобщены и тревожны. Но сегодня, у вас будет повод отвлечься. В этот день мы все объединены единым горем утраты. Утрачена флешка, на которой я хранил для вас статью о диссипативной динамике живого напочвенного покрова. Вместе с ней пропало содержимое подарочной бутылки коньяка, мой рукописный реферат на тему «Сатанизм-как социальное явление» и весь тираж осеннего номера «Лабораторного Журнала», отпечатанный в объеме двух с половиной экземпляров. Воистину, в этот день можно посыпать голову пеплом, ибо об этот реферат я в свое время исписал четыре ручки и мне он чертовски дорог, как память о студенческих годах.

Дабы загладить боль утраты, я предлагаю вам статью из пропавшего «Лабораторного Журнала» (а где вы ее теперь прочитаете?), описывающую сущность, принципы применимости и алгоритм метода Бенфорда на примере анализа данных о площадях ООПТ России и площадях, охваченных лесными пожарами в 2009-2013 годах. Сам же я отправляюсь в келью, где буду страдать вплоть до открытия магазина.

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

Свое название бенфорд-последовательность получила в честь Фрэнка Бенфорда Альберта-младшего — американского инженера-электрика, физика и оптика, жившего в штатах в первой половине XX века. Однако, сам «Закон Бенфорда», он же «закон первой цифры» впервые описан за три года до его рождения американским астрономом, математиком и экономистом Саймоном Ньюкомбом. Работая в 1881 году с логарифмическими таблицами в книгах, он обнаружил, что сильнее всего истрепаны страницы на которых содержаться логарифмы чисел, начинающиеся с единицы. На первый взгляд, вероятность оказаться на первом месте в числе одинакова для всех цифр и составляет 1/9. Однако, чем выше по значению было число, состоящее из первой цифры логарифма, тем в большей сохранности находились страницы. Все это наводило на подозрение о неравномерной встречаемости первых цифр в числах.

Спустя пол-века за эту проблему взялся Фрэнк Бенфорд. Он рассчитал вероятности встречаемости цифр на первом месте в числе для различных данных. Бенфорд использовал площади бассейна 335 рек, удельную теплоемкость материалов, население городов, молекулярную массу химических соединений, номера домов и другие данные. Во всех случаях наблюдалась единая закономерность — чисел, начинающихся на единицу было примерно в шесть раз больше, чем чисел, начинающихся на девятку. Собранная статистика позволила вывести формулу распределения вероятности появления первой цифры в числе:

P(d) = log_b(d+1)-log_b(d) = log_b(1+1/d)

где:
b — основание системы счисления, в нашем случае b = 10;
d — первая цифра в числе;

На основе этой формулы была построена бенфорд-последовательность — последовательность вероятности появления различных цифр на первом месте числа. Рассчитанная по формуле, эта последовательность выглядит следующим образом: 30.1, 17.6, 12.5, 9.7, 7.9, 6.7, 5.8, 5.1, 4.6. Вероятность того, что на первом месте в числе окажется единица составляет 30.1%, двойка — 17,6% и так далее до девятки (4.6%).

Долгое время, эта интересная закономерность не находила никакого применения. Однако после 1997 года на нее обратили внимание и стали все активнее использовать для проверки фальсификации данных, например результатов голосования (в том числе и в России). В 1997 году М. Нигрини и Л. Миттермайер в издании «Аудит: Журнал теории и практики» опубликовали шесть разработанных математических тестов, основанных на законе Бенфорда. Тесты были успешно введены в практику аудиторской компанией «Эрнст и Янг» и позволили выявить несоответствие между реальными и заявленными данными клиентов.

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

При решении вопроса применимости метода Бенфорда обычно рекомендуют исходить из «естественности» данных (если данные получены в ходе естественного течения событий, то к ним применим метод Бенфорда). Этот критерий верен, но довольно сложен для использования. В ходе работ с бенфорд-последовательностями я пришел к выводу, что метод бенфорда работает только с данными, топологическое множество которых самоподобно, а элементы могут принимать произвольные значения.

Для проверки применимости метода необходимо аппроксимировать их показательной функцией (чаще всего используется экспонента) и убедиться, что коэффициент аппроксимации составляет 0,9 и выше. Если при этом отсутствуют правила, детерминантно определяющие значение того или иного числа, то метод бенфорда к вашим данным применим.

Алгоритм применения бенфорд-метода в программах LibreOfficeCalc и MS Excel

1. Исходные данные

Со страницы сайта oopt.aari.ru, разработанного ФГБУ «ААНИИ» и Лабораторией геоинформационных технологий взят перечень особо охраняемых природных территорий России. Список насчитывает 8013 ООПТ, из которых 4410 войдут в нашу обработку. Это действующие или реорганизованные ООПТ, для которых есть данные по площади.

Данные по площади лесных пожаров взяты с сайта федерального агентства лесного хозяйства. Выборка охватывает данные по всем регионам России с первого квартала 2009 года по второй квартал 2013 года. Всего за этот период было охвачено лесным пожаром 949 территорий различной площади.

2. Проверка на распределение

Нам необходимо убедиться, что данные подчиняются экспоненциальному распределению. Сортируем данные по площади и аппроксимируем их экспонентой.

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

3. Избавление от нулей

Отличительной особенностью фрактальных множеств, к которым относятся и наши данные является их масштабная инвариантность. Распределение не зависит от единиц в которых выражены величины. Будь наши данные выражены в километрах, миллиметрах или ангстремах, мы всегда будем наблюдать одинаковые закономерности. Масштабная инвариантность позволяет нам избавиться от значений менее единицы простым умножением на 100 (в каждом конкретном случае может быть различный порядок, в зависимости от наименьшего числа в выборке. В нашем случае таким числом было 0,01). Сделать это необходимо, поскольку формула Бенфорда использует логарифмы, а потому не работает с нулевыми числами.

4. Отделение первой цифры и расчет

Методом LEFT() в LibreOfficeCalc или ЛЕВСИМВ() в Excel отделяем первую цифру из каждого числа. Получившийся столбец с первыми цифрами чисел сортируем и подсчитываем количество единиц, двоек, троек и т.д. до девяток. Вероятность встречи каждой цифры рассчитываем как отношение количества чисел, начинающихся с данной цифры к общему количеству чисел. Например, если в выборке по пожарам было 273 числа, начинающихся на единицу, а общий объем выборки 949, то вероятность того, что первой цифрой в числе будет единица составит 100%*273/949=28,8%. В итоге у вас получится аналог вот таких таблиц (верхняя таблица — данные по площади ООПТ, нижняя таблица — данные по площади пожаров):

По ним же, для большей наглядности можно построить соответствующие графики сравнения фактической и расчетной бенфорд-последовательности (вверху для площади ООПТ, внизу для площади лесных пожаров):

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

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

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

P.S. Да, я знаю, что качество приведенных картинок отвратительно. Но поверьте, вы встретились с ними в странный момент их жизни.

Мапим по гуглопанорамам — наземное фотограмметрическое картирование в QGIS с помощью плагина stereoSurveys

Posted on 22.06.2015
by Ночной косильщик

Read in English

Замечание 1. В данной статье не расматриваются юридические вопросы законности использования описанного метода при работе с данными компании Гугл. Мое дело метод показать, а с юристами сами разбирайтесь.
Замечание 2. Собственно, ничто не мешает использовать любые другие данные, вплоть до своих фотографий.
Замечание 3. Код описываемого ниже модуля от первой до последней строки написан Enrico Ferreguti. Мое значение в этом проекте чисто терапевтическое.

Пару месяцев назад я опубликовал пост о технологии применении снимков Google StreetView для фотограмметрического картирования территории. Этот незатейливый текст вдохновил Enrico Ferreguti (по его словам) на разработку модуля StereoSurveys для QGIS.

Основное назначение модуля — перенос контуров объектов, попавших в объектив камеры гугломобиля в точечный слой QGis. Наличие объекта с известным пеленгом на двух геопривязанных снимках позволяет однозначно установить его местоположение по свойству суммы углов треугольника. Использовать это свойство на практике возможно было и ранее, однако, только после появления StereoSurveys появилась возможность значительно сократить трудоемкость работ и увеличить точноность нанесения данных.

Для иллюстрации работы модуля, нанесем в точечном слое местоположение фонарных столбов на улице Текстильной (ХБК, город Шахты). Со спутникового снимка их не видно, поэтому единственный способ нанести их не от балды — воспользоваться описываемым методом.

Улица Текстильная, вдоль которой необходимо отметить фонарные столбы

1. Для начала скачиваем модуль с гит-хаба. На тот случай, если гит-хаб закроют (твою-ж мать…) сохранил копию у себя на сервере. Последняя ссылка подойдет так-же для тех, у кого скачанный с гит-хаба архив не открывается (как у меня, например).

2. Скачанный архив необходимо распаковать в папку хранения модулей QGIS. Для windows XP это обычно C:\Documents and Settings\[username]\.qgis2\python\plugins для windows 7: C:\Users\[username]\.qgis2\python\plugins, для linux: /home/[username]/qgis2/python/plugins. Если в папке home отсутствует папка qgis2 (или .qgis2), то, возможно, у вас не отображаются скрытые файлы. В debian-подобных системах (debian, ubuntu, mint, OSGeoLive и др.) это исправляется так: правая кнопка мыши — отображать скрытые файлы.

3. Если у вас винда — обратите внимание на название папки [username]. Плагин не переносит кириллицу! Если в названии файла, проекта, плагина или пути к ним встретится русская буква, QGIS выдаст следующую ошибку:

Traceback (most recent call last):   File "", line 1, in   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\pyplugin_installer\installer.py", line 274, in upgradeAllUpgradeable     self.installPlugin(key, quiet=True)   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\pyplugin_installer\installer.py", line 322, in installPlugin     reloadPlugin(key) # unloadPlugin + loadPlugin + startPlugin   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\qgis\utils.py", line 319, in reloadPlugin     loadPlugin(packageName)   File "C:/PROGRA~1/QGISWI~1/apps/qgis/./python\qgis\utils.py", line 200, in loadPlugin     msg = msgTemplate % (packageName, "', '".join(sys.path)) UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 9: ordinal not in range(128)

Для пользователей Windows 7, причина кроется как правило в том, что папка «Users» в этой системе названа как «Пользователи», кроме того, обычно кириллическое написание имеет папка [username]. Теоретически, исправить эту беду можно создав новую учетную запись с правами администратора. Через нее следует войти завершив текущую сессию, после чего стандартным способом сменить название директорий на латиницу. Насколько это возможно и действенно, я утверждать не берусь — не проверял.

В Линуксе, как правило, папка [username] всегда может быть названа только латиницей. Поэтому, если у вас Линукс — переходите к следующему пункту.

4. Теперь можно запустить QGIS, либо перезапустить его, если он работал до этого.

В верхнем меню выбираем: модули — управление модулями-с ошибками. Ставим галку в чекбоксе stereo surveys и нажимаем установить

После установки появляется текст «Модуль неисправен invalid syntax». Презираем его и закрывая окно установки модулей.

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

На панорамах Google отображается площадь Прато-делла-Валле — что находится в Падуе, недалеко от Венеции. Это красивейшие места, но в качестве отправной точки для модуля не самые удачные — нам ведь требуется картировать шахтинскую улицу.

Для точечного слоя, создадим шейп-файл с названием test и системой координат EPSG: 3785 (можно и EPSG: 3857 — все работает, другие датумы не пробовал).

Что-бы вернуть его в рамки окна — перетащим таблицу слоев (менеджер слоев, TOC — все его по-разному называют) в нижнюю часть экрана.

Для того, что-бы картирование было более наглядным, подгрузим слой OpenStreetMap — Mapnik, воспользовавшись плагином OpenLayersPlugin. Это не обязательно, но очень удобно. Приблизим нужный участок.

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

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

Первое сообщение об ошибке:

Второе сообщение об ошибке:

После нескольких неудачных попыток модуль срабатывает как надо и пользователь видит следующее:

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

— Непонятные числа, поля ввода и текст not calibrated слева и справа от окон с панорамами (первые два числа слева и справа — это координаты точки, в которой сделана панорама.

— Числа по центру, под окном со спутниковым снимком, которые обозначают следующее (я могу ошибаться):

H — высота точки, взятой на прицел в обоих панорамных окнах в метрах, относительно земли;

+/- — погрешность местоположения точки, взятой на прицел в обоих окнах, в метрах;

Lon, Lat — долгота и широта;

X,Y — неизвестные прямоугольные координаты;

— Под числами, расположена кнопка с текстом, «Digitize on map», по клику на которой, точка, взятая на прицел в обоих панорамах должна переносится в точечный слой.

— В окне отображения данных QGIS, помимо OSM-карты, пользователь видит три точки: зеленую — точка из которой снята панорама в левом окне StereoSurveys, красную — точка, из которой снята панорама в правом окне и желтую — точка, взятая на прицел в обоих окнах просмотра панорам.

Можно начинать работу. Находим на обоих панорамах одну и ту же точку. Кнопка Digitize on map не срабатывает, поэтому, включаем редактирование слоя и наносим ее вручную (кликаем по желтой точке, предварительно выбрав инструмент «добавить объект»). В проекте, который идет как пример к плагину, кнопка Digitize on map работает, но тоже далеко не всегда. Этот вопрос еще необходимо прояснить.

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

Прицеливаемся поточнее и стреляем — ставим точечный объект поверх желтой точки.

Точно так-же поступаем для остальных объектов. Картирование фонарного столба на противоположной стороне улицы.

Навигация осуществляется средствами Google StreetView. «Проезжаем» на несколько метров вперед в обоих окнах просмотра панорам и берем на прицел новый столб.

Иногда, без видимых причин возникает сообщение об ошибке:

Игнорируем его и продолжаем работать дальше.

Ради интереса, попытаемся изменить числа в полях StereoSurveys. Числа ввести можно только корректные. Насколько я понял из общения с Enrico, данные поля позволяют корректировать данные о высоте точки. Первое поле отвечает за высоту камеры над поверхностью земли (2.5 метра), второе за высоту поверхности земли (по умолчанию 0). Эти параметры особенно важны в горной местности с большими перепадами высот и при картировании объектов, находящихся на большом удалении от точек съемки панорам.

Не отвлекаемся и стреляем столбы дальше.

Процесс захватывает.

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

Еще точечку.

В результате, мы получаем точечный слой, который планировали. После нанесения всех точек, закрываем модуль и сохраняем полученный слой. Иногда, после закрытия модуля красная и зеленая точки (точки съемки панорам) не исчезают, в этом случае, необходимо отключить модуль через меню-модули-управление модулями-снять галку с чекбокса напротив StereoSurveys и нажать «Закрыть».

Любопытный момент: обычно, снимки привязывают к gps-трекам. Я за всю Одессу говорить не буду, но в OpenStreetMap так и происходит. Думаю в Google тоже. При этом трек рассматривается в качестве центра дороги, что частично верно только для проселочных колейных дорог. Игнорирование понятия полосы дороги, приводит к системной ошибке в координатах до 5 метров (обычно +/- 3 м). Сама по себе, это величина небольшая, часто незначительная на фоне погрешности прибора. Однако, в том случае, если координаты объекта используются для расчетов детерминированных показателей, ошибки могут быть колоссальны. Это категорически запрещает использование популярных веб-проектов для расчета площади секторов, лежащих в створе с известными координатами, анализа видимости объектов, привязки объектов по двум точкам…, боюсь, этот список может оказаться длинным.

Обратите внимание на местоположение фонарного столба на улице Ворошилова.

Карта OpenStreetMap — столб стоит на дороге.

Карта Google. Аналогичное местоположение столба. Так-же, обратите внимание на местоположение дороги, относительно столбов освещения.

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

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

Вот карта фонарных столбов, полученная с помощью модуля:

А вот, та же карта, полученная два месяца назад вручную. Ошибки нанесения (дублирование столбов) — налицо.

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

- Не работает с кириллицей;

- Не хватает угла обзора панорам как в модуле go2streetview;

- Возникает ошибка при попытке переместить точку на карте;

- Не работает кнопка Digitize on map;

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

- Не высвечивается предупреждение, если погрешность больше заданной величины;

- При запуске модуля должны отображаться снимки из текущих координат экстента;

- При наличии таблицы слоев, модуль выходит за размеры экрана;

- Не исчезают точки после закрытия плагина;

- Нет явного объяснения значения чисел и полей ввода в плагине;

- Много времени уходит на масштабирование снимков, не хватает кнопки "сбросить увеличение";

- Не хватает кнопки "назад" для каждого из окон панорам;

- Не хватает кнопки "вперед", перемещающей обе точки;

P.S. Спасибо Enrico Ferreguti за написание такого чудесного плагина. Десять лет назад я говорил, что скоро наступят времена, когда картографы долгими зимними вечерами будут превращать видеозаписи своих летних путешествий в точнейшие карты. Тогда надо мной все смеялись. Теперь, благодаря Enrico, я понимаю, что был прав.