Парсинг local.osm с gis-lab.info

Возникла проблема - файл заметно увеличился за последние годы и теперь парсить его стало гораздо сложнее. Суть такова - есть некоторый самодельный скрипт на питоне, для парсинга используется xml.sax, но во время разбора скрипт начал падать от нехватки памяти. Вопрос - может кто-то подобным уже занимался и наталкивался на грабли с разбором гигантских файлов?

Или может просто я изобретаю велосипед и есть более подходящее решение для загрузки в постгрес минимальных данных для роутинга? по сути нужны только часть данных из ways, nodes и relations в некотором своём представлении.

Кстати, была мысль пытаться читать файл блоками, но всё равно все результаты придётся хранить в памяти, чтобы потом обработать и сложить в выходной файл должным образом, боюсь, что памяти не хватит, или я не прав?

Работаю вот с такой железякой на FreeBSD:
CPU: Intel(R) Xeon(R) CPU E5606 @ 2.13GHz (2141.95-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
real memory = 51543801856 (49156 MB)

Заранее спасибо за ответы.

Не знаю как там с xml, но в o5m я не гнушаюсь три раза пройтись по файлу и собрать все нужные мне данные, тем более не все подряд объекты мне нужны.

А памяти не хватает саксу, или структурам самого скрипта?

local.osm сконвертируйте osmconvert’ом в local.o5m, отфильтруйте osmfilter’ом дороги, сконвертируйте обратно в .osm.

А как строится роутинг в постгресе? Используйтся pgRouting или чтото другое/свое?
Если pgRouting, то не изобретайте велосипед, а используйте osm2pgrouting.

sax
нехватки памяти
sax
нехватки памяти

Лолшто?

Лехко! Бывают саксы, которые сперва строят дерево, а потом его обходят.

Похоже, что у меня именно такой случай, запилено примерно так:


from xml.sax import make_parser as XMLParser
from xml.sax.handler import ContentHandler

parser = XMLParser()
parser.setContentHandler( self )

try:
    parser.parse( self.filename )
except Exception, e:
    print 'parser.parse error'

падает как раз на этом моменте, может попадался какой-нибудь кошерный сакс, который более эффективно работает?

dudka используется пока своё, pgRouting как раз рассматриваю как возможную альтернативу. Сейчас собственная простейшая реализация поиска кратчайшего пути на питоне в постгресе :slight_smile:

Отфильтруйте дороги для начала - файл уменьшится втрое.

Можно попробовать Imposm
http://wiki.openstreetmap.org/wiki/Imposm_parser

Уже вырезанные хайвэи пытаюсь парсить, делаю так:

osmosis --read-pbf file=‘local.osm.pbf’ --way-key keyList=‘highway’ --used-node --write-xml file=‘local.osm.highways.xml’
либо так
osmfilter local.osm.pbf --keep=‘highway=’ --keep-relations= -o=local.osm.highways.xml

на выходе получается файл размером примерно 7Гб

Кстати, под Win8 x86_64 почему-то без ошибок осмозис работает, но файл на выходе получается в несколько раз меньше и с виду всё вполне корректно

чтобы не загружать XML целиком в память, можно воспользоваться этим
http://lxml.de/tutorial.html#parser-objects

отклонюсь от темы - на windows получалось установить? при установке проблемы возникают, автору написал, но вдруг кто-то уже ставил.

Гм, ну и маразм, учитывая основной юзкейс саксов — линейный обход с минимальным потреблением памяти. >:3

IMHO, лучше всего отказаться от питона и збацать плугинг к osmosis-у, который будет выдавать готовые данные в вашем формате.

Я для своих целей делал подобное, но реализовал его из двух частей.

Первая часть занимается только фильтрацией и подготовкой графа дорог (детектирование изолятов, разбиение по перекрёсткам, создание двунаправленых линий).
https://github.com/sergeyastakhov/OSM/tree/master/osmrouting
http://www.openstreetmap.org/user/Sergey%20Astakhov/diary/18063

Вторая часть уже в составе приложения (но тоже в виде таска для osmosis), берёт на входе подготовленный таким образом граф и пишет его в базу.

хорошая идея, спасибо, поковыряю документацию на тему плагинописательства