Even wrote:
Hermann,
I'm not aware of any GDAL Trac ticket with the patch attached, some text
explaining why and when it is necessary/usefull, and ideally a step by step
scenario and sample data that demonstrates its usefulness. This is the general
procedure to submit enhancements & bug fixes, o
Selon Markus Neteler :
Hermann,
I'm not aware of any GDAL Trac ticket with the patch attached, some text
explaining why and when it is necessary/usefull, and ideally a step by step
scenario and sample data that demonstrates its usefulness. This is the general
procedure to submit enhancements & bu
On Tue, Sep 1, 2009 at 8:39 AM, Hermann Peifer wrote:
> Jukka Rahkonen wrote:
>>
>> Hermann Peifer gmx.eu> writes:
>>
>>> Adam wrote:
You can test with http://pastebin.com/m45e46f53
Also remember to use -wo SKIP_NOSOURCE=YES
>>> Adam,
>>>
>>> Will your patch appear in trunk/gda
Jukka Rahkonen wrote:
Hermann Peifer gmx.eu> writes:
Adam wrote:
You can test with http://pastebin.com/m45e46f53
Also remember to use -wo SKIP_NOSOURCE=YES
Adam,
Will your patch appear in trunk/gdal/alg at some point in time?
Hi,
It would be very interesting to
test the effect of this
Hermann Peifer gmx.eu> writes:
> Adam wrote:
> > You can test with http://pastebin.com/m45e46f53
> > Also remember to use -wo SKIP_NOSOURCE=YES
> >
>
> Adam,
>
> Will your patch appear in trunk/gdal/alg at some point in time?
Hi,
I had less time than I thought for testing gdalwarping .vrt f
Adam wrote:
You can test with http://pastebin.com/m45e46f53
Also remember to use -wo SKIP_NOSOURCE=YES
Adam,
Will your patch appear in trunk/gdal/alg at some point in time?
Hermann
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osg
Adam Nowacki wrote:
You can test with http://pastebin.com/m45e46f53
Also remember to use -wo SKIP_NOSOURCE=YES
Now the input images are read in many chunks, rather than 1 (or max 2)
before. Nevertheless, the performance is really great. Now, 100 tiles
are warped in 5 minutes! That's 4-5 time
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?
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? Warping begins with the destination
window size of entire output image size. If this size is larger than
dfWarpMe
On Aug 22, 2009, at 4:51 AM, Hermann Peifer wrote:
Just to repeat my earlier observations: over the last days, I tried
with all kinds of -wm and GDAL_CACHEMAX settings, and also added
the options TILED=YES and SKIP_NOSOURCE=YES. I haven't documented
the performance changes systematically, b
Selon Mateusz Loskot :
Actually, it would rather belong to
http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp
> 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
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? Warping begins with the destination
> window size of entire output image size. If this size is larger than
> dfW
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? Warping begins with the destination
window size of entire output image size. If this size is larger than
dfWarpMe
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
Frank Warmerdam wrote
Jukka Rahkonen wrote:
Conclusion: Too slow to be useful with my settings.
Question 1: Should it work this way?
Question 2: If yes, is it worth trying to find the limits when it goes
too slow
and perhaps file a ticket?
I hate to bring this up so late in the discussion,
Jukka Rahkonen wrote:
Gdalwarp has now been running for 27 hours. Process is taking 70 megabytes of
memory and 5-15 percent of processor time. As a result I have now output tiff
file that is very, very slowly growing in size. Now, after 27-hour run the
filesize is 13 gigabytes. Judged by the file
Just a thought, but 2.3GB is remarkably like the maximum size of a positive
32bit integer. Is the file being written on Windows or some other 32bit system?
Peter
Even Rouault wrote:
Quoting Rahkonen Jukka :
Jukka, you can probably speed up considerably the gdalwarp
process by adding "-co TIL
Quoting Rahkonen Jukka :
> >
> > Jukka, you can probably speed up considerably the gdalwarp
> > process by adding "-co TILED=YES" to the gdalwarp
> > commandline. For such a big output file, using the default
> > stripped structure of a TIFF will be very inefficient because
> > the way gdalwarp pro
Even Rouault wrote:
> Quoting Jukka Rahkonen :
>
> > Hermann Peifer gmx.eu> writes:
> >
> > >
> > > Jukka wrote
> >
> > > >
> > > > Did you try to use gdalwarp also for the second step with
> > > > -srcnodata
> > value
> > [value...]? I believe you did set
> > > some NODATA value in step 1 fo
Quoting Jukka Rahkonen :
> Hermann Peifer gmx.eu> writes:
>
> >
> > Jukka wrote
>
> > >
> > > Did you try to use gdalwarp also for the second step with -srcnodata
> value
> [value...]? I believe you did set
> > some NODATA value in step 1 for the intermediate images.
> > >
> > > -Jukka Rahkonen-
Hermann Peifer gmx.eu> writes:
>
> Jukka wrote
> >
> > Did you try to use gdalwarp also for the second step with -srcnodata value
[value...]? I believe you did set
> some NODATA value in step 1 for the intermediate images.
> >
> > -Jukka Rahkonen-
>
> I did. However, the main problem with
Jukka wrote
From: Hermann Peifer gmx.eu>
A promising approach seemed to be to warp/resample the ASTER files one by one
and create 1500 separate tiles
in LAEA projection, as an intermediate step. Then I created a vrt file with
gdalbuildvrt and
gdal_translated it into tiff format. The result d
Robert Coup wrote
On Sat, Aug 15, 2009 at 10:57 PM, Hermann Peifer wrote:
I have the same observation while working with ASTER GDEM tiles (1x1 degree
tiles, 3601x3601 pixel each). When warping/merging, say: 10 tiles into a
single outfile.tif, then it takes gdalwarp around 5 seconds per tile to
On Sat, Aug 15, 2009 at 10:57 PM, Hermann Peifer wrote:
>
> I have the same observation while working with ASTER GDEM tiles (1x1 degree
> tiles, 3601x3601 pixel each). When warping/merging, say: 10 tiles into a
> single outfile.tif, then it takes gdalwarp around 5 seconds per tile to do
> the job
Felix Schalck wrote:
Hello,
As explained in my previous question, I'm trying to create a high
resolution topographic map of europe based on cgiar processed srtm
data. Of cours, the first step is to merge the 5*5° tif tiles into one
big tif, which can be achieved using gdalwarp's mosaic feature.
25 matches
Mail list logo
