When running 'epsg_tr.py -wkt 3857', gdal produces the WKT listed below.
I believe the projection that is stated in the WKT is incorrect though.
The combination of WGS 84 as base geogcs with Mercator_1SP as projection
means that the regular ellipsoidal Mercator projection will be used
which is
Selon Pepijn Van Eeckhoudt pep...@vaneeckhoudt.net:
When running 'epsg_tr.py -wkt 3857', gdal produces the WKT listed below.
I believe the projection that is stated in the WKT is incorrect though.
The combination of WGS 84 as base geogcs with Mercator_1SP as projection
means that the regular
On 14-12-12 10:10, Even Rouault wrote:
Selon Pepijn Van Eeckhoudt pep...@vaneeckhoudt.net:
I also believe that the current WKT definition is known to be a bit hackish (is
there some official/generally agreed name for the projection that should be used
?). But you are probably using not the most
On 14-12-12 10:10, Even Rouault wrote:
I also believe that the current WKT definition is known to be a bit hackish (is
there some official/generally agreed name for the projection that should be used
?). But you are probably using not the most recent version of GDAL, since recent
versions
I'm running in to a situation where I believe the filesystem cache
settings are screwing things up. Based on iozone tests I'm not getting
near the throughput I should for large 4gb+ files with multiple writing
processes. It is a complex interaction of the number of dirty pages in
filesystem cache
Interesting:
http://www.centos.org/docs/4/html/rh-gfs-en-6.1/s1-manage-direct-io.html
---Original Message---
From: Ethan Alpert ealp...@digitalglobe.com
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Can GDAL be configured to do direct I/O? (bypass cache,
control blocksize,
Selon Ethan Alpert ealp...@digitalglobe.com:
I'm running in to a situation where I believe the filesystem cache
settings are screwing things up. Based on iozone tests I'm not getting
near the throughput I should for large 4gb+ files with multiple writing
processes. It is a complex interaction
Hi list,
This should simple, but I failed to make it work. I simply want a black
pixels in a RGB GeoTIFF to become transparent or white. Using GDAL 1.6.3.
I'm trying
gdalwarp -srcnodata 0 -dstalpha in.tif out.tif
I also tried (since it's RGB)
gdalwarp -srcnodata 0 0 0
Hi,
GDALDataset::RasterIO pass the request off to each band objects
rasterio methods with appropriate arguments
In GDALRasterBand::RasterIO
(http://www.gdal.org/classGDALRasterBand.html#a5497e8d29e743ee9177202cb3f61c3c7)
Some formats may efficiently implement decimation into a buffer by
Seems like this is a straightforward issue but finding it difficult to solve
online.
I have a new crop of 4-band orthoimages, as GeoTIFFs. I want to create mosaics
of some tiles. There is a slight pixel overlap at the edges. When I run
gdalwarp it always treats the 4th band as alpha,
Le vendredi 14 décembre 2012 19:17:07, Smith, Michael a écrit :
Seems like this is a straightforward issue but finding it difficult to
solve online.
I have a new crop of 4-band orthoimages, as GeoTIFFs. I want to create
mosaics of some tiles. There is a slight pixel overlap at the
Thanks Evan
BUT
Firstly in my binaries-only install I don't see any .cpp files
And secondly the other method (using VRTs) how would one then automate that (to
do, say 1000 tiles in a script). The editing of the VRT would be the tricky
part.
==
Michael
And secondly the other method (using VRTs) how would one then automate that
(to do, say 1000 tiles in a script). The editing of the VRT would be the
tricky part.
sed s/ColorInterpAlpha\/ColorInterp// should do it
But actually I think that if you just want to mosaic files in the same
Anyone looked at the trying to read in the geosoft.com file formats (.gdb) used
in their mineral and oil/gas exploration software.
They already have ERMapper and ArcGIS extensions as well as an SDK, though I
don't know how deep it goes..
gdal_translate -of VRT input.tif output.vrt -b 1 -b 2 -b 3
Mike, you can try to adapt that call to a for loop if it does what you expect.
---Original Message---
From: Smith, Michael michael.sm...@maine.gov
To: gdal-dev@lists.osgeo.org gdal-dev@lists.osgeo.org
Subject: Re:
15 matches
Mail list logo