Комментарии 29
За статью спасибо.
У меня есть два вопроса, которые немного не понял.
1. Откуда берутся данные для работы в программах (карты, планы т т.д.)? Открытые источники есть?
2. Есть ли возможность в перечисленных инструментах по картам высот получать модели рельефа?
У меня есть два вопроса, которые немного не понял.
1. Откуда берутся данные для работы в программах (карты, планы т т.д.)? Открытые источники есть?
2. Есть ли возможность в перечисленных инструментах по картам высот получать модели рельефа?
Преподаю ГИС лесникам, на практических занятиях работают в QGIS. Очень легко дается многим. Единственный недостаток с точки зрения обучения в вузе — слишком быстро развивается, не успеваю каждый год переделывать методички. Раньше работали в Панораме, бррр. Еще была лицензия на ArcGIS, но я попросил ее не продлевать. Не хочу привязывать к продукту, который стоит миллионы.
Судя по беглому взгляду в документацию — возможность встроить QGIS в свое приложение имеется, да?
Карты можно экспортировать в jpeg, или вообще создавать атласы в своих проектах. Если речь о том, чтобы вставить интерактивную карту в веб-приложение, то NextGIS Web дает возможность встраивания кода карты на сторонний сайт. И, в статье не упоминал, но сам QGIS может работать как картографический веб-сервис, так что вводите в локальной сети адрес сервера и получаете карту в браузере.
Спасибо за информацию. Jpeg не подходит. Мне нужно именно полноценное встраивание в декстоп-приложение, желательно без посредников. На данный момент используется веб-апи дубль-гиса во встроенной вкладке с браузером и хочется от него уйти уже, наконец. В документации я вроде как нашел нужную инфу, но там для Qt, с которым я мало знаком. Да и основное приложение написано с использованием другого IDE и языка
Возможность имеется, но лицензия GPL накладывает определенные ограничения на такой продукт. Оцените, насколько это подходит для вашей задачи.
Автору благодарность (и два чая) за большой труд.
Всех заинтересованных приглашаю в https://t.me/nextgis_chat (и в https://t.me/ruosm конечно).
Всех заинтересованных приглашаю в https://t.me/nextgis_chat (и в https://t.me/ruosm конечно).
Статья очень полезна, новичкам в ГИС.
QGIS на самом деле прекрасен.
А еще понравился QGIS MAP SERVER.
Если на клиенте только QGIS то работает в несколько раз шустрее Geoserver-а. Кстати из растра умеет сам тайлы нарезать. Гляньте тоже, скорее всего и вам пригодится.
QGIS на самом деле прекрасен.
А еще понравился QGIS MAP SERVER.
Если на клиенте только QGIS то работает в несколько раз шустрее Geoserver-а. Кстати из растра умеет сам тайлы нарезать. Гляньте тоже, скорее всего и вам пригодится.
Если город описан в OSM, то без проблем. Какой город?
Дык, было недавно.
Адресация дело тонкое, еще более тонкое — фактические границы населенных пунктов. В федеральной адресной системе (ФГИС) проблем с ними множество, но для решения прикладных задач обычно достаточно точности, которую предоставляет OSM.
Навскидку погуглил.
Для Марий Эл нашел только предложение платного скачивания послойной вырезки из карт OSM — 200 рублей тут. Уверен, что можно найти вырезку бесплатно или поработать с послойной картой всей России (см.ниже как). Тоже была на гислаб.
Чтобы далеко не ходить — на странице платного предложения выше есть список стандартных слоев OSM, а при переходе по ним — полей соответствующих таблиц. Нас интересуют два слоя:
В таблицах содержатся схожие поля, описывающие адреса — можем делать с ними что хотим. Конечно, для этих объектов есть геометрия. И если нам из полигона контура здания надо получить x, y точки, то QGIS это легко делает.
BUILDING A_STRT <addr:street>
A_SBRB <addr:suburb>
A_HSNMBR <addr:housenumber>
B_LEVELS <building:levels>
NAME Но надо еще отделить адреса в городе Йошкар-Ола из общей массы, а если скачаете карту всей России, то тем более. Судя по описанию в таблицах домов в адресе нет поля город. Не проблема — берем еще слои из карты. Нам помогут:
или
В них содержатся полигоны границ субъектов федерации, муниципальных и иных территориальных образований, в том числе населенных пунктов. Находим и выделяем в таблице одного из этих слоев нужное территориальное образование. Применяем выделение в другой таблице (с домами) для выделения и копируем выделенные объекты на новый слой. На карте будут точки адресов, подпишите их если надо полями в свойствах слоя. А в таблице слоя — все дома в городе.
Вуаля
Навскидку погуглил.
Для Марий Эл нашел только предложение платного скачивания послойной вырезки из карт OSM — 200 рублей тут. Уверен, что можно найти вырезку бесплатно или поработать с послойной картой всей России (см.ниже как). Тоже была на гислаб.
Чтобы далеко не ходить — на странице платного предложения выше есть список стандартных слоев OSM, а при переходе по ним — полей соответствующих таблиц. Нас интересуют два слоя:
- building-point — 149 объектов
- building-polygon — 123524 объекта
В таблицах содержатся схожие поля, описывающие адреса — можем делать с ними что хотим. Конечно, для этих объектов есть геометрия. И если нам из полигона контура здания надо получить x, y точки, то QGIS это легко делает.
BUILDING A_STRT <addr:street>
A_SBRB <addr:suburb>
A_HSNMBR <addr:housenumber>
B_LEVELS <building:levels>
NAME Но надо еще отделить адреса в городе Йошкар-Ола из общей массы, а если скачаете карту всей России, то тем более. Судя по описанию в таблицах домов в адресе нет поля город. Не проблема — берем еще слои из карты. Нам помогут:
- boundary-polygon -143 объекта
или
- settlement-point — 1630 объеков
В них содержатся полигоны границ субъектов федерации, муниципальных и иных территориальных образований, в том числе населенных пунктов. Находим и выделяем в таблице одного из этих слоев нужное территориальное образование. Применяем выделение в другой таблице (с домами) для выделения и копируем выделенные объекты на новый слой. На карте будут точки адресов, подпишите их если надо полями в свойствах слоя. А в таблице слоя — все дома в городе.
Вуаля
Ссылка на бесплатное скачивание ноябрьской версии карты Марий Эл:
http://be.gis-lab.info/data/osmshp/latest/RU-ME.7z
Скачал, открыл в QGIS — все выше указал верно.
Есть видео как выделить дома в пределах полигона границ территориального образования
Удачи!
http://be.gis-lab.info/data/osmshp/latest/RU-ME.7z
Скачал, открыл в QGIS — все выше указал верно.
Есть видео как выделить дома в пределах полигона границ территориального образования
Удачи!
Очень интересная статья. Спасибо!
Понимаю, что путаю теплое с мягким, однако есть задача сделать себе «наколеночный» редактор слоев карт, которые дальше уже визуализируются средствами JS-библиотек OSM.
Есть ли готовые «велосипеды», которые бы позволил экспортировать карту в определенный формат, а потом визуализировать средствами leaflet, например?
Например, слои можно разместить на каком-нибудь бесплатном или собственном сервере баз данных PostgreSQL, вести с ними работу в QGIS и других приложениях, например LibreOffice, Microsoft Access или Microsoft Excel, а на сайте NextGIS.com один раз настроить слой для отображения на веб-карте.
Понимаю, что путаю теплое с мягким, однако есть задача сделать себе «наколеночный» редактор слоев карт, которые дальше уже визуализируются средствами JS-библиотек OSM.
Есть ли готовые «велосипеды», которые бы позволил экспортировать карту в определенный формат, а потом визуализировать средствами leaflet, например?
Форматов, в которые выгружаются слой из QGIS много, можно поразбираться.
Но если правильно понял вопрос, то надо сформировать, например, код JS для размещения 100 объектов на карте. Пусть это будут 100 полигонов.
Заглядываю в пример со страницы библиотеки:
Если изменения не очень частые, то вручную бы взял координаты из QGIS, обработал и слепил бы строки в Excel. Или, если требуется постоянная корректировка данных, то да, зарядил бы, через базу данных по тому же принципу:
— Открываю QGIS, создаю слой полигонов с системой координат WGS 84 (EPSG:4326) и наношу объекты на этот слой. Затем открываю таблицу слоя и щелчком по левому верхнему углу выделяю всю таблицу. Копирую через CTRL-C. Вставляю на лист Microsoft Excel. Получаю созданную ранее таблицу с аттрибутами, но с еще одним столбцом геометрии в весьма читаемом виде. Пример значения столбца:
Далее через CTRL-H меняю.
", " ---> "],@["
«Polygon ((» ---> «var@polygon@=@L.polygon([»
"))" ---> "]).addTo(mymap);"
" " ---> ",@"
"@" ---> " "
Все, строки выглядят так:
Строго по образцу, на весь перенос не более пяти минут и копипасте из Excel в код.
Но если правильно понял вопрос, то надо сформировать, например, код JS для размещения 100 объектов на карте. Пусть это будут 100 полигонов.
Заглядываю в пример со страницы библиотеки:
var polygon = L.polygon([
[51.509, -0.08],
[51.503, -0.06],
[51.51, -0.047]
]).addTo(mymap);
Если изменения не очень частые, то вручную бы взял координаты из QGIS, обработал и слепил бы строки в Excel. Или, если требуется постоянная корректировка данных, то да, зарядил бы, через базу данных по тому же принципу:
— Открываю QGIS, создаю слой полигонов с системой координат WGS 84 (EPSG:4326) и наношу объекты на этот слой. Затем открываю таблицу слоя и щелчком по левому верхнему углу выделяю всю таблицу. Копирую через CTRL-C. Вставляю на лист Microsoft Excel. Получаю созданную ранее таблицу с аттрибутами, но с еще одним столбцом геометрии в весьма читаемом виде. Пример значения столбца:
Polygon ((35.93971509137796261 56.84680113750829378, 35.94017645918111015 56.84715874618873244, 35.94050731111398278 56.84702646086687139, 35.94121239322927153 56.84676224849280857, 35.94044389596734135 56.84617271621075218, 35.93949998958188985 56.84652204346423332, 35.93981141884147945 56.84676244409779144, 35.93971509137796261 56.84680113750829378))
Далее через CTRL-H меняю.
", " ---> "],@["
«Polygon ((» ---> «var@polygon@=@L.polygon([»
"))" ---> "]).addTo(mymap);"
" " ---> ",@"
"@" ---> " "
Все, строки выглядят так:
var polygon = L.polygon([35.93971509137796261, 56.84680113750829378], [35.94017645918111015, 56.84715874618873244], [35.94050731111398278, 56.84702646086687139], [35.94121239322927153, 56.84676224849280857], [35.94044389596734135, 56.84617271621075218], [35.93949998958188985, 56.84652204346423332], [35.93981141884147945, 56.84676244409779144], [35.93971509137796261, 56.84680113750829378]).addTo(mymap);
Строго по образцу, на весь перенос не более пяти минут и копипасте из Excel в код.
… а потом обнаружить, что в полигонах бывают дырки…
… а потом обнаружить, что попадаются еще MULTIPOLIGON и, не приведи господь, CURVEPOLYGON…
… а потом обнаружить, что длина записи для содержимого ячеек Excel 32767 знаков, а WKT каких-то объектов вылезает далеко за эти пределы…
Не то чтобы решение плохое — сам множество операций делаю в Excel. Просто есть подводные камни )
Если окажется, что штатными средствами имеющихся программ задача не решается, рекомендую посмотреть на библиотеку NetTopologySuite (или JavaTopologySuite, или GEOS — смотря какой язык вам доступнее). Там из WKT-текста легко создать геометрические объекты, с которыми можно делать уже все, что заблагорассудится.
Если говорить про обработку геометрии в БД — то копайте в сторону PosgreSQL + PostGIS, не изобретайте велосипедов самостоятельно.
… а потом обнаружить, что попадаются еще MULTIPOLIGON и, не приведи господь, CURVEPOLYGON…
… а потом обнаружить, что длина записи для содержимого ячеек Excel 32767 знаков, а WKT каких-то объектов вылезает далеко за эти пределы…
Не то чтобы решение плохое — сам множество операций делаю в Excel. Просто есть подводные камни )
Если окажется, что штатными средствами имеющихся программ задача не решается, рекомендую посмотреть на библиотеку NetTopologySuite (или JavaTopologySuite, или GEOS — смотря какой язык вам доступнее). Там из WKT-текста легко создать геометрические объекты, с которыми можно делать уже все, что заблагорассудится.
Если говорить про обработку геометрии в БД — то копайте в сторону PosgreSQL + PostGIS, не изобретайте велосипедов самостоятельно.
есть задача сделать себе «наколеночный» редактор слоев карт, которые дальше уже визуализируются средствами JS-библиотек OSM.
… а потом обнаружить, что в полигонах бывают дырки…
… а потом обнаружить, что попадаются еще MULTIPOLIGON и, не приведи господь, CURVEPOLYGON…
… а потом обнаружить, что длина записи для содержимого ячеек Excel 32767 знаков, а WKT каких-то объектов вылезает далеко за эти пределы…
Речь идет о том, чтобы самому наносить объекты. Так что вероятность таких проблем минимальна.
Статья полезная, спасибо.
Выскажу только пару замечаний/дополнений.
1. Формат SHP, конечно, по-своему хорош. Хотя бы тем, что он открытый, и его «едят» практически любые ГИС-программы. Но поскольку он весьма древний, есть у него свои ограничения: геометрия только одного типа на слой (либо точки, либо линии, либо полигоны), довольно узкие ограничения по длине наименований, длине значений и количеству полей; часто возможны проблемы с кодировкой текста (особенно, если передавать между разными программами). Плюс обработка SHP-файлов довольно медленная, что для больших объемов может быть критичным. Как альтернативу предлагаю рассмотреть SQLite — он также поддерживается многими программами (хоть и не столь широко) и лишен большинства недостатков SHP. В одном файле SQLite можно собрать сразу несколько слоев (иногда это плюс, иногда минус) и даже организовать связи между ними через внешние ключи.
2. Про географические системы координат — строго говоря, в школе мы не изучали WGS84, т.к. это система координат на конкретном (забугорном) эллипсоиде. То, что изучалось в школе, правильнее назвать LL (Долгота/Широта без привязки к конкретному элипсоиду). Но это мелочь. Гораздо серьезнее то, как вы создали СК, подобрав параметры эмпирическим путем. Вы, конечно, вольны делать, как вам удобно, но рядом надо приписать: НЕ ПОВТОРЯЙТЕ НИ В КОЕМ СЛУЧАЕ! Любая эмпирика в вопросах систем координат неизбежно рано или поздно приводит к тому, что накапливается значительный объем данных, привязанных черт знает как, и который потом кому-то надо пытаться привести в нормальный вид. И если при использовании разных, но известных СК это еще хоть как-то возможно (и то не гарантировано, если в разное время в один источник пишутся данные с разными видами привязки), то в случае таких вот пользовательских, искусственно подогнанных координат, накопленные данные рискуют отправиться в конце концов в мусорку.
В остальном — да, неплохой ликбез.
Выскажу только пару замечаний/дополнений.
1. Формат SHP, конечно, по-своему хорош. Хотя бы тем, что он открытый, и его «едят» практически любые ГИС-программы. Но поскольку он весьма древний, есть у него свои ограничения: геометрия только одного типа на слой (либо точки, либо линии, либо полигоны), довольно узкие ограничения по длине наименований, длине значений и количеству полей; часто возможны проблемы с кодировкой текста (особенно, если передавать между разными программами). Плюс обработка SHP-файлов довольно медленная, что для больших объемов может быть критичным. Как альтернативу предлагаю рассмотреть SQLite — он также поддерживается многими программами (хоть и не столь широко) и лишен большинства недостатков SHP. В одном файле SQLite можно собрать сразу несколько слоев (иногда это плюс, иногда минус) и даже организовать связи между ними через внешние ключи.
2. Про географические системы координат — строго говоря, в школе мы не изучали WGS84, т.к. это система координат на конкретном (забугорном) эллипсоиде. То, что изучалось в школе, правильнее назвать LL (Долгота/Широта без привязки к конкретному элипсоиду). Но это мелочь. Гораздо серьезнее то, как вы создали СК, подобрав параметры эмпирическим путем. Вы, конечно, вольны делать, как вам удобно, но рядом надо приписать: НЕ ПОВТОРЯЙТЕ НИ В КОЕМ СЛУЧАЕ! Любая эмпирика в вопросах систем координат неизбежно рано или поздно приводит к тому, что накапливается значительный объем данных, привязанных черт знает как, и который потом кому-то надо пытаться привести в нормальный вид. И если при использовании разных, но известных СК это еще хоть как-то возможно (и то не гарантировано, если в разное время в один источник пишутся данные с разными видами привязки), то в случае таких вот пользовательских, искусственно подогнанных координат, накопленные данные рискуют отправиться в конце концов в мусорку.
В остальном — да, неплохой ликбез.
1. Насчет SQLite — согласен. Но не хочется заводить начинающего пользователя в дебри. Тем более, при работе с SQLite столкнулся с проблемами именования полей. Только короткие, латиница, запрещенные слова «type», «source», «id», и прочее.
2. Географические системы координат — да, но опять же, ставил задачей направить пользователя по кратчайшему маршруту. Хочешь получать географические координаты — настрой слой на систему координат WGS 84.
Насчет эмпирической пользовательской системы — не согласен. Многое зависит от задач.
Из публичной кадастровой карты поворотные точки, по моей информации, не получить никак — надо для каждого участка заказывать кадастровые паспорта. А для принятия управленческих решений на основе визуализированных данных устранение сдвига с любой погрешностью благо.
Кроме того, эта система применяется ведь не к моему слою, а к тому, который выдает ПКК. Так что мы эти данные не храним и не копим.
Кстати, может кто знает, как из ПКК получить контур участка на свой слой?
2. Географические системы координат — да, но опять же, ставил задачей направить пользователя по кратчайшему маршруту. Хочешь получать географические координаты — настрой слой на систему координат WGS 84.
Насчет эмпирической пользовательской системы — не согласен. Многое зависит от задач.
Из публичной кадастровой карты поворотные точки, по моей информации, не получить никак — надо для каждого участка заказывать кадастровые паспорта. А для принятия управленческих решений на основе визуализированных данных устранение сдвига с любой погрешностью благо.
Кроме того, эта система применяется ведь не к моему слою, а к тому, который выдает ПКК. Так что мы эти данные не храним и не копим.
Кстати, может кто знает, как из ПКК получить контур участка на свой слой?
Надо же, у меня ровно обратный опыт — в SHP жесткие ограничения на именования полей (латиница, без пробелов, до 30 знаков, если не ошибаюсь), а в SQLite — хоть русскими буквами с пробелами, и без проблем.
А откуда вы знаете, что к чему надо подтягивать? Какой из источников точнее? Потом на карте с подтянутыми данными будут размещены какие-то объекты, на их основе выпущена какая-то производная документация, и пошло-поехало, концов не найдешь. Повторюсь, для своей задачи вы вольны делать, как посчитаете нужным (особенно, если хорошо понимаете, что делаете), но во вводной статье для новичков я бы не стал давать такие «бест-практисес».
Опять же, значения, которые вы подобрали, подходят для вашего района, в котором вы работаете. В соседнем (а тем более в удаленном) кадастровом районе смещения будут совершенно другими. И если в каждом районе подбирать свои эмпирические коэффициенты, увязать потом все воедино будет совершенно нереально (а то, что у Росреестра у самого данные между районами не сбиты, только усугубит проблему).
Одно время на ПКК был доступен публичный сервис, позволяющий получать данные по кадастровым участкам в JSON в любой системе координат, но потом эту лавочку прикрыли. В любом случае, такое использование противоречило пользовательскому соглашению, потому что на выписках они деньги зарабатывают.
Так что, думаю, правильный ответ: «законно — никак».
устранение сдвига с любой погрешностью благо.
А откуда вы знаете, что к чему надо подтягивать? Какой из источников точнее? Потом на карте с подтянутыми данными будут размещены какие-то объекты, на их основе выпущена какая-то производная документация, и пошло-поехало, концов не найдешь. Повторюсь, для своей задачи вы вольны делать, как посчитаете нужным (особенно, если хорошо понимаете, что делаете), но во вводной статье для новичков я бы не стал давать такие «бест-практисес».
Опять же, значения, которые вы подобрали, подходят для вашего района, в котором вы работаете. В соседнем (а тем более в удаленном) кадастровом районе смещения будут совершенно другими. И если в каждом районе подбирать свои эмпирические коэффициенты, увязать потом все воедино будет совершенно нереально (а то, что у Росреестра у самого данные между районами не сбиты, только усугубит проблему).
как из ПКК получить контур участка на свой слой?
Одно время на ПКК был доступен публичный сервис, позволяющий получать данные по кадастровым участкам в JSON в любой системе координат, но потом эту лавочку прикрыли. В любом случае, такое использование противоречило пользовательскому соглашению, потому что на выписках они деньги зарабатывают.
Так что, думаю, правильный ответ: «законно — никак».
Извините за критику, но...
Не совсем понятно назначение статьи. Если бы автор написал свой пользовательский опыт: как он конкретно решал свои бизнес-залачи, чего удалось достичь, тогда бы простить можно все понятийные и технические огрехи, т. к. понятно, что автор непрофессионал в геоинформатике, только недавно узнал про этот пласт человеческих знаний.
Если же это в стиле рекламной брошюры QGIS, то количество фактических ошибок по классам ПО, форматам данных, системам координат и пр. превращает содержимое в бесполезную тыкву, которая только навредит тем, кто также захотел немного узнать о геоинформационном ПО.
Таким образом:
подробные технические описания с кучей ошибок вредны и никому пользы не несут. Новички будут дезинформировали, профессионалы поржут.
бизнес-кейс не раскрыт и менеджменту нечего почерпнуть полезного, а технические описания их могут не сильно интересовать.
Я бы удалил такую писанину...
Автору спасибо за труд! Но писать надо о вещах, в которых хорошо разбираешься, чтобы это приносило пользу обществу. Иначе, это графоманство.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бесплатные геоинформационные решения QGIS и NextGIS