consiglio HARDWARE per sistema webgis

[Andrea Peri]

Il 25/10/2012 21:34, Andrea Aime ha scritto:
> Ci sono anche soluzioni intermedie che GWC al momento non supporta,
> ma per le quali stiamo cercando fondi: create le tile cache separate,
> ma fare poi in modo che GWC possa rispondere a una richiesta
> di N layer prendendo dalle varie cache e fondendo il risultato in una sola
> tile: è un compromesso che aumenta la flessibilità a discapito di un maggiore
> uso di CPU (più lento di una cache statica, ma pur sempre più veloce dell'uso
> di un WMS diretto).

Non risco a capire come possa essere piu' veloce.

Se a un server WMS si chiede di spedire una mappa prodotta a partire da un set di raster che sono una OFC.
Lui apre i files su disco, dotati di tiles, seziona le parti che servono prepara l'immagine e la spedisce.


Te stai dipengendo uno scenario in cui sostanzialmente il GWC diventa un server WMS.

perche' si apre dei files su disco , seleziona quelli che servono e li spedisce.

Ipotizzando che nel piatto non si mette la capacita' programmatoria di chi scrive il codice.

Funzionalmente il processo è lo stesso.

Anche quando ci sono piu strati sovrapposti (sempre di raster) non riesco a intravedere funzionalmente una maggiore velocita' del sistema GWC rispetto al Server WMS stesso.

Proprio perche' alla fine dei salmi entrambi fanno le stesse cose.

Su questo aspetto mi piacerebbe proprio capire come funzionalmente un sistema GWC riesce a superare un server WMS. Ovviamente parlo di un Server WMS in termini generali, non uno in particolare. :)


E poi non va dimenticato che si deve anche fare i conti con i diversi client WMS .
Alcuni di essi non ammettono proprio di spedire una richiesta con piu' strati, ma la scompongono in tante richieste distinte, e poi sfruttnao la trasparenza per proporre il risultato finale.


In merito ai vettoriali.
Che essi siano funzionalmente piu' lenti dei raster come tempo di produzione , non ci piove, per essi pesa quantomeno il tempo di rasterizzazione che nel caso dei raster non è rpesente.

Pero il vettoriale offre un maggior livello qualitativo rispetto al raster che come si sa' "sgrana".
Nel momento in cui si decide di usare un sistema di cache, si sta dicendo che al vettoriale si sostituisce una sua rappresentazione pre-rasterizzata.

Questo significa che la qualit'a è prestabilita, e sigifica altresi che si perde il livello qualitativo originale.
Quesot non sempre è accettabile.

In genere se i sistemi sono per usi dedicati si puo' stabilire il livello qualitativo del servizio e a partire da esso stabilire cosa si vuole offrire e con che mezzi e risorse.

Se invece non si punta a un uso dedicato, allora o si f'a un sistema a scarsa qualita' e quijdi si puo' anche pre-rasterizzare i vettoriali e velocizzare il tutto, ma se si vuole accontentare 
le varie tipologie di utenze occorre non perdere di vista il discorso qualitativo.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Andrea Aime]

2012/10/26 Andrea Peri <[hidden email]>:

> Il 25/10/2012 21:34, Andrea Aime ha scritto:
>> Ci sono anche soluzioni intermedie che GWC al momento non supporta,
>> ma per le quali stiamo cercando fondi: create le tile cache separate,
>> ma fare poi in modo che GWC possa rispondere a una richiesta
>> di N layer prendendo dalle varie cache e fondendo il risultato in una sola
>> tile: è un compromesso che aumenta la flessibilità a discapito di un
>> maggiore
>> uso di CPU (più lento di una cache statica, ma pur sempre più veloce
>> dell'uso
>> di un WMS diretto).
>
> Non risco a capire come possa essere piu' veloce.
>
> Se a un server WMS si chiede di spedire una mappa prodotta a partire da un
> set di raster che sono una OFC.
> Lui apre i files su disco, dotati di tiles, seziona le parti che servono
> prepara l'immagine e la spedisce.

Infatti io parlavo di tiles prodotte a partire di dati vettoriali, con i raster
la cosa non ha pressochè alcun senso.

A proposito, il vettoriale cachato il tiles non "sgrana" a meno che non
venga riscalato (cosa che si fa quando si vuole ottenere un WMS
generico da una tile cache).
Qui si parla di avere una tile cache più flessibile, ma
pur sempre una tile cache, in cui le richieste devono collimare con
le griglie di caching, ma senza l'obbligo di cachare separatamente
ogni possibile combinazione di layer sul server, ne imporre al client
di caricarsi migliaia di tiles per produrre la mappa finale (cosa che
di norma manda in crash o notevole rallentamento i browser).

Ciao
Andrea

--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: [phone]
fax: [phone]
mob: [phone]

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Alessandro Radaelli]

...il mio interesse era infatti per il caso di uso "Mappa complessa da
dati vettoriali ed uso su sistema webgis" che quindi può imporre griglia
allineamento e in molti casi scale predefinite. Sono casi molto comuni,
come per esempio la pubblicazione WEBGIS di un piano regolatore o altri
strumenti di pianificazione.

Il 26/10/2012 14:14, Andrea Aime ha scritto:

> 2012/10/26 Andrea Peri <[hidden email]>:
>> Il 25/10/2012 21:34, Andrea Aime ha scritto:
>>> Ci sono anche soluzioni intermedie che GWC al momento non supporta,
>>> ma per le quali stiamo cercando fondi: create le tile cache separate,
>>> ma fare poi in modo che GWC possa rispondere a una richiesta
>>> di N layer prendendo dalle varie cache e fondendo il risultato in una sola
>>> tile: è un compromesso che aumenta la flessibilità a discapito di un
>>> maggiore
>>> uso di CPU (più lento di una cache statica, ma pur sempre più veloce
>>> dell'uso
>>> di un WMS diretto).
>> Non risco a capire come possa essere piu' veloce.
>>
>> Se a un server WMS si chiede di spedire una mappa prodotta a partire da un
>> set di raster che sono una OFC.
>> Lui apre i files su disco, dotati di tiles, seziona le parti che servono
>> prepara l'immagine e la spedisce.
> Infatti io parlavo di tiles prodotte a partire di dati vettoriali, con i raster
> la cosa non ha pressochè alcun senso.
>
> A proposito, il vettoriale cachato il tiles non "sgrana" a meno che non
> venga riscalato (cosa che si fa quando si vuole ottenere un WMS
> generico da una tile cache).
> Qui si parla di avere una tile cache più flessibile, ma
> pur sempre una tile cache, in cui le richieste devono collimare con
> le griglie di caching, ma senza l'obbligo di cachare separatamente
> ogni possibile combinazione di layer sul server, ne imporre al client
> di caricarsi migliaia di tiles per produrre la mappa finale (cosa che
> di norma manda in crash o notevole rallentamento i browser).
>
> Ciao
> Andrea
>

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Andrea Peri]

>Infatti io parlavo di tiles prodotte a partire di dati vettoriali, con i raster
>la cosa non ha pressochè alcun senso.

ok, avevo capito male allora.

>A proposito, il vettoriale cachato il tiles non "sgrana" a meno che non
>venga riscalato (cosa che si fa quando si vuole ottenere un WMS
>generico da una tile cache).

Nel caso del Tile mi torna. Le scale sono collimanti e quindi non scalando si mantiene la qualita'.

>Qui si parla di avere una tile cache più flessibile, ma
>pur sempre una tile cache, in cui le richieste devono collimare con
>le griglie di caching, ma senza l'obbligo di cachare separatamente
>ogni possibile combinazione di layer sul server, ne imporre al client
>di caricarsi migliaia di tiles per produrre la mappa finale (cosa che
>di norma manda in crash o notevole rallentamento i browser).

Quesot mi fa' venire in mente un altro possibile impiego di questi sistemi di cache:

Impiegare il GWC come sorgente dati raster per il server wms.
Uniformando cosi' tutti i dataset raster in una sola sorgente dati.

Il server wms anziche' accedere a dati raster in formato originale, li accede o meglio li fa' accedere al GWC e si f'a mandare il risultato, poi il server wms de-tilizza le mappe ricevute dal GWC (unica operazione che lui dovrebbe compiere) e poi infarcisce il risultato con gli strati vettoriali e etichette varie.
Un vantaggio potrebbe essere riuscire a tenere piu' facilmente allineato il server wms con un eventuale altro repository piu' lento (perche' piu' distante)
Magari usando un altro server wms asservito al colloquio esclusivo con il GWC.
Ho sempre avuto l'impressione che una tale impostazione potrebbe velocizzare il server wms.
Tra l'altro in quesot modo si riesce a garantire una sorta di copertura completa del suolo per la parte raster.
Ovvero il GWC potrebbe spedire tiles basati su dataset anche differenti, ma con l'obiettivo di spedire sempre una mappa completa e non parziale.
Un po' come il 50K IGM.
Cosa questa che a un server wms non riesce proprio bene o comunque impiegherebbe del tempo a fare, perche' elabora gli strati indipendentemente l'uno dall'altro e poi mette tutto insieme.

Saluti,

Il giorno 26 ottobre 2012 14:14, Andrea Aime <[hidden email]> ha scritto:

2012/10/26 Andrea Peri <[hidden email]>:

> Il 25/10/2012 21:34, Andrea Aime ha scritto:
>> Ci sono anche soluzioni intermedie che GWC al momento non supporta,
>> ma per le quali stiamo cercando fondi: create le tile cache separate,
>> ma fare poi in modo che GWC possa rispondere a una richiesta
>> di N layer prendendo dalle varie cache e fondendo il risultato in una sola
>> tile: è un compromesso che aumenta la flessibilità a discapito di un
>> maggiore
>> uso di CPU (più lento di una cache statica, ma pur sempre più veloce
>> dell'uso
>> di un WMS diretto).
>
> Non risco a capire come possa essere piu' veloce.
>
> Se a un server WMS si chiede di spedire una mappa prodotta a partire da un
> set di raster che sono una OFC.
> Lui apre i files su disco, dotati di tiles, seziona le parti che servono
> prepara l'immagine e la spedisce.

Infatti io parlavo di tiles prodotte a partire di dati vettoriali, con i raster
la cosa non ha pressochè alcun senso.

A proposito, il vettoriale cachato il tiles non "sgrana" a meno che non
venga riscalato (cosa che si fa quando si vuole ottenere un WMS
generico da una tile cache).
Qui si parla di avere una tile cache più flessibile, ma
pur sempre una tile cache, in cui le richieste devono collimare con
le griglie di caching, ma senza l'obbligo di cachare separatamente
ogni possibile combinazione di layer sul server, ne imporre al client
di caricarsi migliaia di tiles per produrre la mappa finale (cosa che
di norma manda in crash o notevole rallentamento i browser).

Ciao
Andrea

--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: <a href="tel:%2B39%200584%20962313" value="[phone]">[phone]
fax: <a href="tel:%2B39%200584%201660272" value="[phone]">[phone]
mob: <a href="tel:%2B39%20%20339%208844549" value="[phone]">[phone]

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[giohappy]

Il server wms anziche' accedere a dati raster in formato originale, li accede o meglio li fa' accedere al GWC e si f'a mandare il risultato, poi il server wms de-tilizza le mappe ricevute dal GWC (unica operazione che lui dovrebbe compiere) e poi infarcisce il risultato con gli strati vettoriali e etichette varie.

In pratica esporre un WMST come WMS, no? Io MapProxy lo uso anche per questo...

giovanni

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Andrea Peri]

Parli del cascading ?

Non saprei.
L'accesso via rete in http è piu' lento di un accesso su filesystem.
Pero' si avvantaggerebbe di non dover aprire tutti gli handles.

Puo' darsi che alla fine il paradigma sia quello del cascading. Io pero' immaginavo un accesso esclusivo del server wms al GWC e quindi non necessariamente via rete in http, ma magari anche con protocolli piu' vispi.
Caso mai l' http permetterebbe di tenerlo su una macchina virtuale distinta.
Il bello delle macchine virtuali è che è virtuale anche la rete e quindi  il colloquio tra macchine virtuali è piu' veloce che tra macchine fisiche connesse da un cavo ethernet.

Il giorno 26 ottobre 2012 15:05, G. Allegri <[hidden email]> ha scritto:

Il server wms anziche' accedere a dati raster in formato originale, li accede o meglio li fa' accedere al GWC e si f'a mandare il risultato, poi il server wms de-tilizza le mappe ricevute dal GWC (unica operazione che lui dovrebbe compiere) e poi infarcisce il risultato con gli strati vettoriali e etichette varie.

In pratica esporre un WMST come WMS, no? Io MapProxy lo uso anche per questo...

giovanni

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------


_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Andrea Aime]

2012/10/26 G. Allegri <[hidden email]>:

>
>> Il server wms anziche' accedere a dati raster in formato originale, li
>> accede o meglio li fa' accedere al GWC e si f'a mandare il risultato, poi il
>> server wms de-tilizza le mappe ricevute dal GWC (unica operazione che lui
>> dovrebbe compiere) e poi infarcisce il risultato con gli strati vettoriali e
>> etichette varie.
>
>
> In pratica esporre un WMST come WMS, no? Io MapProxy lo uso anche per
> questo...

Si, sia GeoWebCache che MapProxy sono in grado di generate risposte WMS
libere a partire dalla tile cache.

Non sono mai stato soddisfatto dalla qualità del risultato, se
l'origine è vettoriale
il risultato è di qualità non accettabile, se è raster mi pare che con
dati di origine
ben configurati (inner tiling, overview ecc) non si vada poi molto
distante dalle
prestazioni di un WMS, specialmente se le richieste sono ampie (il che richiede
di leggere molte tile da disco)

Ciao
Andrea

--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: [phone]
fax: [phone]
mob: [phone]

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012

[Andrea Aime]

2012/10/26 Andrea Peri <[hidden email]>:

> Quesot mi fa' venire in mente un altro possibile impiego di questi sistemi
> di cache:
>
> Impiegare il GWC come sorgente dati raster per il server wms.
> Uniformando cosi' tutti i dataset raster in una sola sorgente dati.
>
> Il server wms anziche' accedere a dati raster in formato originale, li
> accede o meglio li fa' accedere al GWC e si f'a mandare il risultato, poi il
> server wms de-tilizza le mappe ricevute dal GWC (unica operazione che lui
> dovrebbe compiere) e poi infarcisce il risultato con gli strati vettoriali e
> etichette varie.
> Un vantaggio potrebbe essere riuscire a tenere piu' facilmente allineato il
> server wms con un eventuale altro repository piu' lento (perche' piu'
> distante)
> Magari usando un altro server wms asservito al colloquio esclusivo con il
> GWC.
> Ho sempre avuto l'impressione che una tale impostazione potrebbe velocizzare
> il server wms.
> Tra l'altro in quesot modo si riesce a garantire una sorta di copertura
> completa del suolo per la parte raster.
> Ovvero il GWC potrebbe spedire tiles basati su dataset anche differenti, ma
> con l'obiettivo di spedire sempre una mappa completa e non parziale.
> Un po' come il 50K IGM.
> Cosa questa che a un server wms non riesce proprio bene o comunque
> impiegherebbe del tempo a fare, perche' elabora gli strati indipendentemente
> l'uno dall'altro e poi mette tutto insieme.

Praticamente l'idea è di usare la cache di GWC come piramide di immagini.
Abbiamo giocato parecchio con le piramidi di immagini, e per ottenere
buone prestazioni bisogna stare alla larga dai "tanti piccoli file"
che compongono
la tipica tile cache.

Aprire molti file è dispendioso, e sotto carico si arriva facilmente al problema
di "too many open files".
Le piramidi di immagini sono utili, ma meglio se sono composte da file
più sostazioni,
2048x2048, con inner tiling

Ciao
Andrea


--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: [phone]
fax: [phone]
mob: [phone]

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
605 iscritti al 10.7.2012