On 11-05-17 03:31 PM, Petteri Packalen wrote:
Chaitanya, Frank,
I verified that only one libgdal exists in a system. I have also added '-co'
switch to gdal_fillnodata.py in order to force BigTiff creation (BIGTIFF=YES).
But the problem persists.
However, I think I have traced the problem down t
I think you configured it correctly.
Although the MG4 lidar SDK can be made to read .las files, the GDAL MG4Lidar
driver only knows how to read .sid files (and .view files - see docs).
I don't believe there is a way to read .las files using GDAL right now. You'll
probably need lasinfo from lib
Thanks Kirk and Chaitanya,
It was indeed GDAL_HOME. I used double quotes around it and after removing
it it is working.
LizardTeck provided some sample data. And I'm using it to check if my
version of GDAL is correct.
I use gdalinfo to check the .sid file and it works. When I do a gdalinfo on
the
The line it is complaining about is almost certainly the following line, where
MRSID_DIR is used for the first time. Not sure how it gets 72.
What is your value for GDAL_HOME? There might be some kind of quoting issue
going on. Also, I'm not sure I ever tested it with relative paths, so that
Paul,
Perhaps the variable $(GDAL_HOME) is not being substituted correctly. Try
the absolute path for MRSID_DIR.
On Wed, May 18, 2011 at 3:48 AM, Paul Meems wrote:
> Hi all,
>
> I'm trying to compile GDALv1.8 on Win7 using VS2008Pro.
> So far I've added successfully GEOS, cUrl, ECW, Proj.4 and
Hi all,
I'm trying to compile GDALv1.8 on Win7 using VS2008Pro.
So far I've added successfully GEOS, cUrl, ECW, Proj.4 and Xerces.
I'm now trying to add MrSid support.
I've downloaded the Unified Decode SDK v8 from LizardTech and changed this
in my nmake.opt:
MRSID_DIR =$(GDAL_HOME)\..\Lizard
Selon Petteri Packalen :
Yes, that's a very likely reason. When COMPRESS != NONE is specified, the driver
has no way to know if the file will be a regular tiff or a bigtiff, so it
chooses regular tiff. For your case, if you are in position to build GDAL by
yourself, you can try changing the follow
Chaitanya, Frank,
I verified that only one libgdal exists in a system. I have also added
'-co' switch to gdal_fillnodata.py in order to force BigTiff creation
(BIGTIFF=YES). But the problem persists.
However, I think I have traced the problem down to:
http://svn.osgeo.org/gdal/trunk/gdal/a
I'll install the latest and see if the problem disappears!
-mike.
On May 16, 2011, at 10:56 AM, Chaitanya kumar CH wrote:
> Michal,
>
> I can't think of anything else that may be causing this. Can you run this
> using the latest version, gdal-1.8?
>
> On Mon, May 16, 2011 at 11:14 PM, Michal
I hope youll enjoy after visiting this site...
http://comitemarnebillard.com/friends_links.php?saolid=69te9
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hello Even,
My apologies for the late reply.
I took the quick and not-so-dirty way : gdal is repackaged in the OTB
ppas, where I have applied the last strategy you mention : I let the
warning about libtiff version mismatch be emitted, but still register
the driver.
Everything is back to norm
On 11-05-17 07:54 AM, Jorge Martin wrote:
Hello Frank,
I am reading libtiff manual and it is possible to write different IFD
(directories, I do not know the correct word) in the same tiff file using
*TIFFWriteDirectory *function. Is it possible to use it in gdal library?
Jorge,
While in the
Petteri,
Can you confirm that you have no other libgdal at a different location. The
python script may be loading a different libgdal.
Also check the value of environment variable PYTHONPATH where you use the
FWTools utilities.
On Tue, May 17, 2011 at 3:40 PM, Petteri Packalen wrote:
> Hello,
>
Hello Frank,
I am reading libtiff manual and it is possible to write different IFD
(directories, I do not know the correct word) in the same tiff file
using *TIFFWriteDirectory
*function. Is it possible to use it in gdal library?
Many thanks,
Jorge
2011/5/17 Jorge Martin
> Hello Frank,
>
>
Hello,
I'm facing a problem related to BigTiff support in experimental FWTools3
on Linux. BigTiff support works fine with all compiled programs (e.g.
gdal_translate, gdalwarp) but not with the python script
gdal_fillnodata.py. For instance, executing:
gdal_fillnodata.py -md 10 unfilled.tif
Hello Frank,
TIFF 6.0 specifications has a sub-section in page 16 which is called
"Multiple Image per TIFF file" and there is only a description of this issue
but anything about its implementation:
"There may be more than one IFD in a TIFF file. Each IFD defines a subfile.
One potential
16 matches
Mail list logo
