Need to make the "jp2kakdataset" recognize vsisubfile. Guidance appreciated.
===
gdal_translate -of NITF -co IC=C8 foo.tif foo.ntf
Input file size is 5677, 2428
ERROR 4: `/vsisubfile/933_41351268,foo.ntf' not recognised as a supported
file format.
>>I *think* it could be trivially extended to support JP2KAK with a case
>>similar to the one for JasPer with the filename encoded using the
>>/vsisubfile/ mechanism.
Frank, I'm looking into this now. Partial success
gdal_translate -of NITF -co IC=C8 foo.tif foo.ntf
Input file size is 5677, 24
Thanks, you were right on both counts.
1. Code change in nitfimage.c fixed the ERDAS/Global Mapper error.
2. To get the improved accuracy I did have to specify the GEOPSB TRE as
well.
To make this work in mapserver I'll need to do something like the following,
but that means the OUTPUTFORMAT will
Even thanks for all your help. With the correct syntax the NITF generation
does complete without error. But it seems that writing GEOLOB also changes
the way IGEOLO is written.
EXAMPLE:
If I don't create the GEOLOB, then IGEOLO is written as follows.
IGEOLO 258041N0665839E250841N0665915E250807
Even, thanks for responding. The ultimate goal is to serve up NITFs via
MapServer. So if we need to specify a TRE option, we would need to define it
in the mapfile.
Still, this is a good lead. Do you have any guidance on exercising this from
the command-line?
gdal_translate -of NITF -co TRE=GE
Just wanted to confirm. NITFs potentially store location data in 2 places.
IGEOLO and GEOLOB. But GEOLOB has more accuracy (more decimal places).
There was a ticket which modified the NITF driver to read GEOLOB (if
present),
http://trac.osgeo.org/gdal/ticket/3180
But the NITF driver does not w
Thanks to Chaitanya kumar for the help.
Specifying a BLOCKXSIZE and BLOCKYSIZE on the command line solved this.
gdal_translate -of NITF -co BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 foo.tif
foo.ntf
Furthermore, adding these options to my mapserver map file worked as well.
OUTPUTFORMAT
NAME NITF
I'm seeing an issue with generating large NITFs 1GB+.
1. I've tried using "GDAL1.7dev" in Linux and "GDAL 1.7.2" in Windows.
2. The images are all 8-bit 3band.
3. I've tried going from
TIF --> NITF
Tiled-tif --> NITF
NITF --> NITF
4. In terms of validating the input data, I've l
Thanks Tamas,
I have a ton of info, and logs, from the various combinations of things I've
tried. I can provide the output .so libraries if you think it will help.
I did one interesting experiment where I included gdal_wrap.cc in the
compilation of "libgdal.so". This exposed the bindings dir
In the past I've opened threads on GDAL/Mono. This may have been too specific,
so I'd like to rephrase the topic to include GDAL SWIG bindings for any
language in Linux.
Just looking for feedback. Has anyone succeeded in getting the bindings to work
in Linux? I realize the buildbots generate
1. Should rely on $(CXX) $(CC) and including GDALmake.opt for building
the .cpp .c .cxx files
What does this mean, in terms of actually creating a build? In other words,
what does "Should rely on" mean? Do I set a flag, an environment variable?
--
View this message in context:
http://n2.n
Tamas:
I've been working on the Mono bindings for gdal for months now. All these steps
look like they might solve my problem, but I'm having trouble translating them
into actions. For example:
2. $(LD) should be used instead of $(LD_SHARED) when linking the
shared libraries with libtool.
Do
12 matches
Mail list logo
