Introduction

Я андроид разработчик и...

Мне довелось допиливать небольшой проект(~500h), в котором на старте было принято решение использовать Yandex.Maps API, потому что зачем для Москвы использовать гугл карты, если есть наши. Сейчас расскажу, как все прошло.

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

С 10 июня 2019 (а технически с ноября 2019), Яндекс прекратил поддержку анонимного использования сервисов JS API & HTTP Geocoder — тарифицируемые запросы к API (поиск, геокодирование, панорамы и т.д.) перестали работать. Но адекватного биллинга и трекинга запросов Яндекс — не предоставил. Если интересно как спихнуть счёт за геокодирование на гигантов рунета (перечисленных партнёров на заглавной странице сервиса), а так же — как трекинг запросов делается «по уму» — прошу под кат.

Для большинства приложений, которые используют работу с геопозицией, картами и маршрутами, я предпочитаю Google Maps. Потому как Google Maps имеет обширный набор функций, хорошую документацию, а также отличный mapkit для реализации любых визуальных и программных идей. К большому сожалению Google Maps не является панацей для реализации всех возможных задач. Проблема заключается в том что имеются местности, города и т.д., которые не до конца изучены компанией, и ввиду этого могут отсутствовать номера домов и даже целые улицы.

В конце сентября состоялся самый большой в мире хакатон, который проходил в Казани. Данное мероприятие по количеству участников вошло в «Книгу рекордов Гиннесса».

На эти 48 часов перед нами была поставлена задача:

В рамках практически любого онлайн-продукта можно встретиться с задачей, которая требует применения того или иного сервиса, связанного с картами, геокодированием, гео-позиционированием. Лично я уже почти 10 лет работаю над онлайн-каталогом недвижимости, а также в рамках ряда других проектов есть опыт использования специфичных функций различных онлайн гео-сервисов.

В этой статье я рассмотрю гео-задачи, которые наиболее часто встают перед программистами, сделаю небольшой обзор сервисов, предлагающих решения для этих задач, и поделюсь опытом использования этих сервисов.

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

Вступление

Сегодня геолокация и геопозиционирование превратились в государство, о котором мы не мечтали около 60 лет назад, в период первых мыслей о создании Интернет-сети.

Исследуйте геолокацию и API бесплатно вместе с сервисом геолокации IPGeolocation.io

Картография превратилась в чудо — из безумно больших листов бумаги в то, что умещается на ладони.

На сегодня, карты используются не только для поиска культурного центра в Париже, но чтобы иметь возможность найти все:

• ближайший отель
• аптеку или больницу
• продуктовый магазин
• университет или школу
• место проведения концерта Pink в Сан-Франциско

Трансформация технологии на этом не остановится. Это станет лучше и точнее, как никогда.

Эволюция во времени

Давайте посмотрим, как началась эволюция геолокации. Путешествие этого явления начинается с давнейших времен.

Экскурс в прошлое

В приложении OsmAnd для телефонов на операционной системе android есть возможность добавления дополнительных слоев на карты OSM (Open Street Map). Полезным дополнением для вашей навигационной системы будет слой Strava heatmap, результат записанных во время путешествий и тренировок треков бегунов, велосипедистов, пловцов. Визуализация этих данных позволяет при навигации найти с одной стороны наиболее популярные маршруты, выделенные внушительными полосами, так и определить проходимость или проезжаемость участка на местности по тонким нитям одиночных треков.

С 2018 года Strava labs в свободном доступе предоставляет только тейлы низкого разрешения. Произошло это, по всей видимости, для “обеспечения безопасности” в ответ на публикации о массовом рассекречивании местоположения тренировок пользователей.

Для поиска популярных маршрутов низкой детализации вполне достаточно, но для того, чтобы оценить проходим ли участок местности нужны записи одиночных треков.

Это вам не двухдневный хакатон, где мало спишь и много кодишь. Это целых десять суток на создание продуманного проекта. С 20 по 30 сентября глобальная цифровая адресная система Naviaddress проводит хакатон для «программистов на длинные дистанции». В качестве финишной ленточки – призовой фонд в 400 000 рублей.

Винсент Вега на парковке. Винсент Вега в поликлинике. Винсент Вега в городе Ковров Владимирской области… Мемы с растерянным героем Джона Траволты – это не только смешно, но ещё и правда. Кто из нас не оказывался в ситуации безнадёжного поиска объекта, когда только и остается, что развести руками?

Два самых распространенных подхода к адресации – почтовый и геокоординатный – зачастую бессильны в современном мире. Из-за неверно указанного адреса 20% почтовой корреспонденции возвращаются отправителям. Неспособность доходчиво объяснить своё точное расположение снижает клиентский поток бизнесов, которым не повезло с адресом. Люди тратят жизнь и нервы, прежде чем найдут искомое.

Google решил сделать из Google Maps новый миллиардный бизнес, подняв цены в 14 раз и уменьшив лимит бесплатного использования почти в 30 раз, всё с минимальным периодом уведомления. К счастью, это немедленно стимулировало конкуренцию. Apple Maps, MapBox, TomTom — что выбрать?

Наш стартап GdziePoLek.pl позволяет пациентам находить нужные лекарства в обычных аптеках. И даже по названию («где найти лекарства») понятно, насколько важно отображение на карте. Работу сервиса легко объяснить одной картинкой, на фоне которой всегда были карты Google Maps:


Типичная страница нашего сервиса показывает наличие лекарства в аптеках

Привет, Хабр.

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

В 2013 году два айтишника и музыкант собрались и подумали: давайте разобьем всю Землю на квадраты, а потом пометим каждый квадрат тремя словами. И разбили. И пометили.

Получился бесплатный сервис what3words.com, который замахнулся на революцию в геокодировании. Ребята уверяют, что почтовые адреса и координаты не годятся для повседневной жизни. Пора от них отказываться там, где возможно.
Казалось бы, таких революционеров пруд пруди, но у what3words.com есть важное отличие: сервис взлетел. Им пользуются автопроизводители вроде Land Rover, правительства африканских стран и даже ООН.

Про использование Google MAPs API написано много статей, но основная часть из них устарела на столько, что глазам становится просто больно. Здесь хочу рассказать про замечательную библиотеку для работы со всеми MAPs API в частности Directions API, а так же о том как все это встроить в приложение.

Введение

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

К сожалению (или к счастью?), готовых решений я не нашёл. Google Карты позволяют накладывать маркеры и фигуры на карты, но эти способы представляют слишком мало информации. С Яндекс картами оказалось не лучше. Но Карты Гугл имеют механизм пользовательских наложений с HTML-содержанием. И для инкапсуляции этой работы с картами и наложениями я создал JavaScript библиотеку GMapsTable. Возможно, кому-нибудь она окажется интересной или полезной. Рабочий пример.

→ Демо: ссылка
→ Исходники: ссылка

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

В этой статье мы рассмотрим:

1. Внедрение Google Maps на сайт

• Добавление через вставку iframe в разметку
• Добавление через API

2. Кастомизация маркера

• Инициализация маркера
• Анимация маркера
• Изображение маркера

3. Кастомизация информационного окна

• Добавление информационного окна
• Открытие информационного окна
• Кастомизация элементов информационного окна
• Параллакс-эффект для элементов в информационном окне

4. Кастомизация карты

• Изменение цвета объектов карты
• Кастомизация элементов управления
• Маска для карты

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

В прошлой своей статье я рассказал про построение простых графиков с помощью библиотеки d3, с ее же помощью планировал отрисовывать и карты, но поэкспериментировав с d3, Raphael и paper.js понял что велосипедостроения избежать не удастся и переделал отрисовку на HTML Canvas, о чем и хочу рассказать в данной статье.

Чаще всего я хожу в кино спонтанно. Внезапно возникает желание оказаться в прохладном тёмном зале, и встаёт задача выбора — куда идти и что смотреть. Одно из условий этой задачи — чтобы выйти из дома в течение ближайших пятнадцати минут, в идеале — прямо сейчас.
Мне надоело всякий раз перебирать по многу страниц на сайте Афиши, и я решил сделать сервис, максимально быстро решающий мою проблему.

В подмосковном Подольске, в микрорайоне Силикатная-2, есть один лайфхак — когда на дворе уже 9 вечера, и пиво в магазинах уже не продают — достаточно просто перейти дорогу, чтобы его купить. Через дорогу Москва — в ней желаемое до 11 найти можно.

Остается решить только одну проблему — темной ночью, в незнакомом районе, среди однотипных многоэтажек… узнать на какой стороне ты находишься.

Исторически на этот вопрос отвечает «обратный геокодер»(reverse geocoder). Он важная часть практически всех картографических АПИ — Google, Яндекс, и даже OSM. Но в большинстве случаев его ответ предназначается человеку, и содержит исключительно текстовое описание локации.

Это-не-технологично! И уж точно непрактично. Esosedi, кушали этот кактус пару лет, а потом просто сделали свой обратный геокодер. Главное как и зачем.

Совсем недавно на хабре искали Смерть Кащееву (nested set и вложеность административных рубрик), ходили по районам(отображение данных регионов на карте), и (не)попадали на счетчик Яндекса (прямой геокодер). А теперь разберем, что такое обратный геокодер, и зачем он нужен. А потом разберем механики его работы.

Как я делал свою первую карту на Leaflet.js.

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

Итак задание было следующее: есть черно-белый планшет (маленький кусок карты города) размером 5913x7863 пикселей в формате .bmp + .shp слои.

(изначально карты были отрисованы в формате .dwg (формат автокада), но это закрытый формат и с ним ничего не сделаешь, поэтому ребятам пришлось сохранить каждый слой отдельно в .shp + атрибутивные данные в .dbf)

Из этого всего нужно сделать онлайн карту, основной функционал которой — это вывод атрибутов при нажатии на слой и включение/отключение этих слоёв.

Выбор пал на leaflet.js, так как это оболочка с открытым кодом, на ней сделаны OSM и мой любимый 2GIS. К тому же он хорошо работает на мобильных устройствах.

Для организации работы веб-карт по технологии Slippy Map требуется организовать тайловое хранилище, в котором могут предварительно рендериться (генерироваться) тайлы в заранее заданном контексте карты, либо использоваться набор сервисов для генерации тайлов по запросу, либо некий симбиоз из первых двух подходов.
Первый подход имеет недостаток — требуется слишком большое хранилище для тайлов. Так, по данным OpenstreetMap по состоянию на март 2011 года требовалось 54ТБ места для хранения тайлов. По моим подсчетам для актуальных данных на июнь 2015 года эта цифра уже составляет около 100ТБ (это только оценка, на реальный эксперимент я не решился) для хранения тайлов масштабов 0...17. Такой «прирост» оценок вызван тем, что за прошедшее время данные OpenStreetMap существенно пополнились, детализировались районы, которые в марте 2011 года были пустыми. Нельзя также списывать со счетов неоптимальность сжатия (в моем случае по сравнению с OpenStreetMap) формата PNG (у меня средний размер тайла составляет 4.63КБ против 633 байт OpenStreetMap'а в марте 2011 года), сложность стиля рисования карты mapnik'ом и прочие мои нюансы. В любом случае требуется ОЧЕНЬ много места для тайлового хранилища, что может себе позволить далеко не каждый сервер. Ситуация усугубляется еще и тем, что для блочных файловых систем маленькие по размеру тайлы расходуют целый блок (тайл размером 103 байта может занимать целый блок, например, 4КБ), что приводит к неэффективному расходованию физического пространства жесткого диска. Для большого количества тайлов (для крупных масштабов карт) в рамках одной директории может еще наблюдаться проблема невозможности хранения требуемого количества файлов либо директорий больше, чем позволяет файловая система. Но при всем при этом данный поход обеспечивает комфортное время выполнения запроса на отдачу тайла.
Второй подход хоть и не требователен к емкости тайлового сервера, но требует организовать и поддерживать несколько сервисов (PostgreSQL, Postgis, HStore, mapnik, renderd, mod_tile, apache), которые бы надежно генерировали и отдавали тайл запрашиваему клиентскому сервису. Также требуется периодически подчищать кэш тайлов. Иными словами платой за небольшую емкость жесткого диска тайлового сервера является сложность архитектуры и значительное время выполнения запроса на отдачу каждого конкретного тайла (по моим подсчетам до 500мс только для 1 клиента, для высоконагруженного сервиса это время может вырасти до неприемлемых величин).