I'm not sure if this is the right venue - please direct me to another list.
I am having an issue processing DigitalGlobe NTF/JPEG2000 imagery with GDAL and
MapServer.
I am currently using Version 1.8.1 MSVC2008 (Win64) -release with mapserver
6.0.1 found here:
http://www.gisinternals.com/sdk/
Hi,
I don't see any obvious reason this would fail in this fashion. I would
suggest you try and reproduce this with a very small file with lots of classes
and then file a ticket including the data.
Best regards,
On Sat, Jul 16, 2011 at 2:51 PM, jt2000 wrote:
> /usr/local/bin/pct2rgb.py -rgba r
/usr/local/bin/pct2rgb.py -rgba raster.grc convert.tif
*Traceback (most recent call last):
File "/usr/local/bin/pct2rgb.py", line 167, in
dst_data = Numeric.take(band_lookup,src_data)
File "/usr/local/lib/python2.7/site-packages/numpy/core/fromnumeric.py",
line 103, in take
return take
I have a large (>500MB) GRC file that is not being read by GDAL correctly.
*[me@server data]$ gdalinfo filename.grc
ERROR 4: `filename.grc' not recognised as a supported file format.
gdalinfo failed - unable to open 'filename.grc'.*
Is this due to the size? I have other 200MB files that work fi
Folks,
I should have mentioned more widely, I have written up a ticket on
this issue at:
http://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
Zoltan,
ERROR 6 is a generic error number, so a google on it would not be helpful.
It sounds like you got all or almost all your data, so I suppose how much you
followup will depend on how exactly you want to preserve the data.
Assuming you would like to follow up the best approach is likely to f
Selon David Burken :
Dave,
I presume you build GDAL against external libgeotiff, and not internal
libgeotiff. In any case, it is weird because cpl_serv.h should be installed when
installing libgeotiff (I've just verified it with libgeotiff from svn). So I
presume the include paths in the GDAL com
Selon Jim Pendleton :
I don't know anything about the particularities of Android, but the normal
procedure to build the GDAL Java bindings is running 'make' from the swig/java
directory. The swig/java/GNUmakefile should link the *jni.so files with libgdal.
You might need potentially to tweak it if
I downloaded and tried the mitab in Windows, and it gave me the record
number on which it failed.
True enough, that record in the MID file was incorrect according to the
schema.
So, for the next version of ogr2ogr, any chance we can get a record
number please :-) ?
Thanks for the pointer, C
Hi Chaitanya,
I'm shelling out from a Genamap script to Linux BASH shell, to run
ogr2ogr, so nope, not in Windows.
Regards,
Zoltan
On 2011/07/16 12:36, Chaitanya kumar CH wrote:
Zoltan,
If you are in Windows, try the mif2tab utility from
http://mitab.maptools.org/
OGR's Mitab driver is bas
Zoltan,
If you are in Windows, try the mif2tab utility from
http://mitab.maptools.org/
OGR's Mitab driver is based on the same library.
On Sat, Jul 16, 2011 at 3:34 PM, Zoltan Szecsei wrote:
> Hi,
> I'm converting a bunch of MID-MIF files to TAB format, and one of them
> gives:
> ERROR 6: Error
Hi,
I'm converting a bunch of MID-MIF files to TAB format, and one of them
gives:
ERROR 6: Error during reading Record.
google comes up with: CreateField() not supported by this layer
So I check the mif headers and they seem fine, and contain 240 POINT
records with schema layout of 43 fields
12 matches
Mail list logo
