Задача - организовать присвоение mp-типа в зависимости от нескольких тегов.
Например, amenity=parking преобразовать в полигон(0x05) и точку (0x2f0b) , а amenity=parking+access=private, только в полигон, причем другого типа (0x06)
Да без проблем.
Я из чисто гуманистических побуждений пытаюсь предостеречь этих двух людей от ошибки.
Ну и заодно десятки и сотни людей, регулярно качающих *.MP для собственных нужд, от неразумной траты трафика.
Не следует плодить лишних сущностей: есть OSM и есть MP. Они разные. И не нужно пытаться создать новую сущность, сочетающую в себе свойства их обеих: мы получим не сумму достоинств, а сумму недостатков.
Тогда прошу прощения. Недопонял. Я считал, что так будет конвертиться MP, выкладываемый на сайте для всеобщего скачивания, а не для чьего-то внутреннего индивидуального использования.
Так, прощения попросил. Но по прежнему продолжаю рекомендовать - если не хватает данных в MP, переходить на OSM, а не изобретать костыли. Просто чисто по человечески: мне жалко чужого времени, потраченного зря. Особенно времени людей, которые делают что-то полезное для других.
andriano, если вы так хотите пересчитывать чужое время, подумайте, сколько займет создание конвертеров вида osm2navitel, osm2rus, osm2{anotherpogram}, и стоит ли им заниматься при существовании osm2mp и mp2{нужный_формат}.
Хотите сэкономить чужое время - пишите полезные патчи и присылайте их авторам
Если существующие osm2mp и mp2{нужный_формат} вполне удовлетворяют, то - нет.
Это же очевидно! Зачем приписывать оппоненту заведомо абсурдную точку зрения?
Патч - это что? Я этот термин воспринимаю как “заплатка” - обход обнаруженной ошибки вместо ее исправления.
andriano, в самом деле, если вы хотите нам помочь, а не учить нас жить, запилите препроцессор, который будет заменять в 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)
Я правильно понимаю?
Формат конфига мне не нравится.
Предлагается единственная логическая операция - конъюнкция, которая не составляет полную систему. Соответственно, невозможно сделать конструкцию типа: если присутствует такой-то тег, но при этом нет такого-то, то сделать то-то.
Отсутствует информация, к объектам какого из типов (node, way, relation) следует применять данное правило.
Теги некоторых типов (например, name) могут содержать произвольные строки. Нет никаких средств работы с ними. Например, мы не сможем организовать приоритет имен: при наличии name:ru берется оно, если нет - то name:en, если нет, то int_name, если нет, то name - и все это записывается в name.
Нечетко формулируется, ЧТО НАДО СДЕЛАТЬ, что приводит к неоднозначности, а также ошибкам, в результате которых программа может делать совсем не то, что хотел автор конфига.
Если устранить очевидные недостатки (ввести полную систему логических функций и возможность работы с произвольными строками), то однострочная система записи каждого “акта обработки” окажется слишком громоздкой. И составитель конфига может в ней напутать, да и мне лень разбирать строку с учетом приоритетов и скобок. Дело, конечно, не слишком сложное, но я им не занимался и у меня нет готовых инструментов.
Поэтому предлагаю придумать ассемблероподобный язык, в котором на каждой строке записывается одна элементарная операция или директива.
Предлагаю примерно следующее:
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-ы, то это уже только для программистов. Но тогда проще уж писать на Java (если это плугин для osmosis) или на одном из готовых скриптовых языков которые элементарно туда интегрируются…