никто вас не разводит, просто как то вы не совсем понимаете, как работает рендер.
1 раз в минуту, мапник работает на минутных диффах.
а при изменении области - для всех объектов в этой области.
8 гигов из рам чисто под индексы - дешево?
Зачем раз в минуту? Пересчитывать подписи городов требуется только при изменении точки города, триггеры с условиями никто в постгресе не отменял. Заводите доп атрибут у точек города на каких зумах его рисовать и пересччитываете при изменении геометрии точки города. Причем тут изменение областей, названия и взаимное расположение городов не зависит от границ областей. Атрибуты кэпитал и популейшен и т.д. тоже.
Я вполне представляю как работает рендер, точнее я понимаю что вы имеете в виду и почему считаете что это очень дорого. Что рендер выдергивает объектики потом к ним применяет определнные правила рисовать/не рисовать и как рисовать. По крайней мере для точек городов. Ну вот и говорю, добавляете точкам городов 1 атрибут который пересчитываете. Пересчитываете редко, при изменении объектов лишь одного типа. При отрисовке же это всего лишь еще одна колонка при выборке атрибутов.
8 гигов из рам под индексы, для проекта масштабов планеты - дешево, считай что даром, у меня на ноуте 8 стоит, геймеры ради игрушек ставят по 16/32 и разделы винта кэшируют в оперативке чтоб игрушки быстрее загружались. Одноклассники чтобы кешировать муру типа смайликов юзают кэш на 90 гигов из рам, и не считают что это дорого. Уж для индекса геометрии по всей планете, жмотить 8 гиг - это крохоборство. И вам всеравно нужны эти индексы.
триггеры - это хорошо… совсем я про них забыл.
но вы проблему в одну сторону рассматриваете. предположим, я сосчитал плотность около одного НП, вывел размер. вешаю триггер на изменение его геометрии и положения. но это одна сторона медали. но ведь нам надо будет еще пересчитать коэффициент для всех НП около старого местоположения и около нового. а это минимум двойная выборка из всей таблицы 2 раза (до апдейта и после). и тут индексы особо не помогут, потому что для каждой точки придется применить функцию.
Ткну пальцем в небо…
А если считать плотность населённых пунктов на тайл?
Скажем, если нас. пунктов 3 или меньше, то рисуем надписи всех. Если больше, то выкидываем по классам - сначала деревни и т.д. пока не останется 3 или меньше.
С одного зума на другой нас.пункты переходят из 4-х тайлов в один, так что плотность пересчитывается просто.
^^ и получим кашу из десятков равнозначных населённых пунктов. Кроме того не забываем что надписи нп будут пересекаться с надписями рек и прочих объектов а посему откидываться из-за этого. А ещё некоторые названия длиннее других то есть будут первыми кандидатами на вылет. То есть в итоге полуслучайное одеяло из названий которое интересно в алгоритмическом смысле но нифига не удобное по жизни.
Выборка городов идет не по геометрии а просто по атрибутам. Выборка 100 000 записей с джоином по pk и фильрацией по столбцу. Если для бд 100 000 записей проблема - это фэйл, если не хочется тягать эти данные по сети, пишете к постгрехе плагин, вроде как с ней можно и из питона и из явы дружить. В самом “тупом” случае вы в начале считаете расстояние от каждого до каждого это n * n где n - число городов. Потом достаточно пересчитывать расстояние от измененного до каждой из груп. Но это самый очевидный путь.
Можно к примеру строить диаграмму Вороного для всех городов и площадь сектора будет пропорциональна четверти квадрата среднего расстояния до соседей, пусть будет s. (Ну это почти то о чем говорит OverQuantum просто более заумно и более надежно если у ва не 10 н.п. на тайл а наоборот 1 н.п. на 100 тайлов ну и границы тайлов такому методу побоку) Строится диаграмма имнип за n log n. потом просто в зависимости от зума вы либо рисуете точку если s больше выбранного порога для данного зума, либо берете соседейи определяете кого из них отрисовать. Чтобы быстро взять соседей, можно хранить для ячейки ее соседей. Для 100 000 это доступно на кленте не говоря уж о сервере. Все это счасте не обязательно постоянно держать в оперативе. Можно еще построить на этой штуке дерево, укрупняя ячейки и выкинуть из оперативки все листя на диск и держать только вершину дерева опеределенной глубины. Чтобы не пересчитывать всю диаграмму при изменении одного города, можно ограничиваться при пересчете определенным кругом соседей например 2-3 круга соседей имхо вполне достаточно.
Наконец все это нужно на зумах 5-15 где скорость обновления в минуту никуда не уперлась, покатит и раз в день, если не реже. В общем решение придумать можно, было бы желание и свободное время на реализацию.
fserges ну у мапсерфера имхо неплохо получилось.
mapnik (который программа) вобще не берет в расчет тайл, если посмотрите, то многие названия размещаются на разных тайлах. он отрисовывает области, пиктограммы, надписи и линии, а потом уже определяет, что куда пихнуть.
под названием прилепить пиктограмму (точку), размер которой будет соответствовать уровню, как на бумажных картах.
в общем, констатируем:
чтобы отображались названия более удобно, нужно просто переделать всю базу, увеличить и без того огромную нагрузку в разы, усложнить связи…
в результате, правда, это все упрется в “свободу”, которая царит в русскоязычной части OSM, где boundary с admin_level=1 помечаются парки.
я попробовал сейчас частично реализовать то, о чем мы говорили, и получил затык вот на такой фигне.
Никогда не понимал причин подобного нигилизма.
Да я вообще свой собственный рендер поднимать собираюсь, т.ч. я ручками и сделаю как мне надо и меня в общем-то всё устраивает 
Просто сыр-бор потянулся от этого поста:
Не, я не предлагаю название рисовать строго внутри одного тайла. Я предлагаю плотность точек нас. пунктов считать по тайлам. Или по аналогичному иерархическому разделению планеты на прямоугольники. А рисовать как рисуется сейчас - хоть через несколько тайлов.
ИМХО, так проще чем считать диаграмму Вороного или другую “математически красивую” плотность.
Ну можно суммировать количество букв. Если, скажем, 140 букв набралось - начинаем выкидывать нас. пункты низкого уровня. Если шрифты сильно разные, можно количество букв на размер шрифта домножать.
Скажите, допустим в далеком будущем, можно предположить, что вся карта будет отображаться, как на этом сайте? belayatserkov.bc.ua
вроде все ж есть для этого
По ссылке - не карта, а хрен знает что. Кроме как при большом приближении, ничерта различить нельзя, условные обозначения отсутствуют и так далее. За то куча деталей просто выдуманы. Это уже не карта, но еще не bird’s eye, точнее - имитация второго. Надеюсь, что до такого дурацкого вида никогда не дойдет.
Гы 
Прикольно. На этом можно замутить какую-то онлайн-игру. Вроде SimCity или автогонок по городу.
А как карта - это бесполезно.
По-моему, это клево. Буду ждать, когда кто-нибудь сделает такое на основе osm.