Клуб API Карт

Отображение б`ольшего числа точек и вершин ломаной в Static API

Пост в архиве.

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

В последнее время при отрисовки трека или маршрута все чаще и чаще нарываюсь на ограничение длины HTTP GET запроса. Разумеется использование кодирование вершин ломаной и понижение степени точности передаваемых долей градуса (передавать 3-4 знака после запятой вместо 6) частично решает данную проблему, но не устраняет ее.

Вопросы к Яндексу:

1. Неужели так жизненно важно в HTTP GET запросе в Static API передавать столь длинный API KEY ??

Ведь вы всеравно не сможете его сверить с зарегистрированным на данного пользователя, Static API "съедает" любой ключ из действующих, выданный для любого сайта. Зато он нехило ограничивает длину строки GET запроса оставшуюся на полезные данные. В целях статистики и контроля на ваш сервер всеравно же передается Referer и IP клиента, разве этого не достаточно?

Посмотрите как к примеру реализованы графики Google Charts - никаких API KEY нет и впомине, только полезные данные.

2. Для передачи больших объемов данных быть может стоит применить метод HTTP POST чтобы обойти ограничение на длину запроса ? Опять же по аналогии Google Charts.

Use GET or POST to get your image. GET, is either when you type the URL directly into your browser, or use it in an <img> tag. However, URLs are limited to 2K in length, so if you have more data than that, or have a taste for blood, you should consider using POST instead, as described here.
Заранее спасибо.

 

9 комментариев
Там дело не только в длине GET запроса.
Еще есть "не более 5ти линий и не более 100 вершин( сумарно )"

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

До 100 вершин как до Китая... Ломаная всего одна + 2 метки...все.


Если не кодировать вершины в base64, то запись одной вершины ломаной без стилей занимает в среднем 20 байт (",37.655131,55.741814")


И еще надо учитывать, что на мобильных устройствах ограничение на длину запроса меньше чем 2K.


PS Javascript API(converter) на мобильных устройствах не вариант....ну кроме особо новых разумеется.

Длина API-ключа особой погоды не делает.
Ключи когда-нибудь всё же отменят, но когда пока не известно.


А чем вам поможет POST для решения вашей задачи?
И какие из приемов получения картинок из G.Charts 
(если заменить в них POST на GET)
не работают со статик АПИ?

Cовсем отменять ключи нет необходимости, в java версии для PC, планшетов и т.п. пусть живут, но вот когда надо обеспечить совместимость с более древними девайсами, то только HTTP GET/POST и в нем уже длина ключа в 88+5 знаков могут оказаться лишними, а с обрезанным URL карта не загрузится.


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

А что мешает отправить GET c вебсервера?
Там вроде бы нет ограничения 2к на длину запроса

Если GET запрос слать с вебсервера, то по сути мы получаем предварительное кеширование графики с Яндекс.Карт на нашем вебсервере, что вызывает ряд вопросов:


1.Примерно тоже что и скопировать к себе локально все тайлы и вообще к Яндексу не обращаться.


2.Страница загружается существенно быстрее с РАЗНЫХ серверов.


3.Ширина канала Интернет на отдачу полагаю у Яндекса больше.


4.А оно надо писать систему кеширования на вебсервере сервиса картинок скачиваемых с Яндекса ??

Не понял про кеширование.
Вернее причем тут GET?
Кешировать можно и полученные POST-ом картинки.

Хороший вариант для отображения больших ломанных с помощью статикАПИ - использовать симплификацию.
То есть не отображать все вершины на всех масштабах.
А расчитать какие вершины на каких масштабах должны быть видны.
Именно так я и поступаю, но чтобы картинка соотвествовала реальности приходится увеличивать число отображаемых вершин и соотсветственно растет длина запроса.
...Google Charts с Яндекс Картами скрещивать никто и не собирался, я привел их как пример реализации передачи большого числа параметров.