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