{ "version": "https:\/\/jsonfeed.org\/version\/1", "title": "ШТОСМ: заметки с тегом qgis", "_rss_description": "ШТОСМ", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/shtosm.ru\/tags\/qgis\/", "feed_url": "https:\/\/shtosm.ru\/tags\/qgis\/json\/", "icon": false, "author": { "name": "Илья Зверев", "url": "https:\/\/shtosm.ru\/", "avatar": false }, "items": [ { "id": "1543", "url": "https:\/\/shtosm.ru\/all\/ataka-na-4326\/", "title": "Пяти знаков после запятой хватит всем", "content_html": "
\n\"\"\n<\/div>\n

В начале мая Ньёлл Доусон показал<\/a>, что свежий QGIS при выборе системы координат EPSG:4326 (или любой другой, основанной на датуме WGS-84, включая 3857) предупреждает: эта СК опасна для точности ваших данных.<\/p>\n

\n

*я иногда путаю датум (параметры эллипсоида, как WGS-84), системы координат (как на этот эллипсоид натянуты широта и долгота, как 4326) и проекции (отображение эллипсоида на плоскость, как 3857).<\/p>\n<\/blockquote>\n

Неужели всё настолько плохо, что WGS-84 нужно отменить? Напомню, эта система координат используется почти везде: в GeoJSON, в приёмниках GPS, в данных OpenStreetMap. Мы рисуем в этой системе поребрики и балконы на домах, пользуясь пучками GPS-треков и RTK для достижения сантиметровой точности.<\/p>\n

Проблема в том, как позже разъяснил Ньёлл<\/a> и ранее — этот отчёт 2019 года<\/a>, что местные (статические) СК привязаны к земле, а глобальные (динамические) — к общим параметрам земного шара. Австралия, например, медленно плывёт: с 1994 года она сместилась на 1,8 метра на северо-восток. Динамичность WGS-84 означает, что то, что единожны нарисовано в СК на её основе, каждый год нужно сдвигать.<\/p>\n

В качестве местных в Австралии используются «слепки» WGS-84: система координат GDA94 была определена в 94 году как «эквивалентная WGS-84». А GDA2020 в прошлом году определили точно так же. Получается<\/a>, можно преобразовать координаты без пересчитывания GDA94 → WGS-84 → GDA2020 и получить ответ, отличный от преобразования GDA94 → GDA2020.<\/p>\n

Земная кора двигается и под остальными континентами, пусть и с меньшей скоростью. WGS-84 — динамическая СК: чтобы точно отражать физические координаты, к широте и долготе в ней нужно добавлять время наблюдений. Иначе, как пишет ИКАО в разделе 3.3.1 инструкции по WGS-84<\/a>, даже учитывая теоретическую сантиметровую точность GPS-приёмников, точность данных в этой СК не превышает одного метра по горизонтали. То есть, пять знаков после запятой — предел точности для широты и долготы в WGS-84.<\/p>\n

Чтобы увеличить точность хранения координат, рядом с ними нужно хранить «эпоху» — то есть, год наблюдений. Проблема в том, что ни один популярный формат хранения геоданных не поддерживает поле метки времени, особенно чтобы учитывать его в преобразованиях координат. После твита Ньёлла это начало меняться: с июня поле epoch<\/i> добавили в GeoPackage<\/a>.<\/p>\n

GeoJSON и KML неисправимы, шейпфайлы и PostGIS тоже, соответствующее поле<\/a> WKT CRS не поддерживает даже Proj 8. А вот в OpenStreetMap... формально, все объекты имеют дату создания, которую с натяжкой можно считать нужной меткой времени. Но кто в здравом уме использует OSM как формат для обмена геоданными? А при конвертации информация о времени теряется.<\/p>\n

Обойти эту проблему легко: используйте местные, или хотя бы статические, системы координат. GDA2020 (EPSG:7844) для Австралии, ETRS89 (EPSG:4258) для Европы, ГСК-2011<\/a> (EPSG:7683) для России. Но скорее всего (ролик с ржущим фермером) у вас нет таких вариантов, и остаётся ждать, когда боги геоджейсона придумают решение. Глобальных СК лучше 4236 нет, поэтому<\/a> последний QGIS 3.10 по умолчанию всё ещё предлагает эту систему для новых проектов.<\/p>\n", "date_published": "2021-08-01T14:54:33+04:00", "date_modified": "2021-08-01T14:50:56+04:00", "image": "https:\/\/shtosm.ru\/pictures\/australia-moving-nq8.png", "_date_published_rfc2822": "Sun, 01 Aug 2021 14:54:33 +0400", "_rss_guid_is_permalink": "false", "_rss_guid": "1543", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/shtosm.ru\/pictures\/australia-moving-nq8.png" ] } }, { "id": "1435", "url": "https:\/\/shtosm.ru\/all\/obhodnye-listy-v-qgis\/", "title": "Обходные листы в QGIS", "content_html": "

\n\"\"\n<\/div>\n

Шесть лет назад я написал инструкцию<\/a>, как печатать обходные листы с использованием современного (на тот год) открытого софта и активно разрабатываемого (на тот год) рендерера Maperitive. Вечером перед тульской картовстречей я посмотрел на каталог этого рендерера и понял, что хватит это терпеть. Но что открыть взамен? В mapnik непросто повернуть карту (а это критично), с эзотерическими рендерерами, типа alaCarte и smrender, долго разбираться. Я уже много лет советую всем QGIS для печати карт — так возьму его сам.<\/p>\n

Это одновременно статья про то, как непросто и одновременно несложно было разобраться в инструментах и получить файл pdf с обходными листами, и инструкция. Печатайте больше обходных листов и выводите картографов на улицы. Вам не обязательно загружать собранные объекты именно в OpenStreetMap, но мы были бы рады. А вот данные для печати, кроме как из OSM, взять неоткуда. Начнём с их подготовки.<\/p>\n

(Если вы делаете обходные листы, не дочитав заметку до конца, советую заглянуть в главу «волшебство»).<\/p>\n

Подготовка данных<\/h2>\n

Прежде всего, вам понадобятся QGIS версии не ниже 2.14, GDAL не ниже 2.0 и JOSM.<\/p>\n

    \n
  1. Откройте JOSM, включите «режим эксперта», если ещё не.<\/li>\n
  2. В меню «Файл» выберите «Загрузить с Overpass API» и введите туда запрос: (node({{bbox}});<;>);out meta;<\/tt><\/li>\n
  3. Выберите район картовстречи и качайте. А затем сохраните в файл .osm и закрывайте редактор.<\/li>\n
  4. Теперь нужен GDAL, чтобы сделать файл для QGIS. Для сохранения тегов типа addr:housenumber нужно настроить ogr2ogr. Если коротко, берите этот osmconf.ini<\/a> и положите к данным. Возможно, вы захотите добавить тегов в поля attributes<\/i> разделов [lines]<\/i> и [multipolygons]<\/i>.<\/li>\n
  5. Выполните из командной строки:<\/li>\n<\/ol>\n
    ogr2ogr --config OSM_CONFIG_FILE osmconf.ini -t_srs EPSG:3857 -f GPKG party.gpkg party.osm<\/code><\/pre>
    Здесь мы используем все достижения последних трёх лет: простое скачивание данных из Overpass API, хорошую поддержку формата OSM библиотекой GDAL и формат GeoPackage. Последний опубликован только три года назад и удобен для хранения данных из OSM: в отличие от шейпов, файл получается всего один и при этом непустой.<\/p>\n
    Файл osmconf.ini в комплекте GDAL разочаровывает на каждом шагу: очень мало тегов, даже адресов нет. И нет полигональных водоёмов. То ли дело файл style, приложенный к osm2pgsql. Воспользовался бы последним, но тогда цепочка получилась бы слишком сложной: osm → osm2pgsql → postgresql → ogr2ogr → gpkg. Два шага в этой цепочке выглядят лишними.<\/p>\n
    Оформление карты в QGIS<\/h2>\n
    Было бы здорово сказать: «просто используйте этот стиль на ваш файл», как обычно с мапником или маперитивом, но в мире высоких ГИС не всё так просто. Нужно открывать свойства каждого слоя, кликать на цвета, делать дубликаты, фильтровать. Любое ваше действие QGIS запишет в файл проекта, поэтому я не дам свой: кто знает, какую порнографию вы откопаете в tula.qgs<\/i>. Так что — пошаговая инструкция.<\/p>\n
      \n
    1. Откройте в QGIS файл GeoPackage и добавьте слои lines<\/i> и multipolygons<\/i>. В первом лежат дороги, ручьи и заборы, во втором — здания, парки и водоёмы.<\/li>\n
    2. Справа внизу кликните на «EPSG:4326», включите перепроецирование на лету и выберите проекцию EPSG:3857, привычную по растровым картам.<\/li>\n
    3. Отфильтруем дороги. Кликните правой кнопкой на слое линий, там — «Фильтр». Выделим улицы: highway in (’trunk’, ’primary’, ’secondary’, ’tertiary’, ’residential’, ’unclassified’, ’pedestrian’)<\/tt><\/li>\n
    4. Теперь оформим: двойной клик на слое, во вкладке стиля цвет #777777 и толщину 0,3 мм.<\/li>\n
    5. Во вкладке «Подписи» окна свойств сверху выберите «показывать подписи» и ниже поле «name». Цвет #666666 и размер шрифта 10.<\/li>\n
    6. А что с пешеходными дорожками? Правую кнопку на слое, «Дублировать». Правите теги в фильтре на (’footway’, ’path’)<\/tt> и в свойствах: «простая линия», стиль линии ставите в «штриховая».<\/li>\n
    7. Аналогично для всех остальных слоёв: линии highway=service<\/i>, railway=rail<\/i>, waterway NOT NULL<\/i> и полигоны воды, парков и зданий building NOT NULL<\/i>.<\/li>\n
    8. Для зданий нужно указать подписи не только с номером дома, но и с этажностью. Справа от выбора поля подписи жмите на кнопку «ε» и введите формулу: addr_housenumber || ’\/’ || building_levels<\/tt><\/li>\n<\/ol>\n
      \n\"\"\n<\/div>\n
      На этапе фильтрации данных в слое я понял, что импорт файлов OSM напрямую — это шляпа: на любой чих QGIS мне мерзко отвечал: «какая-то проблема в вашем SQL». Поэтому нужен GeoPackage. Можно справиться и с более старым Spatialite, но зачем.<\/p>\n
      После танцев с бубном в Maperitive (да, я помню их спустя шесть лет!) оформление карты в QGIS — праздник предсказуемости и удовольствие конфигурируемости. Не программирование, а интерактивный выбор из списков. Никаких подписей поверх линий, работает их вытеснение, а линии не меняют толщину и цвет в непонятной зависимости от масштаба. Да и вообще не нужно думать о масштабе. Первые десять минут не верил, что всё так просто, но да: быстро переписал все размеры и цвета из стиля для Maperitive<\/a> и увидел красивую карту.<\/p>\n
      Пирог<\/h2>\n
        \n
      1. Добавьте новый векторный слой типа Polygon. В нём нужны поля name<\/i> (строка) и rotation<\/i> (целое число).<\/li>\n
      2. В его свойствах отключите заливку, добавьте жирный контур и подпись из name<\/i>.<\/li>\n
      3. Включите редактирование и обводите листы для печати, один за другим. Левый клик — добавить точку, правый — завершить. Рисовать лучше прямо по улицам. Поле fid, если есть, заполнять не нужно. Называйте полигоны в формате «14-запад»: номер куска в пироге и указание на его часть.<\/li>\n<\/ol>\n
        Опять же, видя прямоугольники листов на карте, ощутил наступление будущего: не нужно терпеть ме-е-едленный поворот всей карты в Inkscape, элементарно переставить или подвинуть куски. Единственное, чего не хватает, — автоматического вычисления поворота, чтобы каждый кусок печатать в максимально возможном масштабе. Поле rotation<\/i> придётся заполнять самостоятельно.<\/p>\n
        Печать атласа<\/h2>\n
          \n
        1. «Проекты» → «Создать макет», там во вкладке «Атлас» включите его, выберите слой, скройте его и щёлкните на «создать многостраничный документ».<\/li>\n
        2. Добавьте карту и во вкладке «Свойства элемента» отрегулируйте положение и размер. Включите «используется для атласа» с полем 0%, выше свяжите вращение карты с полем rotation<\/i>.<\/li>\n
        3. Добавьте в угол текстовую метку с содержимым [% «name» %]<\/tt> и настройте её вид.<\/li>\n<\/ol>\n
          Это всё — если не нужно поворачивать карту на отдельных листах. Но, конечно, поворачивать надо. Поэтому:<\/p>\n
            \n
          1. Включите предпросмотр атласа.<\/li>\n
          2. В окне QGIS откройте таблицу атрибутов слоя пирога и включите редактирование.<\/li>\n
          3. Для каждого листа оцените поворот в градусах (положительные значения — по часовой стрелке) и впишите в нужную строку. После этого в окне макета нажмите «Обновить» и проверьте угол. Поправьте, если не попали.<\/li>\n
          4. «Следующий объект» — и так далее до последней страницы. Муторно, но всё проще и быстрее, чем в Inkscape.<\/li>\n<\/ol>\n
            Теперь точно всё. Из меню «Атлас» сразу печатайте или сохраните в PDF. Если нужно проверить оформление, напечатайте одну страничку из меню «Макет».<\/p>\n
            Нет, не всё<\/h2>\n
            Боже, двадцать два шага. Пирог «наполеон» готовить проще, чем пирог к очередной картовстрече. Даже с учётом современных технологий получилось длинно и сложно. Клики правой кнопкой мыши, клики левой. Нам нужно проще. Поэтому я начал смотреть, как оптимизировать отдельные этапы. Главное — подбор углов поворота. Глазами получается неточно, а в модуле processing есть интересная функция «oriented minimum bounding box», которая делает ровно то, что нужно: находит повёрнутый прямоугольник минимальной площади, в который вписывается каждый объект слоя.<\/p>\n
            \n\"\"\n<\/div>\n
            Открыл питонскую консоль, набросал короткий скрипт — и действительно, поверх слоя домиков в своём районе увидел россыпь повёрнутых прямоугольников вокруг них. А в атрибутах — размеры и углы. Сохранил скрипт, довольный. Через пару минут дошло: плагины же тоже на питоне пишутся. Если делать не только для себя — нужен плагин. А если делать плагин, то нужно идти до конца, чтобы получилось...<\/p>\n
            Волшебство<\/h2>\n
            Именно по этой причине эта заметка задержалась на три недели. Забудьте все шаги выше. Забудьте Overpass, забудьте ogr2ogr, забудьте свойства слоёв и составление атласов. Теперь подготовка пирога так же проста, как его обход:<\/p>\n
              \n
            1. Установите модуль «Walking Papers».<\/li>\n
            2. Найдите кнопку с синими прямоугольничками и после нажатия выберите «Скачать данные OSM».<\/li>\n
            3. На новом слое нарисуйте (слева вверху карандашик и какая-то область) полигон вокруг области картовстречи. Затем снова жмите «Скачать».<\/li>\n
            4. Ура, есть карта! В слое «Pie Overview» наметьте широкими линиями границы кусков пирога.<\/li>\n
            5. В слое «Pie Sheets» обведите кварталы, которые войдут на каждый лист. Обычно это два-три листа на кусок пирога. Давайте им названия в виде «4-запад», с номером куска и ориентиром внутри него.<\/li>\n
            6. Снова под той же синей кнопкой «Подготовить к печати». Всё, просмотрите листы и экспортируйте в PDF.<\/li>\n<\/ol>\n
              \n\"\"\n
              Картинка со старой версией модуля, где был лишний шаг<\/div>\n<\/div>\n
              Невероятно! Шесть шагов, из которых только два требуют осмысленной работы, чесания головы, пристального взгляда на спутниковые снимки, ворошения прошлых пирогов, захлопывания крышки ноутбука с возгласом «да ну его, завтра нарисую!» Печать качественных<\/i> обходных листов больше не удел гиков, которые «на ты» с таким осмерским софтом, который вы бы не захотели встретить в тёмной подворотне. Жду не дождусь августа, чтобы воспользоваться модулем по назначению.<\/p>\n
              Внутри QGIS<\/h2>\n
              Осталась одна ма-аленькая проблемка. Если повернуть страницу атласа, то её масштаб станет мельче, чтобы вместить все данные с неповёрнутой страницы. А если карта управляется объектами с отдельного слоя, то на вычисление масштаба размеры этих объектов не влияют (посмотрите на отступ до дороги сверху на правом листе на фотографии в начале статьи). Вот незадача: хотели повернуть кварталы вдоль листа, чтобы приблизить их до упора и не мельчить при обходе, а получилось наоборот. Из-за этого поворот карты становится бесполезным. Что же делать?<\/p>\n
              Как известно, открытый софт развивается через боль. Если вас что-то не устраивает в QGIS, вы либо идёте жаловаться в телеграм, либо оплачиваете разработку в NextGIS, либо делаете git clone<\/i> и открываете Qt Designer сами. Будучи ленивым, я пропустил первые два шага, нашёл в исходниках вычисление размеров объекта и всунул в нужное место geometry.rotate()<\/i>. Пул-реквест<\/a> отправился в ветку будущего релиза QGIS 3.0.<\/p>\n
              А дальше я начал узнавать, чем гостеприимный опенсорс отличается от пассивно-агрессивного, как принято в OSM. «Офигенное решение проблемы, спасибо!» — поприветствовал меня один из разработчиков QGIS. И сразу такое тёплое чувство внутри: меня ждали, мне рады, я не зря изучал исходники. «Только допиши тест на питоне, пожалуйста» — и окрылённый, я пошёл изучать систему тестирования QGIS и писать нужную функцию.<\/p>\n
              В процессе наткнулся на неудобство API прямоугольников и дописал функции их сдвига. Так я узнал про SIP bindings и зачем нужен скрипт prepare_commit.sh<\/i>, который нужно запускать до git commit<\/i>. На каждом этапе я мог кинуть клавиатуру в окно от очередного «сделай ещё тут кое-что», но благодаря вежливости и доброжелательности участников проекта я был рад делать ещё и ещё. Только метафорической линейкой по пальцам удержало меня от новых правок и улучшений в коде QGIS. Зачем оставаться в OSM и всё это терпеть, когда там так приятно и легко, и говорят спасибо после мёржа?<\/p>\n
              \n\"\"\n
              Встреча приятных людей в Эссене, фотография Аниты Грейзер<\/div>\n<\/div>\n
              Но проблема осталась<\/h2>\n
              Версия QGIS 2.18 останется в большинстве репозиториев до сентября 2018 года: моя правка в неё не попадёт. Пользоваться модулем хочется прямо сейчас, не дожидаясь новых версий QGIS. Поэтому нужно как-то обойти ошибку. С пул-реквестом за плечами решение оказалось несложным: модуль делает копию слоя пирога с модифицированной геометрией и новыми атрибутами. Новый слой невидимо управляет параметрами карты, чтобы у вас были идеальные обходные листы.<\/p>\n
              Как ещё можно улучшить? Ну, например, сделать рисование листов пирога сразу прямоугольниками пропорций листа А4. Тогда этап вычисления углов поворота станет ненужным. Слой тайлов OpenStreetMap пока приходится подключать вручную через QuickMapServices<\/a>: возможно, лишние клики стоит оптимизировать, общаясь с этим модулем напрямую. Это поможет и для подготовки обзорных страниц в атлас. Наконец, оформление обходных листов зашито в модуль: чтобы его поменять, нужно править файл внутри каталога, но после обновления модуля правки потеряются.<\/p>\n
              Буду ли я улучшать модуль? Нет, он достаточно хорош и мне лень.<\/p>\n
              Писать модули прикольно. Что для JOSM, что для QGIS. По окончании радует ощущение, что операции, которые требовали времени и внимательности, переложены на машину и делаются одной кнопкой. Оформление модуля трудоёмко: нужно копаться в API, разбираться с репозиторием, рисовать значки и не забыть про переводы. Альтернатива — короткие куски кода для консоли python или плагина JOSM Scripting<\/a>. Писать их не проще, а найти потом, когда через год-другой возникнет похожая задача, — почти невозможно. Так что лучше неделю потерять, но потом несколько часов сэкономить.<\/p>\n",
            "date_published": "2017-07-05T11:44:18+04:00",
            "date_modified": "2017-07-05T11:43:25+04:00",
            "image": "https:\/\/shtosm.ru\/pictures\/tula-pies.jpg",
            "_date_published_rfc2822": "Wed, 05 Jul 2017 11:44:18 +0400",
            "_rss_guid_is_permalink": "true",
            "_rss_guid": "https:\/\/shtosm.ru\/all\/obhodnye-listy-v-qgis\/",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css",
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": [
                    "https:\/\/shtosm.ru\/pictures\/tula-pies.jpg",
                    "https:\/\/shtosm.ru\/pictures\/building-layer-labels.png",
                    "https:\/\/shtosm.ru\/pictures\/rotated-buildings-nq8.png",
                    "https:\/\/shtosm.ru\/pictures\/qgis_wp_menu-nq8.png",
                    "https:\/\/shtosm.ru\/pictures\/qgis-essen-meeting.jpg"
                ]
            }
        }
    ],
    "_e2_version": 3576,
    "_e2_ua_string": "E2 (v3576; Aegea)"
}