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 <[email protected]> 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 > 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) >>> 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 >>> <[email protected]> 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 us :-) >>>> >>>> Your 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-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 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
