Hi everyone,
I am getting this weird error when I try to convert a vrt to a tif.
Some context: We are tiling a set of tifs(in a list file). First we generate a
vrt from the list. Then we assign a projection on the generated vrt using
gdaltranslate. We then clip the output using gdalwarp
Moses.Gone at t-systems.com writes:
Hi everyone,
I am getting this weird error when I try to convert a vrt to a tif.
Some context: We are tiling a set of tifs(in a list file). First we
generate a vrt from the list. Then we assign a projection on the generated
vrt using
Moses,
Hum, your VRT is 2147483647 x 2147483647 large, which is the largest possible
raster that GDAL can handle in theory ! Something must have gone seriously wrong
when building it. I suspect that some input files have weird or inconsistant
georeferencing causing the extent to go to those crazy
On Tue, Apr 1, 2014 at 7:57 AM, Even Rouault
even.roua...@mines-paris.orgwrote:
Moses,
Hum, your VRT is 2147483647 x 2147483647 large, which is the largest
possible
raster that GDAL can handle in theory ! Something must have gone seriously
wrong
That would be more than enough pixel range
Selon Newcomb, Doug doug_newc...@fws.gov:
On Tue, Apr 1, 2014 at 7:57 AM, Even Rouault
even.roua...@mines-paris.orgwrote:
Moses,
Hum, your VRT is 2147483647 x 2147483647 large, which is the largest
possible
raster that GDAL can handle in theory ! Something must have gone seriously
I think something is wrong in you vrt file. The number of pixels seems
extremely high 2147483647 x 2147483647. This would result in a huge
geotiff ~ 4611686014132420609 bytes. A regular geotiff is limited to 4 GB
in size. This can be increased with Big Tiff support.
On 1 April 2014 03:31,
Hi all,
I've been successfully reading OSM PBF files using GDAL Python bindings, even
files larger than 5Gb. I did have to use OGR_INTERLEAVED_READING=YES and
OSM_USE_CUSTOM_INDEXING=NO, but eventually OSM PBF is read and I can extract
data.
If I use osmconvert [0] and osmfilter [1] to
On Mon, Mar 31, 2014 at 4:03 PM, Even Rouault
even.roua...@mines-paris.orgwrote:
Hi Etienne,
Thanks for your ideas.
Hi all,
I have a few suggestions for gdal 2.0, based on my personal experience in
learning to use, enhance and maintain gdal/ogr code.
- replace cpl/csl/string/xml
The 2 objections I have with json are :
- it is so verbose that editing by hand is not as easy as .csv
- the xml tags make file size much larger than .csv files, unless they
would be stored in a compressed file (gzip)
On the other hand, who messes with theses files on a regular basis anyway?
It
Hello Even,
I would like to contribute an OGR driver for SAP SQL Anywhere. We have had
this code in-house at SAP for some time, but I just received permission to
contribute it to the GDAL project.
Unfortunately, it may be several days before we have a patch ready to
contribute . If we do
I've wrestled with various nodata issues in the past, now it's hitting me
again...
I'm using Photoshop to delete collars on scanned maps, creating an alpha mask.
GDAL has no problem with this. What I want to do is merge maps together (after
rectification), then set any remaining nodata areas
On Tue, Apr 1, 2014 at 12:36 PM, Etienne Tourigny
etourigny@gmail.com wrote:
The 2 objections I have with json are :
- it is so verbose that editing by hand is not as easy as .csv
- the xml tags make file size much larger than .csv files, unless they would
be stored in a compressed file
Hello gdal,
I have a set of geotiffs that have a strange max (infinity?) values that I
would like to set to nodata. These originally were netcdf files. With the
current of gdal in OSGEO4W, gdalinfo reports:
gdalinfo -mm pola_cascadiad_sift2_maxspeed.tif
Driver: GTiff/GeoTIFF
Files:
Hi,
I'm not getting the results I'm expecting using GDALCopy Words() and I was
wondering if someone might have some insight into where I'm going wrong. I'm
reading data from a raster block by block. I read the block data into an array.
I'm calling GDALCopyWords() like this:
GDALCopyWords(
14 matches
Mail list logo
