On Tue, Mar 22, 2011 at 09:58:04AM -0500, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > On Tue, Mar 22, 2011 at 12:55 AM, Curt, WE7U <[email protected]> wrote: > > What image format are you using? ?I think something like PNG might be one of > > the faster ones. ?It might also decrease your file size dramatically. > > > Curt, what's the transmogrification procedure to go from DRGs to PNGs? > I assume DOQQs would follow a similar path?
Not Curt, but I'll suggest some procedures. There is a way to do it using "png snapshots" in Xastir, but that has a cost in map quality. The png snapshots are saved at screen resolution with a .geo file that will allow you to read them back in as a base layer. This method is quick and dirty, you can pre-render favorite views (as, for example, map bookmarks) easily. So long as you stay at the zoom levels at which the png snapshots are taken, the rendering will be precisely what it was originallly but would be very fast. But if you zoom in, the saved, pre-rendered image is simply scaled up, making it much uglier than what would result from re-rendering the original files (which are invariably at much higher resolution than screen resolution, and have been downsampled for display). A better way to do DRG->PNG transformation it would be with gdalwarp, because it does not only image format transformation but also coordinate system warping. You need GDAL installed, of course. DRGs and DOQQs are in UTM projection, meaning that the TIFF driver in Xastir has to jump through hoops to do an approximate warping (a non-uniform scaling and rotating) of the image onto Xastir's coordinate system (which basically treats longitude and latitude as X,Y coordinates). This is why they're so slow. It's not even a strictly correct warping that Xastir does, but an approximation that happens to work reasonably well for USGS 24K topos --- the real computations that would make it correct for any scale map would be even slower. If you really wanted to use png/.geo instead, you need to do that warping up front, because the .geo format driver simply scales the image and plops it down one corner is in the right place --- for UTM this means the top left and bottom right corners of the image would be in the right spot, but nothing in the interior would be. That's how it's so fast, it just puts the image down as is, scaling uniformly in both X and Y dimensions. So, what you want is to do the stretching and twisting needed in one operation and save that file. gdalwarp -t_srs EPSG:4326 -co WORLDFILE=true foo.tif foo.png will do the trick, creating in the process a file "foo.wld" with the top left corner position and pixel size in lat/lon. This data *could* be used to back out a .geo with enough effort (geo files need the top left and bottom right corners in lat/lon, and the numbers of pixels in X and Y of the image). Be warned, though, that one of the other things the GeoTIFF driver in Xastir does for you is collar trimming of the DRG for seamless tiling of adjacent maps. By warping them into PNG and using the .geo driver instead you lose that. Furthermore, when doing the gdalwarp you also get regions around the edge of the image of "no data". These further interfere with seamless tiling. To do it all really well for fast and accurate map rendering, you need to spend a lot of time preparing your maps. You need to strip the collars in their original projection, tile them all together, then do a gdalwarp, then cut the tiled and warped larger image into smaller tiles and convert to png. This can be a challenge. The payoff is fast map rendering because all the hard work was done outside xastir and the results saved. The convenience of having Xastir do the collar stripping and tiling comes at a computational cost every time you render images. Sticking with the geotiff driver, but cutting the tiffs into smaller chunks is likely to produce better map displays. The primary time savings will result from Xastir's ability to skip reading pieces of the map that are off-screen. A large geotiff file that covers an area much larger than the current display still needs to be read in its entirety --- were this cut into smaller geotiff tiles, the rendering can simply skip tiles that are off-screen. Cutting up a geotiff into smaller tiles can be done with some gdal tools, too, specifically gdal_translate with the "-srcwin" option to select chunks of the source image by pixel/line bounding box. Making sure that collar stripping still works can be a challenge, because you'd have to generate a fake .fgd file with just the right parameters for each tile (i.e. any tile that had even a piece of collar in it would have to have the lat/lon of the corners of the non-collar data in the file). Generation of those fake .fgd files could be scripted, of course, with enough effort; one could even write a script that went through each source geotiff, cut it into appropriate tiles, and created fake fgd files from knowledge of the source's real FGD file and the chunks you cut the thing into. Again, the payoff will be faster rendering and roughly correct tile placement, but for considerable up-front effort. -- Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 http://kevan.org/brain.cgi?DDTNM "The truth will set you free, but first it will piss you off." _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
