Creazione di poligoni vettoriali con prestazioni di rendering come GISCloud?

Ho cercato una soluzione solida che mi permettesse di creare una mappa web e sovrapporre poligoni vettoriali senza impiegare un'eternità a caricare tali dati con l'obiettivo di consentirmi di visualizzare ogni poligono di un colore diverso su un evento hover.

Per quanto ne so, ci sono 3 opzioni specifiche per raggiungere questo obiettivo tramite canvas, SVG, Flash.

Flash sembra che sarebbe la soluzione migliore se funzionasse su Apple iPhone / iPad in quanto sembra fornire il rendering più veloce e un display più pulito. La tela sembra essere la seconda scelta migliore, ma richiede MOLTO tempo se sono presenti centinaia di poligoni visualizzati su una mappa mentre SVG impiega ancora più tempo per il rendering.

Ho quasi perso la speranza di trovare una soluzione a questo problema, ma oggi mi sono imbattuto in una società chiamata GISCloud http://www.giscloud.com (attualmente in versione beta con iscrizione gratuita).

Questa società è riuscita SOMEHOW a trovare un modo fantastico per rendere centinaia di vettori su una mappa in tempo quasi reale. Sono rimasto sorpreso dal loro approccio e la mia domanda alla comunità riguarda come possiamo replicare il loro approccio per l'uso con tecnologie esistenti come volantini, openlayer, cera ...

Dai un'occhiata a te stesso visualizzando questa fantastica demo: http://www.giscloud.com/map/284/africa

Assicurati di passare con il mouse su uno qualsiasi dei poligoni sulla pagina e prova i controlli di zoom per vedere che questi poligoni sono effettivamente vettori.

Quello che ho notato osservando le richieste con firebug è che la mappa richiede specifici file json. Sembra che a seconda del livello / area di zoom ci siano più file json richiesti.

Vorrei anche menzionare qui che una volta che giscloud carica i dati sulla pagina passando sopra un vettore, cambia immediatamente il colore senza creare una nuova richiesta.

ESEMPI:

• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/3/3.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/5/3.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/4/4.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/3/4.json
• http://cft1.giscloud.com/t/1316509973/map284/layer1156/3/5/4.json

Suppongo che la struttura dell'URL segua la logica standard del servizio di piastrellatura (ad esempio la terza all'ultima cartella è il livello di zoom ...).

In ogni caso ho analizzato i dati effettivi di questi file json e sembra che la logica che stanno usando segua un tipo di logica con cui creano i loro vettori basandosi solo su questi valori di dati:

• larghezza / altezza: definiscono la larghezza e l'altezza dei dati forniti in ogni richiesta json
• pixel: qui definiscono i valori dei pixel che presumo siano in qualche modo correlati ad alcune coordinate generali di pixel x / y per livelli di punti generalizzati? Immagino che in qualche modo abbiano un modo di semplificare automaticamente la regione in base al livello di zoom. Sto assumendo da loro usando le coordinate dei pixel. Immagino che stiano riducendo drasticamente la dimensione dei dati che devono essere caricati rispetto ai dati lat / long.
• stili: qui definiscono due valori css RGB. "F" che rappresenta il colore del file poligonale e "S" che rappresenta il colore del bordo poligonale.
• geom: qui è dove immagino che in qualche modo stiano definendo in modo specifico ciascun poligono all'interno del riquadro che viene caricato dove tali dati vengono definiti in base alla finestra del contenitore della mappa. Ciò che è anche interessante è che ogni voce ha un valore "S" che presumo sia usato come un attributo facoltativo o valore di collegamento funzione e alla fine di ogni voce qui c'è un'area che sembra definire un ID specifico per vettore insieme a l'ID layer che suppongo sia utilizzato per unire in qualche modo i dati di ogni richiesta di riquadri json chiamata.

Suppongo anche che abbiano in qualche modo trovato un modo per determinare e suddividere automaticamente i dati che devono essere caricati per ogni riquadro a seconda della dimensione dei dati che dovrebbero essere caricati per il riquadro richiesto.

Ecco una ripartizione estratta di una di queste richieste:

{"width":256,"height":256,"tile":
{"pixels":
[0,6461,-1,0,5,148,0,509,-1,10715,-1,1,-1,251,-1,1,-1,1,-1,251,-2,3,-1,255,-1,249,-2,5,-2,247,-1,509,-3,251,-1,2,-2,253,-2,252,-2,254,-1,255,-1,254,-1,255,-1,1276,-2,13,-1,233,-1,2,-1,253,-1,1,-1,255,-1,247,-1,1306,-1,1533,-1,1269,-1,1276,-1,2303,-1]},

"styles":
[{"f":"rgb(99,230,101)","s":"rgb(5,148,0)","lw":"0"}],

"geom":
[
{"s":0,"p":[4,143,5,144,3,146,1,146,2,143,4,143],"c":"layer1156_5098"},
{"s":0,"p":[-2,143,0,140,2,141,2,144,1,146,-2,144,-2,143],"c":"layer1156_5067"},
{"s":0,"p":[7,143,5,144,4,143,2,143,2,141,5,138,6,139,5,141,7,143],"c":"layer1156_5051"},
{"s":0,"p":[10,141,11,137,12,137,14,137,12,142,9,143,9,142,10,141],"c":"layer1156_5041"},
{"s":0,"p":[1,136,0,140,-2,143,-2,136,1,136],"c":"layer1156_5038"},
{"s":0,"p":[8,143,5,141,5,137,8,136,10,137,10,141,8,143],"c":"layer1156_5033"},
{"s":0,"p":[5,137,2,141,0,140,1,136,1,136,2,135,3,136,5,137],"c":"layer1156_5028"},
{"s":0,"p":[10,134,12,136,11,138,8,135,10,134],"c":"layer1156_5020"},
{"s":0,"p":[-2,133,0,136,-2,136,-2,133],"c":"layer1156_5005"},
{...}
...
]
}

Come possiamo replicare lo stesso (o simile) tipo di velocità usando i postgis (che anch'io sono quelli che sembrano usare)?

Ho visto questa tecnica usata in passato. Mi è stato spiegato da Zain Memon (di Trulia) che mi ha aiutato a dare un contributo quando Michal Migurski stava creando TileStache. Zain lo ha spiegato spiegando la sua demo di Trulia che utilizza questa tecnica in uno dei nostri precedenti meeting di GeoMeetup SF qualche tempo fa . In effetti, se sei a San Francisco la prossima settimana (questo è il mio tentativo zoppo di una spina, lo toccherà , quindi sentiti libero di presentarti :)

OK, ora alla spiegazione.

Innanzitutto, stai guardando leggermente nel posto sbagliato quando guardi i file json sopra.

Lasciami spiegare (il più breve possibile), perché.

Le tessere vengono passate proprio come le normali tessere renderizzate, non è un grosso problema lì, sappiamo come farlo e quindi non ho bisogno di spiegarlo.

Se lo ispezioni in Firebug, vedrai che otterrai anche un sacco di immagini che sembrano vuote, come questa .

Perché è vuoto? Non è. I pixel contengono dati - semplicemente non dati di immagini visibili tradizionali. Stanno usando una tecnica molto intelligente per passare i dati codificati nei pixel stessi.

Quello che è successo negli ultimi dieci anni è che le persone hanno scambiato dati di leggibilità e portabilità dei formati a spese dell'efficienza di archiviazione.

Prendi questo esempio di dati di esempio xml:

<data>

  <feature>
    <point>
      <x> -32.1231 </x>
      <y> 10.31243 </y>
    </point>
    <type> 
      sold
    </type>
   </feature>

  <feature>
    <point>
      <x> -33.1231 </x>
      <y> 11.31243 </y>
    </point>
    <type> 
      available
    </type>
   </feature>

</data>

OK, quanti morsi trasferiscono questo? A condizione che siamo utf8 (1 byte per carattere quando si tratta di questo contenuto). Bene, abbiamo circa 176 caratteri (senza contare le tabulazioni o gli spazi) che rende questi 176 byte (questo è ottimista per vari motivi che ometterò per motivi di semplicità). Intendiamoci, questo è per 2 punti!

Tuttavia, qualche asino intelligente che non capisce di cosa sta parlando, da qualche parte, affermerà che "json ti dà una maggiore compressione".

Bene, mettiamo la stessa assurdità xml di json:

{ "data": [
            "feature" : { "x" : -32.1231, "y" : 10.31243 , "type": "sold" },
            "feature" : { "x" : -33.1231, "y" :11.31243, "type": "avail" },
          ]
}

Quanti byte qui? Pronuncia ~ 115 caratteri. Ho anche tradito un po 'e l'ho ridotto.

Supponiamo che la mia area copra 256x256 pixel e che io sia a un livello di zoom così elevato che ogni funzione viene visualizzata come un pixel e che ho così tante funzioni che è piena. Di quanti dati ho bisogno per mostrare che 65.536 funzioni?

54 caratteri (o byte utf - e sto anche ignorando alcune altre cose) per voce "caratteristica" moltiplicata per 65.536 = 3.538.944 o circa 3,3 MB

Penso che tu abbia la foto.

Ma è così che trasportiamo i dati in un'architettura orientata ai servizi. Merda gonfia leggibile.

E se volessi trasportare tutto in uno schema binario che mi sono inventato? Dillo invece, ho codificato tali informazioni nell'immagine a banda singola (cioè in bianco e nero). E ho deciso che 0 significa venduto, 1 significa disponibile e 2 significa che non lo so. Diamine, in 1 byte, ho 256 opzioni che posso usare - e ne sto usando solo 2 o tre per questo esempio.

Qual è il costo di archiviazione di quello? 256x256x 1 (solo una banda). 65.536 byte o 0,06 MB. E questo non prende nemmeno in considerazione altre tecniche di compressione che ottengo gratuitamente da diversi decenni di ricerca nella compressione delle immagini.

A questo punto, dovresti chiederti perché le persone non inviano semplicemente i dati codificati in formato binario anziché serializzare su json? Bene, per prima cosa, javascript fa schifo alla grande per il trasporto di dati binari , ecco perché le persone non lo hanno fatto storicamente.

Un fantastico lavoro in giro è stato usato da alcune persone quando sono uscite le nuove funzionalità di HTML5, in particolare canvas . Cos'è questo fantastico work-around? Si scopre che è possibile inviare dati tramite il filo codificato su quella che sembra essere un'immagine, quindi è possibile inserire quell'immagine in una tela HTML5, che consente di manipolare direttamente i pixel ! Ora hai un modo per catturare quei dati, decodificarli sul lato client e generare gli oggetti json nel client.

Fermati un attimo e pensaci.

Hai un modo per codificare un'enorme quantità di dati georeferenziati significativi in ​​un formato altamente compresso, ordini di grandezza più piccoli di qualsiasi altra cosa fatta tradizionalmente nelle applicazioni web e manipolarli in javascript.

Il canvas HTML non ha nemmeno bisogno di essere usato per disegnare, è usato solo come meccanismo di decodifica binaria!

Ecco di cosa parlano tutte quelle immagini che vedi in Firebug. Un'immagine, con i dati codificati per ogni singolo riquadro che viene scaricato. Sono super piccoli, ma hanno dati significativi.

Quindi, come si codificano questi nel lato server? Bene, devi generalizzare i dati sul lato server e creare un riquadro significativo per ogni livello di zoom che ha i dati codificati. Al momento, per farlo, devi creare il tuo - una soluzione open source pronta all'uso non esiste, ma hai tutti gli strumenti necessari per farlo disponibile. PostGIS eseguirà la generalizzazione tramite GEOS, TileCache può essere utilizzato per memorizzare nella cache e aiutarti a innescare la generazione dei riquadri. Sul lato client, dovrai usare HTML5 Canvas per passare le speciali "tessere false" e quindi puoi utilizzare OpenLayers per creare veri e propri oggetti javascript sul lato client che rappresentano i vettori con effetti di passaggio del mouse.

Se devi codificare più dati, ricorda che puoi sempre generare immagini RGBA per pixel (che ti danno 4 byte per pixel o 4.294.967.296 numeri che puoi rappresentare per pixel ). Posso pensare a diversi modi per usarlo :)

Aggiornamento : risposta alla domanda QGIS di seguito.

QGIS come la maggior parte degli altri Desktop GIS , non ha un set fisso di livelli di zoom. Hanno la flessibilità di zoomare su qualsiasi scala e renderizzare. Possono mostrare dati da WMS o da fonti basate su tessere? Certo che possono, ma il più delle volte sono davvero stupidi al riguardo: ingrandisci in misura diversa, calcola il riquadro di delimitazione, calcola la piastrella richiesta, afferrale, mostrale. La maggior parte delle volte ignorano altre cose, come le cache delle intestazioni http che lo farebbero in modo da non dover recuperare. A volte implementano un semplice meccanismo cache (memorizza il riquadro, se lo chiedi, controlla il riquadro, non chiederlo). Ma questo non è abbastanza.

Con questa tecnica le piastrelle e i vettori devono essere recuperati ad ogni livello di zoom . Perché? Perché i vettori sono stati generalizzati per adattarsi ai livelli di zoom.

Per quanto riguarda il trucco di mettere le tessere su una tela HTML5 in modo da poter accedere ai buffer, l'intera cosa non è necessaria. QGIS ti consente di scrivere codice in Python e C ++, entrambi i linguaggi offrono un eccellente supporto per la gestione dei buffer binari, quindi questa soluzione è davvero irrilevante per questa piattaforma.

* AGGIORNAMENTO 2 **:

C'è stata una domanda su come creare le tessere vettoriali generalizzate in primo luogo (baby step 1 prima di poter serializzare i risultati in immagini). Forse non ho chiarito abbastanza. Tilestache ti consentirà di creare "riquadri vettoriali" efficaci dei tuoi dati a tutti i livelli di zoom (ha anche un'opzione che ti consente di tagliare o non tagliare i dati quando passa il bordo del riquadro). Questo si occupa di separare i vettori in tessere a vari livelli di zoom. Sceglierei l'opzione "non tagliare" (ma selezionerà una tessera arbitraria in cui copre più area). Quindi puoi alimentare ogni vettore tramite l'opzione di generalizzazione GEOS con un numero elevato, infatti, lo vuoi abbastanza grande da far crollare polilinee e poligoni su se stessi, perché se lo fanno, puoi rimuoverli dal livello di zoom poiché per quello stadio sono irrilevante. Tilestache ti consente persino di scrivere semplici provider di dati pythonic in cui puoi inserire questa logica. A quel punto, puoi scegliere di servirli come file json (come fanno con alcuni dei campioni di mappe africane) o come geometrie serializzate nei png, come fanno in altri campioni (o quello di Trulia) che ho dato sopra.

Diretto dallo sviluppatore Dino Ravnic in un recente post sulla mailing list :

Non è un grande segreto come l'abbiamo fatto, quindi sarei felice di condividerlo con te ... la chiave sta in due cose:

1. rimuovendo da una piastrella tutti i vettori che sono troppo piccoli per essere visibili, cioè la loro area quando calcolati in pixel è inferiore a 1px. quindi lasciamo cadere un tale vettore e al posto di un pixel quindi c'è la proprietà "pixels" nel nostro riquadro json

2. i vettori che saranno effettivamente visibili vengono generalizzati e quindi scritti in una tessera con le loro coordinate in pixel

Da parte del cliente, rendiamo su tela quei pixel statici e quei vettori visibili. Oltre ai vettori, abbiamo implementato la gestione degli eventi del mouse per ottenere l'hovering, ovvero l'interattività. e basta.

Il nostro motore di mappe back-end fa tutto il lavoro pesante perché non usiamo alcun precaching e tutte le piastrelle vengono generate al volo. è molto importante per noi avere una mappa che può essere aggiornata rapidamente.

Quindi sembra che il lato client sia la parte facile. È impressionante che i dati vengano visualizzati senza alcuna memorizzazione nella cache.

Cita anche un servizio di hosting che potrebbe interessarti. È possibile valutare il costo del tentativo di ricreare questo con il costo dell'utilizzo di un servizio pronto.

Come ho descritto nell'elenco OSGeo, la chiave sta nel fornire dati come riquadri JSON vettoriali con pixel per geometria subpixel e geometria generalizzata per quelle funzionalità che saranno effettivamente visibili a un certo livello. Le prestazioni sono eccezionali perché questa tecnica elimina tutte le informazioni vettoriali non necessarie e lascia solo quei vettori che avranno effettivamente un impatto visivo sulla mappa. I pixel sono lì per riempire gli spazi vuoti ed essere posizionati al posto di quei vettori subpixel. Questo è quanto riguarda il formato delle tessere.

Sul lato backend c'è il vero sollevamento di carichi pesanti. Non stiamo usando TileStache o qualsiasi altro motore di mappatura poiché abbiamo scritto il nostro che può, con una serie di ottimizzazioni, produrre tale grafica vettoriale in tempo reale.

Per prima cosa abbiamo iniziato a fornire riquadri di mappe come file SWF e ultimamente abbiamo appena abilitato l'output su JSON in modo da poter utilizzare HTML5 Canvas per il rendering della grafica. Di seguito puoi trovare un benchmark che confronta questo tipo di tecnologia vettoriale con la tecnologia raster (mapnik). Per un confronto equo, cercare solo risultati in modalità CGI.

http://www.giscloud.com/blog/realtime-map-tile-rendering-benchmark-rasters-vs-vectors/

Stiamo programmando di fornire questa tecnologia come servizio di hosting di tessere mappa. L'idea è quella di ospitare i tuoi dati geografici sul cloud e tramite HTML5 consegnarli in qualsiasi client di mappe ad alta velocità, senza la necessità di preconfigurare i riquadri. Se sei interessato a partecipare a questa beta, non esitare a contattarci qui: http://www.giscloud.com/contact/

Sembra che una domanda molto simile sia stata recentemente posta sul forum OSGeo Open Layers , con gli sviluppatori di GIS Cloud che descrivono il loro approccio, che è un interessante mix di geometrie GeoJSON e pixel statici. Generano in realtà tutte le tessere vettoriali al volo invece di utilizzare una cache preconfigurata di file GeoJSON.

Esri ha implementato un approccio simile, usando ArcGIS Server e Feature Layers , che possono generalizzare le geometrie al volo e inviarle via cavo come JSON.

Per un metodo semplice che puoi effettivamente implementare ora, puoi creare tessere vettoriali con Tilestache (che ha il supporto PostGIS ) e consumarle in Polymaps . Polymaps utilizza SVG, ma le prestazioni sono abbastanza buone e le regole CSS regolano lo stile degli elementi della mappa, quindi il rendering delle caratteristiche dipende totalmente da te. Ecco un post sul blog che analizza qualcosa di simile a quello che stai chiedendo.

Ho giocato con OpenLayers usando Canvas e ho ottenuto risultati ragionevoli.

Come menzionato nelle altre risposte: per fornire e mostrare i vettori al volo, devono essere generalizzati per ogni livello di zoom e ogni set di dati. Inoltre, puoi utilizzare la codifica della polilinea di Google per ridurre considerevolmente le dimensioni.

Ho usato un semplice meccanismo di consegna. Ogni geometria era una funzione JavaScript all'interno di una risposta HTTP JavaScript. non avanzato come la consegna di vettori basata su tessere, ma semplice e open source!

Non ho provato Google Maps v3 con Canvas, ma ho visto un paio di demo del New York Times che mi hanno colpito.

Non so esattamente quale soluzione viene utilizzata da questa azienda (potresti forse chiederle direttamente) ma ho un'idea.

La soluzione chiave per migliorare il trasferimento in rete e la velocità di rendering dei dati vettoriali è generalizzarli in base al livello di zoom: il trasferimento e il rendering a un livello di zoom elevato migliaia di oggetti progettati per un livello di zoom molto più basso spesso richiedono molto tempo (e anche inutile perché il display finale di solito non è leggibile - vedi ad esempio questa immagine ). Per implementarlo, il database del tuo server Postgis deve essere multi-scala : per ogni livello di zoom, dovrebbe esserci una rappresentazione dell'oggetto adatta a questo livello di zoom. Queste diverse rappresentazioni possono essere calcolate automaticamente usando tecniche di generalizzazione. Inoltre, i dati vettoriali inviati dal server al client non dovrebbero dipendere solo dall'estensione spaziale, ma anche dal livello di zoom: il server invia i dati adeguati a seconda del livello di zoom. Questo è l'approccio difeso in questo eccellente documento :-)

Esiste un documento interessante, una demo e un codice sorgente di un software sviluppato da Stanford Visualization Group che utilizza un datacube per ogni riquadro per visualizzare ed esplorare un ampio set di dati geografici. Può essere utilizzato solo per l'insieme di dati punto ma può essere un modo interessante.

http://vis.stanford.edu/papers/immens

Vizzuality con la loro piattaforma CartoDB e la libreria chiamata Torque stanno anche sperimentando in qualche modo come disegnare un elevato volume di dati.

http://cartodb.github.io/torque/
https://github.com/CartoDB/torque/tree/new_torque