We are reading NITF images which occupy the lower 12bits of a 16bit
datatype. These images clearly have ABPP=12 and NBPP=16 set in the
header. However, when I use GetMetadataItem(NBITS), the string
returned is always 'null'. I have also tried GetMetadataItem(ABPP) -
which also returns 'null'.
I recently updated our GDAL source to version 1.7.3 from 1.7.1 and
suddenly we appear to have lots of black lines across any imagery read
using the GDAL (e.g. NITF files, WMS geotiffs). Wondering if it was a
1.7.3 issue, I switched to 1.7.2 which showed exactly the same problem.
Moving back to
Hi Ralf
What is the conclusion:
1. Are we going ahead with image-io 1.1 and GDAL 1.7.3 OR image-io
1.0.8 and GDAL 1.7.3
2. What about ELGIS 5?
Thanks
Viji
On Tue, Dec 14, 2010 at 4:25 PM, Mathieu Baudier mbaud...@argeo.org wrote:
# these tests still fail in EL5 environments
rm
Thanks Ivan,
I forgot to mention that I use GDAL 1.7.3.
It seems to me that the ECW api has changed quite a bit, as 1.7.3 doesn't
compile against it ?
For instance, I get
ecwcreatecopy.cpp(896) : error C2039: 'SetKeySize' : is not a member of
'NCS::CView'
In addition, the NCSJPC_EXPORT_ALL
Hi, I am the maintainer of gdal_retile.py. A user and me developed an
essential performance improvement for large images.
What is the best way to get the python file and the dox file into
trunk and into the 1.7 branch.
I have an OSGeo Account, but no svn commit access, so I could open a
Oyvind,
I tried adding those defines on ecw/makefile.vc and it did worked but I don't
know if that is the right thing do to:
-/DLIBECWJ2 /DWIN32 /D_WINDLL -DFRMT_ecw -DNO_X86_MMI
+/DLIBECWJ2 /DWIN32 /D_WINDLL -DFRMT_ecw -DNO_X86_MMI
-DECWSDK_VERSION=41 -DNO_COMPRESS
And, of
Hello Ari,
yes that is definitely helpful. But I still wonder if it might be
easier/quicker to use GeoJSON as a interchange format and tranform from
geojson to other formats than using OGRs internal structure. I already
have some convenience classes for creating GeoJSON structures in Python.
On 10-12-15 09:15 AM, christian.muel...@nvoe.at wrote:
Hi, I am the maintainer of gdal_retile.py. A user and me developed an essential
performance improvement for large images.
What is the best way to get the python file and the dox file into trunk and
into the 1.7 branch.
I have an OSGeo
Thanks !
I did allmost exactly the same as you, but didn't include -DNO_COMPRESS.
It compiles fine now. However, seems like it can't load gdal_ECW_JP2ECW.dll
anymore.
I now compile GDAL as a static lib, with ECW as a plugin. Could this result
in GDAL not loading dynamic plugins ?
-- Oyvind
On 12/15/2010 05:11 PM, Frank Broniewski wrote:
Hello Ari,
yes that is definitely helpful. But I still wonder if it might be
easier/quicker to use GeoJSON as a interchange format and tranform
from geojson to other formats than using OGRs internal structure. I
already have some convenience
On Dec 15, 2010, at 9:30 AM, Ari Jolma wrote:
On 12/15/2010 05:11 PM, Frank Broniewski wrote:
Hello Ari,
yes that is definitely helpful. But I still wonder if it might be
easier/quicker to use GeoJSON as a interchange format and tranform from
geojson to other formats than using OGRs
I am working on converting a NITF to imagine format using GDAL 1.7.2. I can
create files that are readble and seem to be correct in my program and
according to gdalinfo and hfatest, but they do not open in ViewFinder. If I
dumb down the geotransform so that a mapinfo node is added to the
Le mercredi 15 décembre 2010 12:58:15, Smart, Gary a écrit :
Gary,
I am not aware of such a corruption having been reported. Would you be able to
craft a small self-contained test case (code + data) that you could share and
that exhibits the issue ?
(well the issue you describe reminded me a
Le mercredi 15 décembre 2010 12:52:06, Smart, Gary a écrit :
We are reading NITF images which occupy the lower 12bits of a 16bit
datatype. These images clearly have ABPP=12 and NBPP=16 set in the
header. However, when I use GetMetadataItem(NBITS), the string
returned is always 'null'. I
On Dec 15, 2010, at 3:58 AM, Smart, Gary wrote:
I recently updated our GDAL source to version 1.7.3 from 1.7.1 and suddenly
we appear to have lots of black lines across any imagery read using the GDAL
(e.g. NITF files, WMS geotiffs). Wondering if it was a 1.7.3 issue, I
switched to 1.7.2
The image works in the real imagine viewer, so it could be Erdas' problem.
This is what IMAGINE has to say about the image I created:
Erdas Imagine File Information
--
File Name: po_1027098_red_000.img
Last
http://osgeo-org.1803224.n2.nabble.com/file/n5838904/gdalwarp_problem.doc
gdalwarp_problem.doc
Hi there,
I was trying to use GDALWARP command to do the NTv2 transformation on some
German map data (raster data). However I have come across a lot of errors
saying failed to find a grid table for
On 10-12-15 09:24 PM, heng.feng wrote:
http://osgeo-org.1803224.n2.nabble.com/file/n5838904/gdalwarp_problem.doc
gdalwarp_problem.doc
Hi there,
I was trying to use GDALWARP command to do the NTv2 transformation on some
German map data (raster data). However I have come across a lot of errors
I have seen that Even has invested some time into gdal_retile, writing
a test case on trunk and making some python specific changes to the
utility itself. Since gdal_retile.py was my first python program I
want to say thank you for that.
Comparing 1.7 to trunk, I see that gdal_retile.py
Thanks a lot, Frank. Your explanations really make sense to me. We have got
the raster data and the link for the grid shift file from one of our
customers. I think I need to check with the customer to find out what is the
possible reason. Will let you know if I have got any further question about
Am 15.12.2010 16:47, schrieb Howard Butler:
On Dec 15, 2010, at 9:30 AM, Ari Jolma wrote:
On 12/15/2010 05:11 PM, Frank Broniewski wrote:
Hello Ari,
yes that is definitely helpful. But I still wonder if it might be
easier/quicker to use GeoJSON as a interchange format and tranform from
21 matches
Mail list logo
