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 tags
2009/3/7 Tomas R
>
> 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
>
>
I looked back and the issue have appeared to be solved by using the x64
binaries provi
2009/3/6 Tomas R
> 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
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 s
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 i
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,
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 framew
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 FrameworkDir=C:\WINDOWS\Microsoft.NET\F
Tamas, remember the detective work done last year.
32 bit C# interface won't mix at all with 64 bit runtime environment. or
have you found a way around that? have not followed the list for some
time, just now trying to create a 64-bit version of gdal.
Yes, I have a problem too, and yes a q ha
Trying to build a 64 bit version of GDAL on a Vista 32 bit installation
using Visual Studie Express C++ 2008.
So how do I do, and how does it go.
I start up the Visual Studio 2008 x64 Cross Tools Command Prompt. I set
in nmake.opt WIN64= YES
With this GDAL seems to compile ok, no errors and al
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 Ge
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 do
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 $(HDF5_DIR)\dll\hdf5dll.li
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 \ $(SZIP_D
That was exactly it, thanks very much Tamas.
-jeff
Tamas Szekeres wrote:
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.
Be
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
> I am building a 64-bit GDAL on a
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 -I.
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
18 matches
Mail list logo
