Как получить api яндекс карт

Бесплатно ли использование API яндекс карт

Я подключил api Яндекс карт на сайт для отображения местоположения компании, карта только помогает найти компанию. Прочитал про трафик, про то, что ПО должно быть открытым и т.д. но все равно есть какое-то недоверие и страх, что придет счëт через пару лет на миллион. При получении ключа указывается телефон, остальное можно написать фейковое. Как Яндекс отслеживает нарушения, можно ли в них случайно попасть? Как разработчики поступают при надобности подключить карту на сайт? Цепляют на свой аккаунт или просят заказчика предоставить ключ?

веб-программирование
api
yandex-maps-api
яндекс-карта-api

Отслеживать
задан 8 окт 2021 в 22:22
68 13 13 бронзовых знаков

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

8 окт 2021 в 22:57
у яндекс-карт ограничения еще человеческие, у гугла всё еще хуже
8 окт 2021 в 23:11

Если будет превышение по показам — увидите карту с наложенным серым фоном и надписью про превышение. страх, что придет счëт через пару лет на миллион — Договор подписывали? Тогда идут лесом

8 окт 2021 в 23:40

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

9 окт 2021 в 11:19

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

При соблюдении условий можно получить ключ и использовать API Яндекс.Карт бесплатно неограниченное время.

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

Случайного «счёта на миллион» постфактум быть не может. Сервис оплачивается по типу prepaid — оплачиваете год использования — получаете оплаченный коммерческий ключ.

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

Яндекс.Карты API, я устал. Я ухожу

О последней и других каплях в чаше решения о прекращении использования Яндекс.Карты API.

Что случилось?

С 1 ноября Яндекс.Карты уменьшили лимиты на бесплатное использование HTTP API Геокодера с 25 000 до 1 000 запросов в сутки. Но не всех об этом уведомили.

Вдобавок, хоть новые лимиты и касаются только HTTP API Геокодера, он остался спаренным с сервисом встраивания карт. Теперь случайное превышение по использованию геокодера отрубает вам на сутки и карты, несмотря на прежний лимит для встраивания в 25 000.

И вот по поводу компенсации начинается переписка с поддержкой.

Сначала она не видит, что мы вообще используем API. Но прозревает после нашего скриншота.

Потом она перенаправляет на оформление коммерческого использования .

Дальше она не видит, как мы используем геокодер, чем объясняет отсутствие уведомления о новых лимитах. Хотя у нас обычный характер использования геокодера — это до 100 ежедневно со скачками до 1 000, и несколько раз в год — до 25 000.

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

Переписка заняла 3-и дня, из которых первый день карты не работали, т.к. никто ничего не стал компенсировать даже на время разбирательства.

Но ноги этого начали расти чуть больше года назад. «Почему появилась эта статья» что-то напоминает — да? 🙂

Версионирование Шрёдингера и др.

До лимитов основной проблемой было версионирование.

Вот вы если указываете номер версии, скажем, 1.65, какую рассчитываете получить в итоге?
Я думал, что — 1.65. Но нет, в Яндекса.Картах свято уверены, что это может и 1.72, и 1.75, и т.д. Хорошо хоть только возрастает. Но это не точно.

На вопрос, где они узнали, что это хорошая практика, ответили ссылкой на свою же документацию о версионировании. Ловко — да? 🙂

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

По началу я рационализировал такой подход задумкой быстрой обратной связи и внесением правок. Поэтому сообщал о всем, что находил. Но опять не угадал. Как я Вас понимаю, ReDev1L.

Поддержка могла реагировать годами. И даже поправленные баги могут возвращаться.

Т.е. вы должны сами отслеживать и знать все изменения, даже те, которые внутри кода, и вносить правки в соответствии с планом работ Яндекса.

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

Не буду уже тратить время на документацию и архитектуру кода, которая часто напоминает итальянское блюдо.

Это просто бизнес, ничего личного.

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

Лишнее тому подтверждение — недавний срыв большой сделки с Яндексом. Все-таки кто-то считается с настроениями пользователей.

Свои проекты мы строим по-другому.

До этого API Яндекс.Карт использовался больше 7 лет из-за их покрытия и удобных лимитов. Но теперь, учитывая характер использования, новые лимиты, расценки и качество поддержки, в этом нет смысла. Значительно дешевле, удобней и гибче использовать собственные решения на основе других открытых и бесплатных продуктов.

Тем более, что и так приходилось писать свои обертки для решения проблем сервисов Яндекс.Карт. Например, тот же геокодер натренирован на статистике пользовательского ввода. Из-за чего нередко бывает, что точный адрес не гео-кодируется, а вот, например, без вида улицы — находится.

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

Еще одно интересное следствие всей этой истории — это то, что я перестал воспринимать сотрудников Яндекс как серьезных специалистов. И приходится делить, минимум на 10-ть, все что они говорят, даже если и появляется желание их послушать.

Из, возможно, забавного.

Как-то у Яндекса в Недвижимости появилась функциональность, которая очень напоминала то, что являлось уникальным предложением нашего проекта.

После чего внутренний параноик задумался о случайности совпадений. Т.к. мы за 5 лет до того начали решать проблему поиска жилья с учетом качества жизни. В частности, с учетом экологии, и используя интерактивные карты. А это до сих пор очень нишевый сервис.

P.S.
Есть что-то похожее и про Google. Думаю как-нибудь тоже написать, если допечет.

Кто знает, есть ли плагин для leaflet, чтобы можно было его использовать с backend’ом под API Яндекс.Карт? Если что — я уже начал писать похожее решение.

яндекс.карты
как делать не надо
продукт
маркетинг
пользовательский опыт
api

Веб-разработка
API
Яндекс API
Геоинформационные сервисы

API Яндекс.Карты – геокодирование и маршрутизация на JavaScript

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

Но предположим, что перед пользователем стоит задача обработать большой список адресов/координат, а именно, посчитать расстояния между точками по автомобильным дорогам и определить координаты внушительного списка объектов. Тогда-то он и столкнется с отсутствием возможности пакетной обработки в пользовательском интерфейсе сервиса. Однако, Яндекс об этом позаботился, предоставив в условно-бесплатное пользование JavaScript API.

Разработчики на JavaScript API получают техническую поддержку, подробную документацию, инструментарий для тестирования кода в “песочнице” на сайте проекта https://yandex.ru/dev/maps/jsapi/

Итак, я попробую воспользоваться этим инструментом для решения задачи геокодирования и построения маршрутов. Мне понадобится учетная запись Яндекс и API ключ для сервиса “JavaScript API и HTTP Геокодер”, который можно создать в Кабинете разработчика https://developer.tech.yandex.ru. Не буду подробно останавливаться на этом моменте, в сети достаточно информации, чтобы самостоятельно разобраться.

JavaScript API работает только в браузере, поэтому для выполнения кода нужно разработать web-страничку. В моем случае я могу обойтись статичным html-файлом, т.е. читать исходные данные и записывать результат буду в html-элементы, т.е. для упрощения обойдусь без использования серверной части. Итак, запускаю текстовый редактор и создаю заготовку будущей web-страницы.

JavaScript API Yndex.Map

Тут будет два многострочных текстовых поля, первое для ввода исходных данных (data) и второе — для записи результата (target), и две кнопки для запуска процесса обработки и очистки поля с результатом.

Обратите внимание, в заголовке страницы в элементе script подключается так необходимый мне API от Яндекса, а в параметрах url атрибута src необходимо указать тот самый секретный api-ключ, полученный в кабинете разработчика.

После загрузки страницы, в глобальном контексте выполнения JavaScript станет доступен объект ymaps, через который я получаю доступ к API, в том числе и к необходимым мне функциям геокодирования и маршрутизации. Напишу две функции “router” и “geocoder”, которые, как не сложно догадаться, реализуют построение маршрута и выполняют геокодирование. Конечно же JavaScript API реализуют значительно больше картографических сервисов и даже получаемые тут данные о маршруте и местоположении являются далеко не полными. Полное описание используемых методов доступно по ссылке, указанной в начале этого материала. Но вернемся к поставленной задаче и разберемся сначала с функцией “router”:

function router(from, to)< return ymaps.route([from,to], ) .then(r => > ) .catch(e => >); >

В качестве аргументов она принимает пункты отправления и назначения, которыми могут быть как строками с адресом, так и массивами [широта, долгота]. Эти аргументы передаются в метод route объекта ymaps вместе с параметрами построения маршрута, в моем случае routingMode: “auto” – это указание строить именно автомобильный маршрут. Метод возвращает promise-объект, содержащий в том числе протяженность маршрута в метрах, который затем и возвращает функция.

Очередь функции “geocoder”:

function geocoder(place)< return ymaps.geocode(place, ).then( r => < let geo = r.geoObjects.toArray()[0]; let data = geo.properties.get('metaDataProperty').GeocoderMetaData; let point = geo.geometry.getCoordinates() let result = ; return result;> ).catch(e => >) >

Функция принимает адрес строкой или массив [широта, долгота]. Этот параметр передается в метод geocode объекта ymaps вместе с параметрами геокодирования, в моем случае results: 1 – указание вернуть только один, наиболее точный, результат. Функция вернет promise-объект, содержащий координаты, тип, наименование, точность геокодирования.

Ну что ж, уже можно пользоваться. Например, если вызвать следующий код

, то в консоль браузера будут записаны результат геокодирования объекта “Москва” и информация о протяженности автомобильного маршрута “Москва -> Санкт-Петербург”

Остается только реализовать построчную обработку содержимого элемента “data” и запись результата в элемент “target”. Ниже приводится итоговое содержимое html-файла, в котором это реализуется функцией “start_process”.

Страница в браузере с результатами обработки выглядит примерно следующим образом:

Верхнее текстовое поле для вставки исходных данных, в нижнее пишется полученный результат. Если в строке исходных данных встречается разделитель (разделителем между пунктом отправления и прибытия является “;”), то осуществляется расчет маршрута, в противном случае выполняется геокодирование сроки (в примере на картинке выше “Лондон”). Также регулярным выражением определяется, являются ли исходные данные географическими координатами (широта и долгота разделены запятой) или строкой адреса, при этом адреса и координаты можно комбинировать при построении маршрута.

Внимательному читателю наверняка сразу бросилась в глаза вот эта конструкция в листинге кода:

await new Promise(r => setTimeout(r, 50));

Тут я делаю короткую (50 мсек) паузу перед обработкой следующей строки, т.е. искусственно устанавливаю предел максимальной скорости обработки в 20 строк в секунду. Спросите, зачем? И тут настало время упомянуть о технических лимитах бесплатного использования JavaScript API от Яндекса. А их два, но они довольно «вкусные»:

— Суточное ограничение – до 25000 запросов к API (каждый вызов метода geocode или route считается за 1). Информация о расходовании суточного лимита доступна в Кабинете разработчика.

— Кол-во запросов в секунду – не более 50

Т.е. пауза между вызовами API нужна, чтобы не превысить «скоростной лимит», установленный Яндексом.

На этом, пожалуй, всё, “за кадром” осталась css-таблица стилей, а также разработка backend на Node.js, но это — уже совсем другая история.