Картостиль veloroad для печати маршрутов

Заранее извиняюсь за пессимистичный комментарий, но то, что появился очередной стиль, не поддерживающий surface, несколько удивляет. Ну и раз он велосипедный, можно было под это дело наконец-то придумать систему обозначения проходимисти тропинок, т.к. bicycle=yes/no как бы не подходит и нигде не отображается, но больше ничего и нет.

Вообще, несколько удивляет то, что велосипедисты либо используют достаточно сложный Ozi, либо рисуют маршруты прямо по равномерно-зелёным лесам без намёка на тропинки от Яндекс-карт. А учитывая, что не все понимают даже то, что OpenCycleMap=OSM и его можно править (пруф) (и это несмотря на наличие этого слоя на главной), немногие узнают и будут использовать этот стиль (разве что если включть его в MapBBCode с повсеместным внедрением оного).

Меня самого очень огорчает, что нет адекватного стиля с отображением покрытия дорог (не считая UniRS для османда). Возможно, во второй половине лета я им займусь. Стиль veloroad создан для клуба веломарафонцев, поэтому покрытие там не важно, а важны горизонтали и ориентиры: примыкающие дороги, населённые пункты. Выгруженные масштабы в Ozi выложу завтра. Раз велосипедистов не обучить осму, буду продвигать осмокарты в те инструменты, которыми они уже пользуются.

Немного оффтоплю, но в первом посте как бы мимоходом было упомянуто вот что:

Вообще интересно было бы почитать, но не совсем понятно: эти “хитрости” касаются именно взаимодействия оболочки для рендера с базой данных или же оба компонента рассматриваются по отдельности? Потому что дальше в том же абзаце идёт рассказ о стиле ЗАО “Карта”, а это больше “по дизайну” (TileMill), а не “по данным” (PostGIS). Хотя, может, это просто “лирическое отступление”, к теме отношения не имеющее :slight_smile:

Хороший дизайн подразумевает сложную обработку данных, особенно в OSM.

Никогда не пробовал большие выгрузки, отсюда вопрос: Ozi умеет работать с нашей проекцией веб-Меркатор (нелинейный масштаб в зависимости от широты) ?

По-моему, да, умеет: треки ложатся на полученные подложки для Ozi отлично.

Сделал выгрузки масштабов 8, 9, 9.5 и 10 в 150 dpi для ozi, ссылка и инструкция по использованию — на textual.ru/brevet.

Рассказал про стиль в штосме. Также посчитал занимаемое базой данных место: после заливки 17 гигабайт, прирастает на 0,6 в день. Поэтому примерно раз в 10 дней приходится перевырезать и загружать заново. Это автоматизировано, но всё равно неприятно: хотелось бы минутное обновление не всей планеты, а только нужного региона.

Грохать не нужные данные после каждого наката дифа?

Диффы же накатываются ежеминутно, и сразу на базу: не уверен, что удаление данных из базы по полигону будет достаточно быстрым (и ничего не поломает в механизме обновлений).

У меня это реализовано так:
процедуру накатывания дифов вызывает демон, после чего он же запускает процедуру очистки, соответсвенно, пока чистка не закончится следующего дифа не будет.
процедура очистки:
• все изменения дифов логируются тригерами
• на старте очистки тригеры дизейблятся (тригер просто не осуществляет логирование при наличии некоего значение в некоторой таблице)
• по логам анализируются измененные записи и удаляются не нужные
• опять же по логам анализируются не изменялись ли статистируемые объекты и обновляются в статистических таблицах
• очищаем логи, включаем тригеры логирования, процесс очистки окончен.
Благодаря анализу лишь измененных данных и расстановки соответсвующих индексов процедура очистки и обновления данных порядка десятка таблиц происходит быстрее наката диффов.

немного статистики по накату ~5-ти минутным диффам (регион - Эстония)

Не очень разбираюсь в деталях, но предложу вариант - не накатывать закачанные обновления (osc) сразу, а сначала обрезать osmfilter-ом, например. Это если есть возможность покопаться в скриптах обновления.

Приятный стиль! Заинтересовал значок железнодорожных станций) Можно узнать, от чего зависит размер значка и положение серого квадратика на нем?

Тоже поначалу склонялся к этому варианту, однако не нашел готового решения, решил костылять, взялся за дело и задумался “а как?”. Попадала нода в наш регион, ее кто-то подвинул и она вылетела, мы ее из дифа вырезали (диф имеет только актуальные данные), ибо не попадает, а у себя оставили. Не годится.

Хм. Спасибо за картинку со статистикой, она обнадёживает. Правда, я так понимаю, твоя база — совсем не osm2pgsql --slim. Я поэкспериментирую в этом направлении как-нибудь.

Размер зависит от значения: railway=station или railway=halt. Положение серого квадратика на картах генштаба обозначает направление выхода, но у меня оно, к сожалению, случайно: это направление по данным OSM никак не определить в общем случае.

У меня osmosis PostGIS + hstore без потери данных (если не ошибаюсь, osm2pgsql льет только интересующие данные). Геометрии строю только на те объекты, которые интересуют и хранятся они в отдельных, тех самых, статистических таблицах.

Zveik, а как у тебя получается значок вдоль линии поворачивать?

Разный знак для станции и остановки давно использовался на космоснимках, но не поворачивается. А фича, про то, что поворачивать его лицом к станции -это следующий вызов

Кстати, подписи населенных пунктов рисуюся с пунсонами или без. Смешивать это на одной карте для разных типов нп в правилах классической бумажной картографии не принято . Этим грешит яндекс, но что им до советской картографической школы)

и зеленые массивы слишком мелко (ИМХО) подписаны

Сейчас вспомнился еще один, рассматриваемый мною вариант (уже не помню, в следствии чего я от него отказался), возможно, он тебе больше подойдет.

Перекидываешь паблик таблицы в новую схему, паблик наполняешь аналогичными пустыми таблицами. Перенесенные таблицы наследуешь от соответсвующих паблик таблиц. При должном тестировании запросов эту процедуру можно проделать прямо на живую. Что имеем в итоге:
• Рендер обращается к паблик таблицам и видит данные как пустых паблик, так и данные живых таблиц, ибо они наследованы. Ничего не изменилось.
• osm2pgsql накатывает дифы на паблик, инсерты идут в паблик, делиты и апдейты отрабатывают как на пустом паблике, так и на наследованных. Т.е. для osm2pgsql тоже ничего не изменилось, но, живые данные тут же апдейтятся, а вот новые объекты остаются только в паблике. Анализом данных только паблика с живыми данными + нужный регион решается судьба этих новых объектов.

Угол беру от ближайшего к точке стометрового отрезка железной дороги. Стиль выложен на гитхаб, sql-запрос можно взять оттуда. Проблема со станциями — что их почти нигде нет. Или, например, что делать на остановках двухпутных линий, где платформы внутри или снаружи?

Я знаю, что неаккуратненько, но — удобно. Маркеры убираются для небольших городов, чтобы не закрывать сеть дорог. По-моему, там всё достаточно хорошо подогнано, чтобы было понятно, к чему относятся подписи.

На все претензии к размеру букв ответ один — карта должна хорошо смотреться на печати, поэтому размеры принудительно уменьшены (поначалу были на 1-4 пункта больше). На тайлах кое-как читается, уже хорошо.

Насчет советской картографической школы не знаю, а вот в западной такой подход применяется. Но в этом случае контур нп должен быть каким-то образом выделен (цвет, ширина контура), а надпись поставлена в место, где проявляется наиболее высокая степень их взаимоотношения. Причем расстояние между полигоном и надписью должен зависить от масштаба, размеров области (полигона) и надписи (шрифта).

Runge,
для населенных пунктов -пунсон -это не только местоположение объекта на карте, но и отображение типа объекта. Обычно это численность населения и административная принадлежность. Если пунсон убрать, то и то и другое можно выразить в шрифте, но если смешать две сущности -пунсон и разные шрифты -получится конфликт легенд. У “западников” на мелкомасштабных картах возможен вариант, когда агломерацию показывают площадным знаком, соответсвующим ее реальному контуру и это типа пунсон. и красят ее цветом пунсона. Но это справедливо, пока этот контур в масштабе не сильно от пунсона отличается по размерам