Hi lists,
The ImageIO-Ext 1.0.3 version have been released.
Major changes are:
- Added JPEG2000 Kakadu support (A R/W plugin leveraging on the Kakadu driver via JNI)
- Added DOQ1 and DOQ2 support (2 new plugins leveraging on GDAL).
- All GDAL plugins are now based on GDAL 1.4.5. (Native libraries are available in the Document and Files section)
More project’s details are available at 1.
Best Regards,
the GeoSolutions team.
–
Eng. Daniele Romagnoli
Software Engineer
GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
Daniele Romagnoli ha scritto:
Hi lists,
The ImageIO-Ext 1.0.3 version have been released.
Major changes are:
- Added JPEG2000 Kakadu support (A R/W plugin leveraging on the Kakadu
driver via JNI)
- Added DOQ1 and DOQ2 support (2 new plugins leveraging on GDAL).
- All GDAL plugins are now based on GDAL 1.4.5. (Native libraries are
available in the Document and Files section)
Congratulazioni! Visto che e' anche frutto del tuo lavoro, potresti
spiegarci sinteticamente quali sostanziali benefici potrebbe comportare
il suo utilizzo per la famiglia di GFOSS Java-based? Grazie.
ciao
Antonio
--
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano
On Wed, Jul 08, 2009 at 05:01:59PM +0200, Daniele Romagnoli wrote:
- All GDAL plugins are now based on GDAL 1.4.5. (Native libraries are
available in the Document and Files section)
1.5.4 forse?
--
Francesco P. Lovergine
Ciao Antonio,
lo scopo di imageio-ext è semplice, usando il meccanismo a plugin
proprio di ImageIO, la libreria standard sun per fare I/O di immagini,
aggiunge support a nuovi formati, tra cui molti di quelli gestiti da
gdal.
Notare che ImageIO è uno dei componenti base di GeoTools e di GeoServer.
Il nostro scopo è da una parte aumentare i formati supportati da
GeoTools e GeoServer, dall'altro aumentare le possibilita' di image
processing puro in Java.
Ho visto che segui particolarmnete gvSIG, sarebbe interessante ad
esempio che gvSIG, azichè usare una build di gdal propria, potrebbe
appoggiarsi ad imageio-ext anche se dubito che questo accadra' mai.
Simone.
------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
-------------------------------------------------------
2009/7/8 Antonio Falciano <afalciano@yahoo.it>:
Daniele Romagnoli ha scritto:
Hi lists,
The ImageIO-Ext 1.0.3 version have been released.
Major changes are:
- Added JPEG2000 Kakadu support (A R/W plugin leveraging on the Kakadu
driver via JNI)
- Added DOQ1 and DOQ2 support (2 new plugins leveraging on GDAL).
- All GDAL plugins are now based on GDAL 1.4.5. (Native libraries are
available in the Document and Files section)
Congratulazioni! Visto che e' anche frutto del tuo lavoro, potresti
spiegarci sinteticamente quali sostanziali benefici potrebbe comportare
il suo utilizzo per la famiglia di GFOSS Java-based? Grazie.
ciao
Antonio
--
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
No, 1.4.5.
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Owner - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
-------------------------------------------------------
2009/7/9 Francesco P. Lovergine <frankie@debian.org>:
On Wed, Jul 08, 2009 at 05:01:59PM +0200, Daniele Romagnoli wrote:
- All GDAL plugins are now based on GDAL 1.4.5. (Native libraries are
available in the Document and Files section)
1.5.4 forse?
--
Francesco P. Lovergine
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Simone Giannecchini ha scritto:
Ciao Antonio,
lo scopo di imageio-ext è semplice, usando il meccanismo a plugin
proprio di ImageIO, la libreria standard sun per fare I/O di immagini,
aggiunge support a nuovi formati, tra cui molti di quelli gestiti da
gdal.
Notare che ImageIO è uno dei componenti base di GeoTools e di GeoServer.
Il nostro scopo è da una parte aumentare i formati supportati da
GeoTools e GeoServer, dall'altro aumentare le possibilita' di image
processing puro in Java.
Ho visto che segui particolarmnete gvSIG, sarebbe interessante ad
esempio che gvSIG, azichè usare una build di gdal propria, potrebbe
appoggiarsi ad imageio-ext anche se dubito che questo accadra' mai.
Simone, grazie per le info. Immagino che uDig, utilizzando le librerie
Geotools, ne trarra' diversi benefici sia a livello di formati
supportati che in termini prestazionali. Lo stesso dicasi eventualmente
per openJUMP, Kosmo, ecc.
ciao
Antonio
--
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano
Ciao Antonio,
per uDig posso rispondere che da lunedi' diverse aziende (in primis
Camp2camp, Lisasoft, Axios, HydroloGIS) forniscono sviluppatori per
uno sforzo comune di una settimana per portare la versione di sviluppo
di uDig a livello maturo. Tale versione contiene il lavoro su
imageio-ext di Geosolutions.
Ciao
Andrea
2009/7/10 Antonio Falciano <afalciano@yahoo.it>:
Simone Giannecchini ha scritto:
Ciao Antonio,
lo scopo di imageio-ext è semplice, usando il meccanismo a plugin
proprio di ImageIO, la libreria standard sun per fare I/O di immagini,
aggiunge support a nuovi formati, tra cui molti di quelli gestiti da
gdal.
Notare che ImageIO è uno dei componenti base di GeoTools e di GeoServer.
Il nostro scopo è da una parte aumentare i formati supportati da
GeoTools e GeoServer, dall'altro aumentare le possibilita' di image
processing puro in Java.
Ho visto che segui particolarmnete gvSIG, sarebbe interessante ad
esempio che gvSIG, azichè usare una build di gdal propria, potrebbe
appoggiarsi ad imageio-ext anche se dubito che questo accadra' mai.
Simone, grazie per le info. Immagino che uDig, utilizzando le librerie
Geotools, ne trarra' diversi benefici sia a livello di formati
supportati che in termini prestazionali. Lo stesso dicasi eventualmente
per openJUMP, Kosmo, ecc.
ciao
Antonio
--
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
Salve.
A proposito, due domande (mie curiosita', nessuna polemica sottintesa) per
i javisti:
- mi pare di vedere molta replicazione di sforzi fra uDIG/JGRASS, gvSIG e
Kosmo/JUMP: come mai non si riesce ad arrivare, non dico ad
un'unificazione, ma all'emergere di una piattaforma dominante?
- perche' una versione cosi' vecchiotta delle GDAL per Imageio?
Salutoni.
Ciao Antonio,
per uDig posso rispondere che da lunedi' diverse aziende (in primis
Camp2camp, Lisasoft, Axios, HydroloGIS) forniscono sviluppatori per
uno sforzo comune di una settimana per portare la versione di sviluppo
di uDig a livello maturo. Tale versione contiene il lavoro su
imageio-ext di Geosolutions.
--
Paolo Cavallini
http://faunalia.it/pc
Paolo Cavallini ha scritto:
Salve.
A proposito, due domande (mie curiosita', nessuna polemica sottintesa) per
i javisti:
- mi pare di vedere molta replicazione di sforzi fra uDIG/JGRASS, gvSIG e
Kosmo/JUMP: come mai non si riesce ad arrivare, non dico ad
un'unificazione, ma all'emergere di una piattaforma dominante?
Un po' questioni di controllo, un po' perché è più facile sviluppare
rispetto al C, un po' perché non c'e' carenza di sviluppatori Java
in giro. Le probabilità di una unificazione a breve termine
sono pressochè nulle, anzi, stiamo assistendo alla nascita di altri
filoni, tipo Puzzle GIS e iGeoDesktop.
- perche' una versione cosi' vecchiotta delle GDAL per Imageio?
Stabilità. Un server Java è un solo processo altamente multi-threaded,
se un thread va in segfault si tira già l'intero server, ergo le
eventuali librerie native devono essere assolutamente stabili, il
segfault è semplicemente inaccettabile.
Ciao
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Il giorno ven, 10/07/2009 alle 16.38 +0200, Andrea Aime ha scritto:
Un po' questioni di controllo, un po' perché è più facile sviluppare
rispetto al C, un po' perché non c'e' carenza di sviluppatori Java
in giro. Le probabilità di una unificazione a breve termine
sono pressochè nulle, anzi, stiamo assistendo alla nascita di altri
filoni, tipo Puzzle GIS e iGeoDesktop.
Interessante (dal punto di vista dell'ecosistema del software). La
proliferazione tipo "bazaar" ha effetti positivi sulla qualità dei
programmi, in accordo alla teoria di ESR?
> - perche' una versione cosi' vecchiotta delle GDAL per Imageio?
Stabilità. Un server Java è un solo processo altamente multi-threaded,
Andrea, ignoranza mia: parlando di server ti riferisci a un componente
utilizzato anche nelle applicazioni desktop? Oppure questa stabilità
necessaria in ambito server si ripercuote in maniera pletorica sugli
utenti desktop? Tenendo conto che comunque GDAL 1.4.5 non è "stable" ma
"oldstable" (riprendendo la terminologia usata per le release Debian),
cioè 1.4.5 è una "end of support release".
Ciao e grazie per le interessanti informazioni,
steko
--
Stefano Costa
http://www.iosa.it/ Open Archaeology
Ciao:
2009/7/10 Paolo Cavallini <cavallini@faunalia.it>:
Salve.
A proposito, due domande (mie curiosita', nessuna polemica sottintesa) per
i javisti:
- mi pare di vedere molta replicazione di sforzi fra uDIG/JGRASS, gvSIG e
Kosmo/JUMP: come mai non si riesce ad arrivare, non dico ad
un'unificazione, ma all'emergere di una piattaforma dominante?
ho scoperto qua ancora
- OrbiGIS
- PuzzleGIS
non sto più dietro... 
Bazaar va bene ma non so - se tutti fanno
circa lo stesso...
saluti da http://www.ogrs2009.org/ ,
Markus
Markus Neteler ha scritto:
Ciao:
2009/7/10 Paolo Cavallini <cavallini@faunalia.it>:
Salve.
A proposito, due domande (mie curiosita', nessuna polemica sottintesa) per
i javisti:
- mi pare di vedere molta replicazione di sforzi fra uDIG/JGRASS, gvSIG e
Kosmo/JUMP: come mai non si riesce ad arrivare, non dico ad
un'unificazione, ma all'emergere di una piattaforma dominante?
ho scoperto qua ancora
- OrbiGIS
- PuzzleGIS
non sto più dietro... Bazaar va bene ma non so - se tutti fanno
circa lo stesso...
A quanto pare il "bazar" non e' una prerogativa esclusiva lato Java.
Vedo freschi freschi un paio di annunci proprio in questa lista. 
Assistiamo a continui rilasci, a volte discutibili, dovuti al
proliferare di API, framework, librerie e quant'altro (ben vengano, per
carita'!), per cui chi ha un po' di dimestichezza con la programmazione
con un minimo sforzo e' in grado di realizzare una propria applicazione
GIS del cui destino solo la selezione naturale potra' dirci qualcosa.
D'altro canto, emergono nuovi progetti che di tanto in tanto
rivoluzionano il ns modo di vedere le cose, tuttavia solo quelli con
la testa sulle spalle e che riescono a costruire un importante zoccolo
duro di risorse e sostenitori sopravvivono e si evolvono.
Ben vengano in tutto cio' i "crossover" (Qgis+GRASS, uDig+GRASS=jGRASS,
gvSIG+Sextante, ecc.) in quanto rappresentano un vero punto di incontro
e di consolidamento di piu' soluzioni, spesso complementari tra loro.
jGRASS, in particolare, e' un brillante esempio di come C e Java possono
coesistere, prendendo il meglio da entrambi.
Per fortuna il mondo non e' solo bianco o nero...
ciao
Antonio
--
Antonio Falciano
http://www.linkedin.com/in/antoniofalciano