Comments 19
Мне кажется или с википедией что-то не так. Разве не стоит делать вставку фрейма с open street map, в базе хранить только нужные точки и области которые стоит подсветить. И выполнять все подсветки и отображения в браузере на клиенте?
С Panoramio тоже когда-то делали хотлинки на других сайтах.
А теперь фото с этого сайта остались в основном в Википедии.
Всё правильно Википедия делает.
А теперь фото с этого сайта остались в основном в Википедии.
Всё правильно Википедия делает.
Вы имеете в виду — карту в iframe вместо рендерёных карт? Но во-первых, карты в iframe есть и так — открываются по нажатию на географические координаты объекта. Во-вторых, рендерёная карта часто удобнее, показывает именно этот объект, или объект более высокого уровня. В общем, одно не заменяет другого.
С Википедией много всего не так, но это не тот случай. Просто в Википедии есть два уровня решения проблем: на уровне движка и на уровне контента. Описываемое в статье решение на уровне контента, и хотя генерация кучи карт может показаться не самым простым делом, это всего-лишь времязатраты, сам алгоритм прост и понятен: картинки и CSS.
Как только же мы переходим к решению на уровне движка всё становится намного сложнее.
1. Нам нужна карта, которую мы будем вставлять во фрейм. OSM напрямую с официального сайта вставлять нельзя, потому что это а) передача данных пользователей сторонней компании, б) она не предназначена для этого, и не выдержит такую нагрузку. Соответственно, нужно поднимать свой стек для генерации карт на основе OSM.
2. Так как мы делаем глобальное решение, то нам сразу же нужен картостиль, который будет адекватно смотреться на всех масштабах, а не только при показе карт.
3. Нужны механизмы для добавления объектов на эти карты при помощи вики-кода. И опять же, результат должен адекватно выглядеть и для маленьких карт в карточках, и в больших на весь экран.
4. Нам нужно взять откуда-то контур страны, который мы будем отображать на карте (логично, что тоже из OSM).
5. Не забываем, что у нас пятый по посещаемости сайт, поэтому вспоминаем про кеширование и стараемся не подгружать карты без необходимости.
И да, на текущий момент это более-менее сделано, и два года назад (для сравнения — Википедия к тому моменту существовала уже 16 лет) было активно внедрено в части разделов. Сейчас в большинстве статей карта открывается вверху по ссылке на координаты, но есть и статьи (пример), в которых это используется в карточке. Но в примере как раз хорошо видно, что карта 1) достаточно шумная, 2) не достаточно информативная в одном масштабе.
Так что, даже при том, что я как раз очень активно агитирую за использование динамических карт там, где это разумно, нужно признать, что старый механизм вставки изображений не так плох, как может показаться на первый взгляд.
Как только же мы переходим к решению на уровне движка всё становится намного сложнее.
1. Нам нужна карта, которую мы будем вставлять во фрейм. OSM напрямую с официального сайта вставлять нельзя, потому что это а) передача данных пользователей сторонней компании, б) она не предназначена для этого, и не выдержит такую нагрузку. Соответственно, нужно поднимать свой стек для генерации карт на основе OSM.
2. Так как мы делаем глобальное решение, то нам сразу же нужен картостиль, который будет адекватно смотреться на всех масштабах, а не только при показе карт.
3. Нужны механизмы для добавления объектов на эти карты при помощи вики-кода. И опять же, результат должен адекватно выглядеть и для маленьких карт в карточках, и в больших на весь экран.
4. Нам нужно взять откуда-то контур страны, который мы будем отображать на карте (логично, что тоже из OSM).
5. Не забываем, что у нас пятый по посещаемости сайт, поэтому вспоминаем про кеширование и стараемся не подгружать карты без необходимости.
И да, на текущий момент это более-менее сделано, и два года назад (для сравнения — Википедия к тому моменту существовала уже 16 лет) было активно внедрено в части разделов. Сейчас в большинстве статей карта открывается вверху по ссылке на координаты, но есть и статьи (пример), в которых это используется в карточке. Но в примере как раз хорошо видно, что карта 1) достаточно шумная, 2) не достаточно информативная в одном масштабе.
Так что, даже при том, что я как раз очень активно агитирую за использование динамических карт там, где это разумно, нужно признать, что старый механизм вставки изображений не так плох, как может показаться на первый взгляд.
Приветствую, коллега!
Спасибо за статью, посмотрю инструменты, которыми вы пользуетесь, может пригодятся…
Я рисовал карты в проекте графическая мастерская, но там всё зависит от запроса.
Могут быть схемы сражений, путей, трубопроводов и т.д.
Спасибо за статью, посмотрю инструменты, которыми вы пользуетесь, может пригодятся…
Я рисовал карты в проекте графическая мастерская, но там всё зависит от запроса.
Могут быть схемы сражений, путей, трубопроводов и т.д.
.svg){kind=link}
.svg){kind=link}
Тематические карты я тоже рисовал. Обычно начинал с контурной карты из GMT -> в формат .eps -> конвертация в .pdf -> импорт в Inkscape, либо экспорт в SVG из Maperitive, и дальше уже нанесение тематической части карты.
Я брал выгрузку из QGIS — он умеет выгружать svg. Потом добавлял тематическую часть в Inkscape.
Ещё вспомнил как делал карту маршрутов из аэропорта — в этом случае готовил исходник в mapbox и наносил сверху аэропорты и маршруты, но в тот раз был нужен исходник в красивых цветах, который в википедии без надобности…
Ещё вспомнил как делал карту маршрутов из аэропорта — в этом случае готовил исходник в mapbox и наносил сверху аэропорты и маршруты, но в тот раз был нужен исходник в красивых цветах, который в википедии без надобности…
А в какой программе можно сделать раскройку карты мира для глобуса?
За GMT отдельное спасибо. Я как-то умудрился не заметить этот инструментище.
Может быть имеет смысл ещё и с графикой работать в CLI? Вообще бы здорово получилось — всё описание карты в виде скрипта.
Может быть имеет смысл ещё и с графикой работать в CLI? Вообще бы здорово получилось — всё описание карты в виде скрипта.
Скриптом я описываю только то что делается через GMT, но тематические карты можно практически полностью делать в нём. Так например можно сделать текстовый файл с координатами маркеров и расставить их тоже через GMT. Но у этого инструмента есть свои ограничения, например, проблемы с кириллицей в шрифтах.
Погодите, то есть _все_ карты в Википедии сделаны руками, по-одной, и руками же залиты в страницы??
Если карта это рисунок, на него обычно можно нажать и увидеть кто его сделал, когда и всю историю изменений :)
Википедия также использует и OSM, со своим стилем, своим рендером и своим кешем тайлов.
Что касается «руками залиты в страницы» — это не всегда так, например, для административных единиц поддерживается информация об иерархии, шаблоны автоматически подтягивают информацию о том какие карты использовать. Получается что иногда руками, иногда автоматом.
Википедия также использует и OSM, со своим стилем, своим рендером и своим кешем тайлов.
Что касается «руками залиты в страницы» — это не всегда так, например, для административных единиц поддерживается информация об иерархии, шаблоны автоматически подтягивают информацию о том какие карты использовать. Получается что иногда руками, иногда автоматом.
Мы с автором разделяем эстетическое удовольствие от изготовления карт.
Я тоже программист, и одновременно, являюсь профессиональным картографом. Стараюсь совмещать обе специальности. И, когда получается (последнее время всё реже, т.к. карта для многих начинает становиться простой иллюстрацией, а не средством анализа), испытываю удовольствие от работы.
Про карты в Википедии всё сказано верно, стоит добавить, что Гугль-проекция прекрасно работает на населённые области планет, но не на приполярные, там будут серьёзные искажения, растяжение по горизонтали. Сами полюса в ней отображать не получится принципиально. Для этого лучше использовать стереографические проекции.
Не знаю, будут ли работать с ней указанные в статье инструменты. Ведь там потребуется переводить градусы планеты в ортогональные единицы карты, чтобы отрисовать их там. Непреодолимые проблемы могут возникнуть с наложением растровых объектов на друга в этих регионах. Впрочем, всё это решаемо, хотя бы в профессиональных ГИС-системах.
Единственное, на что всегда обращаю внимание на современных картах, построенных с применением компьютерных программ, так это на частое отсутствие масштабной линейки.
Если нет на карте средства измерения масштаба, любому картографу сразу ясно — делал обычный любитель картинок, а не картограф. Без масштаба точная карта превращается в обычное изображение, обладающее определёнными эстетическими свойствами, но не свойствами измеримости и сравнения!
Автору — искренняя благодарность за материал!
Я тоже программист, и одновременно, являюсь профессиональным картографом. Стараюсь совмещать обе специальности. И, когда получается (последнее время всё реже, т.к. карта для многих начинает становиться простой иллюстрацией, а не средством анализа), испытываю удовольствие от работы.
Про карты в Википедии всё сказано верно, стоит добавить, что Гугль-проекция прекрасно работает на населённые области планет, но не на приполярные, там будут серьёзные искажения, растяжение по горизонтали. Сами полюса в ней отображать не получится принципиально. Для этого лучше использовать стереографические проекции.
Не знаю, будут ли работать с ней указанные в статье инструменты. Ведь там потребуется переводить градусы планеты в ортогональные единицы карты, чтобы отрисовать их там. Непреодолимые проблемы могут возникнуть с наложением растровых объектов на друга в этих регионах. Впрочем, всё это решаемо, хотя бы в профессиональных ГИС-системах.
Единственное, на что всегда обращаю внимание на современных картах, построенных с применением компьютерных программ, так это на частое отсутствие масштабной линейки.
Если нет на карте средства измерения масштаба, любому картографу сразу ясно — делал обычный любитель картинок, а не картограф. Без масштаба точная карта превращается в обычное изображение, обладающее определёнными эстетическими свойствами, но не свойствами измеримости и сравнения!
Автору — искренняя благодарность за материал!
Масштабная линейка нужна была во времена, когда карта висела на стене. Сейчас же давно уже всё в цифре и программа сама способна посчитать расстояние, ты только укажи откуда и до куда.
Эти аргументы слышал. Мне лично хватает линейки, чтобы оценить расстояние, или площадь, или соотношения между ними. И я это сделаю на порядок быстрее на глаз, чем вызов имеющейся (если!) линейки и время на попытки понять, как она работает. Такие интерфейсы, невзирая на простоту, часто пишутся людьми, далёкими от понимания нужд среднего пользователя.
На растровой карте в виде обычной картинки нет и быть не может программного курсора, который обладает таким возможностями. А была бы линейка — и всё в порядке
Короче, Вам не понятно, зачем придумали и используют масштабную линейку. Так и скажите. Но не выдавайте себя за идеологического её противника)))
А на всех уважающих себя крупных картографических серверах таковая линейка присутствует. И никому не мешает своей назойливостью. Если я ошибаюсь, прошу указать обратное.
На растровой карте в виде обычной картинки нет и быть не может программного курсора, который обладает таким возможностями. А была бы линейка — и всё в порядке
Короче, Вам не понятно, зачем придумали и используют масштабную линейку. Так и скажите. Но не выдавайте себя за идеологического её противника)))
А на всех уважающих себя крупных картографических серверах таковая линейка присутствует. И никому не мешает своей назойливостью. Если я ошибаюсь, прошу указать обратное.
Ну какая линейка на меркаторе, она же там бесполезна, я уж молчу про площади. Не знаю, кто ей вообще там будет пользоваться. Хотя вот вижу, есть любители старой школы.
Линейка на любой проекции, в т.ч. и Меркатора — полезна. Посмотрите ЛЮБЫЕ атласы бумажные, где используются далеко не UTM или ГК — везде есть линейка.
Почему линейка есть и она горизонтальна? Потому что любая профессиональная проекция имеет в виду минимизацию искажений формы, длины или углов. Умозрительные проекции, которыми потчуют обывателей современные картографы, а на деле менеджеры, не упоминаю. Это не картография, а — реклама с использованием методов картографии.
Линейка на Меркаторе есть средство визуального контроля расстояний и площадей сторон. Пример использования в достаточно профессиональных компьютерных полукартографических системах:
Яндекс:
Гугль:
Действительно, масштаб на поверхности планеты в проекции Меркатора изменяется. Как и площади. Но на конкретной широте масштаб постоянен. Это легко увидеть, если двигать окно карты вверх или вниз не меняя увеличения. Размер линейки будет при этом меняться.
Полагаю, в данном случае масштабная линейка соответствует центру окна электронной карты. Если замерить длину по горизонтали вверху и внизу, она будет разной. Яндекс показывает длину в мелком масштабе в виде части дуги меридиана, что визуально верно, демонстрируя кривизну поверхности земного шара на плоскость карты.
Т.к. теперь размывается разница между картой и картинкой, связанная с глобализацией мозгов, то отсутствие или наличие масштабной линейки есть дело воли автора.
Я лишь указываю на то, что линейка — это инструмент визуального контроля при работе с картой взглядом, без наличия специальных программных инструментов.
Представьте себе просто картинку с картой. Если на ней нет линейки, обыватель может только гадать, сколько километров между интересующими его точками. Вот и вся разница.
На мой взгляд, отбрасывание масштабной линейки, как обязательного элемента любой карты есть невежество и деградация культуры в этой области.
Не отсюда ли растут ноги у набирающей популярность идеи о плоской Земле, несомой слонами стоящих на черепахе, плавающей в мировом океане))
Тут точно нет места масштабной линейке)))
Почему линейка есть и она горизонтальна? Потому что любая профессиональная проекция имеет в виду минимизацию искажений формы, длины или углов. Умозрительные проекции, которыми потчуют обывателей современные картографы, а на деле менеджеры, не упоминаю. Это не картография, а — реклама с использованием методов картографии.
Линейка на Меркаторе есть средство визуального контроля расстояний и площадей сторон. Пример использования в достаточно профессиональных компьютерных полукартографических системах:
Яндекс:
Гугль:
Действительно, масштаб на поверхности планеты в проекции Меркатора изменяется. Как и площади. Но на конкретной широте масштаб постоянен. Это легко увидеть, если двигать окно карты вверх или вниз не меняя увеличения. Размер линейки будет при этом меняться.
Полагаю, в данном случае масштабная линейка соответствует центру окна электронной карты. Если замерить длину по горизонтали вверху и внизу, она будет разной. Яндекс показывает длину в мелком масштабе в виде части дуги меридиана, что визуально верно, демонстрируя кривизну поверхности земного шара на плоскость карты.
Т.к. теперь размывается разница между картой и картинкой, связанная с глобализацией мозгов, то отсутствие или наличие масштабной линейки есть дело воли автора.
Я лишь указываю на то, что линейка — это инструмент визуального контроля при работе с картой взглядом, без наличия специальных программных инструментов.
Представьте себе просто картинку с картой. Если на ней нет линейки, обыватель может только гадать, сколько километров между интересующими его точками. Вот и вся разница.
На мой взгляд, отбрасывание масштабной линейки, как обязательного элемента любой карты есть невежество и деградация культуры в этой области.
Не отсюда ли растут ноги у набирающей популярность идеи о плоской Земле, несомой слонами стоящих на черепахе, плавающей в мировом океане))
Тут точно нет места масштабной линейке)))
Sign up to leave a comment.
Опыт создания позиционных карт для Википедии