Thanks Frank & Even,
Following Even's comments I think I'll just leave the gzip functionality out
until we get the platform zlib fixed. I'll also ignore the img2tif stuff
assuming it will disappear in a future release anyway. A conditionally
compiled lfind in gdal/port sounds ideal. I've got
Hi,
My apologies for introducing problems from an old version, but it is what is
installed & I can't have it changed for weeks at least
The problem is with ogr2ogr in version 1.3.1 of GDAL under FreeBSD.
I need to generate GMT files for an online mapping application generating
publication
pcr...@pcreso.com wrote:
An example ogr2ogr command is:
ogr2ogr -f "Mapinfo File" -dsco "FORMAT=MIF" -nln sql ttt 'PG:host=wms dbname=db_trawl user=woodb' -sql "select station_no, trackline from station"
Brent,
I'm not sure what is going on, but I'd suggest you try :
ogrinfo 'PG:...' -
Hi Frank,
My current workaround is to use the GML driver instead of Mapinfo (don't
extract the geometries as geometries), then grep/sed/tr the GML file to get a
GMT one. This does not actually use ogr2ogr to get the geometries, but returns
them as a field with the X & Y coords in a space separa
I've gotten the map tile output from gdal2tiles.py to work properly with
Tilecache and the results look pretty good. However, I'm seeing a fairly
large gap in data at the international dateline. I recall seeing some
discussion about this between Frank and Klokan on the list previously, and
recomp
Hi Roger,
the problem is related to the default behavior of GDAL warping core,
which sometimes does not have enough input pixels or has a problem to
calculate correct target extent.
What you can do is to warp your input data into EPSG:900913 by
gdalwarp utility before tiling by gdal2tiles utility
