daun daun ha scritto: > Salve, > stavo procedendo ad un confronto tra desktop gis open source Grass, > gvSIG e UDIG (tramite iso9126). Mi è stato detto che però non potevo > assolutamente escludere dal confronto MapServer (che poi non è nemmeno > un desktop gis)in quanto su grosse quantità di dati aveva risultati > molto positivi. > > Quanto è vera questa affermazione? Cosa si intende per gestire grosse > quantità di dati?Non se ne dovrebbe occupare il dbms?
Non so cosa intendessero, ti posso offrire una interpretazione però. Il DBMS può certamente gestire grossi volumi di dati, ma quando li estrai dal DBMS per farne una analisi, visualizzazione o altro è la tua applicazione che li deve gestire. Ora, ci sono applicazioni che sono memory bound e altre che non lo sono, ovvero, alcune applicazioni cercano di tenere in memoria tutti i dati estratti, altre trovano modi per lavorare in "streaming", ovvero leggere i dati dalla sorgente a piccoli pacchetti e portare a termine il lavoro assegnato indipendenemtente da quanti dati hai cercato di usare (ovviamente i tempi ne risentiranno, ma non arrivi ad esaurire la RAM). A modo suo, diverse delle applicazioni che hai citato lavorano in questo modo. MapServer, GeoServer e uDig lavorano in streaming, gli puoi chiedere di disegnare mappe con qualunque volume di dati, la mappa verrà generata (tempo permettendo). Lo stesso dicasi di GRASS, che nella maggior parte dei casi legge un gruppo di righe dal raster, le processa, e poi passa al gruppo successivo. Un esempio di applicazione desktop memory bound è Jump (e derivati), i vettoriali vengono caricati completamente in memoria per semplificare il lavoro e avere migliori prestazioni, ma puoi lavorare soltanto su un set di dati che possa risiedere completamente in RAM. Non so se ho risposto alla tua domanda. Ciao Andrea _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
