Ciao Juanita, please, read my comments below... Simone ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder
Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Thu, Feb 3, 2011 at 5:27 PM, Juanita Avila <juanita...@gmail.com> wrote: > I've had all sorts of trouble getting GeoServer 2.0.2 to create an > ImageMosaic from GeoTIFF files. No matter what I try I get this error: > > Could not list layers for this store, an error occurred retrieving them: > Unable to acquire a reader for this coverage with format: ImageMosaic > > I finally managed to create an ImageMosaic by taking a hint from the > mosaic_sample that ships with GeoServer and converting my GeoTIFF files to > PNGs, but I don't feel that this is an ideal solution. > > I suspect that the GeoServer GeoTIFF reader is not quite compatible with > the GeoTIFF files that I'm using, even though I've tried all sorts of > conversion tools including gdalwarp, Erdas ViewFinder. I've even followed > the old instructions for manually generating shape information with > gdaltindex. > > The images that I'm attempting to mosaic are publically available at this > site: > > http://aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect > > Notice that each image also comes with a world file (.tfw) and an HTML text > description. > These geotiff files do not have a proper EPSG code, GeoServer requires it in order to publish them. > These files are somewhat problematic to mosaic in their native state because > each has it's own localized projection. However, I found that I easily could > reproject the files to EPSG:4326 (WGS 84) with both Erdas ViewFinder and > gdalwarp. > You should not reproject each of them separately, you should try to merge them first (look at gdal_merge for this) otherwise you can use gdal_warp and warp all of them at the same time. If you don't do this you'll get all sort of side effects (i.e. black collar) at the edges. > In fact, I also had trouble creating a simple GeoTIFF store/layer from just > one of these files until I removed the .tif extension from the file. Once I > did that, GeoServer had no trouble processing the image! Honestly I have no idea what you are talking about here. > GeoServer could not > determine projection information unless I reprojected the files to EPSG:4326 > first, but it did load the files either way, so long at the .tif extension > was removed. I also tried .tiff, .geotiff, .TIF, .TIFF, and .GeoTIFF; but > the only method that worked was no extension at all! > Same as above for the extension of the files. As far as the projection is concerned, geoserver sees the projection but it needs a proper epsg code which we do not have for these files. > Let's consider creating a simple mosaic with just 2 images that are right > next to each other on a map of the earth: > > Chicago 81 North.tif > Detroit 81 North.tif > > The projection information for each of these files is identical (NAD83 , > EPS:4269) except for the "latitude of origin": > > Chicago: "latitude_of_origin",42.66666666666666 > Detroit: "latitude_of_origin",42.1 > > The tif files also reference the .tfw files. > > gdalwarp -t_srs EPSG:4326 "Chicago 81 North.tif" 4326_chicago_81_north.tif > gdalwarp -t_srs EPSG:4326 "Detroit 81 North.tif" 4326_detroit_81_north.tif > > After these conversions, the GeoTIFF files no longer reference the tfw files > and the tif files share the exact same projection: > > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.257223563, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433], > AUTHORITY["EPSG","4326"]] > > By copying them to a new chic_det_test directory under the geoserver > coverages directory, I can try to create a new ImageMosaic store: > Data Source Name: chic_det_test > URL: file:coverages/chic_det_test > > I always see my favorite error, even if I remove the .tif extensions from > the files: > > Could not list layers for this store, an error occurred retrieving them: > Unable to acquire a reader for this coverage with format: ImageMosaic > > A survey of the geoserver.log file provides no additional information on the > cause of the problem: > > 2011-02-03 10:57:50,343 INFO [geoserver.web] - Getting list of coverages for > saved store file:coverages/chic_det_test > java.lang.RuntimeException: Could not list layers for this store, an error > occurred retrieving them: Unable to acquire a reader for this coverage with > format: ImageMosaic > > The Erdas ViewFinder method is similar. I open the files in that GUI > tool, choose to save as TIFF, with the following Output File Options: > Change Output Pixel Size to Degrees > Change Output Projection to Category: Geographic and Projection: Lat/Lon > (WGS 84) > Resample Method: Nearest Neighbor > > Erdas ViewFinder produces a .tfw AND an .aux file, which are both referenced > in the .tif file, so I copy the .tif, .tfw, and .aux files to a new > erdas_chic_det_test folder under geoserver coverages and try again. > Data Source Name: erdas_chic_det_test > URL: file:coverages/erdas_chic_det_test > > Same error! > What you did below is not recommended. Png is a bad format for generic gis serving. Here (http://www.youtube.com/user/GeoSolutionsIT#p/a/u/0/X74LH9bDuek) is a video that shows what I did in my tests. I used a snapshot for geoserver 2.0.x taken from here: http://geoserver.org/display/GEOS/Nightly 2.0.x is stable hence you can use it. Simone. > I finally got smart and renamed the .tfw files to .pgw files, grabbed the > projection information the .tif files and created a .prj for each tif, then > opened the tifs in an image editing tool and saved as .png. At least the > image editing allowed me to strip off the legend information (which we > really do not want to display on map of the earth). > > That did the trick, but it's not a great solution. These maps are regularly > updated, so we'll need to follow this process every couple months to keep > our site up to date. > > If you have any other recommendations, I'd be very grateful! > > Thanks for your help, > Juanita Dahlin > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > Geoserver-users mailing list > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users > > ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
