Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 81
познавательно, спасибо.
вот только не понял, "Что делать, если ваша карта выглядит так?" ? если отмечено миллион флажков на карте, то что с ними делаете Вы, отображаете N штук и все?
Если вы посмотрите на рабочий пример - то увидите желтенькие группировочные маркеры и по клику на него у вас появится список маркеров в этой области.
понял
мне сразу попались несколько «группировочных» маркеров с одной записью в каждом. Глюк?
Смените, а то кладбище какое то..
альтернативиное название статьи - как раскукожить объекты на гугль мапс
Привет, Влад ;-)
Мне нравится, что проект сделан "с душой"
По поводу карты - да, немного напргает подгрузка маркеров, если двигаться по карте. Но если это не так часто происходит, то конечно можно пренебречь. Или не "затенять" карту при подгрузке, чтобы это не так сильно бросалось в глаза.
Мне нравится, что проект сделан "с душой"
По поводу карты - да, немного напргает подгрузка маркеров, если двигаться по карте. Но если это не так часто происходит, то конечно можно пренебречь. Или не "затенять" карту при подгрузке, чтобы это не так сильно бросалось в глаза.
Тут мы сделали упор на скорость, так как самый чистый вариант с "постепенной" загрузкой маркеров довольно-таки ресурсоемкий. А мы все-таки ориентируемся на регионы и слабые офисные компьютеры.
Вы забыли посмотреть как проблема реализована в самом продвинутом по части жонглировании обьектов сайте - викимапии.
Если коротко - у них запрос обьектов изначально производиться по секторам. Сектор соотвествует по своим размерам картинке сегмента карты и позиционируется также.
Это к тому же позволяет влет кэшировать эти запросы и обслуживать кучу народа.
А у вас - чуть сдвинул карту и пошла ОЧЕНЬ не хилая нагрузка на сервер.
А у меня(я не викимапия) - "за последние 24 часа было запрошено 478040 уникальных сегментов карты"
Сортировка выдачи производиться просто - 100 самых больших обьектов.
А ваша "уж больно регулярная" карта мне не понравилась.
Хотя, если честно , попробую часть вашего подхода себе поставить. А то с картинками на карте труба иногда
Если коротко - у них запрос обьектов изначально производиться по секторам. Сектор соотвествует по своим размерам картинке сегмента карты и позиционируется также.
Это к тому же позволяет влет кэшировать эти запросы и обслуживать кучу народа.
А у вас - чуть сдвинул карту и пошла ОЧЕНЬ не хилая нагрузка на сервер.
А у меня(я не викимапия) - "за последние 24 часа было запрошено 478040 уникальных сегментов карты"
Сортировка выдачи производиться просто - 100 самых больших обьектов.
А ваша "уж больно регулярная" карта мне не понравилась.
Хотя, если честно , попробую часть вашего подхода себе поставить. А то с картинками на карте труба иногда
Тот способ, который реализован в викимаии у нас называется Статичные квадраты.
Когда проводили тестирование, вариант с динамической группировкой оказался быстрее статичных квадратов. Объяснение этому простое - лишняя нагрузка на БД и табличка с 23+ кк записей.
Когда проводили тестирование, вариант с динамической группировкой оказался быстрее статичных квадратов. Объяснение этому простое - лишняя нагрузка на БД и табличка с 23+ кк записей.
Эээ нет, вы меня не поняли.
Какраз нагрузка на сервер становиться сильно меньше
Способ ЗАГРУЗКИ обьектов в викимапии подразумевает подгрузку карты "статическими квадами" В одном кваде они до 400 обьектов передают.
Сортировка и выдача 100 нужных - на клиенте.
Адресс сегмента также говорит на каком зуме показать надо.
Не требуется хранить 23+кк секторов.
Глянул в кеш мемкешеда.. есть - отдал, или переживал и отдал.
Нету - сгенерил и отдал. И положил в кеш - ну на неделю например.
Генериться квад быстро. Берется из кеша сильно быстрее.
А что у вас - сдвинул карту и на секунду-две-три подвис непонятно зачем.
Вы бы хоть управление оставляли, подгружая обьекты в фоне.
Еще раз скажу - это не способ хранения обьектов. Хотя по адрессу квадтри очень удобно делать выборку.
Это не способ борьбы с наложением одних обьектов на другие.
Это адресация клиентом серверных данных.
у вас - ОДИН запрос на сервер с данными
lat1 55.522411831398216
lat2 55.98762792516235
lng1 37.2216796875
lng2 38.0126953125
за 281мсек
чуть сдвинул - другой запрос
надо - 4 или больше запросов по размерам и положениям квадов данного зума.
Получаем 4 запроса за 80-150мсек. Которые выполняются паралельно...
Чуть сдвинул -ничего не меняется.
Чуть более сдвинул - ничего не меняется.
И только если сдвинул на 128 и больше пикселей - подгружаются сегмент. Один-два-три или более.
Тоесть в вашем случае можно даже ничего не менять.
Просто попросить клиент малек по другому данные фетчить.
Итого реальное колличество запросов на сервер - упадет.
Потому что - карта загрузилась и сразу запросила много много сегментов.. - можно отдать из кеша - адресса, параметры, а значит и данные неизменны..
а потом вал запросов от клиента прекращается.
Сейчас у вас мало народа на сайте. Особенно если хабр эффект вычесть.
Но когданить он будет. Пожалейте сервер. Не насилуйте его
Какраз нагрузка на сервер становиться сильно меньше
Способ ЗАГРУЗКИ обьектов в викимапии подразумевает подгрузку карты "статическими квадами" В одном кваде они до 400 обьектов передают.
Сортировка и выдача 100 нужных - на клиенте.
Адресс сегмента также говорит на каком зуме показать надо.
Не требуется хранить 23+кк секторов.
Глянул в кеш мемкешеда.. есть - отдал, или переживал и отдал.
Нету - сгенерил и отдал. И положил в кеш - ну на неделю например.
Генериться квад быстро. Берется из кеша сильно быстрее.
А что у вас - сдвинул карту и на секунду-две-три подвис непонятно зачем.
Вы бы хоть управление оставляли, подгружая обьекты в фоне.
Еще раз скажу - это не способ хранения обьектов. Хотя по адрессу квадтри очень удобно делать выборку.
Это не способ борьбы с наложением одних обьектов на другие.
Это адресация клиентом серверных данных.
у вас - ОДИН запрос на сервер с данными
lat1 55.522411831398216
lat2 55.98762792516235
lng1 37.2216796875
lng2 38.0126953125
за 281мсек
чуть сдвинул - другой запрос
надо - 4 или больше запросов по размерам и положениям квадов данного зума.
Получаем 4 запроса за 80-150мсек. Которые выполняются паралельно...
Чуть сдвинул -ничего не меняется.
Чуть более сдвинул - ничего не меняется.
И только если сдвинул на 128 и больше пикселей - подгружаются сегмент. Один-два-три или более.
Тоесть в вашем случае можно даже ничего не менять.
Просто попросить клиент малек по другому данные фетчить.
Итого реальное колличество запросов на сервер - упадет.
Потому что - карта загрузилась и сразу запросила много много сегментов.. - можно отдать из кеша - адресса, параметры, а значит и данные неизменны..
а потом вал запросов от клиента прекращается.
Сейчас у вас мало народа на сайте. Особенно если хабр эффект вычесть.
Но когданить он будет. Пожалейте сервер. Не насилуйте его
при очень больших обьемах данных есть смысл вообще генерировать тайлы и подставлять их как оверлеи, нагрузка на сервер при генерации картинок конечно будет больше, но отдавать надо будет по сути только статику
Благодарю за разъяснение. Решение интересное.
Т.е если я сдвинул на 120 пикселей и увидел свой дом, то на ним все равно ничего не прорисуется т.к. до 128 не дотянул?
Ну и у мемкэша есть такая особенность, что они иногда случается падает, и тогда надо заново генерить весь кэш, а если он упадет в пик посещаемости?
Все-таки в геопроектах лучше не пытаться запускать ракеты на дизельном топливе, есть специальные геосервера со своим внутренним кэшем. Мы, например, использовали Spatial DB в связке с VE, очень удобно и практично.
Ну и у мемкэша есть такая особенность, что они иногда случается падает, и тогда надо заново генерить весь кэш, а если он упадет в пик посещаемости?
Все-таки в геопроектах лучше не пытаться запускать ракеты на дизельном топливе, есть специальные геосервера со своим внутренним кэшем. Мы, например, использовали Spatial DB в связке с VE, очень удобно и практично.
мемкешед падает? Обновите версия сервера\клиента - у ЖЖ он почемуто не падает.
+У меня три кешеда запушено. Если упадет один - переживу.
Если вы сдвинете карту на 120 пикселей - вы увидите свой дом. Потому что раз мааааленький кусочек этого дома был виден - подгрузился весь сегмент.
И только когда сдвинете малек больше - увидите сарай за домом, точнее подгрузиться новый сегмент
+У меня три кешеда запушено. Если упадет один - переживу.
Если вы сдвинете карту на 120 пикселей - вы увидите свой дом. Потому что раз мааааленький кусочек этого дома был виден - подгрузился весь сегмент.
И только когда сдвинете малек больше - увидите сарай за домом, точнее подгрузиться новый сегмент
Я даже испугался, увидев это) Статья интересная, спасибо
Хмм, еще один способ есть.
Показывают наиболее популярные точки в зависимости от зума, а при приближении показывать менее приоритетные в данной зоне. Загвоздка только одна как определить наиболее популярные для конкретного пользователя, но и это решаемо=)
Показывают наиболее популярные точки в зависимости от зума, а при приближении показывать менее приоритетные в данной зоне. Загвоздка только одна как определить наиболее популярные для конкретного пользователя, но и это решаемо=)
Ну согласитесь, в нашем случае эту систему не внедрить :)
На Автокадабре сделано таким образом. Есть фильтр по интересности и он меняется при зумме. Кроме этого подгружаются только те объекты, которые видны + ещё немного за краями карты, что бы они отображались сразу, когда пользователь немножко двигает карту
Класс. До примерно половины из этого я дошёл сам, но группировку маркеров сделать так и не успел. Теперь видимо возьмусь заново.
Иногда маркеры не группируются. Если немного удалить, когда в сгруппированном маркере много других маркеров и нажать "Показать эту область"
Так и задумано. Представляете что будет, если пользователь кликнув на группировочный маркер кликнет на "Посмотреть эту область" и увидит еще несколько группировочных маркеров? :)
Так и задумано: начиная с определённого масштаба по ссылке "показать эту область" показываем все найденные маркеры без группировки.
$dbWhere - отправляется в вашу бд?
Если не сложно, объясните смысл использования только статичных методов и свойств в классе Medialab_Gmap_Marker.
Уменьшите до масштаба, когда в группу попадает хотя-бы 500 объектов (а "лучше" 1000), кликните на нее и выберите "посмотреть эту область". Догадываюсь, что результат будет не такой, какой Вы ожидали.
Это баг или фича?
Это баг или фича?
И еще, в половине случаев, когда я клацаю на фишку, карта сдвигается, чтобы отобразить попап. В "новой" части карты не прорисовываются объекты.
Это специально. Раскрыл суть тут - http://habrahabr.ru/blog/google/46010.ht…
К сожалению, это вынужденная мера. А то клиенту придется прорисоывать несколько тысяч маркеров :)
p.s. Мы ввели ограничение с какого зума можно отключить группировку.
p.s. Мы ввели ограничение с какого зума можно отключить группировку.
Хаха медиалабовсской движок)) ну норм статья + еще один способ
Может я скажу сейчас ужасную вещь, но есть flash компоненты и сервисы для работы с картами.
например http://www.umapper.com/
даже без тестов могу сказать, что на 200кб xml флеш не подавится :)
например http://www.umapper.com/
даже без тестов могу сказать, что на 200кб xml флеш не подавится :)
Спасибо за статью.
Небольшое не замечание, но предположение.
Кликаем на группе, если облачко не помещается, то карта сдвигаеся, но объекты на открывшемся участке не обновляются. Может попробовать после закрытия облачка обновить карту?
Небольшое не замечание, но предположение.
Кликаем на группе, если облачко не помещается, то карта сдвигаеся, но объекты на открывшемся участке не обновляются. Может попробовать после закрытия облачка обновить карту?
Кроме вышеупомянутых российских проектов, есть зарубежные, успешно решившую такую проблему. Например, realestate.com.au.
Что-то с ссылкой. Вот она: http://www.realestate.com.au/cgi-bin/rse…
...и облегчая, и без того нелегкую, жизнь браузеру //не понравилась структура предложения. Как будто после облегчения она может стать тяжелее. Да и распространенное определение не обособляется, если стоит до определяемого слова.
По-моему было бы логичнее разбивать не на квадраты, а на круги и делать группировку по радиусу окружности.
Сами сталкивались с такими граблями, по сути пришли к схожему по логике решению, но у нас группировка была на всех уровнях до тех пор, пока количество маркеров не становилось разумным.
Кстати, хинт, попробуйте передавать данные не в XML, XML-parser в IE - ужасно тормознутое исчадие ада. Предлагаю попробовать JSON, например.
Сами сталкивались с такими граблями, по сути пришли к схожему по логике решению, но у нас группировка была на всех уровнях до тех пор, пока количество маркеров не становилось разумным.
Кстати, хинт, попробуйте передавать данные не в XML, XML-parser в IE - ужасно тормознутое исчадие ада. Предлагаю попробовать JSON, например.
Был прототип и на JSON. Разницы в скорости не заметили.
У меня еще пара вопросов:
1. var isFirstLoaded = 1;
т.е. JS у вас расчитан только на один инстанс карты на странице?
2. Я так понял, при перемещении карты, у вас все маркеры отрисовываются заново, так?
Я осмелюсь предложить вам такой способ, при перемещении карты строго влево\вправо или вниз\вверх, брать bounds старого окна, и высчитывать разницу с новым окном. Тоесть если ваш вьюпорт имеет размер 200х200 и latitude скажем (0, 20), то при перемещении вправо на 10 пикселей вам не надо брать заново всю зону (1, 21) хотя было бы разумнее не стирать старые маркеры, а просто запросить новые по квадрату (20, 21)
1. var isFirstLoaded = 1;
т.е. JS у вас расчитан только на один инстанс карты на странице?
2. Я так понял, при перемещении карты, у вас все маркеры отрисовываются заново, так?
Я осмелюсь предложить вам такой способ, при перемещении карты строго влево\вправо или вниз\вверх, брать bounds старого окна, и высчитывать разницу с новым окном. Тоесть если ваш вьюпорт имеет размер 200х200 и latitude скажем (0, 20), то при перемещении вправо на 10 пикселей вам не надо брать заново всю зону (1, 21) хотя было бы разумнее не стирать старые маркеры, а просто запросить новые по квадрату (20, 21)
Я наверное опять со своей викимапией влезу.. но чем вам не нравиться plain/text(csv)?
Вы же передаете регуляные, абсолютно табличные данные
Вы же передаете регуляные, абсолютно табличные данные
было бы юзаьельней если бы вместо плюсика на маркере было число объектов в группе
п.с. перезагрузка карты после каждого передвижения очень раздражает
п.с. перезагрузка карты после каждого передвижения очень раздражает
эээ... а что мешало использовать стандартный пример из API
http://gmaps-utility-library.googlecode.…
?
http://gmaps-utility-library.googlecode.…
?
Ибо машинным способом определить налазят ли 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.
Обращение к серверу происходит только один раз, так ка находиться не очень большое количество данных одновременно.
Производиться динамическая группировка маркеров в отличие от зума карты, при этом всплывающее окно окно переделывается в список, содержащий сгруппированные элементы.
Если кому интересно, исходники вот здесь: http://www.australia.com/js/TaMultimap.j…
Код реализован как расширение класса GMap2.
Есть вопрос! Нужно делать почти такое же но с областями покрытия. К примеру, области отображаются кругами (реализуется через GPolygon), естественно их размеры пропроциональны масштабу, т.е. покрывает одну и ту же площадь земной поверхности, не так как у маркеров(размер маркера всегда один и тот же не зависимо от масштаба).
Так вот, задача состоит в том если на карте нанесено огромное количество таких областей, как их объединить в группу или аппроксимировать, чтобы не нагружать пользовательскую машину. Эксперимент для 10000 областей положил браузер на 5 минут....
Так вот, задача состоит в том если на карте нанесено огромное количество таких областей, как их объединить в группу или аппроксимировать, чтобы не нагружать пользовательскую машину. Эксперимент для 10000 областей положил браузер на 5 минут....
Сразу же оговорюсь, что коэффициент прямоугольника для каждого из зумов разный и мы считали ТОЛЬКО Россию.
Эта проблема не сложно решается для карт с проекцией сферического Меркатора типа Яндекса и Гугла;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что делать, если ваша карта выглядит так?