OpenStreetMap *

Про городской округ Сочи я высказывал свое мнение в "Я бы не жил в Сочи в этих местах…"

В этой статье найду места на оставшейся части побережья Краснодарского края на основе данных OpenStreetMap где могут быть проблемы из-за близости к жилью не самых комфортных мест для уютной жизни на побережье Черного Моря. Показать результаты работы моей модели для Туапсе просили еще в комментариях к первой статье "Где бы вы точно не жили и не остановились даже на время, если бы знали и выбирали на основе фактов".

В одной прошлых публикации получил массу полезных коментариев от читателей. Среди них просили для Москвы кроме "плохих" районов было бы интересно увидеть и хорошие.

Честно скажу, что определить какие хорошие непросто. Ведь у каждого свое понятие о том что такое хорошо и нужен доступ к данным, которого у нас нет. Поэтому давайте посмотрим где жить "неплохо". Не жить рядом с тем, что влияет на качество воздуха, уровень шума, ежедневное memento mori, близость к промышленности, безопасность. Найдем группы домов в Москве в пределах МКАД, отдаленные на 150м от перечисленных факторов. Если живете в Москве, то удивитесь - вашего дома скорее всего не будет на этой карте

_{Дисклеймер:
Все нижеизложенное является лишь наблюдением и субъективной оценкой на основе личного опыта автора, а не утверждением.}

ПО OsmAnd расшифровывается, как OpenStreetMap Automated Navigation Directions (источник: оф.сайт), а не как пишут, на некоторых форумах, например, на 4pda, как ОпенСтритМапАНДроид.

В этот раз спустимся южнее, в городской округ Сочи и Сириус! Найдем места где могут быть проблемы из-за близости к жилью не самых лучших мест для уютной жизни на побережье Черного Моря и в горах у Красной Поляны.

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

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

В прошлой публикации "Где бы вы точно не жили и не остановились даже на время, если бы знали и выбирали на основе фактов" читатели здорово помогли с новыми идеями в коментариях для настройки модели, которая отговаривает меня жить в определенных местах. Модель достаточно прозрачная для ее чтения и проверки: не использует ChatGPT/Llama 2 и прочие новомодные штуки, и даже без old-school дифур.
Она просто считает расстояние по прямой в метрах от жилого здания до тех мест в окрестности, рядом с которыми я не хотел бы постоянно находиться.

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

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

Что общего во всех этих факторах, кроме того что я сгустил краски StableDiffusion? В описаном примере для многих людей есть не только экологическая, но психологически дискомфортная составляющая. В студенчестве, в части диплома, связанной с экологией, были расчеты уровня шума в жилых помещениях от трассы/индустриальных объектов. Главный параметр был - расстояние по прямой от жилья.

Зачем? Это странно...

Сегодня открою вам Америку на основе данных OpenStreetMap в PostgreSQL15/PostGIS и моего проекта openstreetmap_h3. Запустим запрос и сравним время его выполнения на колоночном хранилище Citus в PostgreSQL и на стандартном в секционированной по H3 геоиндексу базе данных объемом 100GB.

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

Продолжим тему из публикации «Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap».

Сегодня визуализируем 15 мест где в России больше всего зданий. В этом нам поможет мой проект openstreetmap_h3 и PostgreSQL 15. На данный момент OpenStreetMap H3 единственное решение для импорта OSM данных партиционированных по H3 геоиндексу в PostgreSQL и Citus massive parallel processing. Сохраним данные в колоночное хранилище и посмотрим на план запроса для него.

В этой публикации мы будем агрегировать данные в большой таблице где нас интересуют для этих операций лишь два столбца и сможем извлечь пользу от этой модели данных на NVMe накопителе. Раньше я работал с колоночными базами данных AWS Redshift, Dremio, QuestDB и HeavyDB, но не смотря на их производительность, до функционала/протестированности и стабильности PostgreSQL им еще пока еще ох как далеко. Вот и отлично, попробуем получить все плюсы экосистемы PostgreSQL и колоночного хранилища citus. Вперед, к заветной цели на самых свежих версиях программ нашего аналитического стека!

Зачем же обычному человеку информация из прошлой публикации "Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap"? Если надоело в пятницу читать мемасики и лайкать фотографии котиков в соцсетях, то можно задаться глобальными проблемами аналитики и посчитать протяженность дорог России. Ведь не за горами времена автомобилей с автопилотами... Это конечно не 42, как ответ на главный вопрос жизни, вселенной и всего такого, но результаты будут тоже достаточно лаконичными.

Для этого нам понадобится ноутбук или обычный десктоп, несколько десятков гигабайт свободного места, установленный docker, JVM 11+, maven и мой проект openstreetmap_h3. Анализировать геоданные мы будем с помощью PostgreSQL 15.1, PostGIS 3.3.2, H3 4.1.1. Исходные данные из проекта OpenStreetMap, запросы к БД не претендуют на правильность и качество исходных данных в масштабе страны нам не известно! Данная публикация является грубой интерпретацией данных OSM в первом приближении и не претендует на истинность и неопровержимость. Так же как не стоит верить оценке Хабра на чтение статьи в 127 минут, что сильно превышает реальные 5 минут, которые вы потратите на ознакомление с публикацией.

Продолжу рассказ "Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap" секретами о геоданных OpenStreetMap, на которых множество компаний построили бизнес но не все делятся подробностями... Что ж, сегодня приоткроем завесу!

База данных в PosgreSQL после загрузки из дампа занимает больше 587 GB. Это уже по меркам СУБД большая база и одна огромная таблица на каждый тип объектов не сработает. Для управляемости такие данные надо секционировать, хорошо что PostgreSQL поддерживает декларативное секционирование данных. Осталось лишь придумать как разделить географические данные. После поисков и сравнений мне на помощь пришла иерархическая гексагональная геопространственная система индексирования H Все это было реализовано в моем проекте openstreetmap_h3 для быстрой обработки и загрузки мира в базу.

Когда человек раньше говорил что он контролирует весь мир, то его обычно помещали в соседнюю палату с Бонапартом Наполеоном. Надеюсь, что эти времена остались в прошлом и каждый желающий может анализировать геоданные всей земли и получать ответы на свои глобальные вопросы за минуты и секунды. Я опубликовал Openstreetmap_h3 — свой проект, который позволяет производить геоаналитику над данными из OpenStreetMap в PostGIS или в движке запросов, способном работать с Apache Arrow/Parquet.

Первым делом передаю привет хейтерам и скептикам. То что я разработал — действительно уникально и решает проблему преобразования и анализа геоданных используя обычные и привычные инструменты доступные каждому аналитику и датасаенс специалисту без бигдат, GPGPU, FPGA. То что выглядит сейчас простым в использовании и в коде — это мой личный проект в который я инвестировал свои отпуска, выходные, бессонные ночи и уйму личного времени за последние 3 года. Может быть я поделюсь и предысторией проекта и граблями по которым ходил, но сначала я все же опишу конечный результат.

Первый пост не претендует на монографию, начну с краткого обзора...

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

Недавно мы запустили офлайн карты для Apple Watch. Проект занял более 2 лет и потребовал огромного внимания со стороны нашей небольшой команды энтузиастов. Мы столкнулись с таким количеством продуктовых и технических сложностей, что просто не может не поделиться этим с вами. Вот наша история.

Японцы уже в 2018 году научили немецкий GraphHopper строить маршруты по дорогам хранящимся в PostgreSQL.

Как кастомизировать источник данных, и сохранять новые дороги в таблицу правильно?

JVM основная платформа для Big Data решений, таких как Hadoop, Spark, Presto, NiFi но на производительность значительно влияют копирование/сериализация данных "на каждый чих" с последующей сборкой мусора и отсутствие SIMD оптимизаций при работе с данными.

А можно ли в программе на JVM прочитать сотни гигабайт Parquet файлов без Spark/Hadoop? В этом нам поможет библиотека Apache Arrow - проект, которым объединяются десятки решений для работы с Большими Данными. Но для этого даже не обязателен кластер с тысячами ядер и петабайты хранилища! Обработку данных начнем с "золотого стандарта" для open source: PostgreSQL 14 + PostGIS 3.2.0, а продолжим на OpenJDK 11 + Apache Arrow 9.0.0.

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

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

Эти статьи предназначены для людей, которым интересна тема агрономии. Возможно вы студент, или уже опытный фермер, в любом случае найдёте для себя что-нибудь интересное или новое. Моя задача объяснить не совсем понятные вещи простым языком.

Пошаговая инструкция о том, как установить и использовать расширение PostGIS для PostgreSQL в Docker.

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

[Научно-спортивный препринт].

🔥 Пару дней назад я совершил суточный велопоход в 270 км с амбициозными целями, которые я расписал в статье...