Hi Everyone,
Just fyi, I can't build gdal with an external libgeotif without doing a
hack... Both gdal and libgeotiff from svn trunk. libtiff, geotiff were
installed in a fresh sandbox. Then configured gdal to use external
libtiff/geotiff.
I got gdal to build by removing the libgeotiff in
tree. So it's less complicated and this makes for easy installs
/ uninstalls.
Dave
On 11-11-03 05:31 PM, Mateusz Łoskot wrote:
On 3 November 2011 21:24, David Burken wrote:
Just wondering if you've thought about namespacing the include
paths? That
is:
#include "c
Mateusz,
Just wondering if you've thought about namespacing the include paths?
That is:
#include "cpl_config.h"
#include "gdal_frmts.h"
Becomes:
#include
#include
Or (flattened):
#include
#include
This would make installs / uninstalls cleaner. Say your install prefix is:
/usr/local
Mateusz, all:
It's good to hear there is an effort in this. The dependencies/optional
packages will be painful I expect. If you need testers for Fedora I can
help just let me know.
Take care,
Dave
On 10/19/2011 09:37 AM, Mateusz Łoskot wrote:
On 19 October 2011 13:42, Jayesh Chaudhary wr
Resolved thank you.
On 07/17/2011 01:58 PM, Even Rouault wrote:
Selon David Burken:
Even,
See below with more info, looks like there are multiple defined things
including external cpl_serv.h. Hope this helps.
Dave
Yes, this was helpful. Should be fixed now. See
http://trac.osgeo.org/gdal
://trac.osgeo.org/gdal/ticket/4162
I presume the problem occurs with an external libgeotiff but haven't yet tried
to reproduce the problem.
Best regards,
On Sat, Jul 16, 2011 at 7:06 AM, Even Rouault
wrote:
Selon David Burken:
Dave,
I presume you build GDAL against external libgeotiff, and not int
Hi Frank, all,
Just fyi, getting build error from svn. Looks like cpl_serv.h is gone
now. See below for minor patch.
Take care,
Dave
$ svn update
At revision 22725.
gt_wkt_srs.cpp:33:22: fatal error: cpl_serv.h: No such file or directory
compilation terminated.
make[1]: *** [../o/gt_wkt_sr
Hi Frank, all,
Just fyi we had some nitf data that had jp2 blocks with ycc color
space(JP2_sYCC_SPACE=18) . ossim was crashing because the bands were
set to 3 in the nitf but kakadu was expanding only one channel. I
checked gdal and it was returning only one band(no crash). Anyway
feeding
On 11/29/2010 10:09 AM, Mateusz Loskot wrote:
On 29/11/10 14:57, Even Rouault wrote:
David,
yes, on most 64bit platforms, sizeof(long long)=sizeof(long)=8.
Except on Win64,
where sizeof(long) still = 4 ( see
http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models
). And of
course
Guys,
Just fyi, a long on my machine (Linux 2.6.35.6-48.fc14.x86_64) is 8
bytes. It's the same as long long.
Dave
On 11/28/2010 02:39 PM, Even Rouault wrote:
Frank,
If I agree we can upgrade the C++ API of OGRLayer::GetFeature() and
DeleteFeature() to use GIntBig instead of long, I'm wond
Hi,
In case someone else hits this I needed to uncomment the "WIN64=YES" in
the nmake.opt and everything linked great from an svn build.
Thanks,
Dave
On 11/03/2010 02:25 PM, David Burken wrote:
Hi Everyone,
Just curious has anyone successfully built gdal with VS10? I'm not
Hi Everyone,
Just curious has anyone successfully built gdal with VS10? I'm not
familiar with the link syntax like "/INCLUDE:_OGR_G_GetPointCount" but
all of those are unresolved when linking gdal library. Any ideas
appreciated. See below for build error.
Take care,
Dave
lib /n
Hi Everyone,
gdalinfo was core dumping in method HDF5AttrIterate on some hdf5 data we
have. The value of nAttrSize was greater than the hard coded array
length of 8192. I changed the array size to be dynamic and it seems to
be working now on my small sample of two data sets.
svn diff belo
On 14/06/10 13:32, David Burken wrote:
Hi Everyone,
Just curious if there are any thoughts on migrating to cmake?
A prototype project's started:
http://code.google.com/p/gdal-cmake/
However, it's a bit suspended, temporarily I hope.
Best regards,
--
Mateusz Lo
On 06/14/2010 04:41 AM, Gianni Olivieri wrote:
2010/6/14 Gianni Olivieri:
2010/6/11 Gianni Olivieri:
2010/6/11 Matt Klaric:
While you certainly can accomplish this using GDAL, you'll need to first
figure out which hgt file to open, then translate the geographic coordinate
to
Hi Everyone,
Just curious if there are any thoughts on migrating to cmake?
Regards,
Dave
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Enrico,
I like to build straight from cvs:
cvs -d :pserver:cvsa...@cvs.maptools.org:/cvs/maptools/cvsroot co libtiff
Take care,
Dave
On 07/23/2009 04:56 AM, Enrico Sartorello wrote:
Hi all,
i need to have a correct BIGTiff package for using it in a program
i've written in C.
As far as i c
17 matches
Mail list logo
