[ gpsdrive ] Errors with gdal_warp

[Hamish]

> My laptop is in use elsewhere at the moment, so I do not
> have the URL, but I am sure I got that from a gmane listing,
> which is pointed to by a line on (I think) your wiki
> page...

I've now updated my Google page to link to the latest gdal_slice.sh in
SVN and note a correction to what's found in the old email thread.


> If this was (is) wrong, then the whole thread needs to be
> checked and put into a HOWTO on your wiki.

better: someone put the updated howto in the new GpsDrive wiki and I
remove the link from my webpage.


> Using gdalwarp is a lot easier than using bsb2tif.

and I suspect gdalwarp output is more accurately georeferenced. (??)


Another [cosmetic] thing to consider, instead of gdalwarp'ing to epsg:4326
lat/lon wgs84, set -t_srs to a custom +proj=tmerc projection (or so) with
the projection's +lat_0 and +lon_0 origin centered at the map. Then
gdal_slice it as a map_* instead of top_*, so that the map isn't
"squashed" in the vertical as top_* (Plate Carree projection) assumes
1deg lat = 1 deg lon in distance, which is rather distorted at higher
lats. GpsDrive will position correctly, but it will look a bit weird to
use top_* at high-res map scales.

related: I think with top_* maps the scalebar distance is only valid in
the vertical direction. would need to check against grid overlay.
(1deg lat ~= 111km; 1min lat = 1 naut mile = 1.852km)


> I will try without 'COMPRESS' but I think the error
> is something in the original KAP file. bsb2tif handles the
> file without problem, but gdalwarp chokes.

the problem (AFAIU) is that gdalwarp processes the image in blocks of
fixed size, but when you compress it the bounds of those blocks no
longer line up and pointers go out of the assumed range leading to the
segfault. I can pull out Frank W's explanation of it if you are really
interested.


Hamish