2015-09-14 25 views
12

Al momento sto utilizzando l'API di Google Maps v.3 per disegnare indicatori sulla mappa. Ho circa 500 marker in totale.Caricamento marcatori 100-200K su google map

Per scopi di visualizzazione utilizzo marker marker e marcatori di gruppo utilizzando questo strumento sul lato client nel browser.

Tuttavia, ho intenzione di espandere il numero di posizioni e presumere che possa crescere fino a 100 K o anche 200 K rapidamente.

Ho eseguito alcuni test di stress e mi sono reso conto che la soluzione corrente uccide fondamentalmente il browser e circa 10-20K di indicatori.

Quindi la mia domanda qual è l'approccio migliore per disegnare tanti indicatori (non necessario google maps)?

Ho letto i messaggi con domande simili, ad es .:

Showing many markers in Google Maps

Best solution for too many pins on google maps

Fondamentalmente le persone suggeriscono di utilizzare alcune clusterer per scopi di visualizzazione, che ho già uso.

Oppure utilizzare le tabelle di fusione per il recupero dei dati, che non è un'opzione, poiché i dati devono rimanere sul mio server. Suppongo anche che la funzionalità di visualizzazione sia limitata con le tabelle di fusione.

Sto pensando di attuare il seguente scenario:

  • in ogni pagina di zoom/carico - inviare richiesta AJAX con confini della vista del display, aggiungere circa il 30% su tutti i lati e recuperare i marcatori, che cadere in questa area geografica solo. 30% viene aggiunto nel caso in cui l'utente zooma fuori, in modo che possa visualizzare altri marker rapidamente e quindi recuperare ulteriormente in background il resto intorno (territorio più ampio)

  • Quando il numero di marcatori è superiore a 50 - quindi I piano per applicare il clustering per scopi di visualizzazione. Ma dato che il markerCluster in javascript è piuttosto lento, ovvero non markerCluster ma google stesso, poiché applica ancora le posizioni di tutti i marker, ho intenzione di fare il clustering sul lato server dividendo i limiti della mappa visualizzata nella griglia 15 * 15 e rilasciare marcatori in celle particolari e quindi fondamentalmente inviare ai cluster client con un numero di marker all'interno (ad esempio, come per heatmap). E poi per visualizzare i cluster come marker.

Potrebbe per favore dare qualche idea a chi ha fatto simili. Ha senso in generale. O è un approccio stupido dato che le richieste Ajax saranno inviate al server su ogni zoom e spostamento di ogni mappa e fondamentalmente sovraccaricano il server con richieste ridondanti?

Quello che voglio ottenere è una bella esperienza utente su grandi set di dati di marcatori (da caricare in meno di 2 secondi).

+2

Invece portare il marker attraverso una chiamata ajax in lotti e disegnarli in un batch – sunil

+0

@sunil puoi elaborare? Quindi carica i lotti per determinate regioni e disegna loro una regione per regione - sarà un disastro totale per l'utente che penso. – Volder

+0

Un altro modo per pensare al tuo schema è che hai tessere vettoriali multi-livello sul server - proprio come le tessere mappa ma queste "tessere" sono posizioni di posizioni di marker/cluster all'interno di un'area. Il front-end richiede tali "tessere" in base al livello e all'estensione dello zoom. Il client può memorizzare nella cache tali "tessere" e quindi potrebbe non esserci la necessità di ricaricare con ogni zoom e pan. – headuck

risposta

7

Il tuo approccio è solido. Se possibile, è necessario precalcolare i cluster e memorizzarli nella cache sul lato server, con la loro strategia di aggiornamento determinata dalla frequenza con cui cambia il set di dati sottostante.

Google maps ha ~ 20 livelli di zoom, a seconda di dove ti trovi sul pianeta.A seconda di come sono raggruppati i tuoi dati, se hai 200.000 indicatori totali e sei disposto a mostrare circa 500 sulla mappa in un dato momento, contando tutte le posizioni dei cluster e i marcatori originali, finirai per archiviare circa 2n = 400.000 posizioni server -side con tutti i tuoi livelli di zoom combinati.

possibili strategie di aggiornamento del cluster:

  • aggiornamento su ogni nuovo marcatore aggiunto. Possibile per un'applicazione leggerissima con poche scritture, se hai bisogno di un alto grado di tempestività dei dati.
  • Update in un programma
  • Kick off un aggiornamento se ((ci sono nuovi marcatori poiché l'ultima passata di clustering & & cache è più vecchio di X) || ci sono più di Y nuovi marcatori dall'ultimo passaggio di clustering

La memorizzazione di questi marcatori in un database che supporta i dati geografici in modo nativo può essere utile. Ciò consente istruzioni simili a SQL che interrogano le posizioni.

Lato client, vorrei prendere in considerazione il recupero di un margine del 50% su entrambi i lati, non del 30%. Google ingrandisce con le potenze di 2. Ciò ti consentirà di visualizzare un livello di zoom completo.

Successivamente, se questa applicazione avrà un uso intenso e l'ottimizzazione è utile, registrerei il lato server quando un client esegue lo zoom. Prova a profilare l'utilizzo, in modo da poter determinare se gli utenti eseguono lo zoom avanti e indietro spesso. Con numeri solidi (come "il 70% degli utenti esegue lo zoom dopo aver recuperato i risultati iniziali e il 20% riduce"), è possibile determinare se vale la pena precaricare il livello successivo di dati ingranditi per gli utenti, al fine di ottenere un'interfaccia utente reattività.