Не, если верить этому, то как раз нет. У всех адресуемых объектов адрес правильный.
liosha
То есть:
Это правильно?
Да, правильно. В конфигах же ничего нет про то, что оно должно что-то создавать.
В каком месте эти associatedStreet есть, чтобы проверить ?
liosha
Это потому что Garmin?
Ну а в СитиГИД-е тогда оно почему не работает? И собственно чем здание полигон лучше здания точки в рамках адресной информации?
Это нужно спросить у составителей ситигидовских конфигов 
ЗЫ
ЕМНИП в конвертации Беларуси когда-то такие точки прописывали, и всё работало.
liosha
Другими словами патчить надо не
http://peirce.gis-lab.info/misc/osm2mp_new.zip
а
https://github.com/Zkir/osm2dcm/tree/master/osm2dcm/osm2mp.config
?
Не, я могу отвечать только за современный конвертер. А в http://peirce.gis-lab.info/misc/osm2mp_new.zip достаточно древняя версия. Есть ли баг в ней, я лично не знаю.
Ясно, спасибо.
видимо тут:
#Address on address points
- condition:
- addr:housenumber = *
- building != *
- amenity != *
- shop != *
- office != *
- tourism != *
- craft != *
- only_node
action:
- action: write_poi
type: 0x6100
contacts: no
Последняя строка что значит ?
Судя по коду: “# contact information: address, phone” - то адрес именно там собирается, а без “contacts: yes” он туда не добирается. Но без отладчика это так, гадание на кодовой гуще 
freeExec
Похоже дело не в этом. При наличии contacts: yes/no адрес точки записывается в MP файл если на ней есть тег addr:street. А вот на наличие associetedStreet он почему-то никак не влияет.
В общем я попробую поиграться с конфигом, если будет результат напишу.
Ох. Ну и непросто же копаться в коде на языке в котором ни бум-бум.
Так что не знаю даже то это или нет + нужно оттестировать, но вот выложу получившийся патч к конвертеру
http://peirce.gis-lab.info/misc/osm2mp_new.zip (кстати там версия 90b)
--- osm2mp_new.pl 2012-04-07 22:27:24.000000000 +0300
+++ osm2mp_new.pl.2 2013-01-21 17:46:56.409912875 +0200
@@ -2176,6 +2176,13 @@
$street .= qq{ ($suburb{$suburb}->{name})} if $suburb;
printf "StreetDesc=%s\n", convert_string( $street );
}
+ else {
+ my $poyid_temp = "node:" . $param{nodeid};
+ my $street_name = $street{$poyid_temp};
+ if ($street_name) {
+ printf "StreetDesc=%s\n", convert_string( $street_name );
+ }
+ }
printf "Zip=%s\n", convert_string($tag{'addr:postcode'}) if exists $tag{'addr:postcode'};
printf "Phone=%s\n", convert_string($tag{'phone'}) if exists $tag{'phone'};
Смысл патча:
Если POI (а как POI там в том числе и адресные точки) не имеет тега addr:street, но входит в relation street/associetedStreet с ролью house, то прописываем такой POI параметр StreetDesc значение которого берем из хэш таблицы отношений улиц.
Как доберусь домой оттестирую это получше.
PS Правда я хз StreetDesc это именно то что нужно или нет 
Если ещё вакансии, я готов пройтись по германскому Бранденбургу.
Рискну предположить, что “Город” в Германии - это:
а) place=isolated_dwelling/hamlet/village/town/city (если попали в такой полигон - хорошо, дальше можно не смотреть)
б) de:place=isolated_dwelling/hamlet/village/town/city (если попали, “город” определён)
в) admin_level=8
Также прошу запустить проверку карт:
DE-BE (Germany, Berlin), IL-FULL (Израиль), IL-GS-WB (Израиль и Палестина), RS-FULL (Сербия), CZ-01 (Чехия, Прага).
Не надо ничего предпологать. Надо быть точно уверенным.
Я например уверен что в Германии вы не найдете ни одного полигона/мультиполигона place.
admin_level=8,9,10
До германии еще дожить надо.
Я был бы уверен, если бы все без исключения линии, точки, полигоны и мультиполигоны были отрисованы лично мной. Гарантировать, что не существует ни одного участника, использовавшего не замеченную мной и потому не озвученную мной схему, я не могу.
А зря. Они там заведомо есть.
Насчёт всех населённых пунктов не буду утверждать, но в нескольких городах, где я смотрел, встречаются admin_level=9 - примерные аналоги районов Санкт-Петербурга (Приморский район, Центральный район), admin_level=10 и admin_level=11 - примерные аналоги нашего муниципального образования (муниципальный округ “Княжево”, муниципальный округ “Дачное”), admin_level=8 там вообще нет, а admin_level=6 - крупная часть города (аналог объединения нескольких районов города). Сам город - admin_level=6 или даже admin_level=4 (но при этом стоят place и/или de:place). В случае не очень крупных поселений admin_level=8 - это коммуны, по которым и имеет смысл адресовать улицы.
Смотрим: только по admin_level=9 и admin_level=10 адресовать нельзя, т. к. это части поселений/коммун (Вы же, наверное, будете искать Невский проспект в населённом пункте “Санкт-Петербург”, а не в “Центральный”). Если адресовать по admin_level=8, получится построить адресацию в небольших поселениях, т. к. admin_level=8 - это обычно коммуны. Но одними admin_level=8 полностью адресацию в Германии не построить, т. к. где-то таких единиц нет (или это часть населённого пункта), а населённые пункты имеют admin_level=6 или даже admin_level=4. Но такие города можно определить по place или de:place.
Это вопрос именно должной схемы. Отклонения (ошибки) могут быть какие угодно, но мы совсем не обязаны их поддерживать. Может с немцами поговорить?
Натестируешь, пиши, патчи должны быть натестированы.
Да, именно оно и нужно.
Я в свое время в примерно таком случае учил три-дэ-макс
Zkir
Собственно:
Патч применяется нормально на вашу версию конвертера.
Вот я выбрал участок для проверки.
Файл экспорта из OSM.
MP файлы получившиеся на выходе конвертера с вашими конфигами:
Непатченного и патченного
Вот дифф этих MP файлов (с кодировкой CP1251) а Он же но перекодированный в UTF-8
По диффам видно, что единственные изменения в карте это появление атрибута StreetDesc у тех нод у которых уже есть HouseNumber. Остальные объекты, в том числе и другие POI не затронуты.
Имена улиц тоже проставлены верно (тут я правда только глазами смотрел).
Этого достаточно, или нужны еще какие нибудь тесты?
Ну и патченный конвертер.
Собственно сам патч
PS
К сожалению perl по нынешним временам мне нигде больше не пригодится 