Comments 22
Никогда не знаешь, что твой пост выдет на первую, да? :)
habrastorage.org
Ну и форматирование же…
Быстрей, пока не слили, не прочитав даже.
habrastorage.org
Ну и форматирование же…
Быстрей, пока не слили, не прочитав даже.
1. В isImposition у нас каждый с каждым? Это типа O(n^2)? У нас апи ране позволяет как-то упростить/ускорить?
2. В случае группировки уже иконки какие-то другие д.б. + циферки на них, сколько внутри элементов + при нажатии на группу всплывашка какая-то особая нужна. Это как-то учтено уже или учитываемо легко в текущей реализации?
2. В случае группировки уже иконки какие-то другие д.б. + циферки на них, сколько внутри элементов + при нажатии на группу всплывашка какая-то особая нужна. Это как-то учтено уже или учитываемо легко в текущей реализации?
По 1 пункту — не совсем так. У нас есть один основной цикл по всем возможным элементам, а во втором цикле уже пробегаемся по созданным группам. Т.е. ситуация, описанная вами, возникнет только тогда, когда все элементы будут располагаться разрозненно.
По 2 пункту — иконки другие поставить — не проблема. На последних 2 скринах, как раз таки, я и показал различие между группой и одним элементом(правда возможно это не совсем очевидно на первый взгляд, но у меня надписи всплывают разные :)), так что добавить различное поведение для групп и элементов нет никакой проблемы в текущей реализации.
По 2 пункту — иконки другие поставить — не проблема. На последних 2 скринах, как раз таки, я и показал различие между группой и одним элементом(правда возможно это не совсем очевидно на первый взгляд, но у меня надписи всплывают разные :)), так что добавить различное поведение для групп и элементов нет никакой проблемы в текущей реализации.
Может кто уже реализовывал нечто подобное? Хотелось бы услышать про альтернативные пути решения данной проблеммы…
Посмотри на Dot Density Map, Dot Distribution Map во взрослых ГИС. Принципы те же — разбиение по триангуляции Делоне или диаграмме Вороного как предпроцессинг, на них dynamic level of detail ложится превосходно.
Конечно реализовывали. Это же обычная кластеризация, и ребята из гугла позаботились об этом, правда не в самих картах
Репо на гитхабе
Я использовал это решение, правда упрощенное, без анимации, у меня больно уж много элементов на карте. Когда элементов больше 2К начинает полагивать, когда убрал анимацию, на 5К все работает прекрасною
Вот же, из-за профилактик на хабре моя rss выдает теперь статьи двухлетней давности. Извиняюсь. Понял, когда увидел, что карты v1
Репо на гитхабе
Я использовал это решение, правда упрощенное, без анимации, у меня больно уж много элементов на карте. Когда элементов больше 2К начинает полагивать, когда убрал анимацию, на 5К все работает прекрасною
Вот же, из-за профилактик на хабре моя rss выдает теперь статьи двухлетней давности. Извиняюсь. Понял, когда увидел, что карты v1
Ну правильно говорят, так не пишут :) Я реализовывал что-то подобное. Для эффективных алгоритмов не бегают по циклам 2 раза.
1. Использовать тайлику, то есть перевести координаты в tileX, tileY (можно использовать обычный алгоритм меркатора). Например, представлять координаты в тайлике 31-го зума.
2. Определяется текущий viewZoom. Дальше с координатами проделяется следующая операция, а именно определения плотности квадратов. Один тайл на гугл карте 256x256, то есть можно использовать квадраты 64x64 (или 32x32) чтобы не уплотнялись пины.
3. Переводим координаты в наш рассчитанный tileZoom. int boxX = tileX >> (31 — viewZoom + 5 /*или 6*/). int boxY = tileY >> (31 — viewZoom + 5 /*или 6*/)
4. Теперь нам надо просто сгрупировать по boxX,boxY и выбрать уникальные из них.
Для энтузиастов выбирать уникальные и группировать нужно не через Set, а через int[] массив, но тут уже надо проявить сноровку :)
1. Использовать тайлику, то есть перевести координаты в tileX, tileY (можно использовать обычный алгоритм меркатора). Например, представлять координаты в тайлике 31-го зума.
2. Определяется текущий viewZoom. Дальше с координатами проделяется следующая операция, а именно определения плотности квадратов. Один тайл на гугл карте 256x256, то есть можно использовать квадраты 64x64 (или 32x32) чтобы не уплотнялись пины.
3. Переводим координаты в наш рассчитанный tileZoom. int boxX = tileX >> (31 — viewZoom + 5 /*или 6*/). int boxY = tileY >> (31 — viewZoom + 5 /*или 6*/)
4. Теперь нам надо просто сгрупировать по boxX,boxY и выбрать уникальные из них.
Для энтузиастов выбирать уникальные и группировать нужно не через Set, а через int[] массив, но тут уже надо проявить сноровку :)
Спасибо, интересно — надо будет попробовать на досуге :). Только еще вопрос — обязательно ли выполнять пункты 1-3, если mapView.getLatitudeSpan() возвращает нам уже привязанную к нашим координатам и к ширине занимаемого картой пространства на экране величину? Может достаточно проводить групировку уже на этом этапе? Или я не правильно понял суть описанного вами алгоритма?
Получится метки в узлах регулярной сетки? При нерегулярном распределении не будет отражать реальную картину.
Да, а в чем состоит реальная картина? Опишите — я думаю относительное распределение можно учесть — просто считать частоту и в конце решать отображать или нет.
К примеру, имеем распределение в форме кольца, внутренний радиус которого — больше радиуса вписанной в ячейку сетки окружности, но меньше описанной, а центр совпадает с центром узла сетки. Т.е. очень незначительная часть меток (одна, две, три) попадают в центральный узел сетки. Используя алгоритм с регулярной сеткой мы получим метки во всех ячейках сетки размером 3х3 (или более), т.к. в каждой из ячеек будет как минимум 1 метка, и как минимум в центральной ячейки метка не будет совпадать ни с одним реальным объектом.
Если использовать адаптивный алгоритм, например указанный мною Dot Density Map — мы с большОй долей вероятности получим более правдоподобную схему в форме четырёх (или более) меток, расположенных слева, справа, сверху и снизу от центра кольца. Кроме того, есть возможность центр каждой ячейки адаптивной сетки совмещать с местом расположения реального объекта, «адаптированные» метки более точно отражают «кластеризацию» реальных объектов.
Если использовать адаптивный алгоритм, например указанный мною Dot Density Map — мы с большОй долей вероятности получим более правдоподобную схему в форме четырёх (или более) меток, расположенных слева, справа, сверху и снизу от центра кольца. Кроме того, есть возможность центр каждой ячейки адаптивной сетки совмещать с местом расположения реального объекта, «адаптированные» метки более точно отражают «кластеризацию» реальных объектов.
Эххх… Вот бы в Javascript API то же самое… В некоторых случаях помогает markerclusterer, до тех пор, пока с маркерами никаких хитрых действий производить не надо. Просто на месте густого скопления маркеров отображается кругляш с количеством маркеров
На картинке наблюдается невозможная фигура
в нашем проекте использовался Erdao GeoClusterer, он работает хорошо, только иногда вылезает неприятный баг — иногда не обновляется, требуется тапнуть по экрану чтобы он перерисовался, могу скриншот показать
Почитайте вот эту статью:
developers.google.com/maps/articles/toomanymarkers
developers.google.com/maps/articles/toomanymarkers
Sign up to leave a comment.
Android — фильтруем пины на карте, в зависимости от расстояния друг от друга