Hi Andrea, thanks for your feedback, please read below. Lines marked with an * are my answers.
- at the very beginning of the procedure you say to create a "working dictionary"... I guess you mean a working directory? * Yes, of course --> fixed in the tutorial - I'm on windows with fwtools, even in the fwtools console gdal_retile.py does not work, but calling gdal_retile (without .py) does work. * gdal_retile is gdal_retile.bat which in turn calls "python gdal_retile.py" * --> added the windows stuff to the tutorial and the geotools users guide - to get a nice result on the tiles it would be nice to add -r bilinear to the command line. I guess you want to add that every time anyways, so it's better to add it to the tutorial, otherwise people might spend hours building a pyramid that does not look good * Hmm, I always use nearest neighbour (defautl for gdal_retile), but to be safe, it is ok * --> added "-r bilinear" to the tutorial - a section talking about the pyramid would be nice. Stuff like, telling people how many levels to use. If you want to see your images only fairly zoomed in, a handful of levels are sufficient (but remember to declare a maxScaleDenominator in the SLD Rule), but if you want to make a full pyramid, the number of levels needed should be something like log(size)/log(2) where size is the largest side of the original image * --> added the following link to the tutorial http://star.pst.qub.ac.uk/idl/Image_Tiling.html * --> added calculation hints to the tutorial * I am confused about maxScaleDenominator. I looked at raster.sld and it is not used here. * I think it is only needed if you want to stop zoom out at a given denominater ? - any reason for using 128 pixels tiles? I guess it's just because the input image is small, but maybe there is a deeper reason? * No there is no deeper reason, its because of the small input image * --> added a note about tile size considerations to the tutorial - the configUrl parameter requires a url, and might have to wait for a time out if you don't type it properly. What about supporting also a straight path on the file system, without the protocol, to be chekced with new File(path).exists()? * --> Changed param name from configUrl to config and accept files and URLs * --> Doing the same for cvsUrl and shapeUrl params (not used in the tutorial) to be consistent * --> Updated geotoools user guide and tutorial - in the osm.postgis.xml, 2 = bipolar, but it should actually be "bilinear" * --> fixed in tutorial - any reason why the dll command creates many little sql statements? It would be handier to have just two, one to create the tables, the other to drop them... or not? * Yes, beyond a tutorial, there are many reasons. * 1) fillmeta.sql is only useable if you use a third party utility to import your image data * 2) For some database systems it is simply not possible (db2 requires grid sizes when creating a spatial index, * there is an own advise tool for calculating these sizes, useable after importing the image data) * http://docs.codehaus.org/display/GEOTDOC/Creating+indexes+for+performance * 3) which tablespaces for physical data layout ? * 4) The intension is that these sql files help the user to create his own scripts, fitting for his needs * 5) It is better to force the user to think over the db design, I want to avoid a disappointed users because of a bad db design and they do not be aware of it. - the request to put the drivers in lib/ext does not look like a very good idea, people might have to use different versions of the same jdbc driver in different applications, and putting one in lib/ext prevents it. Any way to get the same result by using -cp and leaving the jdbc drivers out of lib/ext? * Look here for the reason: http://docs.codehaus.org/display/GEOTDOC/Using+the+java+import+utility. * Using the -Xbootclasspath/a: option for a tutorial is unsave, since it is an extended option not guaranteed to work on any java runtime. - the import is tedious if one has many levels. Any chance to create some convention so that a single command can import the whole pyramid? * Not really, for an import with world files it would be manageable. * But if you look at the other possibilities, having a shape file or csv file * for each pyramid, things get complicated, look here for the possibilities * http://docs.codehaus.org/display/GEOTDOC/Using+the+java+import+utility - when looking at the result in GeoServer one can see the image is stretched compared to the original png. This is actually due to the projection, and the fact the original image has probably been rendered in a different one (google mercator I guess). It would be a good idea to explain the reason for the stretch, it might save you some user questions on the topic. * It seems that the image uses EPSG:900913, wich is supported in geotools, but not in postgis * --> added an explanaition to the tutorial Ok, now I'm moving to try an import a bluemarble image (single ecw file, 86400x43200) into the database (with 16 levels pyramid, bilinear interpolation, jpeg format). Well, actually, it's been creating the base level since 15 minutes ago, I guess I'll have to wait quite a bit more (I guess, a few hours... a nice improvement could be to parallelize gdal_retile so that it can leverage multiple cores). Will let you know when/if I finish and get it working :) * A full retile job on 80 GB Erdas image on a ppc with 4.2 Ghz needs also some hours * Parallelize is a challenge, i did some investigations, heavy stuff Another (easy) idea that came to mind is that it would be nice to have GWC learn how to read the files of this pyramid directly. Grab a big image that one cannot server due to licensing constraints (I'm thinking bluemarble), retile, serve directly out with the tile cache (eventually learn how to grab the tiles from the db if the organisation does not allow data on disk). * I had a similiar idea, writing an optional file backend and reading from http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification Cheers Chrsitian ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
