Osm pbf чем открыть
Обновлено: 03.07.2024
Работая над проектом, связанным с обработкой геоданных, возникла необходимость в геокодере. Развернув довольно популярное решение на базе nominatim и попробовав геокодировать адреса разной степени испорченности, я пришел к выводу, что работает он так себе. Даже скармливая ему достаточно адекватные названия улиц, nominatim зачастую не мог их распознать.
Проблема, судя по всему, заключалась в том, что он буквально трактовал передаваемые ему адреса. Например, найти "Караванная улица, Санкт-Петербург" ему не составляло труда, а вот где находится "улица Караванная, Санкт-Петербург" он, почему-то, не знал.
Вторым минусом были совершенно непомерные аппетиты в области занимаего места. Развернутая база данных РФ занимала порядка 50GB, рзворачивалась целую ночь, а ведь ее еще обновлять надо. А если страну добавить? А фиг вам, встроенные в nominatim утилиты такого не позволяют. Приходилось с нуля разворачивать.
В общем, решил я разобраться с данными osm, и попробовать реализовать свое решение. Хотелось, чтобы оно занимало приемлемое количество места, легко разворачивалось и быстро работало.
Готовим данные
Скачиваем себе файл:
Формат данных osm.pbf
Что же это за формат - osm.pbf? Есть формат .osm - это просто xml с данными OpenStreetMap, а osm.pbf - это бинарная версия osm. Чтобы понять, что в нем находится, создадим postgresql базу данных и, используя утилиту ogr2ogr, заполним ее данными из osm.pbf файла.
Конвертируем данные
Необходимо установить пакет gdal-bin, который включает в себя утилиту ogr2ogr:
Теперь создаем тестовую базу данных, в которую загоним данные data.osm.pbf:
Запускаем конвертор (не забудьте указать свои настройки подключения):
Разбиремся с данными
Как же организованы OpenStreetMap данные? Есть три основных типа объектов:
Из этих объектов строятся более сложные объекты. Давайте расмотрим на примере города Иркутска.
Область, занимаемая городом, образует полигон:
<relation - говорит о том, что у нас составной объект c id=1430614.
<tag k="addr:country" v="RU"/> - тэги, которые подробно описывают объект; именно они составляют всю "соль" объекта и, на основании тэгов, мы будем формировать нашу БД для геокодинга. Атрибут k задает ключ тэга, а v, соотвтественно, значение.
Хранится в xml следующим образом:
<way - объект типа путь с >
<nd ref="3878810419"/> - объект типа узел (node) с id=3878810419, в xml хранится следующим образом:
Давайте найдем город в нашей сформированной базе данных:
Отбросил часть столбцов, которые используются для задания специфических характеристик объектов:
- ogc_fid - id нашей базы;
- osm_id - id в базе OSM;
- name - имя;
- type - тип объекта (тут у всех multipolygon);
- place - семантика полигона, то есть город, область, село, остров и т.д. (список возможных значений: SELECT DISTINCT place FROM multipolygons);
- other_tags - те тэги, под которые не выделены отдельные столбцы (это особености поведения ogr2ogr: под часть тегов выделяютс столбцы, под часть нет).
Стоит отметить то, как мы можем получить к ним доступ. Для этого мы и подключили расширение hstore к нашей базе:
Выдаст нам "Иркутская область".
Можно немного и поэкспериментировать теперь. Вот следующая выборка должна выдать нам все дома на улице Байкальской, города Иркутск:
Но тут есть небольшие сложности, связанные с тем, что не для каждого дома указываются все теги. Обычно заполняютя только самые важные. То есть улица и номер дома там будет, а вот название города могут и не указать. Из-за этого использовать данные без предварительной обработки не получится. В принципе, эта проблема вполне решаема и мы справимся с ней, но чуть позже.
Формируем базу
Мы будем использовать imposm3 для конвертации данных в postgres базу. Эта утилита написаная на go - простая и удобная в испльзовании. Позволяет настроить мэппинг и фильтрацию данных. Благодаря этому, мы сэкономим время, затраченное на конвертацию, и место на жестком диске. Нас интересует определение географического местоположения по адресу: номер дома, улица, город. Следовательно, только эти данные мы и будем писать базу.
Устанавливаем imposm3
Для использования imposm3 необходмо иметь установленный golang версии не ниже 1.6 и настроенную переменную GOPATH.
Дальше все просто:
Чтобы утилита была доступна в терминале, не забудьте добавить $GOPATH/bin в $PATH.
Заполняем БД
База данных osm_data_test была у нас тестовая, исключительно для целей изучения сырых данных, предоставляемых osm файлом. Теперь давайте сделаем базу данных под наши специфические нужды (хотя можно было бы использовать и osm_data_test):
Я собираюсь организовать две таблицы:
- одна будет содержать все возможные города/поселки/села с геометрией и прочей полезной инофрмацией;
- вторая будет хранить здания.
Создадим файл mapping.yml и заполним его следующим образом:
Созадим конфигурационный imposm3_config.json файл, чтобы не передавать настройки подключения к БД каждый раз:
Запускаем конверсию и ждем:
Корректируем базу
Теперь у нас есть база данных с двумя таблицами osm_buildings и osm_cities. Давайте подключимся к ней.
Возможно, вы заметили, что там есть еще таблица spatial_ref_sys. Она создается при подключении расширения postgis и содержит числовые ID и текстовые описания систем координат, используемых в пространственной базе данных.
Попробуем выбрать все здания Иркутска:
Все работает очень быстро, так как imposm3 позаботился о создании индексов, но если посмотреть, то огромное количество записей имеет незаполненое поле city. Помните, я писал, что не у всех объектов может быть заполнено поле city, тем не менее, используя postgis функцию st_contains, вычисляющую принадлежность одной геометрии другой (в нашем случае принадлежность полигона здания полигону образующему границы города), мы можем сопоставить город зданию, игнорируя значение osm_buildings.city.
Давайте заполним незаполненые значения поля city в таблице osm_buildings:
Настраиваем поиск
Для поиска я буду использовать возможности postgreqsl для полнотестового поиска.
Рассмотрим процесс преобразования в вектор для полнотекстового поиска:
Если вывод у вас выглядит как-то по-другому, скорее всего, у вас используется не русский язык по умолчанию. В этом случае укажите его явно:
Либо, в качестве альтернативы, вы можете указывать язык явно при построении вектора:
Пойдем дальше. Добавим строку запроса, по которой строится сопоставление:
Получим такой ответ:
Теперь можем выполнить проверку на сопоставление, используя оператор @@:
По сути, идет проверка вложености лексем правого выражения в вектор лексем левого выражения, поменяем текст для вектора со строкой запроса, и такой запрос выдаст нам ложь:
На самом деле postgresql позволяет стоить более сложные запросы, чем те, в которых идет провека на полную вложеность, подробнее об этом можно почитать тут.
Добавляем файл с сокращениями
В адресах часто встречаются различные сокращения для слов: улица как ул., бульвар как бул. и т.д.
Например, очень хотелось бы, чтобы такой запрос выдавал все-таки TRUE:
Для того, чтобы поиск работал лучше, нам потребуется сделать файл с сокращениями. В папке /usr/share/postgresql/9.6/tsearch_data создадим файл thesaurus_russian_postgis.ths и добавим в него следующее содержимое:
Теперь надо его активировать для БД. Для этого выполним следующие команды:
Если захочется, словарь можно будет DROP-нуть, но прежде его надо будет деактивировать:
Теперь можно проверить, как работает пробразование:
Далее, при преобразовании текста лексемы заменяеются на свои сокращенные копии. И, таким образом, наш запрос выдаст уже вполне адекватный ответ:
Создаем индекс для полнотекстового поиска
Теперь, когда мы более менее ориентируемся в посторении полнотекстовых запросов, можно перейти к нашей базе. У нас информация по зданиями хранится в таблице osm_buildings. Мы соберем общий текстовый вектор из трех полей city, street, housenumber. Выглядеть это будет примерно так:
Если запустить следующий запрос, который должен выдать нам все дома на улице Лермонтова, можно подвиснуть на длительное время:
Для ускорения запроса мы создадим IMMUTABLE функцию и, используя ее, построим индекс.
Подождем пару минут, пока он сформируется.
Геокодируем
Попробуем что-нибудь найти:
Все работает мнгновенно, запрос выдает порядка 200 записей. Осталось расколдовать координаты объектов, для этого пригодится то самое поле geometry.
Мы возьмем центр геометрии здания и, перегнав в WGS84, получим список точек на карте:
Если вывести их на карте, получим такую картину (красные точки - это найденные здания):
Это, конечно, еще не полноценный геокодер, но отличная основа. По сути, мы используем голый postgres. Для реализации более сложных решений геокодинга никто не мешает подключить тот же elasticsearch.
Хочу отметить размеры получаемой БД: в такой реализации для данных по всей России размер базы вместе со всеми индексами составил всего порядка 6GB (в противовес 50GB у номинатима).
Если вам не хватает каких-то данных, вы всегда можете отредактировать mapping.yaml и добавить дополнительные столбцы/таблицы. А утилита imposm3 - отличная и быстрая альтернатива утилитам osmosis или osm2pgsql.
На этом пожалуй все, благодарю за внимание.
PS Если вам, вдруг, понравилась эта статья, предлагаю r ознакомлению статью Административная карта на Vue+Flask, где я показываю как можно выводить геометрические данные на интерактивной карте на базе leaflet.js. Стэк все тот же postgresql + imposm3, правда там еще фронт простенький на Vue пишем.
imposm, openstreetmap, postgresql
Обычно, когда кто-то говорит про OSM, то в голове всплывает какой-нибудь из веб-сервисов, или приложение вроде Maps.me, основанные на данных OSM. На самом деле проект OSM — это в первую очередь данные, всё остальное по сути частные случаи их использования. Сервисы предоставляют обычно только часть информации, отрисованной по своим правилам.
Исходно OSM — это набор точек, связей между точками, и тегов к ним. Исходники сообщества имеют два формата. Первоначально XML использовался как приоритетный способ распространения данных, но, файл Planet.osm в несжатом виде уже перевалил за терабайт, и я не вижу смысла использования его для относительно объёмной информации. PBF имеет большое преимущество — он бинарный и файл всей земли имеет размер около 50Гб (сжатый XML порядка 80 Гб).
Речь пойдет об импорте данных OSM из «родного» формата с помощью инструмента Osmosis.
Также нам понадобится PostgreSql с расширением Postgis, в который мы и будем импортировать OSM данные.
Как результат — возможность получения в своей БД информации по объектам с перечисленными здесь тегами.
Подготовка БД.
Вначале создаем БД в Postgresql, название особого значения не имеет.
Далее добавим необходимые для дальнейшей работы расширения.
Расширение Postgis «подключает» к БД собственно модуль по работе с геоданными (напомню, необходимо установить сам Postgis). Расширение hstore предназначено для работы с наборами ключ/значение, т.к. много информации будет содержаться в OSM-тегах.
Скачиваем Osmosis. Вкратце, это ПО для самых разнообразных операций с OSM данными. Имеется неплохая документация по работе с командной строкой. Исходники на Java. Ниже мы будем использовать командную строку. Я также использовал Osmosis как Java библиотеку, исходный код (есть на GitHub) мне показался достаточно понятным, а API несложное в использовании.
Теперь готовим базу данных для импорта. Необходимые таблицы и функции можно создать с помощью скриптов, которые находятся в папке osmosis/script. Помимо основного скрипта, выполним SQL код, который создаст поле для хранения геометрии линий. Это связано с тем, что OSM данные скорее представлены как связи точек, чем как набор геометрических фигур.
Импорт OSM данных в БД
В нашем случае мы можем начать с использования выгрузок от участников сообщества. Есть ресурсы, которые дают возможность загрузить данные только по определенному региону. Например, download.geofabrik.de. Возьмем Воронежскую область. Там она включена в файл, содержащий данные по всему центральному федеральному округу. Можно загрузить central-fed-district-latest.osm.pbf, а нужный «кусок» потом вырезать в отдельный файл или фильтровать по координатам при импорте в БД. Я бы предложил первый вариант:
Тут всё просто. Читаем PBF файл, результаты чтения фильтруем по прямоугольнику координат, и результаты после фильтрации записываем в выходной файл. Фильтровать по координатам можно более точно, используя не прямоугольник, а полигон, координаты которого находятся в отдельном файле.
Полученный файл voronezh.osm.pbf далее импортируем в БД. Для подключения создаем properties файл с параметрами доступа к базе данных:
Ну и сам импорт:
Импортированные данные
Теперь можно уже начать изучение того, что у нас есть в БД. Первая мысль о том, что там набор фигур, однако это не совсем так. Как я уже говорил, основной элемент – точка. Всё остальное создается путем создания связей (отношений) между точками. Углубляться пока не будем, тем более что руки уже чешутся создать свою «плоскую» таблицу с какими-нибудь данными. Что ж, для линий и точек уже всё готово, нужно только создать таблицу с необходимыми полями, и вставить туда нужные записи. А какие поля у нас есть? Тут в помощь вики. Для примера, возьмем пару ключ/значение power=line. Выберем список полей, которые будем использовать, например: name, voltage, operator, cables. Получается, мы хотим выбрать линии, которые обязательно имеют свойство power=line, вместе с полями name, voltage, operator, cables. Создаем таблицу:
И сам запрос для заполнения нашей новой таблицы:
Готово, имеем таблицу с линиями электропередач, где у некоторых линий даже заполнена часть полей! Ну что ж, таблица это конечно интересно, но визуализировать данные для просмотра геометрии тоже бы неплохо. Быстрей всего сделать это с помощью QGIS, не считая того что эту мощную ГИС сначала надо установить. Там мы уже добавляем Postgis слой, в качестве подложки используем любую карту (можно использовать OpenLayers плагин). Настроили, смотрим:
Ура! Даже весьма похоже на правду, подумал я, смотря в окно на ЛЭП.
С точками ситуация практически та же самая, разве что надо использовать таблицу nodes. КДПВ как раз содержит данные по подстанциям. А как быть с полигонами? Полигоны состоят также из линий (замкнутых). Вроде бы можно просто замкнуть линии и наслаждаться результатом, но так не получится. Есть множество подводных камней. Полигоны могут состоять из нескольких замкнутых линий.
Например, на озере может находиться остров. Поэтому получим «дырку» в полигоне. Еще пришлось узнать о значении слова «эксклав» (к моему стыду, знал только про «анклав»). Также полигоны группируются. Например, лес может состоять из нескольких «кусков». Который мы должны представлять как один объект. В довершении всего мы должны отсекать незамкнутые полигоны, если часть данных вышла за пределы карты. Эти, и еще некоторые другие проблемы я решил в SQL скрипте, который благополучно отложил на полку после того как он заработал. На GitHub был найден проект osmosis-multypolygon. Скрепя сердце, я решил что использование данного решения более лучший вариант, нежели мой набор скриптов, написанный на коленке за пару дней. Делаем так, как сказано в README, а именно выполняем список скриптов, и у нас появляется таблица multipolygons, которая заполняется инструкцией из assemble.sql. После того как мы заполнили таблицу с полигонами, можно придумать что мы хотим получить. Давайте выберем территории парков?
Cмотрим в вики, и пишем скрипт:
Ну, скажу честно, тут уже об актуальности данных можно поспорить. Но это уже тема для отдельного разговора.
OSM (сокращение от OpenStreetMap) - это формат файла, используемый программным обеспечением OpenStreetMap. Файлы OSM содержат информацию о карте улиц и могут хранить данные для областей различного размера - от небольших регионов до глобальных сетей улиц.
Архитектура XML
Файлы OSM сохраняют данные в формате XML, и поэтому иногда могут использовать составной суффикс, т. Е. osm.xml.
Схема данных
Файлы OSM хранят данные в структурированном виде. Узлы улиц представлены в виде точек, улицы представлены в виде линий, которые соединяют эти узлы, а отношения хранят свойства улиц, точек и объектов.
Основной файл OSM
Planet.OSM является основным файлом OpenStreetMap, к которому можно получить доступ и изменить его, добавив новые улицы любому пользователю. Пользователи могут добавлять новые улицы или редактировать уже включенные.
Программы, которые поддерживают OSM расширение файла
Следующий список содержит программы, сгруппированные по 3 операционным системам, которые поддерживают OSM файлы. Файлы с суффиксом OSM могут быть скопированы на любое мобильное устройство или системную платформу, но может быть невозможно открыть их должным образом в целевой системе.
Программы, обслуживающие файл OSM
Updated: 02/16/2020
Как открыть файл OSM?
Отсутствие возможности открывать файлы с расширением OSM может иметь различное происхождение. Что важно, все распространенные проблемы, связанные с файлами с расширением OSM, могут решать сами пользователи. Процесс быстрый и не требует участия ИТ-специалиста. Ниже приведен список рекомендаций, которые помогут вам выявить и решить проблемы, связанные с файлами.
Шаг 1. Установите FME Desktop программное обеспечение
Основная и наиболее частая причина, препятствующая открытию пользователями файлов OSM, заключается в том, что в системе пользователя не установлена программа, которая может обрабатывать файлы OSM. Этот легкий. Выберите FME Desktop или одну из рекомендованных программ (например, Merkaartor, GeoVisu, GPX Viewer) и загрузите ее из соответствующего источника и установите в своей системе. Полный список программ, сгруппированных по операционным системам, можно найти выше. Одним из наиболее безопасных способов загрузки программного обеспечения является использование ссылок официальных дистрибьюторов. Посетите сайт FME Desktop и загрузите установщик.
Шаг 2. Обновите FME Desktop до последней версии
Если у вас уже установлен FME Desktop в ваших системах и файлы OSM по-прежнему не открываются должным образом, проверьте, установлена ли у вас последняя версия программного обеспечения. Может также случиться, что создатели программного обеспечения, обновляя свои приложения, добавляют совместимость с другими, более новыми форматами файлов. Это может быть одной из причин, по которой OSM файлы не совместимы с FME Desktop. Последняя версия FME Desktop должна поддерживать все форматы файлов, которые совместимы со старыми версиями программного обеспечения.
Шаг 3. Назначьте FME Desktop для OSM файлов
После установки FME Desktop (самой последней версии) убедитесь, что он установлен в качестве приложения по умолчанию для открытия OSM файлов. Следующий шаг не должен создавать проблем. Процедура проста и в значительной степени не зависит от системы
Процедура изменения программы по умолчанию в Windows
- Нажатие правой кнопки мыши на OSM откроет меню, из которого вы должны выбрать опцию Открыть с помощью
- Далее выберите опцию Выбрать другое приложение а затем с помощью Еще приложения откройте список доступных приложений.
- Последний шаг - выбрать опцию Найти другое приложение на этом. указать путь к папке, в которой установлен FME Desktop. Теперь осталось только подтвердить свой выбор, выбрав Всегда использовать это приложение для открытия OSM файлы и нажав ОК .
Процедура изменения программы по умолчанию в Mac OS
Шаг 4. Убедитесь, что OSM не неисправен
Если вы выполнили инструкции из предыдущих шагов, но проблема все еще не решена, вам следует проверить файл OSM, о котором идет речь. Проблемы с открытием файла могут возникнуть по разным причинам.
1. OSM может быть заражен вредоносным ПО - обязательно проверьте его антивирусом.
Если случится так, что OSM инфицирован вирусом, это может быть причиной, которая мешает вам получить к нему доступ. Немедленно просканируйте файл с помощью антивирусного инструмента или просмотрите всю систему, чтобы убедиться, что вся система безопасна. Если файл OSM действительно заражен, следуйте инструкциям ниже.
2. Проверьте, не поврежден ли файл
3. Убедитесь, что у вас есть соответствующие права доступа
Некоторые файлы требуют повышенных прав доступа для их открытия. Выйдите из своей текущей учетной записи и войдите в учетную запись с достаточными правами доступа. Затем откройте файл OpenStreetMap Map Format.
4. Убедитесь, что ваше устройство соответствует требованиям для возможности открытия FME Desktop
Операционные системы могут иметь достаточно свободных ресурсов для запуска приложения, поддерживающего файлы OSM. Закройте все работающие программы и попробуйте открыть файл OSM.
5. Проверьте, есть ли у вас последние обновления операционной системы и драйверов
Регулярно обновляемая система, драйверы и программы обеспечивают безопасность вашего компьютера. Это также может предотвратить проблемы с файлами OpenStreetMap Map Format. Устаревшие драйверы или программное обеспечение могли привести к невозможности использования периферийного устройства, необходимого для обработки файлов OSM.
Вы хотите помочь?
Если у Вас есть дополнительная информация о расширение файла OSM мы будем признательны, если Вы поделитесь ею с пользователями нашего сайта. Воспользуйтесь формуляром, находящимся здесь и отправьте нам свою информацию о файле OSM.
Используйте OsmSharp для обработки данных OpenStreetMap (OSM)
Модель данных OpenStreetMap
Данные OSM имеют три основных объекта: Узел, Путь и Связь. Для получения дополнительной информации см.OSM-wiki。
Введение в OsmSharp
Совместный проект
Потоковая модель
OsmSharp использует потоковую модель для обработки данных OSM. Все потоковые модели реализуют общий интерфейс IEnumerable <T>, что означает, что можно использовать обработку запросов LINQ.
* OsmStreamSource：
XmlOsmStreamSource: чтение файла OSM-XML
PBFOsmStreamSource: чтение файла OSM-PBF
* OsmStreamTarget：
XmlOsmStreamTarget: записать файл OSM-XML
PBFOsmStreamTarget: записать файл OSM-PBF
* OsmStreamFilter：
OsmStreamFilterDelegate
OsmStreamFilterMerge
OsmStreamFilterNode
OsmStreamFilterProgress
Прочитать файл OSM-PBF
Данные фильтрации запросов LINQ
Записать файл OSM-XML
Откройте файл «filter.osm», чтобы просмотреть содержимое, как показано ниже:
Общая обработка данных
Обрезать
Следующие два метода фильтрации позволяют добиться отсечения.
* FilterBox(float left, float top, float right, float bottom，bool completeWays)
* FilterSpatial(IPolygon polygon, bool completeWays)
Среди них FilterBox () фильтрует по границе и должен установить широту и долготу слева, сверху, справа и снизу. FilterSpatial () обрезается с помощью многоугольника, чтобы все объекты внутри многоугольника. Этот метод должен ссылаться на OsmSharp.Geo. По умолчанию для completeWays установлено значение false. Разница между значениями true и false показана на рисунке ниже. (Красный - результат установлен на true, зеленый - результат установлен на false)
Пример:
Метод GetPolygonFromGeoJson (строка имя_файла) выглядит следующим образом, и необходимо добавить следующие ссылки.
Работа с базой данных
SQLServer
OsmSharp-GitHubЕсть два способа чтения / записи данных OSM из / в базу данных SQL Server.
OsmSharp.Db.SQLServer.dll
использоватьsqlserver-dataproviderПрограммный пакет использует SQL Server в качестве базы данных OpenStreetMap. Чтение / запись данных OSM из / в базу данных SQL Server. Необходимо добавить ссылку «OsmSharp.Db.SQLServer.dll», этот файл не может быть найден на последнем GitHub, я загрузил его на свой GitHub, нажмите, чтобы загрузить.
Запись данных OSM в базу данных SQL Server
Метод вставки данных в реальном времени (Снимок *) и исторических данных (История *) одинаков, но структура таблицы данных отличается. Пожалуйста, проверьте конкретную структуру таблицы данныхGitHubОператор SQL в.
Импорт исторических данных (History *) не удастся из-за повторяющегося идентификатора! ! !
Структура таблицы данных в реальном времени и вставленных данных выглядит следующим образом:
Чтение данных OSM из базы данных SQL Server
OsmSharp.Data.SQLServer.dll
использоватьdata-providersПакет программного обеспечения, вы можете загрузить файл «OsmSharp.Data.SQLServer.dll», добавить ссылку или использовать NuGet для поиска «OsmSharp.SQLServer» для установки.
Лучше всего использовать NuGet для установки, это автоматически добавит соответствующую версию библиотеки OsmSharp, иначе могут возникнуть проблемы. Ниже указан номер версии, соответствующий этой статье.
База данных SQL Server записывает данные OSM
history.pbf
OsmSharp.Data.SQLServer.dll не ограничивает идентификатор, поэтому исторические данные с повторяющимся идентификатором также могут быть напрямую записаны в базу данных.
Следующий рисунок является результатом записи исторических данных, и вы можете видеть, что есть повторяющиеся идентификаторы.
База данных SQL Server для чтения данных OSM
OsmSharp.Data.SQLServer.dll, похоже, не может читать данные OSM из базы данных SQL Server.
план маршрута
Itinero
Ключевые категории:RouterDb，Router，Profiles И RouterPoint
* RouterDb: Manages the data of one routing network. It holds all data in RAM or uses a memory mapping strategy to load data on demand. It holds all the network geometry, meta data and topology.
* Router: The main facade for all routing functionality available. It will decide the best algorithm to use based on a combination of what’s requested and what data is available in the RouterDb.
* Profiles: Definitions of vehicle and their behaviour that can traverse the routing network.
* RouterPoint: A location on the routing network to use as a start or endpoint of a route. It’s defined by an edge-id and an offset-value uniquely identifying it’s location on the network.
пример
Ниже приводится простой пример использования данных OSM для планирования пути.
Читайте также: