Comments 41
Здорово!
Вот только о своих планах отломать все обычно предупреждают заранее и дают тестовый билд «на поправить к будущему релизу» (В идеале).
Простите, промелькнул глазами строчку, что предупреждали.
Тут недавно статья была о том, что IE — сплошный костыль.

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

Эх.
Я напоминаю, что речь идет о бета-версии. В обычных версиях мы себе такого хулиганства не позволяем)
Спасибо за напоминание!
Я правильно понял, как бета станет релизом — останется возможность сидеть на старой версии какой-либо? (судя по комментарию ниже).
Когда бета станет релизом, мы об этом напишем и напишем срок, когда закроем версии беты. То есть если вы используете бету, вам нужно будет перевести свой код на продакшен-вариант в течение какого-то времени после «разбечивания». Вечно хранить у себя версии беты мы не планируем.
Во-первых, мы предупреждали.
Во-вторых изменения не такие уж масштабные. Обновление беты было в четверг, пока пожаловались только единицы.
Когда мы разбетимся, естественно, никаких таких сюрпризов не будет.
Ну и если вы сидите на бете и не хотите под нас подстраиваться — всегда можно подключить конкретную версию беты, например 2.1.3 вместо 2.1-dev.
Выглядит весьма неплохо, но хотелось бы, чтобы алгоритм работы кластеризатора был все же «по-умнее». Как-то не вяжется у меня Яндекс и «разбили на квадратики и посчитали сколько меток попадет в квадратик».
Т.е. лучше бы написали «дискретно полигонный анализ карты с апроксимированной кластеризацией объектов»? Так сказать понятнее, что к делу подходили серьезно?
Отнюдь. Посмотрите на пример того, как «Стало»: есть перекрытия, как кластеров между собой, так и кластеров с метками. Хотелось бы, чтобы такие случаи разруливались и, в случае необходимости, объединялись. Тогда часть кластера, построенная по клеткам, но не попавшая в объединение, сформирует свой кластер и т.д.
Нам тоже хочется сделать что-то посложнее. Но в то же время хочется, чтобы кластеризация на клиенте работала как можно быстрее.
На момент написания алгоритма приборы показывали, что любой более сложный алгоритм ощутимо сказывается на времени исполнения клиентского кода. Мы решили, что в данном конкретном случае скорость важнее, чем сложность алгоритма.
Сейчас картина немного поменялась — мы перестали поддерживать некоторые слабые браузеры, может быть в будущем и посмотрим в сторону усложнения алгоритмы.
Странно что результаты Chrome и Яндекс.Браузера совершенно идентичны!
Лучше бы сделали единое пространство закладок/меток на карте для смартфона и на компьютере для одного аккаунта Яндекса. А то мучаюсь: с начало забиваю метки на смартфоне, а потом на компьютере.
Если не секрет — каким образом, по-вашему, это замечание относится к API Карт?
API Карт — имеет прямое отношение к данной проблеме, так решение данной проблемы легче всего осуществить через API самой же Yandex
На компе забиваете в maps.yandex.ru? Так это «Карты Яндекса» — просто сайт использующий АПИ Карт Яндекса.
АПИ должен решать только свои задачи, как и любой другой нишевый инструмент.
Я хочу, чтобы была возможность, создать свою карту с закладками И использовать ее на сайте с применением API, на смартфоне Яндекс.Карты, на компе зайдя на maps.yandex.ru. На текущий момент такой возможности нет. А так я получается, что во всех ТРЕХ сферах должен забивать отдельно одни и те же закладки (бывает я их по 200 штук за день набиваю).

АПИ должен решать только свои задачи — поэтому и пишу, что не проще сразу везде реализовать единые метки/закладки, в тм числе и в АПИ
«Мои карты» пробовали? У них есть выгрузка в yml/kml, которую можно отобразить где-то далее.
А когда планируется релиз нового API для яндекс.карт под iOS/Android?
Мы не можем вам ничего рассказать про ребят в мобильном направлении нас за это бьют. Но мы уже сами ждем-не дождемся)
Да, да, да. А то ваш API для iOS уже сильно устарел по сравнению с аналогами, а использовать хотелось бы
Когда исправите баг c svg-фоном в fillImageHref, который корректно отображается только в Сафари, плохо в Фаерфоксе и никак — в прочих браузерах?
Я про такой баг, почему-то, не знаю. Можно описать проблему в личке или клубике?
Быть может и не баг.
Вопрос: начиная с какого количества объектов надо задумываться о кластеризации на сервере? В Вашем примере использовано 10 000 точек, отрисовка занимает секунду. Соответственно, 100 000 точек уже будут неюзабельными. Я правильно понимаю?
Я не могу точно назвать количество меток, при котором вам нужно переходить на серверную кластеризацию. Вот по какой причине.

Клиентское время уйдет на 4 вещи:
1. Загрузка списка точек с сервера на клиент
2. создание 100 000 меток.
3. кластеризация меток
4. добавление кластеров и одиночных меток на карту.

Пункт 1 зависит от формата, в котором вы передаете данные — тут ничего не могу сказать.
Пункт 2 всегда одинаковый для всех кейсов — тут понятно.
А вот пункты 3 и 4 сильно зависят от конкретных условий, а именно:
а) сколько объектов попадают в видимую область карты
б) сколько в результате меток и кластеров нужно добавить на карту

Если все 100 000 меток, грубо, попадут в 1 кластер, то может быть время в общем будет не так уж и велико.

В общем, нужно смотреть на конкретные кейсы, но при величинах порядка 100 000 объектов с большой вероятностью надо уже уносить на сервер.
А что про производительность в браузерах? Не смотрели? (В цифрах)
Какая информация вас интересует, помимо представленной на графике?
Конкретно FPS в браузере при различных событиях. Можно конечно и самому посмотреть… Но может кому тоже интересно будет.
Мы бы в своей компании потенциально хотели бы использовать Ваши карты в состав закрытой системы для отслеживания транспорта в реальном времени, плюс опрос времени пути по пробкам между двумя точками.
Вы не планируете вводить подобные опции «для бизнеса»?
Спасибо за вопрос. Напишите пожалуйста мне на почту ache@yandex-team.ru, я маркетолог API Яндекс.Карт и смогу более детально ответить на ваш запрос.
К сожалению, я не знаю, какой принцип версионирования исользуется в API Карт, хотя 3 числа, разделенные точкой — это обычно Apache версионирование. В связи с этим вопрос: разве может API быть не backward compatible в рамках одной и той же мажорной версии (в данном случае это версия 2.x.x)?

Логичнее тогда было бы назвать новый API 3.0.0-beta.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.yandex.ru
Employees
over 10,000 employees
Registered

Habr blog