Greetings Everyone,
I would like to programmtically use GDAL to write a C++ program that takes
two Geotiff images and uses the first image to create a mask that will be
applied to the second image. The first image geographically contains the second
image. The mask is computed from the fir
Frank,
That did it! I was able to get my query back down to < 2 seconds using:
SELECT * FROM alta83_v1 WHERE BOT_LONG > -114 AND BOT_LONG < -113 AND BOT_LAT
> 51 AND BOT_LAT < 52
Now I've got to enhance GeoMoose to calculate the view extents in Lat/Long and
hope mapserver will like a VRT la
Brent Fraser wrote:
Frank,
> Brent,
Any time you provide your own SQL it will be executed unaltered. The
spatial and attribute filters are only automatically built into the
select statement when the select statement is constructed internally
by OGR.
OGR makes *no attempt at all* to interpre
Frank,
> Brent,
Any time you provide your own SQL it will be executed unaltered. The
spatial and attribute filters are only automatically built into the
select statement when the select statement is constructed internally
by OGR.
OGR makes *no attempt at all* to interprete provided SQL (via E
Excellent Frank, thanks for the tips. I thought there might be a problem with
the /vsimem/ since only the VRT XML would be passed as an in-mem buffer, the
actual image data is in a disk file. I'll just pass the entire VRT XML for
simplicity.
-- Dan
> Date: Thu, 11 Jun 2009 12:54:30 -0400
>
Dan Greve wrote:
I'm using the VRT schema to open a raw binary image file. I can
successfully access the image data by creating a VRT file with the
necessary metadata, and then perform GDALOpen using the filename of the
VRT file. Is there a clean way to just create the VRT metadata file in
m
I'm using the VRT schema to open a raw binary image file. I can successfully
access the image data by creating a VRT file with the necessary metadata, and
then perform GDALOpen using the filename of the VRT file. Is there a clean way
to just create the VRT metadata file in memory, instead of
Brent Fraser wrote:
More performance news...
Using ogrinfo -> VRT -> ODBC -> SqlServer2000, the query using:
alta83_v1
- takes less than 2 seconds
Select * from alta83_v1
- a very simple select, logically equivalent to the above
- takes 30 seconds (!)
From the debug messages b
More performance news...
Using ogrinfo -> VRT -> ODBC -> SqlServer2000, the query using:
alta83_v1
- takes less than 2 seconds
Select * from alta83_v1
- a very simple select, logically equivalent to the above
- takes 30 seconds (!)
From the debug messages below,
