Opened 22 years ago

Last modified 22 years ago

#117 closed enhancement (fixed)

gdaltindex and png files

Reported by: doug_newcomb@… Owned by: dron
Priority: high Milestone:
Component: default Version: unspecified
Severity: minor Keywords:
Cc:

Description

Gdal 1.1.6 on Red Hat 7.2, glibc-2.2.4-19.3,  gcc-2.96-98, proj4-4.4.5,
shapelib-1.2.9

I know gdaltindex may not do this for png files, but this  is what happened. 

When using gdaltindex on geotiff files converted to PNGs via gdal_translate
(gdal_translate -of PNG selma.tif selma.png) , the shape
file created gives inaccurate geometry. example from selma, nc 24k DRG State
plane meters, NAD 83 (Output from gdalinfo and shpinfo):
selma.tif :
[dnewcomb@yoda2 drg]$ gdalinfo selma.tif |head -15
Driver: GTiff/GeoTIFF
Size is 4768, 5801
Coordinate System is `'
Origin = (666139.654764,208367.826737)
Pixel Size = (2.438400,-2.438400)
Metadata:
  TIFFTAG_SOFTWARE=Arc/Info
Corner Coordinates:
Upper Left  (  666139.655,  208367.827) 
Lower Left  (  666139.655,  194222.668) 
Upper Right (  677765.946,  208367.827) 
Lower Right (  677765.946,  194222.668) 
Center      (  671952.800,  201295.248) 
selma.png:
[dnewcomb@yoda2 drg]$ gdalinfo selma2.png|head
Driver: PNG/Portable Network Graphics
Size is 4768, 5801
Coordinate System is `'
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0, 5801.0)
Upper Right ( 4768.0,    0.0)
Lower Right ( 4768.0, 5801.0)
Center      ( 2384.0, 2900.5)
Band 1 Block=4768x1 Type=Byte, ColorInterp=Palette

shpinfo on gdaltindex run on single tif and png files:

[dnewcomb@yoda2 drg]$ shpinfo selmatif.shp
Info for selmatif.shp
Polygon(5), 1 Records in file
File Bounds: (              0,              0)
	(     677765.946,    208367.8267)
[dnewcomb@yoda2 drg]$ shpinfo selmapng2
Info for selmapng2
Polygon(5), 1 Records in file
File Bounds: (              0,              0)
	(    1099539.328,    199741.7381)

Change History (3)

comment:1 by warmerdam, 22 years ago

Doug,

I think the basic problem is that the GDAL PNG driver does not write world
files for png files though it does read them.  That is why you just get
raw pixel coordinates when you run gdalinfo on the png files.  

However, I am now sure why you got the results you did in the index file
produced by gdaltindex. 

I have changed this report to an enhancement request for writing world files
for png files.  Are you in a position to prepare your own world files or
are you waiting for me to correct this in GDAL?




comment:2 by warmerdam, 22 years ago

Andrey,

Could you add this capability?  I would like you to add a generic
GDALWriteWorldFile() function to gdal/core/gdal_misc.cpp similar to the
GDALReadWorldFile() function already there, and then add it's use to the
create function in gdal/frmts/png/pngdataset.cpp.  You might want to look at
the gdal/frmts/gtiff/geotiff.cpp code which already supports writing out a world
file. 

I don't think we should write out the worldfile by default ... it should be 
controlled by a creation option (as I think it is in the GeoTIFF case).  


comment:3 by dron, 22 years ago

Added possibility to write world (.wld) files in PNG driver. Use WORLDFILE=YES
option for this purpose.
Note: See TracTickets for help on using tickets.