Препроцессор osm-файлов

Не хватает if’ов :slight_smile: (команды cmp) и меток, по которым можно ветвиться в пределах фрагмента :slight_smile:

Во ВСЕ команды выполнения входят условия, т.е конструкцию вида

if condition_0 then begin
delete;
add;
delete;
end else begin
delete;
add;
end;

записываем так:

c1:n0
d0:

a0:
d0:
d1:
a1:

получается даже короче.

для примера формат осм фильтра (http://code.google.com/p/pyosm/source/browse/tools/osm-filter.README) - http://code.google.com/p/pyosm/source/browse/tools/osm-filter.xml
давно хотел в него replace добавить, но времени как небыло так и нет

Может я чего не понимаю, но нафига изобретать новый язык?
Одно дело - простенький конфиг, и совсем другое - полноценный язык.
Преимущество простого конфига - он понятен и непрограммистам. Когда появляются всякие регистры и if-ы, то это уже только для программистов. Но тогда проще уж писать на Java (если это плугин для osmosis) или на одном из готовых скриптовых языков которые элементарно туда интегрируются…

Не знай… Андриано вот просит)) по мне, поглядев на его проэкт, и правда вопросилось внутри – не проще ли это на Си (к примеру) написать?..
Вопрос не праздный, на самом деле – где делать “талию” – как провести границу между конфигом и исполнительной частью программы)) Андриано вот берётся широко запахать.

Вот именно.
В данном случаее предлагаемый “язык” явно не является полным, т.к. не содержит ни переходов (никаких - ни условных, ни безусловных), ни циклов. Т.к. предназначен для решения очень узкого круга задач. Но внутри этого класса задач он IMHO не должен иметь ограничений, поэтому считаю, что алгебра логики должна быть реализована в полном объеме. И только. Никаких других операций кроме логических не предусмотрено.

…ждём ебилдов. :slight_smile:

А что это?

Чем писать такой препроцессор с такими хитрыми конфигами может лучше 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 далеко не все пользуются.

Да, определенная проблема в этом есть. Тем не менее по пунктам:

  1. Я не пользуюсь интерпретируемыми ЯП т.к. считаю, что программы написанные на них работают неприемлемо медленно. Ну уж не для обработки гигабайтных файлов точно.
  2. Исходники достаточно объемные, т.к. по сути я использовал для написания данной программы наработки из других проектов, ничего из них не удаляя. Так что для “посмотреть” они не очень пригодны. А для “откомпилировать” - тем более, т.к. я пользуюсь очень редким компилятором с не слишком характерного для подобных задач ЯП.
  3. Программа консольная и использует минимум средств WinAPI без привлечения специфических библиотек. Так что с запуском, думаю, могут быть проблемы только из-под “голого” ДОС. Но под “голым” ДОС это принципиально работать не может, т.к. ДОС не поддерживает длину файла более 2 Гб, а для программы подобного назначения это ОБЯЗАТЕЛЬНОЕ условие.