Its just how compression works. If some data is reduced in size then
other has to grow in size. Try -co compress=deflate -co PREDICTOR=2
On 2011-06-15 19:43, Matt Wilkie wrote:
Hi Folks,
I've run into a strange thing, "gdal_translate -co compress=lzw" is
creating files that are larger than the
Easiest would be to just gdal_translate -co COPY_SRC_OVERVIEWS=YES from
properly setup gdalwms source, see http://gdal.org/frmt_wms.html . Local
files can be accessed by using "file:///..." in in ServerURL.
On 2011-01-19 22:14, Jean-Claude Repetto wrote:
Hello,
I am looking for a method to cr
Can you test http://trac.osgeo.org/gdal/changeset/21304/trunk ? Add
true inside .
Jukka Rahkonen wrote:
Jukka Rahkonen mmmtike.fi> writes:
We would like to use gdal_translate for reading fromn our WMS service
which is> secured by our own certificate and thus not automatically
trusted. Our
default block size is 1024x1024 so the 2000x2000 image is split into 4
requests: 1024x1024, 976x1024, 1024x976 and 976x976
Travis Kirstine wrote:
I am doing some testing of the WMS driver with gdal and have a
question. If I define the and parameters as 2000px I
would expect that the WMS requ
I agree with the RFC 3: GDAL Commiter Guildlines.
Even Rouault wrote:
Motion: Extend GDAL/OGR Commit Access to Adam Nowacki.
---
Hi,
Adam is the author of the GDAL WMS driver, that he contributed during the 2007
Google Summer of Code. Since then, he has regularly taken part to discussions
Cassanova, Bill wrote:
*Well, I sorta tried that:*
gdalwarp -s_src '+proj=WGS84' -t_srs '+proj=merc'
hiradff_200910121800_f180_weather_radar.tiff foo.tiff
-s_srs not -s_src
Please, before posting on this list, at least check for typos!
___
gdal-dev m
Cassanova, Bill wrote:
result = GDALGenImgProjTransform(hTransformArg, TRUE, 1, &x, &y,
NULL, &success);
std::cout << std::fixed;
std::cout << result << " " << lower_right.first << ", " <<
lower_right.second << " = " << x << ", " << y << std::endl;
*//** 1 -65.656
Chris Emberson wrote:
The rasters do have colour tables applied, that are expressed using RGB
values, using gdaldem:
75%10700
50%19610927
25%24719572
0%252233109
nv000 0
They are not derived from vector data however. I am unsure of you
You can test with http://pastebin.com/m45e46f53
Also remember to use -wo SKIP_NOSOURCE=YES
Hermann Peifer wrote:
Adam Nowacki wrote:
Some rather counterintuitive gdalwarp behavior: the bigger
dfWarpMemoryLimit (-wm setting) the more cpu time will be wasted on
warping not existing pixels. Why
Some rather counterintuitive gdalwarp behavior: the bigger
dfWarpMemoryLimit (-wm setting) the more cpu time will be wasted on
warping not existing pixels. Why? Warping begins with the destination
window size of entire output image size. If this size is larger than
dfWarpMemoryLimit it is split
Jorge Arévalo wrote:
fPixelSizeX = atof(PQgetvalue(hPGresult, 0, 2));
I get 0.89976158142 instead of 0.9.
0.89976158142... is the value closest to 0.9 that a single precision
float variable can store.
Using 'double' should give 0.90002220...
Something like:
OGRSpatialReference sr;
sr.SetFromUserInput("+proj=geocent");
Christopher Hunt wrote:
Sorry for the hopefully not so dumb question here.
If I want to transform from one projection to a projection of the earth
in 3D, how would I set up my target srs?
I want to take a WGS-84 la
Seth Price wrote:
I actually hope to be addressing performance in my GSoC project. I'm
interested in rewriting the GDAL resampling code to CUDA, so the graphics
card does the hard work. For example, instead of processing one pixel at a
time, the latest GeForce GTX 260 would be able to process 216
Even Rouault wrote:
What raster format would you suggest then?
I mean, based on those requirements:
- Multiband;
- Large files;
- Good performance *reading* the data in pixel space. Not the "band as
usual" ;)
How about rotating the axis so:
stored x axis = data time axis,
stored y axis = data
int bands[4] = { 3, 2, 1, 4 };
GDALDataset::RasterIO(..., 4, bands, 32, 32 * xSize, 1);
but then you probably mixed bits with bytes so:
int bands[4] = { 3, 2, 1, 4 };
GDALDataset::RasterIO(..., 4, bands, 4, 4 * xSize, 1);
[EMAIL PROTECTED] wrote:
I have a BGRA buffer in memory, and a multi-band
http://gdal.org/ogr/drv_ogdi.html
Aurélien Kamel wrote:
Hi all,
For a project I’m working on I’m looking for a GDAL driver that could
read (read only) VMAP files (level 0 and 1). Does such a driver already
exist? The project is quite restrictive, we must use GDAL (and OGR) and
we can’t do
Tamas Szekeres wrote:
Hi All,
Upon thinking about the issues I've been come up with previously, I
consider the following approach could be implemented easily either at
driver or at SWIG interface level. Requires a new class to be
implemented by the async IO supported drivers and a new additional
Tamas Szekeres wrote:
2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>:
In my proposal the user could:
1) LockBuffer()
2) display the current snapshot
3) UnlockBuffer()
4) sleep for 100ms ignoring the update messages (but
NextAsyncRasterIOMessage() still has to be called to get the GARM_CO
Ill talk about my original proposal
(http://lists.osgeo.org/pipermail/gdal-dev/2008-August/018088.html)
instead of the one on trac
(http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support).
Tamas Szekeres wrote:
Honestly I didn't follow the observations that have turned the things
into
Even Rouault wrote:
I don't know JPIP, but I can image that the driver would start a thread when
AsyncRasterIO() is called. It communicates with the server and receives the
updates with a polling loop. When it has received an update,it put the
received data as well as the parameters describing
Norman Barker wrote:
I have created RFC 24 on
http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
I'd suggest creating completely new interface for this.
Why is this better (imo):
- application decides when and how ofter the updates occur, minimal
threading issues
- clearly define
21 matches
Mail list logo
