Загрузка маркеров 100-200K на карте google

В настоящий момент я использую API Google Maps v.3 для рисования маркеров на карте. Всего у меня около 500 маркеров.

В целях отображения я использую маркеры и кластеры с помощью этого инструмента на стороне клиента в браузере.

Однако я планирую расширить число мест и предположить, что он может быстро вырасти до 100 тыс. или даже 200 тыс.

Я сделал некоторые стресс-тесты и понял, что текущее решение в основном убивает браузер и около 10-20K маркеров.

Итак, мой вопрос: какой лучший подход привлечь много маркеров (необязательные карты Google)?

Я читал сообщения с похожими вопросами, например:

Отображение многих маркеров на Картах Google

Лучшее решение для слишком большого количества контактов на картах Google

В основном люди предлагают использовать некоторые кластеры для показа, которые я уже использую.

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

Я думаю о реализации следующего сценария:

на каждой странице zoom/load - отправьте запрос ajax с ограничениями отображения, добавьте около 30% со всех сторон и извлеките маркеры, которые попадают только в эту географическую область. 30% добавляется в случае, если пользователь масштабируется, так что я могу быстро отобразить другие маркеры, а затем снова вернуться в фоновом режиме, остальное вокруг (более широкая территория).
Когда число маркеров превышает 50, я планирую применить кластеризацию для отображения целей. Но поскольку markerCluster в javascript довольно медленный, а именно не markerCluster, а сам Google, поскольку он все еще применяет местоположения всех маркеров, я планирую сделать кластеризацию на стороне сервера, разделив границы отображаемой карты примерно в 15 * 15 сетке и отбрасывать маркеры в определенные ячейки, а затем в основном посылать клиентским кластерам с количеством маркеров внутри (например, для тепловой карты). А затем отобразить кластеры как маркеры.

Не могли бы вы дать некоторое представление о том, кто сделал подобное. Это имеет смысл вообще. Или это глупый подход, поскольку запросы ajax будут отправляться на сервер при каждом масштабировании и сдвиге карты и в основном перегружать сервер с избыточными запросами?

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

Ответ 1

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

Карты Google имеют ~ 20 уровней масштабирования, в зависимости от того, где вы находитесь на планете. В зависимости от того, насколько кластеризованы ваши данные, если у вас есть 200 000 маркеров и вы готовы отображать около 500 на карте в данный момент времени, подсчитывая все местоположения кластера и исходные маркеры, вы в конечном итоге сохраняете примерно 2n = 400 000 местоположений сервера - со всеми вашими уровнями масштабирования.

Возможные стратегии обновления кластера:

Обновление каждого нового маркера. Возможно, для чтения с большим количеством приложений с небольшим количеством записей, если вам нужна высокая степень достоверности данных.
Обновление по расписанию
Отключить обновление, если ((есть новые маркеры с последнего прохода кластеров && кеш старше X) || есть больше, чем Y новых маркеров с момента последнего прохода кластеризации)

Сохранение этих маркеров в базе данных, которая поддерживает геоданные изначально, может быть полезна. Это позволяет SQL-подобным операторам запрашивать местоположения.

На стороне клиента я бы рассмотрел выбор 50% маржи с обеих сторон, а не 30%. Google увеличивает масштаб до 2. Это позволит вам отображать один полный уровень масштабирования.

Далее, если это приложение будет активно использоваться, и оптимизация стоит того, я бы запустил серверную сторону, когда клиент будет увеличивать масштаб. Попробуйте профилировать свое использование, поэтому вы можете определить, часто ли пользователи увеличивают или уменьшают частоту. С твердыми числами (например, "70% пользователей увеличивают масштаб после получения исходных результатов и 20% уменьшения" ), вы можете определить, было бы целесообразно предварительно загрузить следующий уровень масштабированных данных для ваших пользователей, чтобы получить пользовательский интерфейс отзывчивость.