на эти оба вопроса есть ответ в плане адресного поиска, а вот выводить результаты - тут есть некоторые для меня проблемы. Адресный поисковик почти готов, но сейчас авраал на работе, приходиться по выходным работать 
думаю в течении 2 недель найду время добить адресный поиск
ErshKUS, мы очень на тебя рассчитываем, но сейчас вопросы скорее не “как искать? какой должен быть алгоритм”, а “что хотят пользователи? Что нужно человеку?”. Ответить на него в контексте данной темы должен j-wills 
Zkir, зачем же на меня такую ответственность возлагать ? В принципе, ни чего сверхъестественного в поисковике не нужно. Думаю, надо начать с простого, а потом постепенно обрастать новыми фичами. В первую очередь необходимо обеспечить скорость, точность, интуитивность поиска и его “лёгкость” для сервера.
Очень много частных случаев, каждый из которых надо рассматривать отдельно, аля:
- поиск по одному слову из названия улицы: улица Зои и Александра Космодемьянских (к примеру: Александр) и чтоб выдавало сначала все улицы в городе, при чём объединяя разные статусные части улицы в одну, где содержатся “Александры”, потом по удалённости…посёлок в области, город в регионе, город в стране;
- поиск по полному адресу с указание номера дома, строения/буквы;
- поиск города/посёлка в стране;
- поиск улицы, дома и т.д. в другом городе;
- поиск в других странах на разных языках.
Потом уже к POI перейти с возможностью отображения не только точки на карте, но и её адреса, и других имеющихся на ней атрибутов, и “ещё организации в этом здании”.
Ну, и ещё много…много…много мыслей
А ещё хотелось бы русские тайлы по типу OpenStreetMap.by. Так-то бы они бы и так сгодились, но Чалябiнск меня немного напряг
Я так-то знаю, но там какая-то секретная ссылка раньше была чтобы смотреть все данные ОСМ. Сейчас что-то изменилось?
Короче, там флеш.
Ну а раз тайлы уже есть, задача упрощается, надо просто красиво их показывать
Чуток добавил. Хотелось бы всё же видеть результат и тогда уже набивать туда информацию.
По-хорошему, сделать бы online-разбор этого перевода. Т.е. какая-либо страничка на вики, куда народ постит значения новых тегов, перевод их, значки их и это дело онлайн-рисовалка-искалка тегов подхватывает и тут же отрисовывает. В таком режиме можно будет силами сообщества отточить “смотрелку карты” “до блеска”.
Ну и модульность и гибкость кода ресурса, чтобы не переписывать в будущем, а дописывать… 
П.С. сам в веб программировании ни бум-бум. Только си и баш. 
Это было только к вопросу о тайлах, на которых хорошо видны дороги и НП. Ещё там есть супер-вещь, названия дорог рендерятся не на их кусочках, а полностью на дороге!
Вот эта задача мне актуальна в рамках другой, собственной задумки. Не знаю, выделю ли когда-либо время на её реализацию, но всё-таки.
Дык вот первый же возникший вопрос - а есть ли источник тайлов (с покрытием хотя бы по России) без прорисованных POI и названий? Или придётся свои рендерить?
PS: Если вопрос банальный/некорректный - просьба ногами не пинать, с миром OSM тесно не знаком (так, рисую родной город потихоньку, да немного другие по результатам поездок), а технологическая фрагментированность в опенсорсе очень высока, сложно сходу найти ответы на многие вопросы
LinFor, насколько мне известно нет, поэтому и собирались делать свой тайловый сервер, но до него еще руки не дошли.
Простейший вариант. В левую руку берём cloudmade… Правой настраиваем его под себя. Нам нужен рендер совсем без POI. Это легко, тысячи их. Я себе недавно вот такой накрутил:
http://maps.cloudmade.com/?lat=55.771733&lng=37.592543&zoom=17&styleId=43412
У простого способа, как водится большие минусы:
- Редактор Cloudmade мягко говоря “не очень гибкий”.
- Обновляется Cloudmade c боооольшой задержкой.
Что такое “эталонный маршрут” и откуда он берется?
Хотя полезным будет даже сравнивать длину кратчайшего маршрута с расстоянием по прямой - позволит выделить для последующего ручного анализа места, подозрительные на предмет удаления или просто отсутствия участков дорог, которая должны были бы быть.
Как обычно при автоматическом тестировании, за эталон принимаются результаты первого прохода программы, в данном случае - валидатора. Если результаты N-го прохода отличаются от первого, это значит что рутинг существенно изменился, и надо разбираться, почему.
Про корованы забыли…
Самый главный корован, который надо ограбить - сделать, чтобы в дневниках на osm.org можно было отвечать на комменты, и приходили уведомления об ответах на почту.
А вот ещё интересная задачка.
Дано: растр, libjpeg.
Надо: пропатчить libjpeg/gdal так, чтобы пиксели со значением (0,0,0) не оказывали никакое влияние на тот спектр, который будет записан для блока самим libjpeg.
Подробнее: https://plus.google.com/u/0/101291029394395748419/posts/T5vyUKGkPjF
Если это сделать, то геотиффы с фотографиями (а-ля Великие Луки http://latlon.org/maxi?zoom=10&lat=56.40796&lon=30.54385&layers=0000000000000FF0000FBF)) можно будет спокойно делать не 50-, а 3-4-меабайтными, без боязни того, что на склейках вылезут чёрные края от артефактов сжатия jpeg.
Да, это задачка скорее для математиков, чем для программистов. Известно, что аудиокодеки, например Vorbis использует Linear prediction для того, чтобы избежать артефактов в начале и конце трека(в случае, когда они начинаются/заканчиваются не тишиной). А тут поневоле придётся изобретать Bilinear prediction.
Не проще ли отказаться от jpeg для таких тайлов, и использовать png ?