Verso un protocollo per la codifica dei dati vettoriali come immagine


16

Questo è il seguito di questa domanda: creare poligoni vettoriali con prestazioni di rendering come GISCloud?

Nella sua risposta, Yagi delinea una logica per codificare le informazioni geografiche in un formato immagine e decodificarle nel browser. Osserva che "Attualmente, per fare questo, devi fare il tuo". Osserva anche che attualmente non esiste uno standard per questo.

Vista la straordinaria performance dimostrata, sembra che la community possa beneficiare di uno standard. Dalla mia comprensione del problema, sembra che potrebbe essere implementato un modo standard di affrontarlo. Chiamalo B-WFS.

La mia domanda, quindi: quale sarebbe un protocollo utile per codificare i dati vettoriali come immagini? C'è qualcosa che lo rende troppo complesso da affrontare utilmente, o è solo un caso di "nessuno lo ha ancora fatto"?


Mi dispiace per la mia ignoranza, forse non ho capito il punto, ma un geotiff con la tavola dei colori ferito non fa il lavoro?
Pablo,

2
Scusate anche per la mia ignoranza;) Non sono sicuro di cosa sia una tabella di colori, ma non la penso così. L'obiettivo non è quello di passare un'immagine con i metadati corrispondenti. Come hai detto, questo è un problema risolto. L'obiettivo è trasmettere dati vettoriali con metadati in un formato più compatto rispetto a UTF-8 leggibile dall'uomo. Dato che JavaScript non è attrezzato per gestire i dati binari, la soluzione alternativa consiste nel codificare i dati in un file binario di immagine e decodificarli utilizzando HTML 5 Canvas per decodificare l'immagine e quindi trasformarla in oggetti vettoriali.
canisrufus,

1
@Pablo Presumendo che l'I / O di rete (piuttosto che analizzare) sia il collo di bottiglia nel trattare con i vettori sul web, avere un modo consolidato per gestire i vettori con codifica binaria dovrebbe facilitare la scrittura di mappe web con prestazioni migliori.
canisrufus,

Interessante, ora capisco ... Sto cominciando a lavorare con le webmap ora e sto ancora imparando le basi. A proposito, una mappa a colori o colormap è una tabella che lega un valore di cella raster a una classe.
Pablo,

1
@monkut Sì, è diverso. :) Rasterizzare un insieme di vettori è solo renderlo. Ecco. Raster! Ciò di cui stavo parlando in questa domanda è diverso. Dovresti leggere la risposta di Ragi nella domanda a cui ho collegato; questo dovrebbe iniziare a spiegare cosa intendo. Se scopri che non è ancora chiaro, mi prenderò del tempo per scrivere una vera risposta.
canisrufus,

Risposte:


5

Si scopre che questa è una soluzione inutile. XHR2, parte degli aggiornamenti a javascript, consentirà l'importazione e l'analisi dei dati binari senza forzare nulla.


4

Non è necessario che sia uno standard separato in quanto tale, poiché la specifica di implementazione WFS 04-094, clausola 9.4 dice:

Altri formati di output (comprese le versioni precedenti di GML, non XML, binari e formati specifici del fornitore) sono anche possibili a condizione che i valori appropriati per l' attributo outputFormat siano pubblicizzati nel documento sulle capacità [clausola 13]. Questa specifica raccomanda di includere una descrizione descrittiva [sic] nel documento sulle capacità per ciascun formato di output elencato lì.

Il modo più semplice per aggiungere il supporto binario è semplicemente GZIP un flusso JSON, in cui la decompressione viene gestita automaticamente dalla maggior parte dei browser. Detto questo, non l'ho provato, ma richiederebbe un lavoro minimo sia sul lato server che sul lato client, supponendo che entrambi supportino già JSON non compresso.


+1 per punto sullo standard. Lo zipping non è la codifica binaria nello stesso senso. Vale sicuramente la pena di interrogarsi sulle implicazioni relative alle prestazioni tra i due approcci, un geojson zippato rispetto alle geometrie codificate in un'immagine.
canisrufus,

Hai ragione, questo riduce il collo di bottiglia della rete, ma aumenta il carico sul client e sul server. Ma la codifica dei dati vettoriali in un'immagine è, IMO, un approccio non ottimale a causa della lunghezza variabile dei dati vettoriali. Sta anche offuscando la natura dei dati vettoriali. Un approccio migliore potrebbe essere quello di avere due flussi di dati paralleli, uno per il vettore e uno per il raster, che potrebbero essere gestiti da server e dispositivi di archiviazione diversi e quindi combinati dal client.
MerseyViking,

Il problema della lunghezza variabile dei dati vettoriali può essere trattato sostanzialmente nello stesso modo in cui le reti gestiscono i pacchetti di invio. Concordo sul fatto che non è ottimale, ma sembra che siamo spinti a farlo dal fatto che JS non si occupa bene del binario. Scriverò e realizzerò qualcosa da solo, dato che ho tempo. Lo metto qui quando vedo qualcosa che funziona ...
Canisrufus,

1
Penso davvero che Ragi lo abbia definito chiaramente nella sua risposta. Sono d'accordo che non l'ho fatto. :) Può darsi che l'ipotesi che un formato binario possa essere un formato di trasferimento dei dati complessivamente più veloce sia errata. La differenza potrebbe essere semplicemente trascurabile. Ho detto che "le implicazioni sulle prestazioni ... vale la pena esplorare". Ovviamente non posso semplicemente definire un formato binario e quindi dichiarare la vittoria. Vedremo!
canisrufus,

1
@MerseyViking Senza dover ripetere di nuovo la mia risposta, lasciatemi mettere in prospettiva in termini di cicli della CPU (dal momento che la tua ipotesi riguarda l'ottimizzazione prematura). Accesso alla cache L1 = 1 ciclo CPU, L2 = 14 cicli, RAM ~ 250 cicli, Disco = 41.000.000, Rete (dipende dalla larghezza di banda, quindi sii gentile) = 240.000.000. Gli I / O, sia su disco che su rete (nel nostro caso), gli ordini di grandezza sono più lenti. In che modo spostare il carico dall'ultima parte dello spettro nel primo "prematuro" di qualsiasi scala?
Ragi Yaser Burhum,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.