Marc,
Wouldn't it be sufficient to create a warped vrt dataset either by
opening the corresponding xml file or using the AutoCreateWarpedVRT
API?
Then you might want to use ReadRaster on that dataset so as to load
the stuff into an in-memory buffer.
Currently there's no native way to access the w
2008/8/29 Adam Nowacki <[EMAIL PROTECTED]>:
>
> Im trying to design a interface with lowest overhead possible. Driver doesnt
> have to keep its own buffer and later copy, received data can be directly
> dumped into user buffer.
>
Adam,
As I have noted in the previous post we cannot easily conside
2008/8/29 Even Rouault <[EMAIL PROTECTED]>:
> Tamas,
>
> The only thing that was in Adam's proposal and that I don't find in yours is
> that, when the RasterIO in async mode returns something valid, the user has
> no way to know which part of the buffer has been updated by the driver. Thus,
> it in
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_COMPLETE
messa
Tamas,
The only thing that was in Adam's proposal and that I don't find in yours is
that, when the RasterIO in async mode returns something valid, the user has
no way to know which part of the buffer has been updated by the driver. Thus,
it introduces some extra cost for progressive image displ
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_COMPLETE
> message)
>
Ad
Hi Gdal folks,
Let's say we would like to use GDAL warping capabilities for resampling a
dataset (without saving it on a file) at specific xcell and ycell with a
specific resampling method but in Csharp. What would be the best way to do
it?
Let me guess:
- First maintain our own Gdal build (that'
Craig Miller wrote:
Thanks Brent. I'm looking for a C/C++ solution. I'll take a look at
the other polygon processing libraries as well as the level of effort
in porting JTS Cascaded Unions to Geos... that's a conversation for a
different mailing list though.
Craig,
I agree with Brent that pe
Thanks Brent. I'm looking for a C/C++ solution. I'll take a look at the other
polygon processing libraries as well as the level of effort in porting JTS
Cascaded Unions to Geos... that's a conversation for a different mailing list
though.
Craig
-Original Message-
From: Brent Fraser
VRTDatasets seem to be the best way to go in this case. Is there by chance a
way to build a VRTDataset that is an exact copy of a GDALDataset or do I need
to do it manually (not a big deal if I do). BTW, Thanks for all the help.
Christiaan
-Original Message-
From: Lucena, Ivan [mailto:[
I would take a look on how gdal_translate process the "-a_srs"
parameter:
http://trac.osgeo.org/gdal/browser/trunk/gdal/apps/gdal_translate.cpp#L311
Christiaan Janssen wrote:
My problem with this is that I'm not actually trying to reproject the data. The
best example of what I'm doing is try
My problem with this is that I'm not actually trying to reproject the data. The
best example of what I'm doing is trying to create a GeoTIFF version of a
standard TIFF (ie create a full raster copy but with GeoTIFF tags for the
projection and transform embedded), at the same time not limiting my
Christiaan Janssen wrote:
Could someone tell me the best/easiest way to create a copy of a
GDALDataset from one format to another and specifying a projection
different than what is contained in the source GDALDataset.
Have you tried to follow this [1] tutorial, see
GDALCreateGenImgProjTransfor
Could someone tell me the best/easiest way to create a copy of a GDALDataset
from one format to another and specifying a projection different than what is
contained in the source GDALDataset. I realize the CreateCopy does most of this
but I'm forced to use the projection contained in the source
Craig,
I've had limited success with the Union function in Geos (via GDAL). It's
slow and fails on large polygon sets (some of my files have 10,000 polygons
with some convoluted geometry), but if your sets are smaller, it may work.
FYI, Geos is derived (ported?) from JTS; Martin Davis has a
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
Norman,
Honestly I didn't follow the observations that have turned the things
into a different approach, however I agree that doing callback on
different threads might not be the most reliable option in some cases.
By reviewing the current proposal I'm a bit uncertain about how the
objective des
After updating gdal from svn (15242), I get an error in swig/python when
running the install target:
numpy include /usr/lib/python2.5/site-packages/numpy/core/include
running install
running bdist_egg
running egg_info
writing GDAL.egg-info/PKG-INFO
writing top-level names to GDAL.egg-info/top_le
18 matches
Mail list logo
