Параметры osmosis-а

Может я туплю конечно, но какой прямой способ отфильтровать осмозисом дорожный граф, из planet.osm?

Я хочу получить дороги (highway=x|y|z), плюс те отношения, в которые эти дороги входят (например route и запреты поворотов).

–way-key-value --used-node оставляет слишком много мусора (все отношения и все входящие в них точки), а --tf reject-relations как-то слишком круто.

Ввести фильтр отношений? --tf accept-relations type=restrictions, route.

Попробуй так
–tf accept-ways highway=* --tf accept-relations type=restriction,route --used-node

  • из списка линий удаляются не highway-линии
  • из списка отношений удаляются не restriction/route-отношения
  • из списка точек удаляются все не принадлежащие оставшимся после первых двух шагов линиям или отношениям

Не буду создавать новую тему. Модераторы, можно эту переименовать в общую по osmosis
Как извлечь все адресные варианты (точки, линии, отношения) ?
У меня получилось так:

--read-xml file="xml.osm.bz2"^
 --node-key keyList="addr:housenumber" outPipe.0=mynodes^
 --read-xml file="xml.osm.bz2"^
 --way-key keyList="addr:housenumber"^
 --used-node outPipe.0=myways^
 --merge inPipe.0=mynodes inPipe.1=myways outPipe.0=myresult^
 --read-xml file="xml.osm.bz2"^
 --tf accept-relations building=*^
 --used-way^
 --used-node outPipe.0=myrel^
 --merge inPipe.0=myrel inPipe.1=myresult^

Может есть вариант проще и быстрее?

Можно сделать быстрее если

  • использовать pbf вместо osm.bz2
  • добавить --tf reject-ways --tf reject-relations в строке mynodes
  • добавить --tf reject-relations в myways

Действительно, переход на pbf позволил ускорить извлечение в 5 раз. А вот применение фильтров, не дало заметного ускорения. Экспериментировал по 5 запросов на каждый вариант. Спасибо за подсказку.

Добрый день. Появился вопрос. osmosis не умеет файл изменений фильтровать? И если не уметт то чтобы записать изменения объектов определенного типа в базу придется поддерживатьв актуальном состоянии pbf фаил? Задача стоит поддерживать в актуальном состоянии базу poi используя файлы изменений ежедневных дампов.

s777n, cюда Дежин не заходит. :frowning: По слухам, сперва накатывают файл изменений, потом то что получилось, обрезают по границе.

А вообще осмозис очень странная весч.

Запустил загрузку дампа московской области в постгисовскую базу. Примерно так:

Так он сожрал 16 (!) гиг оперативки, при том что сам дамп МО в xml чуть больше одного гига. Вот интересно, зачем ему столько памяти?

16Гб - потому что не потоковый парсер в основе, и он строит цельный DOM?

Ну так сам же сказал всё хранить в оперативной памяти: nodeLocationStoreType=InMemory :slight_smile:

Поставь TempFile или CompactTempFile - будет хранить во временном файле. А расходуется на временное хранилище узлов для сборки объектов геометрии и для подсчёта bbox-ов. В osm формате вся геометрия лежит в разобранном виде, а для базы нужны уже собранные.

Кроме того, java считает, что память можно занимать по своему усмотрению в рамках от -Xms до -Xmx, так что она может занимать просто для того чтобы пореже делать сборку мусора а не для реального хранения данных.

Нет, не в этом дело. DOM там не используется, там своя модель данных, а обработка конечно потоковая. Но особенности osm-овского формата часто требуют временного хранения объектов, чтобы не делать много проходов.

Т.е. ты считаешь превышение в 16 раз - это оправданно? :slight_smile: Я с ужасом думаю, что будет, когда я запущу planet.osm

nodeLocationStoreType=InMemory я поставил потому, что так советуют в единственной толковой статье по поднятию планеты, которая мне попалась. http://ksmapper.blogspot.com/2011/04/parse-planet-into-pgsnapshot-database.html

Пишут что так много быстрее.

Не факт, что там 16 раз, скорей всего меньше. Точные значения можно посмотреть если подцепиться к работающему osmosis-у через jconsole. Там будет видно сколько памяти реально используется.
Но в памяти объекты обычно больше места занимают, чем на диске - это да. К примеру, все строки (т.е. все значения ключей и тегов) в памяти хранятся в виде 16-разрядного несжатого unicode, что обычно занимает больше места чем UTF-8 на диске. :slight_smile:

Ну понятное дело, что память быстрее диска. Но если памяти жалко или не хватает - приходится использовать диск.

Памяти как раз не жалко. И теперь же все насквозь виртуальное, снизу доверху, причем несколько раз.
В наличие есть следующая архитектура
Физическая RAM (4 или 8 Гб) – SSD 64 Гб, на нем файл подкачки – жесткий диск 1 Tб.

Поэтому хотелось бы использовать именно память по максимуму.

–read-binary file=“RU-MOS.osm.pbf” немного быстрее
и скачивать pbf быстрее чем osm.bz2

RU-MOS.osm - просто для теста. Цель поднять планету, и обновлять ее часовыми дифами.

в базу грузить напрямую - застрелишься, делай через дамп.

просто наблюдение: если вы на многопроцессорной (многоядерной) системе из одного большого файла разом режете несколько мелких через --tee, то наилучшая производительность достигается если не буфферизовать (–b) перед --tee, но ставить --b перед каждым --bb.

Подскажите, можно как то распараллелить на 4 ядра процессора? Или только разбить на 4 батника?
call C:\OSM\osmosis\bin\osmosis --read-bin file=russia-european-part.osm.pbf --tee 4 --bp file=RU-MOS.poly completeRelations=yes --wx file=RU-MOS.osm --bp file=RU-MOW.poly completeRelations=yes --wx file=RU-MOW.osm --bp file=RU-LEN.poly completeRelations=yes --wx file=RU-LEN.osm --bp file=RU-SPE.poly completeRelations=yes --wx file=RU-SPE.osm

PS: или ваобще использовать что то другое для нарезки?