С lonely нужно убрать locality.
Я примерно такую же цель преследовал, только не смог добиться от мапника желаемого мне результата. Поэтому обратился к старому доброму Qgis и сделал там почти всё, что хотел. Косяков у Qgis не меньше,чем у мапника, но их или можно обойти или можно терпеть. Главная задача - выгонять карту в печатный вид за один проход, не используя никаких графических редакторов для последующей обработки. Все подписи КП и старта с финишем берутся из непосредственно gpx файла.
Такая огромная карта до сих пор находится на стене в зале ожидания на Финляндском вокзале.
Но тогда уж надо копировать стиль генчтаба на основе http://opentopomap.org
- Опубликовал картостиль (пока без readme)
- Данные теперь обновляются ежеминутно (для z6-z9 нужно дёргать /dirty)
- Была проблема с горизонталями — теперь рисуются.
Стиль генштаба недружелюбен, и его почти невозможно повторить в мапнике. Есть шанс в QGIS (и old_Bibigon, вроде, начинал делать библиотеку символов). А стиль карт того ЗАО можно увидеть на любой станции метро, они там главные поставщики.
Может быть оффтоп, прошу прощения.
Но есть ли возможность подключить описываемый выше стиль и стиль http://opentopomap.org к SASPlanet?
Думаю, вы сами можете ответить на свой вопрос. Конечно, можно.
Измените zmp для openstreetmap в соответствии с URL-ами для искомых серверов, и будет вам счастье.
Четыре новости:
— раздув базу в 1,7 раза, увеличил площадь покрытия на СЗФО, ЦФО, ДВФО и Литву почти целиком. Это предел, для дальнейшего увеличения потребуется сервер с большим диском;
— стиль Lonely Places теперь полезен для упомянутых территорий, также сделал фильтр по значениям highway, и добавил проверку на railway;
— открыл статистику сервера: из неё можно узнать, что база сейчас весит 16 гигабайт, тайлы — полгига, а один тайл отрисовывается примерно за 0,15 секунды (это долго);
— картостиль просто создан для северных территорий, на альтернативах шестой зум пустой:
Про баг с китайскими названиями я в курсе.
Сейчас работаю над продвинутым аналогом nik2img, чтобы сделать выгрузки в формате OziExplorer (велосипедисты его любят) и скачивание выделенных областей в svg.
Уменьшил размеры надписей и толщины линий, теперь карта выглядит значительно чище. И насыщеннее: так, на z9 появились highway=tertiary.
Также опубликовал крутейший скрипт для рендеринга мапником в картинки: Nik4, длинная документация с примерами по ссылке. Скоро прикручу его на сайт с тайлами, чтобы можно было сразу скачивать svg карты с маршрутом и масштабной линейкой.
Заранее извиняюсь за пессимистичный комментарий, но то, что появился очередной стиль, не поддерживающий surface, несколько удивляет. Ну и раз он велосипедный, можно было под это дело наконец-то придумать систему обозначения проходимисти тропинок, т.к. bicycle=yes/no как бы не подходит и нигде не отображается, но больше ничего и нет.
Вообще, несколько удивляет то, что велосипедисты либо используют достаточно сложный Ozi, либо рисуют маршруты прямо по равномерно-зелёным лесам без намёка на тропинки от Яндекс-карт. А учитывая, что не все понимают даже то, что OpenCycleMap=OSM и его можно править (пруф) (и это несмотря на наличие этого слоя на главной), немногие узнают и будут использовать этот стиль (разве что если включть его в MapBBCode с повсеместным внедрением оного).
Меня самого очень огорчает, что нет адекватного стиля с отображением покрытия дорог (не считая UniRS для османда). Возможно, во второй половине лета я им займусь. Стиль veloroad создан для клуба веломарафонцев, поэтому покрытие там не важно, а важны горизонтали и ориентиры: примыкающие дороги, населённые пункты. Выгруженные масштабы в Ozi выложу завтра. Раз велосипедистов не обучить осму, буду продвигать осмокарты в те инструменты, которыми они уже пользуются.
Немного оффтоплю, но в первом посте как бы мимоходом было упомянуто вот что:
Вообще интересно было бы почитать, но не совсем понятно: эти “хитрости” касаются именно взаимодействия оболочки для рендера с базой данных или же оба компонента рассматриваются по отдельности? Потому что дальше в том же абзаце идёт рассказ о стиле ЗАО “Карта”, а это больше “по дизайну” (TileMill), а не “по данным” (PostGIS). Хотя, может, это просто “лирическое отступление”, к теме отношения не имеющее 
Хороший дизайн подразумевает сложную обработку данных, особенно в OSM.
Никогда не пробовал большие выгрузки, отсюда вопрос: Ozi умеет работать с нашей проекцией веб-Меркатор (нелинейный масштаб в зависимости от широты) ?
По-моему, да, умеет: треки ложатся на полученные подложки для Ozi отлично.
Сделал выгрузки масштабов 8, 9, 9.5 и 10 в 150 dpi для ozi, ссылка и инструкция по использованию — на textual.ru/brevet.
Рассказал про стиль в штосме. Также посчитал занимаемое базой данных место: после заливки 17 гигабайт, прирастает на 0,6 в день. Поэтому примерно раз в 10 дней приходится перевырезать и загружать заново. Это автоматизировано, но всё равно неприятно: хотелось бы минутное обновление не всей планеты, а только нужного региона.
Грохать не нужные данные после каждого наката дифа?
Диффы же накатываются ежеминутно, и сразу на базу: не уверен, что удаление данных из базы по полигону будет достаточно быстрым (и ничего не поломает в механизме обновлений).
У меня это реализовано так:
процедуру накатывания дифов вызывает демон, после чего он же запускает процедуру очистки, соответсвенно, пока чистка не закончится следующего дифа не будет.
процедура очистки:
• все изменения дифов логируются тригерами
• на старте очистки тригеры дизейблятся (тригер просто не осуществляет логирование при наличии некоего значение в некоторой таблице)
• по логам анализируются измененные записи и удаляются не нужные
• опять же по логам анализируются не изменялись ли статистируемые объекты и обновляются в статистических таблицах
• очищаем логи, включаем тригеры логирования, процесс очистки окончен.
Благодаря анализу лишь измененных данных и расстановки соответсвующих индексов процедура очистки и обновления данных порядка десятка таблиц происходит быстрее наката диффов.
немного статистики по накату ~5-ти минутным диффам (регион - Эстония)
Не очень разбираюсь в деталях, но предложу вариант - не накатывать закачанные обновления (osc) сразу, а сначала обрезать osmfilter-ом, например. Это если есть возможность покопаться в скриптах обновления.