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

Бывают способы решения, сами по себе являющиеся негодными. Вне зависимости от задачи.
Путь тупиковый.
Тут только два варианта:

  1. Я (или кто другой) сумею убедить Вас в бесперспективности выбранного способа.
  2. Вы пытаетесь его реализовать и убеждаетесь в этом самостоятельно. Но несколько позже, и потратив значительное количество сил и времени.

Я говорил про вопрос Zkir-а - “отсеять к едрене фене частные парковки”.

А кладр-код на домах - это зло.

Леш, значит я в самом деле плохо объясняю. :frowning:

Задача - организовать присвоение mp-типа в зависимости от нескольких тегов.

Например, amenity=parking преобразовать в полигон(0x05) и точку (0x2f0b) , а amenity=parking+access=private, только в полигон, причем другого типа (0x06)

Как ее решить препроцессором?

Zkir, например, тупо добавить препроцессором нужным объектам тег mp_type=*.
В зависимости от всех необходимых условий.

Или преобразовать все amenity=parking+access=private в amenity=private_parking

Это был просто пример.

Да без проблем.
Я из чисто гуманистических побуждений пытаюсь предостеречь этих двух людей от ошибки.
Ну и заодно десятки и сотни людей, регулярно качающих *.MP для собственных нужд, от неразумной траты трафика.
Не следует плодить лишних сущностей: есть OSM и есть MP. Они разные. И не нужно пытаться создать новую сущность, сочетающую в себе свойства их обеих: мы получим не сумму достоинств, а сумму недостатков.

Каким нужным-то? эти объекты еще только предстоит сформировать, причем для одного исходного их может получиться несколько.

Это можно, но “альтернативные” теги в конфигах osm2mp имхо как раз и есть тупиковый путь - путь к полному бардаку.

Блииииииииннннн… Кто чего качает? Какой трафик??? Я конверчу из осм в мп У СЕБЯ НА КОМПЕ. Какой нафиг трафик???

Тогда прошу прощения. Недопонял. Я считал, что так будет конвертиться MP, выкладываемый на сайте для всеобщего скачивания, а не для чьего-то внутреннего индивидуального использования.

Так, прощения попросил. Но по прежнему продолжаю рекомендовать - если не хватает данных в MP, переходить на OSM, а не изобретать костыли. Просто чисто по человечески: мне жалко чужого времени, потраченного зря. Особенно времени людей, которые делают что-то полезное для других.

andriano, если вы так хотите пересчитывать чужое время, подумайте, сколько займет создание конвертеров вида osm2navitel, osm2rus, osm2{anotherpogram}, и стоит ли им заниматься при существовании osm2mp и mp2{нужный_формат}.
Хотите сэкономить чужое время - пишите полезные патчи и присылайте их авторам :slight_smile:

+100500!!!

Если существующие osm2mp и mp2{нужный_формат} вполне удовлетворяют, то - нет.
Это же очевидно! Зачем приписывать оппоненту заведомо абсурдную точку зрения?

Патч - это что? Я этот термин воспринимаю как “заплатка” - обход обнаруженной ошибки вместо ее исправления.

andriano, в самом деле, если вы хотите нам помочь, а не учить нас жить, :wink: запилите препроцессор, который будет заменять в osm файле amenity=parking+pivate=yes на amenity=private_parking. Причем чтобы в конфиге можно было задать что на что заменять и остаются ли исходные теги или удаляются, и какие именно (например так:
amenity=parking+private=yes → amenity=private_parking+private=yes)

Я такой препроцессор вставлю в процесс для Гис Руссы (и Ситигида, когда он созреет).

Как этот препроцессор предполагается использовать и для чего?
Честно говоря, умножение сущностей (добавление новых тегов, которые не увеличивают количество информации в файле, но увеличивают его объем) считаю делом вредным.
Правда, если результат обработку не будет выкладываться в открытый доступ, а лишь использоваться в качестве этапа конвертации - другое дело.
Какие предложения по набору поддерживаемых функций и формату конфига?

andriano, mp - в открытом доступе - зло, потому что под каждую программу все равно нужен свой конфиг.

Использовать предполагается в процессе конвертации osm в rus и dcm для имитации функции, отсутсвующей в osm2mp - обработки нескольких тегов за раз, путем замены одних тегов на другие. Это всех проблем не решит, но пресловутую проблему с частными парковками снимет.

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

Ничего подобного.
С одной стороны:
МР - контейнер для некоторой ОБЪЕКТИВНОЙ информации, которую “каждая программа” может либо использовать, либо - нет. Например, PPSMapEdit не требует для себя какого-либо “своего конфига”.
С другой стороны:
МР - формат промежуточный, т.е. непригодный для непосредственного использования, поэтому особенности конкретных программ (работающих с уникальными форматами данных) должны нивелироваться конвертерами данных для них из МР.

Т.е. нужен инструмент способный анализировать содержимое объекта типа node, way или relation целиком и вносить в него соответствующие коррективы. Без анализа структуры дочерних элементов. (т.е. в relation не анализируются теги дочерних way или node)
Я правильно понимаю?

Формат конфига мне не нравится.

  1. Предлагается единственная логическая операция - конъюнкция, которая не составляет полную систему. Соответственно, невозможно сделать конструкцию типа: если присутствует такой-то тег, но при этом нет такого-то, то сделать то-то.
  2. Отсутствует информация, к объектам какого из типов (node, way, relation) следует применять данное правило.
  3. Теги некоторых типов (например, name) могут содержать произвольные строки. Нет никаких средств работы с ними. Например, мы не сможем организовать приоритет имен: при наличии name:ru берется оно, если нет - то name:en, если нет, то int_name, если нет, то name - и все это записывается в name.
  4. Нечетко формулируется, ЧТО НАДО СДЕЛАТЬ, что приводит к неоднозначности, а также ошибкам, в результате которых программа может делать совсем не то, что хотел автор конфига.
    Если устранить очевидные недостатки (ввести полную систему логических функций и возможность работы с произвольными строками), то однострочная система записи каждого “акта обработки” окажется слишком громоздкой. И составитель конфига может в ней напутать, да и мне лень разбирать строку с учетом приоритетов и скобок. Дело, конечно, не слишком сложное, но я им не занимался и у меня нет готовых инструментов.
    Поэтому предлагаю придумать ассемблероподобный язык, в котором на каждой строке записывается одна элементарная операция или директива.
    Предлагаю примерно следующее:
    10 логических регистры, обозначаемые цифрами 0…9.
    10 строковых регистров, обозначаемых %0…%9.
    комментарии - все, что после точки с запятой.
    директивы:
    u - use - использовать только объекты определенного типа: node, way, relation. Одновременно эта директива указывает на начало нового фрагмента (программы) обработки и обнуляет все регистры. Примеры:
    u:n
    u:nw
    u:wr
    команды загрузки
    s - set - устанавливают логическую переменную в состояние true при наличии указанного условия (пары key=val)
    s0:amenity=parking
    s1:name=%0 ; s1 устанавливается в true при наличии key=“name” и любом значении val, при этом ОДНОВРЕМЕННО значение val заносится в строковую переменную %0
    s2:name:%1=%2 ; s2:=true при наличии любого name: и заполняются две строки
    s3: ; означает присваивание константы true
    команды вычисления: всего 3 штуки - одна унарная и две бинарные, только с логическими регистрами:
    c0:1^2 ; конъюнкция
    c3:0+2 ; дизъюнкция
    c3:n3 ; отрицание
    команды выполнения: всего 2 штуки (удаление и добавление), но с вариациями синтаксиса:
    d0:amenity=parking ; простая команда удаления при значении true регистра 0
    a1:amenity=private_parking ; простая команда вставки при значении true регистра 1
    d2:name=% ; команда удаления при любом val
    d3:name:%=% ; команда удаления для группы key с одинаковым началом
    a4:name=%1 ; вставка вместе с запомненной ранее строкой-константой

PS. Это то, что сходу пришло в голову. Возможно, я где-то ошибся или предложил что-то неразумное.

Не хватает 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) или на одном из готовых скриптовых языков которые элементарно туда интегрируются…