А что это?
Чем писать такой препроцессор с такими хитрыми конфигами может лучше xslt освоить?
Упс mp не xml’ка - извините глупость брякнул.
Ну почему глупость. Обжудается всё-таки препроцессор.
Вот только как xslt будет работать на многомегабайтных файлах… Не любая реализация сдюжит…
Идея в том что если один напишет препроцессор с простыми конфигами, другим не придется ничего осваивать)
А вот плагин к осмозису кажется мне хорошей идеей.
Я пробовал xslt обрабатывать osm данные - медленно и неудобно.
Попробовал плугин TagTransform. Вроде работает.
Пример конфига (transform.xml):
<?xml version="1.0"?>
<translations>
<translation>
<name>Private parking transform</name>
<description>Convert amenity=parking+access=private to amenity=private_parking</description>
<match mode="and">
<tag k="amenity" v="parking"/>
<tag k="access" v="private"/>
</match>
<output>
<copy-unmatched/>
<tag k="amenity" v="private_parking"/>
</output>
</translation>
</translations>
Загружать надо “API 0.6 compatible version”, по первой ссылке какая-то древняя версия лежит. Или самому собрать из исходников.
В плугине отсутствует файл plugin.xml для автоматической регистрации, можно добавить его самому или подключить через командную строку, как описано на странице.
Пример plugin.xml
<?xml version="1.0" ?>
<!DOCTYPE plugin PUBLIC "-//JPF//Java Plug-in Manifest 1.0" "http://jpf.sourceforge.net/plugin_1_0.dtd">
<plugin id="TransformPlugin" version="1.0">
<requires>
<import plugin-id="org.openstreetmap.osmosis.core.plugin.Core"
plugin-version="0.35" reverse-lookup="false"/>
</requires>
<runtime>
<library id="code" path="/" type="code"/>
</runtime>
<extension plugin-id="org.openstreetmap.osmosis.core.plugin.Core"
point-id="Task" id="TransformPlugin/Task">
<parameter id="name" value="transform"/>
<parameter id="class" value="uk.co.randomjunk.osmosis.transform.TransformPlugin"/>
</extension>
</plugin>
а с 0.36 версией он работать будет?
Скорей всего да. Пробовать нужно.
Залил альфа-версию на
http://slil.ru/29195882
Произвольные строки пока не обрабатываются.
Обнаружил, что тегов access=private куда больше, чем private=yes, поэтому в качестве примера использования приведен конф-файл, преобразующий любую из этих комбинаций.
Какая-то странная ситуация: была просьба сделать, а теперь - молчок. Или уже не актуально?
Кстати, заканчиваю работу со строками, но возник другой вопрос: в первоначально предложенном варианте отсутствовала операция сравнения строк. Т.е. например, нельзя выполнить следующую задачу: если имеется cladr=%, то его удалить, но если нет cladr:code и cladr:note, то записать cladr:note с указанным кодом, а если есть, сравнить коды и при несовпадении выдать сообщение об ошибке.
актуально-актуально, просто других дел навалилось. Посмотрю обязательно)
.exe … и сорцов нет. Это проблема. И Windows далеко не все пользуются.
Да, определенная проблема в этом есть. Тем не менее по пунктам:
- Я не пользуюсь интерпретируемыми ЯП т.к. считаю, что программы написанные на них работают неприемлемо медленно. Ну уж не для обработки гигабайтных файлов точно.
- Исходники достаточно объемные, т.к. по сути я использовал для написания данной программы наработки из других проектов, ничего из них не удаляя. Так что для “посмотреть” они не очень пригодны. А для “откомпилировать” - тем более, т.к. я пользуюсь очень редким компилятором с не слишком характерного для подобных задач ЯП.
- Программа консольная и использует минимум средств WinAPI без привлечения специфических библиотек. Так что с запуском, думаю, могут быть проблемы только из-под “голого” ДОС. Но под “голым” ДОС это принципиально работать не может, т.к. ДОС не поддерживает длину файла более 2 Гб, а для программы подобного назначения это ОБЯЗАТЕЛЬНОЕ условие.
Выложил следующую версию (и опять альфа - вот незадача!)
http://slil.ru/29211415
Теперь сделана обработка строк и управление листингом.
Программа может, например, выполнить следующую задачу:
Если у объекта присутствуют теги cladr и cladr:code, причем их значения (val) совпадают, то тег code удаляется (приведен пример).
В принципе, можно сразу было добавить и cladr:note, но решил не усложнять программу.
Из идей - совместить этот инструмент с задачей получения простенькой статистики.
Простенькая статистика, это здорово. Например, хочу запросы: кто рисовал за последнюю неделю? Кто рисовал за период с - по? какие теги рисовали/изменяли за нужный период? Рисовали ли тег (к примеру) highway за запрашиваемый период? Рисовал ли пользователь pupkin тег water за запрашиваемый период?
Да уж. Под статистикой каждый подразумевает нечто свое.
Я, например, когда по совету lesha решил перейти с MP на OSM d качестве источника данных, первым делом попытался “очистить” OSM от той информации, которую я никогда не буду использовать. И “под сокращение” как раз попала та часть, в которой указывается, когда и кем данная точка последний раз была отредактирована. Кстати, объем после этого сразу уменьшился более чем вдвое.
Есть и еще одно препятствие.
В посте №18 вкратце сформулировано, что нужно сделать. И там явно указано, что работать нужно с файлом, а не БД или API. А это значит, что:
- Во входной информации ОТСУТСТВУЕТ информация по истории изменений.
- Сам файл может быть сколь угодно древний.
В этом же случае для сбора статистики подобного рода целесообразно уже пользоваться в качестве источника данных не файлом, а чем-то онлайновым.
А под статистикой я подразумевал анализ состояния информации, имеющейся в ТЕКУЩЕМ файле, т.е. на один момент времени, а не динамика ее изменения со временем.
Тут в ветке “Стандартизация…” я уже выкладывал кое-какую статистику. Просто хотелось бы иметь инструмент, который мог бы восполнить отсутствующую там информацию по каким-нибудь конкретным тегам. И чтобы это можно было сделать просто и быстро.
сделал на пробу пару конфигов для предпроцессора (osmosis+tag_transform), для гармина рестораны раскидываются по типам кухни, для навитела еще места поклонения (церкви, мечети).
если кому интересно http://code.google.com/p/osm2mp-preprocess/
Такое теперь можно непосредственно в конфигах osm2mp задавать.
Во всяком случае рестораны я там частично прописал
Транслитератор из алфавитов отличных от кирилицы-латиницы кто нибудь встречал?