Prodevelop, una delle aziende che porta avanti lo sviluppo di gvSIG
(per esempio tutta la parte di gestione e trasformazione dei/tra
sistemi di riferimento è stata sviluppata da loro) presenterà al
FOSS4G 2007 un prototipo di gvSIG che possa girare sotto palmare,
ovviamente la licenza rimane GPL.
Maggiori informazioni qui: http://www.foss4g2007.org/presentations/view.php/124
Questa è una grandissima notizia!!! Speriamo proceda bene il progetto. E’ un sacco che vengo interrogato su OS e PDA e tutte le volte rimanevo con mezza parola…
Il 27/06/07, Simone Casciaroli <simone.casciaroli@gmail.com> ha scritto:
Prodevelop, una delle aziende che porta avanti lo sviluppo di gvSIG
(per esempio tutta la parte di gestione e trasformazione dei/tra
sistemi di riferimento è stata sviluppata da loro) presenterà al
FOSS4G 2007 un prototipo di gvSIG che possa girare sotto palmare,
ovviamente la licenza rimane GPL.
Maggiori informazioni qui: http://www.foss4g2007.org/presentations/view.php/124
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
La velocità di sviluppo di gvSIG comincia veramente ad impressionarmi.
gvSIG su palmare apre tante altre prospettive. Addio ArcPad!
Ciao
Antonio
Simone Casciaroli ha scritto:
Prodevelop, una delle aziende che porta avanti lo sviluppo di gvSIG
(per esempio tutta la parte di gestione e trasformazione dei/tra
sistemi di riferimento è stata sviluppata da loro) presenterà al
FOSS4G 2007 un prototipo di gvSIG che possa girare sotto palmare,
ovviamente la licenza rimane GPL.
Maggiori informazioni qui: http://www.foss4g2007.org/presentations/view.php/124_______________________________________________
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Devi assolutamente provare il plugin per Eclipse per sviluppare
estensioni per gvSIG finchè è free..è veramente interessante e
velocizza moltissimo lo sviluppo di plugin.
Io ho già sviluppato qualche plugin "a mano" e facendo qualche test
con il plugin per Eclipse mi sono reso conto che si dimezza il tempo
di sviluppo, perchè ti permette di concentrarti sulla logica da
implementare senza dover pensare anche ai framework che ci sono
sotto...però nn lo posso dire sul forum di gvSIG altrimenti il
creatore si monta la testa 
On 6/27/07, Antonio Falciano <afalciano@yahoo.it> wrote:
La velocità di sviluppo di gvSIG comincia veramente ad impressionarmi.
gvSIG su palmare apre tante altre prospettive. Addio ArcPad!Ciao
AntonioSimone Casciaroli ha scritto:
> Prodevelop, una delle aziende che porta avanti lo sviluppo di gvSIG
> (per esempio tutta la parte di gestione e trasformazione dei/tra
> sistemi di riferimento è stata sviluppata da loro) presenterà al
> FOSS4G 2007 un prototipo di gvSIG che possa girare sotto palmare,
> ovviamente la licenza rimane GPL.
> Maggiori informazioni qui: http://www.foss4g2007.org/presentations/view.php/124
>
> _______________________________________________
> Gfoss mailing list: 220 iscritti (28-05-2007)
> Gfoss@faunalia.com
> http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss_______________________________________________
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Grazie per il consiglio. A dire il vero finora ho sviluppato qualcosina
utilizzando solamente il Jython, anche se mi ero promesso di usare Java
su Eclipse non appena si fosse presentata l'opportunità. In termini di
produttività, i vantaggi sono sicuramente notevoli.
Ciao
Antonio
Simone Casciaroli ha scritto:
Devi assolutamente provare il plugin per Eclipse per sviluppare
estensioni per gvSIG finchè è free..è veramente interessante e
velocizza moltissimo lo sviluppo di plugin.
Io ho già sviluppato qualche plugin "a mano" e facendo qualche test
con il plugin per Eclipse mi sono reso conto che si dimezza il tempo
di sviluppo, perchè ti permette di concentrarti sulla logica da
implementare senza dover pensare anche ai framework che ci sono
sotto...però nn lo posso dire sul forum di gvSIG altrimenti il
creatore si monta la testaOn 6/27/07, Antonio Falciano <afalciano@yahoo.it> wrote:
La velocità di sviluppo di gvSIG comincia veramente ad impressionarmi.
gvSIG su palmare apre tante altre prospettive. Addio ArcPad!Ciao
AntonioSimone Casciaroli ha scritto:
> Prodevelop, una delle aziende che porta avanti lo sviluppo di gvSIG
> (per esempio tutta la parte di gestione e trasformazione dei/tra
> sistemi di riferimento è stata sviluppata da loro) presenterà al
> FOSS4G 2007 un prototipo di gvSIG che possa girare sotto palmare,
> ovviamente la licenza rimane GPL.
> Maggiori informazioni qui: http://www.foss4g2007.org/presentations/view.php/124
>
> _______________________________________________
> Gfoss mailing list: 220 iscritti (28-05-2007)
> Gfoss@faunalia.com
> http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss_______________________________________________
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Sono contento di trovare una comunità Java così fervente 
Finora ho utilizzato grass, r, postgres, gdal, ogr, ecc. in varie combinazioni per produrre, da shell, le automazioni e il geoprocessing del caso. Adesso mi sto chiedendo come si può realizzare questa integrazione con prodotti Java. Apparte la libreria Geotools, mi chiedevo come mai tra i prodotti Java non ce n’è uno che permetta la modalità “silent”, senza GUI? Sarebbe poter incrociare gvSIG con R, ad esempio…
Voi che avete più esperienza con i GIS Java cosa ne dite?
Il 27/06/07, Antonio Falciano <afalciano@yahoo.it > ha scritto:
Grazie per il consiglio. A dire il vero finora ho sviluppato qualcosina
utilizzando solamente il Jython, anche se mi ero promesso di usare Java
su Eclipse non appena si fosse presentata l’opportunità. In termini di
produttività, i vantaggi sono sicuramente notevoli.Ciao
AntonioSimone Casciaroli ha scritto:
Devi assolutamente provare il plugin per Eclipse per sviluppare
estensioni per gvSIG finchè è free…è veramente interessante e
velocizza moltissimo lo sviluppo di plugin.
Io ho già sviluppato qualche plugin “a mano” e facendo qualche test
con il plugin per Eclipse mi sono reso conto che si dimezza il tempo
di sviluppo, perchè ti permette di concentrarti sulla logica da
implementare senza dover pensare anche ai framework che ci sono
sotto…però nn lo posso dire sul forum di gvSIG altrimenti il
creatore si monta la testaOn 6/27/07, Antonio Falciano < afalciano@yahoo.it> wrote:
La velocità di sviluppo di gvSIG comincia veramente ad impressionarmi.
gvSIG su palmare apre tante altre prospettive. Addio ArcPad!Ciao
AntonioSimone Casciaroli ha scritto:
Prodevelop, una delle aziende che porta avanti lo sviluppo di gvSIG
(per esempio tutta la parte di gestione e trasformazione dei/tra
sistemi di riferimento è stata sviluppata da loro) presenterà al
FOSS4G 2007 un prototipo di gvSIG che possa girare sotto palmare,
ovviamente la licenza rimane GPL.
Maggiori informazioni qui:
http://www.foss4g2007.org/presentations/view.php/124
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
G. Allegri ha scritto:
Sono contento di trovare una comunità Java così fervente
Voi che avete più esperienza con i GIS Java cosa ne dite?
Che bisogna chiedere ai signori di gvSig. Le applicazioni di cui parli
sono nate per la linea di comando, e la GUI è venuta soltanto dopo,
quindi sono naturalmente staccate.
Al contrario, gvSig è nato per essere una GUI, e staccare la UI può
essere (molto) complicato.
Ciao
Andrea
Ok, lo che questo è il motivo per gvSIG, Udig, ecc. Ma mi interrogvao sul fatto che non ci sono prodotti Java sviluppati per riga di comando… A me sembra una limitazione così evidente! Chiaramente dipende dall’uso che ognuno fa dei GIS…
Vabbè, scusate i filosofeggiamenti
Il 27/06/07, Andrea Aime <aaime@openplans.org> ha scritto:
G. Allegri ha scritto:
Sono contento di trovare una comunità Java così fervente
utilizzato grass, r, postgres, gdal, ogr, ecc. in varie combinazioni per
produrre, da shell, le automazioni e il geoprocessing del caso. Adesso
mi sto chiedendo come si può realizzare questa integrazione con prodotti
Java. Apparte la libreria Geotools, mi chiedevo come mai tra i prodotti
Java non ce n’è uno che permetta la modalità “silent”, senza GUI?
Sarebbe poter incrociare gvSIG con R, ad esempio…
Voi che avete più esperienza con i GIS Java cosa ne dite?Che bisogna chiedere ai signori di gvSig. Le applicazioni di cui parli
sono nate per la linea di comando, e la GUI è venuta soltanto dopo,
quindi sono naturalmente staccate.
Al contrario, gvSig è nato per essere una GUI, e staccare la UI può
essere (molto) complicato.Ciao
Andrea
G. Allegri ha scritto:
Ok, lo che questo è il motivo per gvSIG, Udig, ecc. Ma mi interrogvao sul fatto che non ci sono prodotti Java sviluppati per riga di comando... A me sembra una limitazione così evidente! Chiaramente dipende dall'uso che ognuno fa dei GIS...
Vabbè, scusate i filosofeggiamenti
No, non è per quello che non esistono programmi per linea di comando
scritti in Java. I motivi sono storici:
1) la linea di comando in Java viene vista come console per applicazioni
server e GUI, il supporto per fare input da linea di comando è
penoso. Considera che abbiamo un equivalente della printf solo da
Java 5, e nemmeno in Java 6 c'e' un equivalente della scanf
(ci sono alcune implementazioni in giro, ma poca roba).
Di un equivalente di ncurses poi non ne parliamo...
2) anche se in java6 l'avvio della VM è piuttosto spedito, lo stesso
non si può dire per le versioni precedenti, quindi scrivere un
programma a linea di comando è sempre stato svantaggioso, col
risultato che i programmatori Java privilegiano programmi a lunga
vita, dove si può ammortizzare il tempo di avvio e lasciare al
JIT il tempo di tradurre il bytecode in codice nativo.
Ciao
Andrea
Grazie Andrea, ottimo chiarimento Per il batch continuerò ad usare gli altri prodotti…
La mia domanda comunque nasce dal fatto che mi sto interessando da tempo a soluzioni per il geoprocessing online (analisi statistiche “browser based”), e siccome mi farebbe comodo poter integrare alcuni strumenti all’interno di servlet (senza fare chiamate di sistema ad altri sw) stavo cercando di trovare una via direttamente in Java. Tutto qua.
Il 27/06/07, Andrea Aime <aaime@openplans.org> ha scritto:
G. Allegri ha scritto:
Ok, lo che questo è il motivo per gvSIG, Udig, ecc. Ma mi interrogvao
sul fatto che non ci sono prodotti Java sviluppati per riga di
comando… A me sembra una limitazione così evidente! Chiaramente
dipende dall’uso che ognuno fa dei GIS…
Vabbè, scusate i filosofeggiamentiNo, non è per quello che non esistono programmi per linea di comando
scritti in Java. I motivi sono storici:
- la linea di comando in Java viene vista come console per applicazioni
server e GUI, il supporto per fare input da linea di comando è
penoso. Considera che abbiamo un equivalente della printf solo da
Java 5, e nemmeno in Java 6 c’e’ un equivalente della scanf
(ci sono alcune implementazioni in giro, ma poca roba).
Di un equivalente di ncurses poi non ne parliamo…- anche se in java6 l’avvio della VM è piuttosto spedito, lo stesso
non si può dire per le versioni precedenti, quindi scrivere un
programma a linea di comando è sempre stato svantaggioso, col
risultato che i programmatori Java privilegiano programmi a lunga
vita, dove si può ammortizzare il tempo di avvio e lasciare al
JIT il tempo di tradurre il bytecode in codice nativo.Ciao
Andrea
Sulla chiamata ai geoprocessi a riga di comando secondo me ci si può
ragionare, dovresti guardare il codice per la gestione del
geoprocesso....ma mi viene da dire che più che richiamarli da riga di
comando magari potresti provare proprio a riusare il codice ma ti
ripeto dipende da quanto puoi riutilizzare...
Poi in realtà non ho capito molto se per applicazione web intendi un
applicazione di gestione (ossia che ti permette di far partire il
geoprocesso senza vedere ne l'input ne l'output) oppure un
applicazione web di visualizzazione/editing di mappe che applica
direttamente sulla base dati le trasformazioni (quindi vedi il prima e
il dopo direttamente). In questo secondo caso direi che l'idea della
riga di comando può essere tranquillamente definita "un accrocchio"
On 6/27/07, G. Allegri <giohappy@gmail.com> wrote:
Grazie Andrea, ottimo chiarimento
altri prodotti...
La mia domanda comunque nasce dal fatto che mi sto interessando da tempo a
soluzioni per il geoprocessing online (analisi statistiche "browser based"),
e siccome mi farebbe comodo poter integrare alcuni strumenti all'interno di
servlet (senza fare chiamate di sistema ad altri sw) stavo cercando di
trovare una via direttamente in Java. Tutto qua.Il 27/06/07, Andrea Aime <aaime@openplans.org> ha scritto:
> G. Allegri ha scritto:
> > Ok, lo che questo è il motivo per gvSIG, Udig, ecc. Ma mi interrogvao
> > sul fatto che non ci sono prodotti Java sviluppati per riga di
> > comando... A me sembra una limitazione così evidente! Chiaramente
> > dipende dall'uso che ognuno fa dei GIS...
> > Vabbè, scusate i filosofeggiamenti
>
> No, non è per quello che non esistono programmi per linea di comando
> scritti in Java. I motivi sono storici:
> 1) la linea di comando in Java viene vista come console per applicazioni
> server e GUI, il supporto per fare input da linea di comando è
> penoso. Considera che abbiamo un equivalente della printf solo da
> Java 5, e nemmeno in Java 6 c'e' un equivalente della scanf
> (ci sono alcune implementazioni in giro, ma poca roba).
> Di un equivalente di ncurses poi non ne parliamo...
> 2) anche se in java6 l'avvio della VM è piuttosto spedito, lo stesso
> non si può dire per le versioni precedenti, quindi scrivere un
> programma a linea di comando è sempre stato svantaggioso, col
> risultato che i programmatori Java privilegiano programmi a lunga
> vita, dove si può ammortizzare il tempo di avvio e lasciare al
> JIT il tempo di tradurre il bytecode in codice nativo.
>
> Ciao
> Andrea
>_______________________________________________
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Mi sono spiegato male, scusate.
Ho necessità di realizzare un servizio di “web processing”, da far girare come servlet, e che esponga alcune routine per delle analisi (geo)statistiche, che fanno anche uso di “map algebra”. Il tutto funzionante indipendentemente da un’interfaccia su browser (questa appare ad un altro livello). Siccome queste routine avrebbero bisogno di usare anche R (gstat in particolare), sto cercando il modo migliore per evitare di fare un “accrocchio”, come dici tu. Sicuramente il modo migliore sarebbe non usare chiamate di sistema, ed integrare il tutto riutilizzando codice esistente. Il problema è proprio qua: il codice in giro è per lo più dipendente da GUI e non è facile scorporarlo dal resto… Il problema quindi è:
- interfacciarsi con altri software (R, in questo caso)
- poter utilizzare funzionalità d’analisi raster (map algebra) già implementate
Qualcuno potrebbe consigliare di metter mano a JNI, ma non è roba per me!
Il 27/06/07, Simone Casciaroli <simone.casciaroli@gmail.com> ha scritto:
Sulla chiamata ai geoprocessi a riga di comando secondo me ci si può
ragionare, dovresti guardare il codice per la gestione del
geoprocesso…ma mi viene da dire che più che richiamarli da riga di
comando magari potresti provare proprio a riusare il codice ma ti
ripeto dipende da quanto puoi riutilizzare…
Poi in realtà non ho capito molto se per applicazione web intendi un
applicazione di gestione (ossia che ti permette di far partire il
geoprocesso senza vedere ne l’input ne l’output) oppure un
applicazione web di visualizzazione/editing di mappe che applica
direttamente sulla base dati le trasformazioni (quindi vedi il prima e
il dopo direttamente). In questo secondo caso direi che l’idea della
riga di comando può essere tranquillamente definita “un accrocchio”On 6/27/07, G. Allegri <giohappy@gmail.com> wrote:
Grazie Andrea, ottimo chiarimento
altri prodotti…
La mia domanda comunque nasce dal fatto che mi sto interessando da tempo a
soluzioni per il geoprocessing online (analisi statistiche “browser based”),
e siccome mi farebbe comodo poter integrare alcuni strumenti all’interno di
servlet (senza fare chiamate di sistema ad altri sw) stavo cercando di
trovare una via direttamente in Java. Tutto qua.Il 27/06/07, Andrea Aime <aaime@openplans.org > ha scritto:
G. Allegri ha scritto:
Ok, lo che questo è il motivo per gvSIG, Udig, ecc. Ma mi interrogvao
sul fatto che non ci sono prodotti Java sviluppati per riga di
comando… A me sembra una limitazione così evidente! Chiaramente
dipende dall’uso che ognuno fa dei GIS…
Vabbè, scusate i filosofeggiamentiNo, non è per quello che non esistono programmi per linea di comando
scritti in Java. I motivi sono storici:
- la linea di comando in Java viene vista come console per applicazioni
server e GUI, il supporto per fare input da linea di comando è
penoso. Considera che abbiamo un equivalente della printf solo da
Java 5, e nemmeno in Java 6 c’e’ un equivalente della scanf
(ci sono alcune implementazioni in giro, ma poca roba).
Di un equivalente di ncurses poi non ne parliamo…- anche se in java6 l’avvio della VM è piuttosto spedito, lo stesso
non si può dire per le versioni precedenti, quindi scrivere un
programma a linea di comando è sempre stato svantaggioso, col
risultato che i programmatori Java privilegiano programmi a lunga
vita, dove si può ammortizzare il tempo di avvio e lasciare al
JIT il tempo di tradurre il bytecode in codice nativo.Ciao
Andrea
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Mi incuriosisce sentir parlare di servizio di web processing. Avrei qualche domanda da porti prima di dare qualche modesto suggerimento.
1>che tipo di routine di analisi o map algebra devi esporre nello specifico
2>che tipo di interazione prevedi con l’utente? Synch o Asynch
3>hai vincoli di piattaforma (hai parlato di servlet)? Se si quali?
Ciao,
Simone.
On 6/27/07, G. Allegri <giohappy@gmail.com> wrote:
Mi sono spiegato male, scusate.
Ho necessità di realizzare un servizio di “web processing”, da far girare come servlet, e che esponga alcune routine per delle analisi (geo)statistiche, che fanno anche uso di “map algebra”. Il tutto funzionante indipendentemente da un’interfaccia su browser (questa appare ad un altro livello). Siccome queste routine avrebbero bisogno di usare anche R (gstat in particolare), sto cercando il modo migliore per evitare di fare un “accrocchio”, come dici tu. Sicuramente il modo migliore sarebbe non usare chiamate di sistema, ed integrare il tutto riutilizzando codice esistente. Il problema è proprio qua: il codice in giro è per lo più dipendente da GUI e non è facile scorporarlo dal resto… Il problema quindi è:
- interfacciarsi con altri software (R, in questo caso)
- poter utilizzare funzionalità d’analisi raster (map algebra) già implementate
Qualcuno potrebbe consigliare di metter mano a JNI, ma non è roba per me!Il 27/06/07, Simone Casciaroli < simone.casciaroli@gmail.com> ha scritto:
Sulla chiamata ai geoprocessi a riga di comando secondo me ci si può
ragionare, dovresti guardare il codice per la gestione del
geoprocesso…ma mi viene da dire che più che richiamarli da riga di
comando magari potresti provare proprio a riusare il codice ma ti
ripeto dipende da quanto puoi riutilizzare…
Poi in realtà non ho capito molto se per applicazione web intendi un
applicazione di gestione (ossia che ti permette di far partire il
geoprocesso senza vedere ne l’input ne l’output) oppure un
applicazione web di visualizzazione/editing di mappe che applica
direttamente sulla base dati le trasformazioni (quindi vedi il prima e
il dopo direttamente). In questo secondo caso direi che l’idea della
riga di comando può essere tranquillamente definita “un accrocchio”On 6/27/07, G. Allegri < giohappy@gmail.com> wrote:
Grazie Andrea, ottimo chiarimento
altri prodotti…
La mia domanda comunque nasce dal fatto che mi sto interessando da tempo a
soluzioni per il geoprocessing online (analisi statistiche “browser based”),
e siccome mi farebbe comodo poter integrare alcuni strumenti all’interno di
servlet (senza fare chiamate di sistema ad altri sw) stavo cercando di
trovare una via direttamente in Java. Tutto qua.Il 27/06/07, Andrea Aime < aaime@openplans.org > ha scritto:
G. Allegri ha scritto:
Ok, lo che questo è il motivo per gvSIG, Udig, ecc. Ma mi interrogvao
sul fatto che non ci sono prodotti Java sviluppati per riga di
comando… A me sembra una limitazione così evidente! Chiaramente
dipende dall’uso che ognuno fa dei GIS…
Vabbè, scusate i filosofeggiamentiNo, non è per quello che non esistono programmi per linea di comando
scritti in Java. I motivi sono storici:
- la linea di comando in Java viene vista come console per applicazioni
server e GUI, il supporto per fare input da linea di comando è
penoso. Considera che abbiamo un equivalente della printf solo da
Java 5, e nemmeno in Java 6 c’e’ un equivalente della scanf
(ci sono alcune implementazioni in giro, ma poca roba).
Di un equivalente di ncurses poi non ne parliamo…- anche se in java6 l’avvio della VM è piuttosto spedito, lo stesso
non si può dire per le versioni precedenti, quindi scrivere un
programma a linea di comando è sempre stato svantaggioso, col
risultato che i programmatori Java privilegiano programmi a lunga
vita, dove si può ammortizzare il tempo di avvio e lasciare al
JIT il tempo di tradurre il bytecode in codice nativo.Ciao
Andrea
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
–
Eng. Simone Giannecchini
President /CEO GeoSolutions
Premetto che non sono così esperto di programmazione Java (quindi ogni consiglio è ben accetto!!!), e magari pretendo di fare troppo, però quello che sto cercando di fare (senza entrare troppo nello specifico) è di
- realizzare un servizio per l’elaborazione in tempo reale di serie idrologiche e produzione di mappe derivate, ed aggregazione di queste con altri layer raster tramite “map algebra”. Il tutto deve essere accessibile da utenti remoti autenticati. Queste routine le ho già realizzate con grass+r+postgis, adesso vorrei migrarle su piattaforma java.
- l’interazione dovrebbe essere Asynch.
- parlo di servlet perché pensavo di usare questo sistema per realizzare un servizio RESTful, che possa girare sia su piattaforma linux che windows (un altro motivo percui vorrei migrare le routine verso java).
Comunque sto pensando a Java anche per tutta un’altra serie di motivi che non sto a dire…
Il 27/06/07, Simone Giannecchini < simboss1@gmail.com> ha scritto:
Mi incuriosisce sentir parlare di servizio di web processing. Avrei qualche domanda da porti prima di dare qualche modesto suggerimento.
1>che tipo di routine di analisi o map algebra devi esporre nello specifico
2>che tipo di interazione prevedi con l’utente? Synch o Asynch
3>hai vincoli di piattaforma (hai parlato di servlet)? Se si quali?Ciao,
Simone.On 6/27/07, G. Allegri <giohappy@gmail.com> wrote:
Mi sono spiegato male, scusate.
Ho necessità di realizzare un servizio di “web processing”, da far girare come servlet, e che esponga alcune routine per delle analisi (geo)statistiche, che fanno anche uso di “map algebra”. Il tutto funzionante indipendentemente da un’interfaccia su browser (questa appare ad un altro livello). Siccome queste routine avrebbero bisogno di usare anche R (gstat in particolare), sto cercando il modo migliore per evitare di fare un “accrocchio”, come dici tu. Sicuramente il modo migliore sarebbe non usare chiamate di sistema, ed integrare il tutto riutilizzando codice esistente. Il problema è proprio qua: il codice in giro è per lo più dipendente da GUI e non è facile scorporarlo dal resto… Il problema quindi è:
- interfacciarsi con altri software (R, in questo caso)
- poter utilizzare funzionalità d’analisi raster (map algebra) già implementate
Qualcuno potrebbe consigliare di metter mano a JNI, ma non è roba per me!Il 27/06/07, Simone Casciaroli < simone.casciaroli@gmail.com> ha scritto:
Sulla chiamata ai geoprocessi a riga di comando secondo me ci si può
ragionare, dovresti guardare il codice per la gestione del
geoprocesso…ma mi viene da dire che più che richiamarli da riga di
comando magari potresti provare proprio a riusare il codice ma ti
ripeto dipende da quanto puoi riutilizzare…
Poi in realtà non ho capito molto se per applicazione web intendi un
applicazione di gestione (ossia che ti permette di far partire il
geoprocesso senza vedere ne l’input ne l’output) oppure un
applicazione web di visualizzazione/editing di mappe che applica
direttamente sulla base dati le trasformazioni (quindi vedi il prima e
il dopo direttamente). In questo secondo caso direi che l’idea della
riga di comando può essere tranquillamente definita “un accrocchio”On 6/27/07, G. Allegri < giohappy@gmail.com> wrote:
Grazie Andrea, ottimo chiarimento
altri prodotti…
La mia domanda comunque nasce dal fatto che mi sto interessando da tempo a
soluzioni per il geoprocessing online (analisi statistiche “browser based”),
e siccome mi farebbe comodo poter integrare alcuni strumenti all’interno di
servlet (senza fare chiamate di sistema ad altri sw) stavo cercando di
trovare una via direttamente in Java. Tutto qua.Il 27/06/07, Andrea Aime < aaime@openplans.org > ha scritto:
G. Allegri ha scritto:
Ok, lo che questo è il motivo per gvSIG, Udig, ecc. Ma mi interrogvao
sul fatto che non ci sono prodotti Java sviluppati per riga di
comando… A me sembra una limitazione così evidente! Chiaramente
dipende dall’uso che ognuno fa dei GIS…
Vabbè, scusate i filosofeggiamentiNo, non è per quello che non esistono programmi per linea di comando
scritti in Java. I motivi sono storici:
- la linea di comando in Java viene vista come console per applicazioni
server e GUI, il supporto per fare input da linea di comando è
penoso. Considera che abbiamo un equivalente della printf solo da
Java 5, e nemmeno in Java 6 c’e’ un equivalente della scanf
(ci sono alcune implementazioni in giro, ma poca roba).
Di un equivalente di ncurses poi non ne parliamo…- anche se in java6 l’avvio della VM è piuttosto spedito, lo stesso
non si può dire per le versioni precedenti, quindi scrivere un
programma a linea di comando è sempre stato svantaggioso, col
risultato che i programmatori Java privilegiano programmi a lunga
vita, dove si può ammortizzare il tempo di avvio e lasciare al
JIT il tempo di tradurre il bytecode in codice nativo.Ciao
Andrea
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
Gfoss mailing list: 220 iscritti (28-05-2007)
Gfoss@faunalia.com
http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss–
Eng. Simone Giannecchini
President /CEO GeoSolutions