Frank,
That makes sense ;). I just threw a perl script togther (using Geo::GDAL) to
do it instead.
Thanks,
Steve
-Original Message-
From: Frank Warmerdam [mailto:[EMAIL PROTECTED]
Sent: Thu, November 20, 2008 11:22 AM
To: Mullins, Steven
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal
I blame it all on the guy who implemented -projwin! (sorry, that's a
bit of a joke since I think it was Matt).
:):) Let's not carried away now, I *lobbied* for it (another word for
nagged) pretty hard but didn't write any code. That is still somewhat
beyond my skillset. Thank you for the kind
Mullins, Steven wrote:
Using: GDAL 1.6.0dev, FWTools 2.2.1, released 2008/06/17
ogr2ogr -f csv test_geo geology-all.shp -lco GEOMETRY=AS_XY
Dumps a CSV file with the attributes of the shape, but with no
coordinate fields per the "GEOMETRY=AS_XY" options. The shape
does have point geometry.
Jan Hartmann wrote:
It *is* a teaser, though. Considering that in the current situation
-projwin always has y1 larger than y2, and all other parameters are
always the reverse, couldn't you harmonise -projwin by testing for y1 >
y2 and reversing the y's? This would keep existing scripts working
Using: GDAL 1.6.0dev, FWTools 2.2.1, released 2008/06/17
ogr2ogr -f csv test_geo geology-all.shp -lco GEOMETRY=AS_XY
Dumps a CSV file with the attributes of the shape, but with no
coordinate fields per the "GEOMETRY=AS_XY" options. The shape
does have point geometry.
Any ideas why this woul
Ian Elliott wrote:
Hi,
An error is consistently occurring when I use the nearest neighbour
technique to resample an 8-bit paletted image.
Please see this page for an example:
http://projects.exeter.ac.uk/msel/personnel/iae/gdal/
(The resampling error is shown in image c).
A possible solution I
Hi,
An error is consistently occurring when I use the nearest neighbour
technique to resample an 8-bit paletted image.
Please see this page for an example:
http://projects.exeter.ac.uk/msel/personnel/iae/gdal/
(The resampling error is shown in image c).
A possible solution I have discovered is t
It *is* a teaser, though. Considering that in the current situation
-projwin always has y1 larger than y2, and all other parameters are
always the reverse, couldn't you harmonise -projwin by testing for y1 >
y2 and reversing the y's? This would keep existing scripts working.
Jan
Frank Warmer
