Как стать автором
Обновить

Комментарии 81

познавательно, спасибо.
вот только не понял, "Что делать, если ваша карта выглядит так?" ? если отмечено миллион флажков на карте, то что с ними делаете Вы, отображаете N штук и все?
Если вы посмотрите на рабочий пример - то увидите желтенькие группировочные маркеры и по клику на него у вас появится список маркеров в этой области.
понял
мне сразу попались несколько «группировочных» маркеров с одной записью в каждом. Глюк?
2 одинаковых на одном экране?
нет, в каждом было написано «найдено 1 предложение», предложения были разные, и сейчас не воспроизводится : (
Смените, а то кладбище какое то..
альтернативиное название статьи - как раскукожить объекты на гугль мапс
Привет, Влад ;-)
Мне нравится, что проект сделан "с душой"
По поводу карты - да, немного напргает подгрузка маркеров, если двигаться по карте. Но если это не так часто происходит, то конечно можно пренебречь. Или не "затенять" карту при подгрузке, чтобы это не так сильно бросалось в глаза.
Тут мы сделали упор на скорость, так как самый чистый вариант с "постепенной" загрузкой маркеров довольно-таки ресурсоемкий. А мы все-таки ориентируемся на регионы и слабые офисные компьютеры.
Вы забыли посмотреть как проблема реализована в самом продвинутом по части жонглировании обьектов сайте - викимапии.
Если коротко - у них запрос обьектов изначально производиться по секторам. Сектор соотвествует по своим размерам картинке сегмента карты и позиционируется также.
Это к тому же позволяет влет кэшировать эти запросы и обслуживать кучу народа.
А у вас - чуть сдвинул карту и пошла ОЧЕНЬ не хилая нагрузка на сервер.
А у меня(я не викимапия) - "за последние 24 часа было запрошено 478040 уникальных сегментов карты"
Сортировка выдачи производиться просто - 100 самых больших обьектов.
А ваша "уж больно регулярная" карта мне не понравилась.
Хотя, если честно , попробую часть вашего подхода себе поставить. А то с картинками на карте труба иногда
Тот способ, который реализован в викимаии у нас называется Статичные квадраты.

Когда проводили тестирование, вариант с динамической группировкой оказался быстрее статичных квадратов. Объяснение этому простое - лишняя нагрузка на БД и табличка с 23+ кк записей.
Эээ нет, вы меня не поняли.
Какраз нагрузка на сервер становиться сильно меньше
Способ ЗАГРУЗКИ обьектов в викимапии подразумевает подгрузку карты "статическими квадами" В одном кваде они до 400 обьектов передают.
Сортировка и выдача 100 нужных - на клиенте.
Адресс сегмента также говорит на каком зуме показать надо.
Не требуется хранить 23+кк секторов.
Глянул в кеш мемкешеда.. есть - отдал, или переживал и отдал.
Нету - сгенерил и отдал. И положил в кеш - ну на неделю например.
Генериться квад быстро. Берется из кеша сильно быстрее.

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

Еще раз скажу - это не способ хранения обьектов. Хотя по адрессу квадтри очень удобно делать выборку.
Это не способ борьбы с наложением одних обьектов на другие.
Это адресация клиентом серверных данных.

у вас - ОДИН запрос на сервер с данными
lat1 55.522411831398216
lat2 55.98762792516235
lng1 37.2216796875
lng2 38.0126953125

за 281мсек

чуть сдвинул - другой запрос
надо - 4 или больше запросов по размерам и положениям квадов данного зума.
Получаем 4 запроса за 80-150мсек. Которые выполняются паралельно...
Чуть сдвинул -ничего не меняется.
Чуть более сдвинул - ничего не меняется.
И только если сдвинул на 128 и больше пикселей - подгружаются сегмент. Один-два-три или более.

Тоесть в вашем случае можно даже ничего не менять.
Просто попросить клиент малек по другому данные фетчить.
Итого реальное колличество запросов на сервер - упадет.
Потому что - карта загрузилась и сразу запросила много много сегментов.. - можно отдать из кеша - адресса, параметры, а значит и данные неизменны..
а потом вал запросов от клиента прекращается.

Сейчас у вас мало народа на сайте. Особенно если хабр эффект вычесть.
Но когданить он будет. Пожалейте сервер. Не насилуйте его
при очень больших обьемах данных есть смысл вообще генерировать тайлы и подставлять их как оверлеи, нагрузка на сервер при генерации картинок конечно будет больше, но отдавать надо будет по сути только статику
Простите, но у нас АКТИВНЫЕ обьекты на карте :)
Ну это понятно, я не говорю, что в вашем случае это идеальное решение.
Хотя по клику на карте ничто не мешает вам отрисовать маркер поверх картинки и показать у него infowindow. Координаты клика то у вас есть.
не захочу я кликать на то что без HINTа...
решение, типа как вы говорите, используется гуглом в слое панорамио + карта этих самых кликов.
но у них именно что картиночная задача
Не бывает на 100% идеальных решений.
Благодарю за разъяснение. Решение интересное.
Если угодно могу скинуть клиентские и серверные коды по адресации сегментов.
Честно декодированные с викимапии :)
Буду примерно благодарен.

mastyf (гав гав гав) gmail.com
И мне, и мне. bolter.fire (вызнаетечто) гмэйл.ком
Заранее спасибо.
Мож мне на эту тему пост создать?
Где пост?
Или опять на мыло?
пост(две чтук) будут сегодня
Т.е если я сдвинул на 120 пикселей и увидел свой дом, то на ним все равно ничего не прорисуется т.к. до 128 не дотянул?
Ну и у мемкэша есть такая особенность, что они иногда случается падает, и тогда надо заново генерить весь кэш, а если он упадет в пик посещаемости?
Все-таки в геопроектах лучше не пытаться запускать ракеты на дизельном топливе, есть специальные геосервера со своим внутренним кэшем. Мы, например, использовали Spatial DB в связке с VE, очень удобно и практично.
мемкешед падает? Обновите версия сервера\клиента - у ЖЖ он почемуто не падает.
+У меня три кешеда запушено. Если упадет один - переживу.
Если вы сдвинете карту на 120 пикселей - вы увидите свой дом. Потому что раз мааааленький кусочек этого дома был виден - подгрузился весь сегмент.
И только когда сдвинете малек больше - увидите сарай за домом, точнее подгрузиться новый сегмент
Я даже испугался, увидев это) Статья интересная, спасибо
Хмм, еще один способ есть.
Показывают наиболее популярные точки в зависимости от зума, а при приближении показывать менее приоритетные в данной зоне. Загвоздка только одна как определить наиболее популярные для конкретного пользователя, но и это решаемо=)
Ну согласитесь, в нашем случае эту систему не внедрить :)
На Автокадабре сделано таким образом. Есть фильтр по интересности и он меняется при зумме. Кроме этого подгружаются только те объекты, которые видны + ещё немного за краями карты, что бы они отображались сразу, когда пользователь немножко двигает карту
Класс. До примерно половины из этого я дошёл сам, но группировку маркеров сделать так и не успел. Теперь видимо возьмусь заново.
Иногда маркеры не группируются. Если немного удалить, когда в сгруппированном маркере много других маркеров и нажать "Показать эту область"
Так и задумано. Представляете что будет, если пользователь кликнув на группировочный маркер кликнет на "Посмотреть эту область" и увидит еще несколько группировочных маркеров? :)
Так и задумано: начиная с определённого масштаба по ссылке "показать эту область" показываем все найденные маркеры без группировки.
$dbWhere - отправляется в вашу бд?
Приведён не весь код, на самом деле :-)
Если не сложно, объясните смысл использования только статичных методов и свойств в классе Medialab_Gmap_Marker.
Не видели смысла использовать не статичные методы и классы.
Я начинаю чувствовать, что это как ООП vs. «не ООП» :-)
тут, видимо, класс выполняет роль namespace'a
Уменьшите до масштаба, когда в группу попадает хотя-бы 500 объектов (а "лучше" 1000), кликните на нее и выберите "посмотреть эту область". Догадываюсь, что результат будет не такой, какой Вы ожидали.
Это баг или фича?
И еще, в половине случаев, когда я клацаю на фишку, карта сдвигается, чтобы отобразить попап. В "новой" части карты не прорисовываются объекты.
К сожалению, это вынужденная мера. А то клиенту придется прорисоывать несколько тысяч маркеров :)

p.s. Мы ввели ограничение с какого зума можно отключить группировку.
Хаха медиалабовсской движок)) ну норм статья + еще один способ
Если бы видели в каком состоянии был движок Медиалаба когда мы начали работу над ним - вы бы так не радовались :)
он был в нормальном состоянии хотя я хз чо было до меня я в лабе не долг работаю с февраля
Может я скажу сейчас ужасную вещь, но есть flash компоненты и сервисы для работы с картами.
например http://www.umapper.com/
даже без тестов могу сказать, что на 200кб xml флеш не подавится :)
забыл ссылку на сам компонент - http://afcomponents.com/components/umap_as3/
думаю, если погуглить, найдутся аналоги и для google maps, если это принципиально
Идея интересная, спасибо.
Спасибо за статью.
Небольшое не замечание, но предположение.
Кликаем на группе, если облачко не помещается, то карта сдвигаеся, но объекты на открывшемся участке не обновляются. Может попробовать после закрытия облачка обновить карту?
Тогда есть вариант, что маркер который вы только что открыли, упрыгает на пару сантиметров :)
А ведь на раз :)
Может текущее решение и есть наименьшее из зол :) А может мне нормальных идей в голову не приходит :)
Кроме вышеупомянутых российских проектов, есть зарубежные, успешно решившую такую проблему. Например, realestate.com.au.
...и облегчая, и без того нелегкую, жизнь браузеру //не понравилась структура предложения. Как будто после облегчения она может стать тяжелее. Да и распространенное определение не обособляется, если стоит до определяемого слова.
По-моему было бы логичнее разбивать не на квадраты, а на круги и делать группировку по радиусу окружности.
Сами сталкивались с такими граблями, по сути пришли к схожему по логике решению, но у нас группировка была на всех уровнях до тех пор, пока количество маркеров не становилось разумным.
Кстати, хинт, попробуйте передавать данные не в XML, XML-parser в IE - ужасно тормознутое исчадие ада. Предлагаю попробовать JSON, например.
Был прототип и на JSON. Разницы в скорости не заметили.
У меня еще пара вопросов:
1. var isFirstLoaded = 1;
т.е. JS у вас расчитан только на один инстанс карты на странице?
2. Я так понял, при перемещении карты, у вас все маркеры отрисовываются заново, так?
Я осмелюсь предложить вам такой способ, при перемещении карты строго влево\вправо или вниз\вверх, брать bounds старого окна, и высчитывать разницу с новым окном. Тоесть если ваш вьюпорт имеет размер 200х200 и latitude скажем (0, 20), то при перемещении вправо на 10 пикселей вам не надо брать заново всю зону (1, 21) хотя было бы разумнее не стирать старые маркеры, а просто запросить новые по квадрату (20, 21)
Я наверное опять со своей викимапией влезу.. но чем вам не нравиться plain/text(csv)?
Вы же передаете регуляные, абсолютно табличные данные
мне - нравится, я как вариант предложил. Как альтернативу XML.
Вы предложили JSON который тоже малек избыточен для задач подгрузки обьектов.
Самый идеальный способ в плане оптимизации в таком случае - это подгружать уже готовые .js файлы с созданными внутри них обьектами. Все остальные способы оставляют накладные расходы.
было бы юзаьельней если бы вместо плюсика на маркере было число объектов в группе

п.с. перезагрузка карты после каждого передвижения очень раздражает
НЛО прилетело и опубликовало эту надпись здесь
Ибо машинным способом определить налазят ли N объектов друг на друга потребудет от нас примерно N^2 операций.
С чего вдруг ? За O(N log N) она вполне решается. Диаграмма Воронова => Триангуляция Делоне => кандидаты на объединение...
НЛО прилетело и опубликовало эту надпись здесь
Не наш случай — в этом примере вообще нет группировки, все маркеры заранее разбрасываются по отрезкам масштаба.
Побольше бы таких сайтов, где думают о загрузке пользовательского ПК. А то поназапускают какие-нить пионеры JavaScript снежинок и другой дребедени...
НЛО прилетело и опубликовало эту надпись здесь
Вы самого главного не сказали — кластеры считаются динамически или генерятся заранее? Впрочем, несколько тысяч — наверное, можно и на лету. Не оценивали, сколько времени уходит на кластеризацию на минимальном масштабе?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
я ноутбуки чаще меняю...... как можно googleearth с одного компа на другой перекинуть?
Вот мой вариант реализации динамической группировки большого количества данных на карте: http://www.australia.com/Search.aspx?q=w…

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

Если кому интересно, исходники вот здесь: http://www.australia.com/js/TaMultimap.j…
Код реализован как расширение класса GMap2.
Есть вопрос! Нужно делать почти такое же но с областями покрытия. К примеру, области отображаются кругами (реализуется через GPolygon), естественно их размеры пропроциональны масштабу, т.е. покрывает одну и ту же площадь земной поверхности, не так как у маркеров(размер маркера всегда один и тот же не зависимо от масштаба).
Так вот, задача состоит в том если на карте нанесено огромное количество таких областей, как их объединить в группу или аппроксимировать, чтобы не нагружать пользовательскую машину. Эксперимент для 10000 областей положил браузер на 5 минут....
Сразу же оговорюсь, что коэффициент прямоугольника для каждого из зумов разный и мы считали ТОЛЬКО Россию.


Эта проблема не сложно решается для карт с проекцией сферического Меркатора типа Яндекса и Гугла;)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории