Since there is some interest in the utility (and a new tutorial, thanks Simone), I think about a java port of the Python part of this utility.
Second, on the gdal mailing list, there is some excitement about a new java api for gdal.
If, and only if, the java api is good, I can investigate in porting from Pyhton to Java.
The advantage would be a better integration into geoserver/udig, making life easer for our users and us 
Your opinions
Ciao Christian,
a minor correction, there is no new API for Java, a few people,
including somehow daniele has been trying to refine the SWIG api for
more stability.
Now, about converting GDAL retiles to java, I am not 100 sure that we
should try to convert the python code to Java right away, I have never
been a fan of straight ports.
Geotools, leveraging on imageio-ext should be able to most of the jov
we need, or at least I would try and focus on removing the showstopper
at this level rather than trying to focus on gdal java solely.
I think that if you have some time to dedicate to these matters we
should try and integrate the various mosaic/pyramid pugins into one,
as well as on making the import of mosaic/pyramid easier.
This is my 0,02 €.
Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - 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
-------------------------------------------------------
On Fri, Nov 20, 2009 at 8:44 AM, Christian Müller
<christian.mueller@anonymised.com> wrote:
Since there is some interest in the utility (and a new tutorial, thanks
Simone), I think about a java port of the Python part of this utility.Second, on the gdal mailing list, there is some excitement about a new java
api for gdal.If, and only if, the java api is good, I can investigate in porting from
Pyhton to Java.
The advantage would be a better integration into geoserver/udig, making life
easer for our users and usYour opinions
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Simone Giannecchini wrote:
Ciao Christian,
a minor correction, there is no new API for Java, a few people,
including somehow daniele has been trying to refine the SWIG api for
more stability.Now, about converting GDAL retiles to java, I am not 100 sure that we
should try to convert the python code to Java right away, I have never
been a fan of straight ports.
Geotools, leveraging on imageio-ext should be able to most of the jov
we need, or at least I would try and focus on removing the showstopper
at this level rather than trying to focus on gdal java solely.I think that if you have some time to dedicate to these matters we
should try and integrate the various mosaic/pyramid pugins into one,
as well as on making the import of mosaic/pyramid easier.This is my 0,02 €.
I'll throw in my $0.02 with a big +1 to that, I've been thinking on these exact same lines. You should be able to point at a directory and if you want it to automatically pyramid as well as mosiac you just turn on that option, have it happen seamlessly through GeoServer config. The new automagic mosiac is super awesome, and would be super sweet if the magic extending to pyramiding as well.
Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italyphone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini-------------------------------------------------------
On Fri, Nov 20, 2009 at 8:44 AM, Christian Müller
<christian.mueller@anonymised.com> wrote:Since there is some interest in the utility (and a new tutorial, thanks
Simone), I think about a java port of the Python part of this utility.Second, on the gdal mailing list, there is some excitement about a new java
api for gdal.If, and only if, the java api is good, I can investigate in porting from
Pyhton to Java.
The advantage would be a better integration into geoserver/udig, making life
easer for our users and usYour opinions
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I am with Chris here. I want to state some facts.
I am quite unhappy with the current situation. We have 2 branches of handling images, a file based and a jdbc based. Unfortunately, they have nothing in common. (Besides sublcassing some abstract base classes). The reason for developing gdal_retile.py was that I had to handle very big images, delivered as tile sets or ERDAS images. I tried the tools from Simone (2 years ago) and besides the fact, that it was complicated, I could not handle ERDAS images and I always had heap overflows.
The current situation works for me, because I use gdal_retile.py and the imagemosaic-jdbc module. But our image handling does not really work for our users as I can see on the mailing lists.
Btw, the handling of the jdbc module is not better than the handling of the file module, too many steps to get a result.
Simone created a tutorial how to use the gdal_retile.py for the file based approach. Some times a ago, I created a tutorial using the jdbc based approach. The logical consequence is that both image handling modules rely on gdal_retile.
The Python part of gdal_retile never copies image data into python memory, it uses only handles to the images and delegates the hard work to the gdal library (croping, merging,...).
I think, the image-io gdal extension does a completely different thing, using gdal code to decode image formats to java images.
Of course I do not want a 1 to 1 port of the python code. At a minimum I would
1) Introduce an Interface for storing the tiles. We need at least 2 implementations, storing file based and storing into a jdbc database.
2) Fire events to indicate progress
3) Define an Interface for the input data, having implementations for the command line and Geoserver/udig
The disadvantage is a new dependency to the GDAL Java API.
so far, so good
Chris Holmes writes:
Simone Giannecchini wrote:
Ciao Christian,
a minor correction, there is no new API for Java, a few people,
including somehow daniele has been trying to refine the SWIG api for
more stability.Now, about converting GDAL retiles to java, I am not 100 sure that we
should try to convert the python code to Java right away, I have never
been a fan of straight ports.
Geotools, leveraging on imageio-ext should be able to most of the jov
we need, or at least I would try and focus on removing the showstopper
at this level rather than trying to focus on gdal java solely.I think that if you have some time to dedicate to these matters we
should try and integrate the various mosaic/pyramid pugins into one,
as well as on making the import of mosaic/pyramid easier.This is my 0,02 €.
I'll throw in my $0.02 with a big +1 to that, I've been thinking on these exact same lines. You should be able to point at a directory and if you want it to automatically pyramid as well as mosiac you just turn on that option, have it happen seamlessly through GeoServer config. The new automagic mosiac is super awesome, and would be super sweet if the magic extending to pyramiding as well.
Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italyphone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini-------------------------------------------------------
On Fri, Nov 20, 2009 at 8:44 AM, Christian Müller
<christian.mueller@anonymised.com> wrote:Since there is some interest in the utility (and a new tutorial, thanks
Simone), I think about a java port of the Python part of this utility.Second, on the gdal mailing list, there is some excitement about a new java
api for gdal.If, and only if, the java api is good, I can investigate in porting from
Pyhton to Java.
The advantage would be a better integration into geoserver/udig, making life
easer for our users and usYour opinions
------------------------------------------------------------------------ ------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel------------------------------------------------------------------------- -----
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.
CIao Chris,
a clarification.
I meant to say that IMHO all we need is the ability to import a
pyramid once GDAL_RETILE has created it not to be able to point the
ImagePyramid plugin to a directory and do also automagic creation of
the pyramid. I am not so sure this would work since:
1> the underlying request would timeout easily
2> the server would be unusable for a while.
Of course we could think about adding a utility to GeoServer (rest
extension or whatever) to do such tasks, but still I would be cautious
and I would probably try to reuse GDAL_RETILE.
Ciao,
SImone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - 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
-------------------------------------------------------
On Fri, Nov 20, 2009 at 6:20 PM, Chris Holmes <cholmes@anonymised.com> wrote:
Simone Giannecchini wrote:
Ciao Christian,
a minor correction, there is no new API for Java, a few people,
including somehow daniele has been trying to refine the SWIG api for
more stability.Now, about converting GDAL retiles to java, I am not 100 sure that we
should try to convert the python code to Java right away, I have never
been a fan of straight ports.
Geotools, leveraging on imageio-ext should be able to most of the jov
we need, or at least I would try and focus on removing the showstopper
at this level rather than trying to focus on gdal java solely.I think that if you have some time to dedicate to these matters we
should try and integrate the various mosaic/pyramid pugins into one,
as well as on making the import of mosaic/pyramid easier.This is my 0,02 €.
I'll throw in my $0.02 with a big +1 to that, I've been thinking on
these exact same lines. You should be able to point at a directory and
if you want it to automatically pyramid as well as mosiac you just turn
on that option, have it happen seamlessly through GeoServer config. The
new automagic mosiac is super awesome, and would be super sweet if the
magic extending to pyramiding as well.Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italyphone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini-------------------------------------------------------
On Fri, Nov 20, 2009 at 8:44 AM, Christian Müller
<christian.mueller@anonymised.com> wrote:Since there is some interest in the utility (and a new tutorial, thanks
Simone), I think about a java port of the Python part of this utility.Second, on the gdal mailing list, there is some excitement about a new java
api for gdal.If, and only if, the java api is good, I can investigate in porting from
Pyhton to Java.
The advantage would be a better integration into geoserver/udig, making life
easer for our users and usYour opinions
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Ciao Christian,
I think you are mixing things a little bit in your last email (and I
actually did not understand all the statements, like the one on
imageio-ext gdal support), therefore before concentrating on the
problem we are discussing I would say that statements like "this did
not work therefore I did something else" are bit useless, IMHO,
especially without having heard much feedback from you onthose
problems. Since you are a PMC of geotools I think that you should try
a little bit harder on the communication side :-).
Now back to the topic, I am not against creating something similar to
GDAL_RETILE in java, what I did in the past with the PyramidBuilder
was an attempt towards such a thing. However I lost interest in it
real quickly therefore I never really spent time on
improving/evolving, therefore your work on GDAL_RETILE was a plus for
us as well since we started using it as well. GDAL_RETILE works well
for me therefore I am not so interested in spending time to create
something that does exactly the same thing In java even because
honestly most people that do want to use a pyramid in the end would
just need to retile and add overview to a geotiff while the people who
really need to create a pyramid (e.g. orthophoto) cannot really do
that via the GeoServer interface, at least not in a way that is as
simple as "point to directory and do the pyramid" (as an instace the
underlying http request would easily timeout and/or the server would
become unusable for a long time).
Anyway, assuming we do have a need to create such a tool in java, I am
against creating something that would be tightly couple with GDAL
because:
1> I do not want to end up having multiple version of gdal around
2> GeoTools raster code has already a well defined architecture based
on JAI and ImageIO which can handle all the bits of this.
In my perspective GDAL role in doing these tasks in Java is well
defined, GDAL should leave at the IO level and used via ImageIO, a
different usage is, IMHO, a duplication of efforts and violates the
principles behjind GeoTools architecture.
Summarising:
- I am neutral about creating a tool to create pyramids in GeoTools, I
don't think it is essential due to the fact that GDAL_RETILE works
quite well, but I am willing to provide some help.
- I would suggest to create something that relies on
GeoTools/JAI/ImageIO and also that can exploit GDAL if and where it is
present for accessing more formats.
- I am against something tightly coupled with GDAL since the goal of
our work as PMCs should be to improve and harmonize the various parts
of GeoTools and this approach sems to contraddict such a goal
Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - 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
-------------------------------------------------------
On Sat, Nov 21, 2009 at 5:20 PM, Christian Müller
<christian.mueller@anonymised.com> wrote:
I am with Chris here. I want to state some facts.
I am quite unhappy with the current situation. We have 2 branches of
handling images, a file based and a jdbc based. Unfortunately, they have
nothing in common. (Besides sublcassing some abstract base classes). The
reason for developing gdal_retile.py was that I had to handle very big
images, delivered as tile sets or ERDAS images. I tried the tools from
Simone (2 years ago) and besides the fact, that it was complicated, I could
not handle ERDAS images and I always had heap overflows.The current situation works for me, because I use gdal_retile.py and the
imagemosaic-jdbc module. But our image handling does not really work for our
users as I can see on the mailing lists.Btw, the handling of the jdbc module is not better than the handling of the
file module, too many steps to get a result.Simone created a tutorial how to use the gdal_retile.py for the file based
approach. Some times a ago, I created a tutorial using the jdbc based
approach. The logical consequence is that both image handling modules rely
on gdal_retile.The Python part of gdal_retile never copies image data into python memory,
it uses only handles to the images and delegates the hard work to the gdal
library (croping, merging,...).I think, the image-io gdal extension does a completely different thing,
using gdal code to decode image formats to java images.Of course I do not want a 1 to 1 port of the python code. At a minimum I
would1) Introduce an Interface for storing the tiles. We need at least 2
implementations, storing file based and storing into a jdbc database.2) Fire events to indicate progress
3) Define an Interface for the input data, having implementations for the
command line and Geoserver/udigThe disadvantage is a new dependency to the GDAL Java API.
so far, so good
Chris Holmes writes:
Simone Giannecchini wrote:
Ciao Christian,
a minor correction, there is no new API for Java, a few people,
including somehow daniele has been trying to refine the SWIG api for
more stability.Now, about converting GDAL retiles to java, I am not 100 sure that we
should try to convert the python code to Java right away, I have never
been a fan of straight ports.
Geotools, leveraging on imageio-ext should be able to most of the jov
we need, or at least I would try and focus on removing the showstopper
at this level rather than trying to focus on gdal java solely.I think that if you have some time to dedicate to these matters we
should try and integrate the various mosaic/pyramid pugins into one,
as well as on making the import of mosaic/pyramid easier.This is my 0,02 €.
I'll throw in my $0.02 with a big +1 to that, I've been thinking on these
exact same lines. You should be able to point at a directory and if you
want it to automatically pyramid as well as mosiac you just turn on that
option, have it happen seamlessly through GeoServer config. The new
automagic mosiac is super awesome, and would be super sweet if the magic
extending to pyramiding as well.Ciao,
Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italyphone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://simboss.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini-------------------------------------------------------
On Fri, Nov 20, 2009 at 8:44 AM, Christian Müller
<christian.mueller@anonymised.com> wrote:Since there is some interest in the utility (and a new tutorial, thanks
Simone), I think about a java port of the Python part of this utility.Second, on the gdal mailing list, there is some excitement about a new
java
api for gdal.If, and only if, the java api is good, I can investigate in porting from
Pyhton to Java.
The advantage would be a better integration into geoserver/udig, making
life
easer for our users and usYour opinions
------------------------------------------------------------------------
------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and
focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel-------------------------------------------------------------------------
-----
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment -
and focus on what you do best, core application coding. Discover what's
new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel