Joel Odom wrote:
Is there a canonical way to pick an OGR driver based on a file name or
on a generalized connect string? (For example, if the file name ends in
.shp, it would select the Shapefile driver.) Thanks.
Joel,
No.
I really wanted to send this out with just that one word answer,
Thanks, Frank.
I understand the purist argument against this, though I think that 90% of
the time you can look at a connection string for a data source and determine
what the output driver should be. I'd like to see this feature in the
future, but I understand that it would need a caveat that it
On 05/10/2010 19:40, Even Rouault wrote:
Le lundi 04 octobre 2010 17:23:47, Frank Warmerdam a écrit :
gdal_translate, gdalwarp, ...
Even,
I would suggest -tap for target aligned pixels to go with -tr. I
would think that gdalwarp, gdal_rasterize, and perhaps gdal_merge.py and
gdalbuildvrt
The results of -tap are what I expect, pixels aligned with 0,0. Although I
have a separate question at the end.
Prior to the patch I ran this:
gdal_rasterize -tr 100 100 -a Elevation -l town town.shp townrasterb.tif
and got this:
gdalinfo townrasterb.tif
...
Origin =
Le mercredi 06 octobre 2010 18:42:14, Eli Adam a écrit :
The results of -tap are what I expect, pixels aligned with 0,0. Although I
have a separate question at the end.
ok, I've applied the patch in trunk in r20778
Prior to the patch I ran this:
gdal_rasterize -tr 100 100 -a Elevation -l
Le mercredi 06 octobre 2010 16:35:38, sagar_sahay a écrit :
After tweaking the path variable I got this exception:
Native library load failed.
java.lang.UnsatisfiedLinkError:
/home/gdal/gdal-1.7.2/swig/java/libgdaljni.so:
/home/gdal/gdal-1.7.2/swig/java/libgdaljni.so: wrong ELF class:
I used gdal_translate to convert a geotiff to an ecw file.
C:\Program Files\FWTools2.4.7gdal_translate -of ECW f:\test\mytif.tif
f:\test\myecw.ecw
Input file size is 2353, 2353
0...10...20...30...40...50...60...70...80...90...100 - done.
However, the corner coordinates are different between the
