Если поднять дороги, шрифт для городов сделать побольше, а для деревень поменьше, получится вполне годно.
fserges Нужна, просто отмечены они не очень хорошо. То что при генерализации мелкие объекты вылазят выше - не значит что они должны иметь тот же визуальный вес что и крупные нас. пункты. Ну и пожалуй слишком плотно надписи у гугля раположены.
RusFox вы так говорите как будто нужны прям колоссальные ресурсы. Уж точно меньше чем отрисовка планеты с задержкой применения изменений в 1-5 минут как это удается мапнику на главной. Собственно размещение подписей с равномерной плотностью - это частный случай задачи кластеризации точек. С нею не то что постгреха вполне успешно справляется. С нею и тонкий клиент вполне способен совладать.
Это теория 
Генерализация дорог на словах это тоже просто но где же ежедневно обновляемая обзорка России
стандартный стиль мапника как раз не требует особых нагрузок в отрисовке (у меня Celeron-700, 1Гб RAM вполне справляется), там мощность нужна лишь для ОТДАЧИ клиентам. А вот если попытаться реализовать то, что предлагаете вы (подвыборка НП из подвыборки области для выборки НП) потребует хороших мощностей.
Эм, выборка всех населенных пунктов 100 000 тысяч точек по России и их кластеризация - это быстро, отфильтрованные по конкретному куску карты рф - еще быстрее (по прямоугольной области постгреха фильтрует точки очень быстро). Сто тысяч точек всего, местоположение которых меняется раз в месяц, откуда тут взятся проблемам с производительностью?
Ежедневная обзорка дорог кстати делается - http://peirce.gis-lab.info/daily. Без топологических преобразований, но делается.
Если нормальная обзорка мира/России (а не псевдообзорка путём простого выкидывание некоторых классов объектов) делается то задача генерализации подписей действительно не сложнее.
Мне нужна рендеренная карта OSM Краснодара, подробнее пообщаемся по номеру, вознаграждение прилагается (8-918-101-51-89 Дмитрий)
Генерализация подписей проще, т.к. подписи не роутинговые.
Ну так сделайте кто-нибудь если это так всё просто 
Толсто Просто похоже никому особо не уперлось, чтобы пинать команду мапника на главной осм или к своему слою прикручивать.
C коммуникацией между командой мапника и русским сообществом есть некоторые проблемы)
Понятно
Вот пример не из мапника - Mapsurfer, та же часть Германии:
То есть для отрисовки одного объекта мы должны сначала найти саму область (подвыборка), потом найти все объекты в этой области (подвыборка) и только потом мы получим плотность, высчитаем размеры, отобразим и перейдем к следующему объекту.
Только так мы сможем обеспечить актуальность из ежеминутных диффов, которые используются для отображения основного слоя мапника.
Имхо слой с названиями на зумах с 5 по 17 стоит отдельно генерить, а может и по 22 (и не ради генерализации а ради многоязычности). Соответсвенно вы 1 раз считаете кластеризацию городов и прочих интересующих вас на данном зуме названий. При изменении 1 нас. пункта надо пересчитать расстояние от нового объекта до старых кластеров на каждом из 12 зумов. (Точнее для крупных зумов будет быстрее проверить если в определенной окрестности другие города/кластеры. Это благодаря тому что постгреха строит индексы по геометрии происходит очень дешево).
Хватит уже меня разводить на написание реального примера
dkiselev,
если ты его напишешь, то мы его вставим в мапник в Ситигид.
Кого, его? Алгоритм кластеризации точек на постгрехе? Или на винде/андроиде? Этож не секрет, для постгрехи есть плагин, есть хранимка. Для явы/сей есть несколько алгоритмов. Можно выдрать из опенлеерс. Или нужна отдельная табличка в бд с триггерами на пересчет и процедурами? Чего конкретно нужно то?
Подозреваю, что имелось ввиду перенести алгоритм в конвертер, чтобы на навигаторе были видны деревни на малых зумах.
Дак загвоздка то не в кластеризации, а в том что нужно будет разобраться в конверторе и в том как он работает, хотя бы примерно.
Лучше всего всего плагин для осмозиса, который будет присваивать точечным place=* желаемый максимальный зум. Его смогут использовать все. Технология - java. Крайне желательно без внешней БД.