Метка «OSM»

За два дня до начала олимпиады наша небольшая команда из трех человек решила поставить эксперимент. Возможно ли за такой короткий срок, а у нас оставалось где-то 50 часов с перерывами на небольшой сон, сделать какой-нибудь полезный и относительно интересный сервис на олимпийскую тематику? То ли из-за сильно сжатых сроков, то ли из-за большого желания принять хоть какое-то (пускай и виртуальное) участие в проведении олимпиады, ответ пришел очень быстро и как-то сам собой. Мы решили сделать агрегатор геопривязанного пользовательского контента из социальных сетей на карту города Сочи.

image image

Читать полностью »

Для работы мы используем postgresql + postgis базу данных с данными для всей планеты от osm.org. На диске она занимает около 350 Gb и работает не быстро, да и хранится на обычном винчестере 2Tb 7200rpm, без RAID-a. Т.к. нагрузка на базу данных постепенно растет, было решено ускорить дисковую подсистему, потратив при этом минимум денег. Вариантов было не много:

  • или купить еще один такой же винчестер и объединить их в raid-0.
  • или купить небольшой SSD и организовать на нем быстрый кэш:
    • dm-cache. Был добавлен в ядро 3.9, ставится просто.
    • bcache. Судя по обзорам самый быстрый. Основной минус — надо форматировать диски перед началом использования. Официально добавлен в ядро 3.10, распространяется как пропатченое ядро 3.9.
    • EnhanceIO. В обзорах я встретил упоминание его, как самого медленного, но простого в использовании. Добавлен в ядро 3.10.

Взвесив плюсы и минусы, а так же спросив отзывы знакомых, я решил остановиться на bcache. О нем и расскажу подробнее.
Читать полностью »

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

Сказ о том, как мы карту с биллингом дружили
Читать полностью »

Все начилось с того, что при разработке геопорталов с использованием ArcGis, заказчики все чаще стали говорить что-то типа: " Нам все нравится, а вот можно все тоже самое сделать, но с использованием открытого ПО", подразумевая при этом замену связки MSSQL+ ArcGis Server + ArcGis Javascript (Silverlight) Toolkit на Postgres (PostGis) + Geoserver + Openlayers.
Ну вобщем-то их понять можно т.к. меняется 1-2-3 млн руб на 0 руб. Особой проблемы в большинстве своем это не представляло, векторные данные переводятся либо через SHP файлы, либо через конвертеры из MSSQL в PostGis (либо просто через запросы SQL). Остался вопрос с растровыми данными. Например есть хорошо прорисованный, настроенный и многоуровневый кэш карты России. В ArcGis он хранится либо в компактном виде (в виде бандлов понятного только ArcGis формата) либо некомпактный, то есть тайлы карты просто лежат в директориях. Тут я обрадовался и подумал, что во втором-то случае точно будет все просто. А нет — тайлы конечно разбиты по уровням однако имеют странные имена и могут лежать в странных подпапках, а с геопривязкой этого кэша вобще беда.
Но потом пришло очень простое и быстрое решение — просканировать свой же сервис (так как сервис отдает тайлы по понятному URL вида "...MapServer/tile/Z/Y/X" где Z — номер уровня, а X и Y номера тайлов по горизонтали и вертикали соответственно). Теперь остался другой вопрос — как эти привязанные тайлы положить на Geoserver? В Geoserver для таких целей используется Image Pyramid Plugin, точнее не совсем для таких — его в основном используют для упрощения работы с гигантскими TIFF файлами, скрипт gdal_retile из пакета gdal проходится по TIFF файлу и создает множество мелких геопривязанных тайлов на разных уровнях, разбитых по папкам с номерами уровней.
Вот собственно и все исходные данные. По ним я сначала написал приложение на родном C#, но решил следовать путем настоящего OSS и переписал на Java, естественно выложив код на GitHub.

Читать полностью »

В Украине открыли доступ к Государственному земельному кадастру. Даже интерактивную карту запилили: map.dazru.gov.ua/kadastrova-karta

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

В частности, украинские оптимизаторы не чужды использованию открытых крауд-сорсных источников карт. По умолчанию карта открывается со слоем карт из OpenStreetMaps. И, конечно же, на этом государственном источнике кадастровой информации отображается вся правда из этих народных карт, например факты незаконного захвата территории в Харьковском Лесопарке, обозначенные в OSM как «Самозахват»:

Читать полностью »

Пролог

Проект OpenStreetMap (OSM) открытых геоинформационных данных под свободной лицензией CC-BY-SA (а в скором времени под Open Database Licence) известен достаточно широко, что бы не тратить время на его подробное представление. Главной особенностью проекта и его основным преимуществом по сравнению с любыми другими аналогами являлся принцип полностью открытых географических данных, которые могут быть использованы кем угодно и и как угодно (в рамках лицензи CC-BY-SA) и могут свободно дополняться и уточняться любым участником проекта. Как и любые другие данные, географические данные точно так же подлежат структурированию при хранении и обработке. В данной статье я постараюсь описать основные части структуры данных OSM остановившись больше на принятых типах данных и представлении их в пространственном виде. Работая постоянно с данными проекта OSM очень часто приходится уточнять или пояснять не которые базовые аспекты, поэтому возникла необходимость кратко изложить их в виде одного текста.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js