Конвертер OSM -> MP

liosha · 2009-07-09 14:59:50

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

как всё это конкретно будет выглядеть, пока обдумываю.
скорее всего, конфиг - это будет функция, которая будет запускаться для каждого объекта.
ей будут передаваться координаты и набор тегов, а из неё самой можно будет вызвать другие функции скрипта, что-то типа writepoi, addcoastline etc.

Aleksandr Dezhin · 2009-07-09 15:27:29

так почему бы не воспользоваться уже имеющимся языком?

Тем что в освоении этот язык не очень прост, что и скажется на развитии конфигов к этому скрипту.

скорее всего, конфиг - это будет функция, которая будет запускаться для каждого объекта.
ей будут передаваться координаты и набор тегов, а из неё самой можно будет вызвать другие функции скрипта, что-то типа writepoi, addcoastline etc.

Получается будет некий API между скриптом и конфигом, т.е. человеку который хочет написать свой конфиг, надо будет знать все аспекты вызова функций в перле. С тем что все параметры функции передаются массивом у новичков точно будут проблемы. Получится либо человек сам изучает перл, или пишем мини-howto как писать конфиги (читай плагины) для скрипта.

Если проблема в том чтобы сделать парсер конфигов аля mkgmap, то могу помочь с написанием соотв модуля, на мой взгляд задачка не очень сложная.

zgremlin · 2009-07-09 15:28:14

liosha wrote:

скриптом, потому что теперешний "плоский" конфиг себя уже исчерпал. расширять его уже не получается.
делать систему стилей по типу mkgmap-овской - тяжело, это, по сути, придумать новый язык и сделать его интерпретатор. так почему бы не воспользоваться уже имеющимся языком?
как всё это конкретно будет выглядеть, пока обдумываю.
скорее всего, конфиг - это будет функция, которая будет запускаться для каждого объекта.
ей будут передаваться координаты и набор тегов, а из неё самой можно будет вызвать другие функции скрипта, что-то типа writepoi, addcoastline etc.

Главное - предусмотреть грамотную структуру, а то так можно конфиг довести до состояния по запутанности превосходящего сам osm2mp.

liosha · 2009-07-09 16:36:22

osm2mp запутанный, потому что изначально ему такой функционал не планировался
У mkgmap тогда были несколько проблем - с кодировками, полигоны не всегда правильно резались, линии иногда уплывали на другой конец карты, и сам img очень неоптимально собирался. Поэтому, когда аффтара пинать надоело, захотелось провести карту через cgpsmapper, у которого таких проблем нет. А роутинг со всеми проверками и всё остальное было навешено уже потом.

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

Aleksandr Dezhin · 2009-07-09 17:02:46

liosha wrote:

Или у еого-то уже есть идеи такого языка?

Честно говоря я не очень долго разбирался с кодом, но мне кажется работу конфига можно формализовать как совокупность проходов, тестов/условий, операций, и политики маршрутизации.
Часть тестов могут быть выполнены на любом проходе (например проверка значения тегов, координаты точек), часть только на/после определенных (например, полигон внутри некой области). Такая же ситуация с действиями.
Так можно дифференцировать выгрузку в городе/за городом. На первом проходе создаются области городов, например по boundary. На след проходе в зависимости от попадания в разные области для дорог выставляются разные уровни видимости. Приблизительно таким же образом можно "поднимать" уровни видимости в малонаселенных городах.
И это все не отменят трансляции этого языка в функции на перле.

liosha · 2009-07-09 18:18:13

zgremlin wrote:

Главное - предусмотреть грамотную структуру, а то так можно конфиг довести до состояния по запутанности превосходящего сам osm2mp.

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

Zkir · 2009-07-09 19:13:05

zgremlin wrote:

По уму, надо бы, в зависимости от класса дороги, делать разные рамочки ~[0x04], ~[0x05], и т.д.,

Да, надо бы разные. В Гис Руссе они всё равно одинаковые, но это уже ее проблемы Хотя еще не факт, что тип дороги надо определять по значению тега highway. К. Галичский например рекомендует (http://www.geopainting.com/ru/maprules.html#6) следущее:

~[0x04] - федеральные трассы, обозначаемые буквой "М"
 (а также европейские "E")
~[0x05] - шоссе, обозначаемые буквой "А"
~[0x06] - местные дороги типа "Р"

т.е в зависимости от буквы дороги, а не от ее фактического состояния.

а встраивать это в код, при наличии конфига, - не очень красивое решение.

А что предлагается вместо этого, перенести часть кода в отдельный файл?

liosha wrote:

Что касается конфига на перле, лично я с этим никаких проблем не вижу.

Что не удивительно - для человека написавшего osm2mp на перле.

Last edited by Zkir (2009-07-09 19:48:36)

Ivan Komarov · 2009-07-09 19:25:13

liosha wrote:

Имхо, вариант гораздо удачнее и по возможностям и по гибкости, чем придумывать новый язык.

Полностью поддерживаю такой подход. Если конфигурирующие функции не будут "монструозными", просто идеальный вариант.

liosha · 2009-07-09 19:26:16

ну вот не надо перла-то бояться
язык как язык, всё как у всех.
поэтому и не понимаю, зачем придумывать новый язык, когда один уже есть

Ivan Komarov · 2009-07-09 19:27:28

liosha wrote:

ну вот не надо перла-то бояться
язык как язык, всё как у всех.
поэтому и не понимаю, зачем придумывать новый язык, когда один уже есть

Угу. Если не перл - так придется язык конфигуратора сначала заимплементить, а потом - всех научить

Aleksandr Dezhin · 2009-07-09 20:15:39

liosha wrote:

ну вот не надо перла-то бояться
язык как язык, всё как у всех.

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

Прошу озвучить лицензию по которой распространяется скрипт. На Google code написано GPL v2, но в шапке скрипта ее нет. Если это правда, то прошу указать лицензию в самом файле.

Aleksandr Dezhin · 2009-07-09 20:25:41

Ivan Komarov wrote:

Угу. Если не перл - так придется язык конфигуратора сначала заимплементить, а потом - всех научить

XML чем не устраивает? Для особо сложных случаев можно прям туда вставки на перле писать.

liosha · 2009-07-09 20:50:56

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

вопросами лицензии я особо не интересовался. пусть будет gpl v2. включать её текст в скрипт не хочу

Aleksandr Dezhin · 2009-07-09 21:29:28

liosha wrote:

вопросами лицензии я особо не интересовался. пусть будет gpl v2. включать её текст в скрипт не хочу

Я просил не о включении ВСЕГО текста лицензии, а о строке типа:

# Distributed under the terms of the GNU General Public License v2

Или что-то в этом духе.

Ivan Komarov · 2009-07-09 22:05:59

Aleksandr Dezhin wrote:

XML чем не устраивает? Для особо сложных случаев можно прям туда вставки на перле писать.

Декларативный, а-ля wix? Имхо, получится монстр
Upd: для XML'а, как я это себе представляю, придется создавать и описывать набор правил обработки и разруливания разнообразных ситуаций, условий и особых случаев (т.е. фактически новый язык), что ничуть не лучше примитивного "plane"-конфигуратора. По мере роста запросов и усложнения обработки, сие должно выродится в совершенно неподдерживаемый конгломерат.
Насколько я себе представляю, идеализированный liosh'ин вариант будет предоставлять сервис в виде ядра, описывающего последовательность обработки OSM-файлов, тогда как конфигурационными плагинами можно будет настраивать нюансы этой обработки.

Last edited by Ivan Komarov (2009-07-09 23:12:54)

Aleksandr Dezhin · 2009-07-10 01:57:44

Постойте, давайте определимся, что же такое для нас "новые конфиги".

1. Есть простые проблемы, которые можно решить расширением конфига, грубо говоря добавлением туда конструкций вида:
railway=rail & service=siding и т.п. + не значительной модификацией скрипта.

2. Есть более глобальные проблемы, которые тяжело решить не запутанным конфигом. Например: понижение скоростных характеристик дороги, при наличии на ней более двух лежачих полицейских на 100 метров, или на низких масштабах два односторонних motorway-я объединять в один, аналогично с автобусными остановками (это всего лишь примеры, подозреваю что они сейчас решаются точность координат на разных уровнях. UPD: посмотрел - не решаются.).

Я говорю о пункте 1 - для этого будет удачным решением НЕ перловые конфиги в виде XML или еще чего-то, в принципе можно и TSV как сейчас, но просто простыня получится широкая.

Пункт номер 2 - это задача совершенно другого уровня, которую вряд-ли российское сообщество OSM сможет решить. Эта задача сопоставима (если не сложнее) с написанием mapnik-а и правил к нему. В любом случае это получится монстр, в конечном итоге, либо со своим языком, либо с набором модулей/плагинов (возможно написанных на разных языках) каждый из которых будет конфигурировться отдельно. Однако целесообразность сомнительна - это всего лишь экспорт для определенных приборов. С тем же успехом можно браться за написание своего редактора или рендерера. Однако пока у нас до этого не доходило.

Поэтому я думаю, что для нас актуален пункт 1, который позволит с небольшими усилиями решить критичные проблемы.

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

Last edited by Aleksandr Dezhin (2009-07-10 02:54:14)

liosha · 2009-07-10 04:19:17

Aleksandr Dezhin wrote:

Постойте, давайте определимся, что же такое для нас "новые конфиги".
1. Есть простые проблемы, которые можно решить расширением конфига, грубо говоря добавлением туда конструкций вида:
railway=rail & service=siding и т.п. + не значительной модификацией скрипта.
2. Есть более глобальные проблемы, которые тяжело решить не запутанным конфигом.

Пункт 2 пока не рассматривается.
По пункту 1 - вот есть уже определившаяся логика для дорог:
выбираем класс и тип в зависимости от тега highway и попадания дороги в город,
меняем тип (но не класс!) и ставим односторонность если junction=roundabout,
прописываем правила доступа в зависимости от access-тегов,
правим среднюю скорость если есть maxspeed,
помещаем в список дорог для дальнейшей обработки,
если highway=pedestrian и area=yes формируем и выводим площадной объект.

Какие будут предложения по формату конфига для описания такой логики?

Aleksandr Dezhin · 2009-07-10 05:14:12

Если на скорую руку, то вот примеры.

liosha wrote:

выбираем класс и тип в зависимости от тега highway и попадания дороги в город,

<if> <!-- это на пероходе n-->
  <test>is_polygon() & [place] in ("city", "town", "suburb")</test>
  <then><o:add_to_mask id="cities" /></then>
</if>

<if> <!-- это на пероходе n+1 -->
  <test>[highway] & in_mask("cities")</test>
  <then>
    <switch>
       <case>
         <test>[highway] = "motorway"</test>
         <then>
           <o:set key="x-class" value="1" />
         </then>
       </case>
       <default>
         <o:set key="x-class" value="0" />
         <o:set key="x-type" value="0" />
       </default>
    </switch>
    <o:push_to_routes /> <!-- добавить в список для генерации роутингово графа -->
  </then>
</if>

liosha wrote:

меняем тип (но не класс!) и ставим односторонность если junction=roundabout, ,

<if>
  <test>[junction]="roundabout" & ![oneway] = "-1"</test>
  <then>
    <o:set key="oneway" value="yes" />
    <o:set key="x-type" value="100" />   
  </then>
</if>

liosha wrote:

прописываем правила доступа в зависимости от access-тегов,

<routing_policy>
  <if>....</if>
</routing_policy>

liosha wrote:

правим среднюю скорость если есть maxspeed,

Не понял совсем понял, что это.

Синтаксис условий можно и посахарить:

<if test="...">
  ...
<else/>
  ....
</if>

<switch>
  <case test="...">....</case>
  <case test="default">....</case>
</switch>

Это немного усложнит разбор, но написание конфигов станет веселей.

liosha · 2009-07-10 06:18:22

то есть как и предполагалось: придумываем новый КС-язык
тогда вопрос: чем он лучше уже имеющегося?

Aleksandr Dezhin · 2009-07-10 07:21:22

liosha wrote:

то есть как и предполагалось: придумываем новый КС-язык
тогда вопрос: чем он лучше уже имеющегося?

Предлагаю взять и сравнить два самых простых варианта, один:

<if test="[junction]=roundabout & ![oneway] = -1" >
    <o:set key="oneway" value="yes" />
    <o:set key="x-type" value="100" />   
</if>

а второй сформулировать на перле в виде функии или части функции.
А потом спросить на форуме того, кто не писал ничего на перле, с каким вариантом ему проще разобраться.

Last edited by Aleksandr Dezhin (2009-07-10 07:23:37)

liosha · 2009-07-10 07:30:57

ну, допустим

if ( $tag{junction} eq "roundabout" ) {
    $type = "0x0C";
    $oneway = 1;
}

Ivan Komarov · 2009-07-10 07:41:22

Так, ветвление уже в язык добавили. Остались циклы и вызов подпрограмм

Aleksandr Dezhin · 2009-07-10 07:52:22

liosha wrote:

ну, допустим

if ( $tag{highway} eq "roundabout" ) {
    $type = "0x0C";
    $oneway = 1;
}

а как значения переменной $type вернется из конфига? через глобальную переменную?
т.е. подразумевается что пользователь конфига уже освоился с отличиями операторов 'eq' и '=='?

ЗЫ: а это такая модераторская фишка убирать из сообщений метку "Last edited by ..."? просто интересуюсь.

Aleksandr Dezhin · 2009-07-10 07:53:10

Ivan Komarov wrote:

Так, ветвление уже в язык добавили. Остались циклы и вызов подпрограмм

Это лишнее. Сделаем гоу-ту.

liosha · 2009-07-10 07:56:38

Aleksandr Dezhin wrote:

а как значения переменной $type вернется из конфига? через глобальную переменную?

как вариант, через запуск API-функции AddRoad

Aleksandr Dezhin wrote:

т.е. подразумевается что пользователь конфига уже освоился с отличиями операторов 'eq' и '=='?

<if test="[junction]=roundabout" > тоже пользователю во сне не явится
посмотрит пример и сделает так же.

Aleksandr Dezhin wrote:

ЗЫ: а это такая модераторская фишка убирать из сообщений метку "Last edited by ..."? просто интересуюсь.

ага

Announcement

#576 2009-07-09 14:59:50

Re: Конвертер OSM -> MP

#577 2009-07-09 15:27:29

Re: Конвертер OSM -> MP

#578 2009-07-09 15:28:14

Re: Конвертер OSM -> MP

#579 2009-07-09 16:36:22

Re: Конвертер OSM -> MP

#580 2009-07-09 17:02:46

Re: Конвертер OSM -> MP

#581 2009-07-09 18:18:13

Re: Конвертер OSM -> MP

#582 2009-07-09 19:13:05

Re: Конвертер OSM -> MP

#583 2009-07-09 19:25:13

Re: Конвертер OSM -> MP

#584 2009-07-09 19:26:16

Re: Конвертер OSM -> MP

#585 2009-07-09 19:27:28

Re: Конвертер OSM -> MP

#586 2009-07-09 20:15:39

Re: Конвертер OSM -> MP

#587 2009-07-09 20:25:41

Re: Конвертер OSM -> MP

#588 2009-07-09 20:50:56

Re: Конвертер OSM -> MP

#589 2009-07-09 21:29:28

Re: Конвертер OSM -> MP

#590 2009-07-09 22:05:59

Re: Конвертер OSM -> MP

#591 2009-07-10 01:57:44

Re: Конвертер OSM -> MP

#592 2009-07-10 04:19:17

Re: Конвертер OSM -> MP

#593 2009-07-10 05:14:12

Re: Конвертер OSM -> MP

#594 2009-07-10 06:18:22

Re: Конвертер OSM -> MP

#595 2009-07-10 07:21:22

Re: Конвертер OSM -> MP

#596 2009-07-10 07:30:57

Re: Конвертер OSM -> MP

#597 2009-07-10 07:41:22

Re: Конвертер OSM -> MP

#598 2009-07-10 07:52:22

Re: Конвертер OSM -> MP

#599 2009-07-10 07:53:10

Re: Конвертер OSM -> MP

#600 2009-07-10 07:56:38

Re: Конвертер OSM -> MP

Board footer