Frank,
I understand that the geotiff driver is not going to do 'seek write' for
every single pixel but since I am not giving it
a change to manage the blocks intelligently (as you said) it is probably doing
ever worse than that. Like Even said, it
is probably getting to a point that it needs
I am building a 64-bit GDAL on a 32-bit windows machine, and enabling
setargv throws this GDAL error when compiling:
*
cd apps
nmake /nologo /f makefile.vc
cl /nologo /MD /EHsc /Ox /W3 /D_CRT_SECURE_NO_DEPRECATE
/D_CRT_NONSTDC_N
O_DEPRECATE /DNDEBUG -I..\port
Jeff,
I'm guessing you're linking against an incorrect version of setargv.obj. I
see the Win64 version can be found in:
C:\Program Files (x86)\Microsoft Visual Studio 8\VC\lib\amd64
if you use VC2008 for example.
Best regards,
Tamas
2009/3/6 Jeff McKenna jmcke...@gatewaygeomatics.com
I am
Hi list,
I tried to create a dll only for hdf5 gdal files, i.e. 3 files in frmts/hdf5
which I modified.
I use MS Visual Studio 2008 and tried to do it with makfile.vc and obviously
included nmake.opt. Once I defined GDAL_ROOT, HDF5_DIR, SZIP_DIR, HDF5_LIB
as $(HDF5_DIR)\dll\hdf5dll.lib \
LFas wrote:
Hi list,
I tried to create a dll only for hdf5 gdal files, i.e. 3 files in frmts/hdf5
which I modified.
I use MS Visual Studio 2008 and tried to do it with makfile.vc and obviously
included nmake.opt. Once I defined GDAL_ROOT, HDF5_DIR, SZIP_DIR, HDF5_LIB
as
On Wed, Mar 04, 2009 at 11:16:46PM +1300, Robert Coup wrote:
Hey folks,
I'm struggling to build either the 1.5 branch or trunk on Ubuntu Intrepid
with gcc 4.3.2 and libtool 2.2.4. The symptoms are the same as described in
http://trac.osgeo.org/gdal/ticket/2138 , except updating ltmain.sh
I've recently begun migrating my Python scripts which use GDAL/OGR to
Python 2.5, and I noticed that GetHistogram?() returns a substantially
different histogram for a given image under 2.5 from what it returns
under 2.3.5. The file in question is a GeoTIFF, and in both cases I am
calling
Hi,
There's something missing in your vcvars.bat (ie vcvarsx86_amd64.bat for
the cross compiler version). Try to check the FrameworkDir and the PATH
environment variables to match with the current locations within the batch
file, like for example:
...
@SET
Hi Tomas,
I don't remember what the exact problem was, however the situation remains
the same, namely:
1. We can compile gdal either for x86 or x64. The x86 version could work
natively with the x86 version on the .NET framework and the x64 compilation
would work with the x64 version of the
When I issue the following SQL query through SqlPal I get 2 columns of
what appears to be valid data
select * from
(select OBJECTID, sdo_nn_distance(1) Dist from
GEONAMES_SDO a1 where DSG LIKE 'PPL%' AND sdo_nn(a1.shape,
sdo_geometry(2001, null, sdo_point_type(-84.4850,-21.9810,
Ah, thanks, will look it up more properly in the morning.
A quick check now did not reveal what may be missing. Strange, it is a
fresh installations of the VSE 2008 and SDK. It should work. Or?
Well, probably the version you linked to is good enough for me and also
a 64 bit version of Proj4
2. No, not in my control. So I will make use of the 64 bit version where
necessary.
If you wish refresh your memory, look back to my question in this list
at 2008-02-29 with subject C#: Gdal on Win64
There you, somewhere in the thread, have provided an explanation
Yours
Tomas
Tamas Szekeres
2009/3/6 Tomas R mon...@home.se
Ah, thanks, will look it up more properly in the morning.
A quick check now did not reveal what may be missing. Strange, it is a
fresh installations of the VSE 2008 and SDK. It should work. Or?
Well, probably the version you linked to is good enough for me
Hi,
a while ago I wrote an application using gdal_translate to translate tags in
a geotiff image. I used the following command: gdal_translate -a_srs $tagfn
$infn $outfn where $tagfn is the file used to modify the tags, $infn is the
input filename and $outfn is the output file name (with the
14 matches
Mail list logo
