[Xastir] reprojection / gdalwarp / geotiff problems

Tom Russo russo at bogodyn.org
Tue Dec 28 00:43:20 EST 2004


On Tue, Dec 28, 2004 at 04:02:39AM +0200, we recorded a bogon-computron collision of the <oh2kku at iki.fi> flavor, containing:
> Hi,
> 
> I have some PNG raster maps that are not in the xastir natural 
> projection. So I converted them with gdalwarp along with an esri world 
> file (named inputfile.tfw) I created like this:
> 
> gdalwarp -s_srs EPSG:2392 -t_srs EPSG:4326 inputfile.png outputfile.tif
> 
> The resulting geotiff does not seem to be what Xastir expects as I get 
> this printed to the terminal and no map is displayed:
> 
> Warning: no PCS in geotiff file outputfile.tif, assuming map is in lat/lon!

This is just a warning.  At one time xastir could not use geotiff files
that did not have a PCS (projected coordinate system), and would reject them.
When I hacked it so that it could use unprojected (lat/lon) geotiffs,
I left in this warning just in case there was a case where there was no PCS
because of a defect, to let the user (and at that time the only user of this
feature was me) know that the assumption was being made that the map was in
lat/lon.

It might be time to remove the warning.  In your case this is just confusing
the issue.

> *** geoTIFF file /long/path/outpufile.tif is not in the proper format:
> ***** Has 3 samples per pixel instead of 1
> ***** Has planarConfig of 2 instead of 1
> *** Please reformat it and try again.

Nod, you must only have one sample per pixel and only one planar config.  
Somehow by using the png file with gdalwarp it's created a tiff file with
something else, with R,G, and B samples for each pixel instead of one
color value per pixel.  Your png file is probably one without a colormap, and
uses 24 bits-per-pixel of color.  Every tif file I've used so far has only one 
byte per pixel, and uses a colormap to map the 256 possible pixel values onto 
colors.

Not immediately sure how to convert the png to tiff without letting gdal
munge it like that, or how to convert the tiff file to a one-sample-per-pixel
and 1 plane.  If I had to do this, I'd probably start by using netpbm 
utilities to change the number of colors --- "pngtoppm < inputfile.png | 
pnmquant 256 | ppmtopng > mungedfile.png" might do the trick, but might really 
ruin the color set of your original map.  Won't know till you try it.

> gdalinfo outputs this for the geotiff file:
> 
> Driver: GTiff/GeoTIFF
> Size is 380, 330
> Coordinate System is:
> GEOGCS["WGS 84",
>     DATUM["WGS_1984",
>         SPHEROID["WGS 84",6378137,298.2572235629972,
>             AUTHORITY["EPSG","7030"]],
>         AUTHORITY["EPSG","6326"]],
>     PRIMEM["Greenwich",0],
>     UNIT["degree (supplier to define representation)",0.01745329251994328],
>     AUTHORITY["EPSG","4326"]]

This is right.

> Origin = (24.445081,60.046957)
> Pixel Size = (0.00007605,-0.00003844)
> Corner Coordinates:
> Upper Left  (  24.4450807,  60.0469570) ( 24d26'42.29"E, 60d 2'49.05"N)
> Lower Left  (  24.4450807,  60.0342702) ( 24d26'42.29"E, 60d 2'3.37"N)
> Upper Right (  24.4739784,  60.0469570) ( 24d28'26.32"E, 60d 2'49.05"N)
> Lower Right (  24.4739784,  60.0342702) ( 24d28'26.32"E, 60d 2'3.37"N)
> Center      (  24.4595296,  60.0406136) ( 24d27'34.31"E, 60d 2'26.21"N)
> Band 1 Block=380x21 Type=Byte, ColorInterp=Red
> Band 2 Block=380x21 Type=Byte, ColorInterp=Green
> Band 3 Block=380x21 Type=Byte, ColorInterp=Blue

There's the reason xastir can't deal --- the three bands.

Not sure what the planarConfig deal is, though.

> What am I doing wrong? I have never used geotiffs before, I just thought 
> that why not put the calibration information right into the same image 
> file as well so I don't have a .png and a .geo to keep in sync. And I 
> think there might be a problem with getting gdalwarp to output the 
> required map calibration information if I went for a BMP or PNG..

Also, .geo doesn't do a completely correct job of georeferencing if the 
source map is not already in lat/long.  You're better off doing what you're
trying to do if you can get the source map into a single byte per pixel.

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 "When life gives you lemons, find someone with a paper cut."



More information about the Xastir mailing list