Какая же здесь специфика? Эта адресная информация важна для всех потребителей.
Точки о которых я говорю не пересекаются ни с какими зданиями-линиями.
Эти точки не будут засорять поиск, а будут только дополнять его
http://www.openstreetmap.org/?lat=56.05319&lon=37.85359&zoom=17&layers=M&node=626360179
Специфика в том, что в тех же гарминах нет типа точек, предназначенного для обозначения городских зданий.
Поиск “ближайших” они именно засоряют.
liosha, по поводу геокодера для Европы.
Будет здорово и всем польза, если ты его сделаешь. Либо в osm2mp, либо даже в виде отдельного скрипта. Бежит, понимаешь, по mp, если видит HouseNumber=* или StreetDesc=, присваивает CityName= и RegionName=*
На последней версии скрипта у зданий-мультиполигонов, входящих как house в отношение associatedSteet, вместо улицы в StreetDesc прописывается город. Этот дом раньше выглядел так:
; WayID = r2108235
; building = yes
[POLYGON]
Data0=(50.4935693,30.4047994),(50.4943519,30.4047926),(50.4943525,30.4049787),(50.4942481,30.4049796),(50.4942492,30.405295),(50.4948818,30.4052895),(50.4948816,30.4052171),(50.4950144,30.405216),(50.4950114,30.4043654),(50.4946841,30.4043682),(50.4946811,30.4034745),(50.4943562,30.4034773),(50.4943593,30.4043862),(50.4937627,30.4043913),(50.4937624,30.404312),(50.4936531,30.4043129),(50.4936535,30.4044028),(50.493568,30.4044035),(50.4935693,30.4047994)
Data0=(50.49453,30.4047879),(50.4945289,30.4045252),(50.4947865,30.4045226),(50.4947882,30.4049378),(50.4944692,30.4049409),(50.4944686,30.4047885),(50.49453,30.4047879)
Type=0x13
Label=13
CityName=Київ
CountryName=Україна
HouseNumber=13
RegionName=Київ
StreetDesc=Маршала Гречка вулиця
[END]
а теперь:
; WayID = r2108235
; building = yes
[POLYGON]
Data0=(50.4935693,30.4047994),(50.4943519,30.4047926),(50.4943525,30.4049787),(50.4942481,30.4049796),(50.4942492,30.405295),(50.4948818,30.4052895),(50.4948816,30.4052171),(50.4950144,30.405216),(50.4950114,30.4043654),(50.4946841,30.4043682),(50.4946811,30.4034745),(50.4943562,30.4034773),(50.4943593,30.4043862),(50.4937627,30.4043913),(50.4937624,30.404312),(50.4936531,30.4043129),(50.4936535,30.4044028),(50.493568,30.4044035),(50.4935693,30.4047994)
Data0=(50.49453,30.4047879),(50.4945289,30.4045252),(50.4947865,30.4045226),(50.4947882,30.4049378),(50.4944692,30.4049409),(50.4944686,30.4047885),(50.49453,30.4047879)
Type=0x13
Label=13
CityName=Київ
CountryName=Україна
HouseNumber=13
RegionName=Київ
StreetDesc=Київ
[END]
Это ошибка скрипта или надо что-то в конфигах подкрутить?
Почему при конвертации в *.mp из *.osm не переносятся точки с тегами “ЗЕБРА” highway=crossing
Баг, починил.
А в конфигах оно прописано?
Привет, liosha.
Давненко не пользовался твоим скриптом “osmget”. Тут попробовал и что-то совсем не то скачалось… Однако, недалеко от области, которая была задана соответствующими координатами. Описание использования (в каком порядке задавать координаты) брал из вики. Что может быть не так?
Что угодно 
Скрипт безбожно устарел, не поддерживается и не рекомендуется.
Спасибо за ответ!
Вы не знаете кто обслуживает!? navitel.osm.rambler.ru как с ними связаться что-бы скрипт подправили
у них нет
а Тут есть!
gis-lab.info/data/mp/
Чем же тогда качать большие куски?
тут свой регион поищи
data.gis-lab.info/osm_dump/dump/latest/
А если нужен определенный фрагмент? Нашел решение, порядок ввода значений области неправильный на вики. Надо такой - minlat, minlon, maxlat, maxlon. Исправьте там, пожалуйста, а то, я думаю, есть еще люди, которые используют этот скрипт.
Пока думаю его сделать в самом osm2mp, тем более что для этого в основном всё готово.
Но даже так там придётся приводить некоторые вещи, которые сейчас конкретные, к сильно общему виду, а это небыстро.
Можешь особенно не торопиться, я уже почти написал отдельный “геокодер”-постпроцессор 
osm2mp 1.03-704
На выходе у всех дорог поменялись местами широта и долгота.
Иначе говоря, координаты узлов вместо 58.5247527,48.8450797 теперь выглядят как 48.8450797,58.5247527
Не должно. Библиотеки не забыл обновить?
ЗЫ.
А, вспомнил. Там действительно порядок поменялся:
http://code.google.com/p/osm2mp/source/diff?spec=svn701&r=701&format=side&path=/trunk/cfg/output-polish.yml
Не знаю в какую тему написать: сообщение от Kotelnikov навело на мысль о постпроцессоре, который прореживал бы данные для определенного масштаба, чтобы не получалась “каша” (напомню там речь шла о нагромождении natural=peak, но это с равным успехом относится к населенным пунктам).
Например у нас есть много natural=peak в какой-то области карты. Алгоритм в зависимости от масштаба (который соответствует Level) оставляет значимые объекты, но делает это так чтобы на определенной площади было не более заданного количества объектов. Например не более четырех горных вершин в радиусе 1 см экрана, или не более двух нас.пунктов в радиусе 1 см, и т.д. Объекты выбираются по убыванию веса - высоты горы, численности населения, статуса нас.пункта и пр. В этом случае можно получить информативную карту для любой местности - как насыщенной данными, так и тундры. Т.е. например в Московской области на определенном масштабе будут видны только областные центры и города, а в Сибири на этом же масштабе будут видны вахтовые поселки.
Понятно что все устройства разные, но мы же выбрали методом тыка значения level для различных объектов…
Возможно это удастся даже внедрить в сам конвертер osm2mp ?
liosha
Всё ясно стало. Набор библиотек и конфигов у меня целиком из osm2mp-read-only. При использовании дефолтных конфигов все дороги на месте, а с конфигами гармина они убежали в Казахстан.
Не мог найти проблемный файл потому, что утилита сравнения каталогов посчитала оба output-polish.yml одинаковыми (не включил опцию “по содержимому”)
Спасибо, работает.
А мне ещё хотелось бы, чтобы таким же образом фильтровались дороги.