[Xastir] Speed issues moving maps.

[Tom Russo]

On Tue, Mar 22, 2011 at 09:58:04AM -0500, we recorded a bogon-computron collision of the <kg4wsv at gmail.com> flavor, containing:
> On Tue, Mar 22, 2011 at 12:55 AM, Curt, WE7U <curt.we7u at gmail.com> 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."