Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Во-первых, нужно использовать «правильную» цветовую модель, я обычно использую HSB/HSL
Я бы назвал «правильными» LAB/HCL, они в достаточной степени учитывают восприятие цвета. А чтобы «учитывать известные фичи человеческого зрения» и контекст хорошо бы взять CIECAM02.
Вот пост на эту тему был бы очень полезен, думаю.
Согласен, Lab, HCL и cubehelix изначально созданы с учётом особенностей человеческого восприятия. Но в отличие от тематических карт использование этих моделей при разработке стиля подложки представляется мне затруднительным. Если знаете подходящий инструмент для этого, напишите. Я в своё время ничего такого не нашёл и даже подумывал о создании инструмента на основе d3.js и chroma.js для этих целей.
А вот про то, как использовать CIECAM02 на таких масштабах я бы тоже с удовольствием почитал.
А вот про то, как использовать CIECAM02 на таких масштабах я бы тоже с удовольствием почитал.
К вопросу о HCL.
Вы выше ругаете Яндекс за выбор цветов для визуализации пробок. Вот я попробовал, используя HCL, подобрать те же цвета (красный, желтый, зеленый) так, чтобы L и C у них были постоянными, а менялся только тон (H), то есть чтобы не выходило такой разношерстной черно-белой картинки, которую вы приводите, как иллюстрацию нарушения иерархической схемы.
Вот что вышло:
Если увеличить Chroma, между красным и зеленым образуются невозможные цвета, так что такой набор невозможен (желтый выпадает).
При Chroma порядка 1.5 цвета выглядят, мягко говоря, отвратительно: зеленый и красный слишком бледные (насыщенный зеленый и красный — это Chroma порядка 2.0), а желтый — это что-то грязное, желто-коричневое (опять же, чистый насыщенный желтый возможен при Chroma 1.35 или около того).
Так что все это не столь просто, взять и выбрать…
Вы выше ругаете Яндекс за выбор цветов для визуализации пробок. Вот я попробовал, используя HCL, подобрать те же цвета (красный, желтый, зеленый) так, чтобы L и C у них были постоянными, а менялся только тон (H), то есть чтобы не выходило такой разношерстной черно-белой картинки, которую вы приводите, как иллюстрацию нарушения иерархической схемы.
Вот что вышло:
Если увеличить Chroma, между красным и зеленым образуются невозможные цвета, так что такой набор невозможен (желтый выпадает).
При Chroma порядка 1.5 цвета выглядят, мягко говоря, отвратительно: зеленый и красный слишком бледные (насыщенный зеленый и красный — это Chroma порядка 2.0), а желтый — это что-то грязное, желто-коричневое (опять же, чистый насыщенный желтый возможен при Chroma 1.35 или около того).
Так что все это не столь просто, взять и выбрать…
Так что все это не столь просто, взять и выбрать…
Это точно! Важно понимать, что это не проблема цветовых моделей. Хотим цвета одинаковой яркости — получим не самые насыщенные и выразительные. Хотим предсказуемую цветовую модель (цилиндр) — получим подогнанные, «бессмысленные» координаты.
Поэтому подбор цветов остаётся делом творческим, полностью его не автоматизируешь.
Так нет же, L в этом случае и не должна быть постоянной — она лишь должна меняться равномерно (или хотя бы монотонно).
Тогда в ч/б виде получится шкала оттенков серого (хотя будет ли она интуитивно понятна — вопрос открытый).
Тогда в ч/б виде получится шкала оттенков серого (хотя будет ли она интуитивно понятна — вопрос открытый).
А в этом случае цвета выйдут еще хуже.
Потому тут как с адаптивным дизайном: попытка угодить всем ведет, вероятнее всего, к тому, что все будет устроено слишком сложно с точки зрения разработки и выглядеть будет одинаково неудобно для всех.
Потому тут как с адаптивным дизайном: попытка угодить всем ведет, вероятнее всего, к тому, что все будет устроено слишком сложно с точки зрения разработки и выглядеть будет одинаково неудобно для всех.
Да, я имел ввиду именно тот факт, что нет шкалы по яркости. Обратите внимание на отрезок Садового кольца рядом со станцией метро «Цветной бульвар». Там в одну сторону всё красное, а в другую зелёное, при этом они неотличимы по яркости. Это ж провал =).
Конечно при выстроении такой возрастающей палитры поломается визуальная иерархия самих дорог, но это не страшно, ведь слой отключаемый.
Картинка с пробками
Конечно при выстроении такой возрастающей палитры поломается визуальная иерархия самих дорог, но это не страшно, ведь слой отключаемый.
Меня в плане слоёв карт дико бесит низкий приоритет железных дорог по сравнению с автомобильными.
Почему ЖД отображаются только при большой детализации? При крупном масштабе, когда отдалил карту, чтобы увидеть большой кусок страны, ЖД почему-то пропадают, а мне подсовывают схему автотрасс, которые мне абсолютно не интересны. (И я лично, подсознательно воспринимая автодороги вещью многократно менее значимой, чем ЖД, постоянно путаюсь, забывая, что эти линии на карте именно автодороги, а не ЖД).
И, что особенно печально, ни у Яндекса, ни у OpenStreetMaps нет опции, позволяющей изменить это поведение, либо я о ней не знаю. У OSM, правда, есть режим «Карта транспорта», но там стиль целиком меняется, а хотелось бы иметь настройку для стандартного вида (который в остальном хорош).
Почему ЖД отображаются только при большой детализации? При крупном масштабе, когда отдалил карту, чтобы увидеть большой кусок страны, ЖД почему-то пропадают, а мне подсовывают схему автотрасс, которые мне абсолютно не интересны. (И я лично, подсознательно воспринимая автодороги вещью многократно менее значимой, чем ЖД, постоянно путаюсь, забывая, что эти линии на карте именно автодороги, а не ЖД).
И, что особенно печально, ни у Яндекса, ни у OpenStreetMaps нет опции, позволяющей изменить это поведение, либо я о ней не знаю. У OSM, правда, есть режим «Карта транспорта», но там стиль целиком меняется, а хотелось бы иметь настройку для стандартного вида (который в остальном хорош).
Логика такая, что по автодороге человек едет и ориентируется сам, а по ж/д его везут. И в масштабе страны, как правило, бессмысленно знать, как едет поезд из Москвы в Новосибирск — просто покупается билет, и поезд едет сам. На гражданской карте ведь никто не рисует авиамаршруты? Смысл имеет поиск по карте мелкого полустанка — но это уже на больших зумах.
Задам вам встречный вопрос (без всякого рода подвохов): для решения какой практической задачи железные дороги должны быть видны на обзорных масштабах?
Логика за текущей ситуацией приблизительно такова:
— действительно, в России (но не в остальном мире) железнодорожные грузовые перевозки составляют 85% от всех грузовых;
— однако, «простого гражданина» это не волнует ни капли — он не занимается железнодорожной логистикой;
— плюс, основная часть железнодорожных перевозок (как грузовых, так и пассажирских) — это перевозки из одного (крупного) населенного пункта в другой, а вариантов, как эти пункты соединены железной дорогой, куда меньше, чем вариантов проезда по автомобильной дороге, потому для оценки пути по железной дороге в общем случае достаточно видеть начальный и конечный пункт, а их и так на карте видно;
— соответственно, для пассажира автомобильного транспорта то, как именно пролегает автомобильная дорога, имеет большее значение, чем для пассажира железнодорожного;
— автомобильные перевозки заметно чаще осуществляются между двумя пунктами, один или оба из которых не являются крупными населенными пунктами или даже населенными пунктами вообще.
Так что основной сценарий использования картографических сервисов как раз говорит в пользу приоритета отображения автомобильных дорог над железными на обзорных масштабах.
А каков ваш сценарий, кроме того, что вам (вероятно, по каким-то советским картам, которые выполняли кроме функции ориентирования еще и пропагандистскую функцию) видеть железные дороги — привычнее?
Логика за текущей ситуацией приблизительно такова:
— действительно, в России (но не в остальном мире) железнодорожные грузовые перевозки составляют 85% от всех грузовых;
— однако, «простого гражданина» это не волнует ни капли — он не занимается железнодорожной логистикой;
— плюс, основная часть железнодорожных перевозок (как грузовых, так и пассажирских) — это перевозки из одного (крупного) населенного пункта в другой, а вариантов, как эти пункты соединены железной дорогой, куда меньше, чем вариантов проезда по автомобильной дороге, потому для оценки пути по железной дороге в общем случае достаточно видеть начальный и конечный пункт, а их и так на карте видно;
— соответственно, для пассажира автомобильного транспорта то, как именно пролегает автомобильная дорога, имеет большее значение, чем для пассажира железнодорожного;
— автомобильные перевозки заметно чаще осуществляются между двумя пунктами, один или оба из которых не являются крупными населенными пунктами или даже населенными пунктами вообще.
Так что основной сценарий использования картографических сервисов как раз говорит в пользу приоритета отображения автомобильных дорог над железными на обзорных масштабах.
А каков ваш сценарий, кроме того, что вам (вероятно, по каким-то советским картам, которые выполняли кроме функции ориентирования еще и пропагандистскую функцию) видеть железные дороги — привычнее?
http://www.openrailwaymap.org/?
Добавлю несколько слов об ошибках оформления, которые преследуют многих.
Основной вид ошибок — это слепое копирование чьего-то подхода без оценки того, в какой степени требования к картам совпадают, а также — слепое использование дизайнерских приемов без понимания, для какой цели они служат.
Например, есть люди, которые уверены, что нет ничего лучше, чем советские топографические карты. При чем — для всего. И они готовы доказывать, что карта дорожной сети в городе тоже должна быть похожа не пресловутые «генштабовские» карты, при том, что во-первых, цветовое оформление этих карт было ориентировано не на полноцветную печать (ради упрощения), а во-вторых, это были карты для ведения военных действий, со всеми вытекающими, вроде обозначения второстепенных улиц только как «проемов между контурами кварталов».
И не стоит молиться на какие-то карты, как на икону, думая, что «вот там-то уж точно над этим трудились профессионалы и они не могли сделать дрянь». Очень даже могли, да и задачи у них могли быть совершенно иными.
Другой вариант — это взять и начать подбирать цветовую гамму для карты в каком-нибудь сервисе типа colorbrewer2.org или tristen.ca/hcl-picker не очень понимая, чему же это все цветовое великолепие должно быть присвоено. Итог — цвета, которые гармонично выглядят на соседних квадратиках в интерфейсе color picker-а, оказываются назначены на какие-нибудь контурные объекты, которые перемешаны с другими данными, и получается полный салат. То же самое — с модой на бледные цвета, которые убивают контраст.
Ну и еще одна вещь, которая, конечно, упирается еще и в ресурсы, но про нее совершенно не стоит забывать. Если функций у карты — множество, нужно смириться с тем, что попытка отобразить важные для всех задач объекты на одном слое, вероятнее всего, приведет к тому, что карта окажется одинаково плохой, а не одинаково хорошей для каждой из задач. Так что нужно всегда рассматривать возможность того, что базовый слой так и будет базовым, а часть объектов, относящихся к решению тех или иных задач, будут вынесены в отдельные слои, которые можно включить и выключить по желанию. Только не надо увлекаться и делать свой слой для каждого типа (например, отдельно для разных видов транспорта) — никаких ресурсов на это не хватит, а пользователь сойдет с ума. Картографический сервис все же не ГИС, там это не нужно.
Основной вид ошибок — это слепое копирование чьего-то подхода без оценки того, в какой степени требования к картам совпадают, а также — слепое использование дизайнерских приемов без понимания, для какой цели они служат.
Например, есть люди, которые уверены, что нет ничего лучше, чем советские топографические карты. При чем — для всего. И они готовы доказывать, что карта дорожной сети в городе тоже должна быть похожа не пресловутые «генштабовские» карты, при том, что во-первых, цветовое оформление этих карт было ориентировано не на полноцветную печать (ради упрощения), а во-вторых, это были карты для ведения военных действий, со всеми вытекающими, вроде обозначения второстепенных улиц только как «проемов между контурами кварталов».
И не стоит молиться на какие-то карты, как на икону, думая, что «вот там-то уж точно над этим трудились профессионалы и они не могли сделать дрянь». Очень даже могли, да и задачи у них могли быть совершенно иными.
Другой вариант — это взять и начать подбирать цветовую гамму для карты в каком-нибудь сервисе типа colorbrewer2.org или tristen.ca/hcl-picker не очень понимая, чему же это все цветовое великолепие должно быть присвоено. Итог — цвета, которые гармонично выглядят на соседних квадратиках в интерфейсе color picker-а, оказываются назначены на какие-нибудь контурные объекты, которые перемешаны с другими данными, и получается полный салат. То же самое — с модой на бледные цвета, которые убивают контраст.
Ну и еще одна вещь, которая, конечно, упирается еще и в ресурсы, но про нее совершенно не стоит забывать. Если функций у карты — множество, нужно смириться с тем, что попытка отобразить важные для всех задач объекты на одном слое, вероятнее всего, приведет к тому, что карта окажется одинаково плохой, а не одинаково хорошей для каждой из задач. Так что нужно всегда рассматривать возможность того, что базовый слой так и будет базовым, а часть объектов, относящихся к решению тех или иных задач, будут вынесены в отдельные слои, которые можно включить и выключить по желанию. Только не надо увлекаться и делать свой слой для каждого типа (например, отдельно для разных видов транспорта) — никаких ресурсов на это не хватит, а пользователь сойдет с ума. Картографический сервис все же не ГИС, там это не нужно.
Спасибо за дополнение, всё в тему.
Возвращаясь к проблеме подбора палитры цветов. Colorbrewer заточен именно под тематические карты, так что тут он мало чем полезен. Чтобы постараться избежать цветового винегрета, по идее нужно строить матрицу сочетания всех цветов (попарно), но я такого инструмента не знаю. И всё равно это не решает всех проблем, так что полностью системный подход в этом вопросе весьма сложная задача.
Возвращаясь к проблеме подбора палитры цветов. Colorbrewer заточен именно под тематические карты, так что тут он мало чем полезен. Чтобы постараться избежать цветового винегрета, по идее нужно строить матрицу сочетания всех цветов (попарно), но я такого инструмента не знаю. И всё равно это не решает всех проблем, так что полностью системный подход в этом вопросе весьма сложная задача.
Вот пример матрицы (это openstreetmap-carto, который «стиль по умолчанию», автор — не я):
Подозреваю, что создание такой матрицы упирается в подготовку списка тех типов, которые нужно проверить, ведь в реальности основной набор типов и их сочетаний конечен.
Да, Colorbrewer — это для тематических карт и карт, которые близки к ним визуально. А заблуждение как раз состоит в том, что набор цветов, подчиняющийся принципам цветовой гармонии — что-то универсальное, магически делающее красивым все, где применяется.
Подозреваю, что создание такой матрицы упирается в подготовку списка тех типов, которые нужно проверить, ведь в реальности основной набор типов и их сочетаний конечен.
Да, Colorbrewer — это для тематических карт и карт, которые близки к ним визуально. А заблуждение как раз состоит в том, что набор цветов, подчиняющийся принципам цветовой гармонии — что-то универсальное, магически делающее красивым все, где применяется.
С моей колокольни, так лучше бы народ использовал дизайн (по крайней мере, цвета) топографических карт. Советских, американских, немецких — неважно, чьих. Просто потому, что там достаточно контраста, в отличие от того, что мы видим сейчас в большинстве продуктов. В попытках выделиться и сделать красиво дизайнеры, кмк, забывают об основном назначении карт — объекты должны быть четко видны. Никаких лайт стилей, никаких веб цветов! Это будет смотреться адекватно только в уютненьком офисе, на идеальном мониторе, при идеальном освещении, но никак не на улице на мобильном устройстве. Типичный пример — последний апдейт одних известных оффлайновых карт, которые были выкуплены не менее известной крупной конторой. Дизайнер нарисовал новые цвета. Они в чем-то даже лучше предыдущей версии, но… Грунтовки и тропинки прорисованы белым. Белым, черт возьми, цветом. Мало того, что это плохо узнаеваемо, так это еще и совершенно нечитаемо, если, например, тропинка идет по чему-то вроде поля — которое тоже почти белое. Как выкручиваться? Даже если есть функция автопрокладки маршрута, даже пешего, которая по той же тропинке нарисует маршрут ярким цветом — полагаться на нее нельзя, а порой и опасно. Дизайнер должен понимать, что при выборе цвета от него может зависеть чья-то жизнь, без шуток — просто от того, сможет человек разглядеть дорогу, али нет. Так что уж лучше как-то поближе к топо.
Вы пользуетесь Maps.me с данными OSM вместо топокарты? Ну, я вам могу только посочувствовать.
Изучайте Maperitive/TileMill.
Изучайте Maperitive/TileMill.
Ну скоро уже можно будет свой стиль создать для Maps.me, Илья обещал.
Расшарьте свои стили пожалуйста, как отличные примеры, если они не являются проприарными
С другой стороны в этом же слое хранятся данные о торговых центрах, складах и других весьма больших зданиях, которые на средних зумах будут хорошими ориентирами. Поэтому нужно разбить здания на категории по занимаемой площади и показывать уже частями, в зависимости от зума.
Очень, очень спорный совет.
Лично я, если вижу на определённом зуме здания, то предполагаю, что это ВСЕ здания, присутствующие в базе данных. И от этого отталкиваюсь при визуальном планировании маршрута, анализе карты и т. д. Но стоит «приблизиться» к земле — и появляется ещё куча домиков. Вау! Нехорошо так делать.
Например: квартал, в котором находится много жилых «свечек» (у которых маленькая площадь основания) и один большой торговый центр (его площадь гораздо больше). И что же, на определённом зуме вы будете рендерить только торговый центр!? Пожалуйста, не нужно. Ведь «свечки» гораздо лучше подходят для ориентира из-за их высоты.
Другой пример: металлургический завод и рядом — жилой квартал. Цеха (имеют большую площадь) будут показаны, жилые многоквартирные дома — нет. А между тем, рядовому пользователю интереснее расположение жилых домов, чем промышленных цехов.
P. S. Извините за резкий тон сообщения.
Ну вы вправе не соглашаться со мной =)
Я так понял вы говорите про 3D, раз упоминаете высоту. В таком случае вырастающие вдруг здания будут выглядеть странно. Но я специально не указывал конкретные значения зумов. Предложенный мной вариант является компромиссом, вы можете не идти на него.
Я так понял вы говорите про 3D, раз упоминаете высоту. В таком случае вырастающие вдруг здания будут выглядеть странно. Но я специально не указывал конкретные значения зумов. Предложенный мной вариант является компромиссом, вы можете не идти на него.
Нет, про 3D я не говорил. Когда упоминал полезность высоких зданий для ориентирования — имел в виду ориентирование на местности. Например, когда перед человеком карта на мобильном устройстве, а он гуляет по городу.
Я понимаю этот совет так: при приближении карты к земле пользователю сначала показываются только большие по площади здания, а потом — все. Иллюстрация:
Это место на карте: ссылка.
Такой подход, на мой взгляд, плох, потому что может ввести пользователя в заблуждение (особенно, если он не станет опускаться ниже зума, на котором отсутствует половина домов).
Если при изменении масштаба карты появляются/исчезают объекты разных категорий (например, малозначимые ж/д пути появляются позже, чем основные), то это нормально. При правильном применении карта становится только лучше.
Но когда человек видит на карте какой-то площадной объект, то он подсознательно считает, что видит все существующие объекты этой категории. И тут он узнаёт, что всё совсем не так, и что в данный момент он видит только здания с площадью более N кв. м. Как-то это нехорошо, я считаю.
Я специально сделал оговорку «площадные», потому что точечных объектов (POI) это не касается.
Если я понял этот совет неправильно, то, пожалуйста, поправьте меня.
Лично я, конечно, решу, как мне поступать. Тем более, не уверен, что мне вообще когда-нибудь придётся заниматься созданием картографического стиля :)
Если бы это касалось одного меня, то я вряд ли написал бы комментарий. Но, когда в обучающей статье, которую прочитает много людей, дают неправильные советы, это плохо. А, так как этот совет я посчитал плохим, то и написал свой комментарий.
Я понимаю этот совет так: при приближении карты к земле пользователю сначала показываются только большие по площади здания, а потом — все. Иллюстрация:
Это место на карте: ссылка.
Такой подход, на мой взгляд, плох, потому что может ввести пользователя в заблуждение (особенно, если он не станет опускаться ниже зума, на котором отсутствует половина домов).
Если при изменении масштаба карты появляются/исчезают объекты разных категорий (например, малозначимые ж/д пути появляются позже, чем основные), то это нормально. При правильном применении карта становится только лучше.
Но когда человек видит на карте какой-то площадной объект, то он подсознательно считает, что видит все существующие объекты этой категории. И тут он узнаёт, что всё совсем не так, и что в данный момент он видит только здания с площадью более N кв. м. Как-то это нехорошо, я считаю.
Я специально сделал оговорку «площадные», потому что точечных объектов (POI) это не касается.
Если я понял этот совет неправильно, то, пожалуйста, поправьте меня.
Лично я, конечно, решу, как мне поступать. Тем более, не уверен, что мне вообще когда-нибудь придётся заниматься созданием картографического стиля :)
Если бы это касалось одного меня, то я вряд ли написал бы комментарий. Но, когда в обучающей статье, которую прочитает много людей, дают неправильные советы, это плохо. А, так как этот совет я посчитал плохим, то и написал свой комментарий.
Вы всё правильно поняли, возможно пример не самый удачный. Но основной посыл ведь был в другом.
Я немного отредактировал текст примера. Но я считаю, что вы слишком категоричны, карты бывают разные, и задачи у них тоже разные. Что уместно в одном случае, не подойдёт в другом. А универсальный совет один — всегда думать головой.
Поэтому для каждого слоя данных необходимо сперва определить диапазон видимости в уровнях зума, иначе у нас будет не карта, а спагетти монстр. При этом иногда слой необходимо разделить на несколько, либо создать дополнительный атрибут, содержащий подкатегорию данных слоя. Таким образом, мы сможем прогрессивно увеличивать плотность данных на карте при увеличении зума.
Я немного отредактировал текст примера. Но я считаю, что вы слишком категоричны, карты бывают разные, и задачи у них тоже разные. Что уместно в одном случае, не подойдёт в другом. А универсальный совет один — всегда думать головой.
Практически все электронные карты, которые я видел, всё-таки показывают частные дома несколько позже, чем все остальные. Видимо, чтобы не создавать шума. Так что все здания, наверное, показывать не стоит.
У нас в OpenStreetMap для каждого типа зданий есть своё обозначение. Например, многоквартирные дома обозначаются тегом building=apartments, а частные — building=detached. И на основании значения тега building=* можно строить рендеринг и показывать домики с building=detached позже, чем другие здания.
Но нельзя (имхо) строить рендеринг на основании «у этого многоугольника площадь 100,1 кв. м, поэтому мы его покажем пользователю сейчас, а у этого — 99,9 кв.м, и поэтому мы его покажем на один зум позже».
Но нельзя (имхо) строить рендеринг на основании «у этого многоугольника площадь 100,1 кв. м, поэтому мы его покажем пользователю сейчас, а у этого — 99,9 кв.м, и поэтому мы его покажем на один зум позже».
Добавил дополнение (UPD) в часть о выборе цветовой модели.
Самый сложный и животрепещущий вопрос при создании собственных карт — вопрос генерализации. И для его решения не стоит делать так, как делают картографические сервисы вроде Гугла или Яндекса, потому что они это делают не особо хорошо. Для начинающих: любой масштаб карты или, соответственно, уровень зума, предполагает некоторое обобщение всего того, что изображается. И это обобщение почти всегда сложнее, чем просто настройка стиля изображения и видимости тех или иных объектов. Чтоб сделать хорошую многомасштабную карту, вам нужно для каждого отдельного масштаба создать с помощью алгоритмов генерализации отдельную основу и потом довести её до лоска вручную. Это обычно очень большая работа.
Разберем конкретный пример с генерализацией жилой застройки на картах городов: вот старая карта Генштаба, на ней Москва. По ссылке слева примерно тот же масштаб на Яндекс картах. Городская застройка с тех пор, конечно, изменилась, но некоторые кварталы остались почти такими же. Что можно увидеть, сравнивая старую и новую карты:
1) На карте Генштаба здания стоят относительно друг друга не так, как на картах Яндекса, они сдвинуты. Те, что стоят на границах кварталов, сдвинуты к этим границам, те, что стоят внутри, либо сливаются друг с другом, либо, наоборот отодвинуты друг от друга, так, чтобы читались проходы между ними.
2) На старой карте небольшие здания и их части выглядят «толще». Некоторые вообще как внемасштабные условные знаки.
3) Если вы уменьшите зум на обеих картах, то увидите, что старая карта по-прежнему показывает застройку кварталов, а новая показывает их уже просто заливками разных цветов и отдельные здания. Может создаться впечатление, что изображена какая-то деревня с тремя домами и огородами.
Какая логика стоит за этими небольшими наблюдениями?
В Яндексе решили примерно так: возьмем основу масштаба 1:10000 и настроим отображение домов полигонами до того момента, пока они станут нечитаемыми, а потом просто отключим их и оставим заливку. Плюс этого подхода в том, что не надо делать отдельных слоев со зданиями для разных масштабов, достаточно отрисовать их контуры один раз по спутниковым снимкам высокого разрешения и добавить каждому атрибут с примерной высотой строения. Минус в том, что в какой-то момент относительно маленькие здания превращаются в нечитаемые пятнышки и это нельзя выправить простыми средствами, например, поставив для стиля изображения обводку полигонов некоторой внушительной толщины. Поскольку Яндекс-карты это продвинутый атлас автодорог, понять их можно.
Логика генштабовского картографа была примерно такова: нужно показать застройку на масштабе, который не позволяет её изобразить полностью масштабными обозначениями. При этом основные элементы должны остаться читаемыми. И он для этого сдвинул здания друг относительно друга, исказил их контуры. Плюс этого подхода в том, что застройка кварталов осталась читаемой на относительно мелком масштабе, минус в том, что при современном подходе пришлось бы применять для этого сложные алгоритмы и потом всё равно доводить результат вручную.
Приведенный пример может показаться надуманным: когда можно легко сменить масштаб карты, непонятно зачем заморачиваться и перегружать её разными элементами, но я лично думаю, что заморачиваться всё же стоит. Карту с хорошо обобщенными деталями читать проще, на ней выделено важное и скрыто второстепенное. Меня в своё время поразило, что на картах SwissTopo отдельностоящие дома отображаются на масштабах вплоть до 1:100000. Для них это важно, поэтому они обобщают свои карты так, создавая для всех этих домов внемасштабные знаки, да ещё и ориентированные.
Разберем конкретный пример с генерализацией жилой застройки на картах городов: вот старая карта Генштаба, на ней Москва. По ссылке слева примерно тот же масштаб на Яндекс картах. Городская застройка с тех пор, конечно, изменилась, но некоторые кварталы остались почти такими же. Что можно увидеть, сравнивая старую и новую карты:
1) На карте Генштаба здания стоят относительно друг друга не так, как на картах Яндекса, они сдвинуты. Те, что стоят на границах кварталов, сдвинуты к этим границам, те, что стоят внутри, либо сливаются друг с другом, либо, наоборот отодвинуты друг от друга, так, чтобы читались проходы между ними.
2) На старой карте небольшие здания и их части выглядят «толще». Некоторые вообще как внемасштабные условные знаки.
3) Если вы уменьшите зум на обеих картах, то увидите, что старая карта по-прежнему показывает застройку кварталов, а новая показывает их уже просто заливками разных цветов и отдельные здания. Может создаться впечатление, что изображена какая-то деревня с тремя домами и огородами.
Какая логика стоит за этими небольшими наблюдениями?
В Яндексе решили примерно так: возьмем основу масштаба 1:10000 и настроим отображение домов полигонами до того момента, пока они станут нечитаемыми, а потом просто отключим их и оставим заливку. Плюс этого подхода в том, что не надо делать отдельных слоев со зданиями для разных масштабов, достаточно отрисовать их контуры один раз по спутниковым снимкам высокого разрешения и добавить каждому атрибут с примерной высотой строения. Минус в том, что в какой-то момент относительно маленькие здания превращаются в нечитаемые пятнышки и это нельзя выправить простыми средствами, например, поставив для стиля изображения обводку полигонов некоторой внушительной толщины. Поскольку Яндекс-карты это продвинутый атлас автодорог, понять их можно.
Логика генштабовского картографа была примерно такова: нужно показать застройку на масштабе, который не позволяет её изобразить полностью масштабными обозначениями. При этом основные элементы должны остаться читаемыми. И он для этого сдвинул здания друг относительно друга, исказил их контуры. Плюс этого подхода в том, что застройка кварталов осталась читаемой на относительно мелком масштабе, минус в том, что при современном подходе пришлось бы применять для этого сложные алгоритмы и потом всё равно доводить результат вручную.
Приведенный пример может показаться надуманным: когда можно легко сменить масштаб карты, непонятно зачем заморачиваться и перегружать её разными элементами, но я лично думаю, что заморачиваться всё же стоит. Карту с хорошо обобщенными деталями читать проще, на ней выделено важное и скрыто второстепенное. Меня в своё время поразило, что на картах SwissTopo отдельностоящие дома отображаются на масштабах вплоть до 1:100000. Для них это важно, поэтому они обобщают свои карты так, создавая для всех этих домов внемасштабные знаки, да ещё и ориентированные.
По сути генерализация проводится каждый раз, когда вы определяете новый уровень смысловой иерархии. Да, это больше чем фильтрация фич, согласен, и я упоминал о модификации данных в разделе «Данные OSM». Ваш ход мыслей понятен, единственное что, не стоит сравнивать карты генштаба и яндекс/гугл — у них разные задачи. Тем более карта генштаба изначально бумажная и создаётся под один масштаб.
Ну, вы сами сказали, что для них это важно, возможно это особенности горной страны. На морских картах, что не удивительно, особое внимание уделяется маякам. Тут, как я неоднократно уже говорил,, все дело в задачах и приоритетах.
SwissTopo отдельно стоящие дома отображаются на масштабах вплоть до 1:100000. Для них это важно, поэтому они обобщают свои карты так, создавая для всех этих домов внемасштабные знаки, да ещё и ориентированные.
Ну, вы сами сказали, что для них это важно, возможно это особенности горной страны. На морских картах, что не удивительно, особое внимание уделяется маякам. Тут, как я неоднократно уже говорил,, все дело в задачах и приоритетах.
Как было сказано, разные цели. Лично мне кажется, что карта Генштаба на уровне микрорайонов перегружена, читать её очень тяжело.
Генерализация, конечно, есть и у Яндекса (те же дороги). Что касается других карт, то у 2ГИС легко можно заметить генерализацию зелёнки и водных объектов.
Не знаю, как у Яндекса, но у того же 2ГИС дома отрисовываются так, чтобы выглядеть лучше. Скажем, дом, стоящий немного неровно относительно соседних домов или дороги, будет принудительно выровнен, т.к. карта так воспринимается лучше.
Генерализация, конечно, есть и у Яндекса (те же дороги). Что касается других карт, то у 2ГИС легко можно заметить генерализацию зелёнки и водных объектов.
Не знаю, как у Яндекса, но у того же 2ГИС дома отрисовываются так, чтобы выглядеть лучше. Скажем, дом, стоящий немного неровно относительно соседних домов или дороги, будет принудительно выровнен, т.к. карта так воспринимается лучше.
Полностью с Вами согласен, у 2ГИС с генерализацией лучше дела обстоят. Насчет перегрузки это понятно, карта Генштаба всё же специального назначения, но сам принцип это не отменяет. Из более современных мне лично очень нравится подход Кристофа Хорманна, вот его блог и примеры карт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дизайн карты: как и почему