As a follow up on this issue, if I remove the -of VRT on the
gdal_translate it will create a geotif and then ALL the tiles are
extracted without any errors. So this looks like a bug in gdalwarp or in
the JP2MRSID driver since the jp2 can be converted to a geotif without
errors and gdalwarp will work with it, but has trouble when you try to
extract sub-zones from the jp2 image.
Currently, I only have 500MB jp2 files to work with, I will look through
the files and see if I can find a smaller one that exhibits the same
behavior.
Does anyone else have any of these large county composite jp2 images
that they can try and confirm this issue with?
-Steve
Stephen Woodbridge wrote:
Hello,
I posted this buried in another thread and thought it should be reposted
in its own thread. A short history, I have a lot of USDA county
composite DOQQs that have been assembled into JPEG2000 files that are
about 500MB each. I am trying to chop these back into DOQQ GeoTiffs. I
have a script that does the chopping, it just automates the process and
issues commands to do the work.
I have abandon using the JPEG2000 driver and an now using the JP2MRSID
driver. This is working better, but I'm still having problems like this:
I create a VRT file as follows for each jp2 file:
mkdir -p /home/swoodbridge/tiler-tiffs/30430-1226332146/src
gdal_translate -of VRT
/var/data/raw_data/minnesota/ortho_1-1_1m_j_mn161_2008_1.jp2 -b 1 -b 2
-b 3 /home/swoodbridge/tiler-tiffs/30430-1226332146/src/tmp.vrt
then the VRT file is iterated over to extract the tiles with commands like:
gdalwarp -srcnodata 0 -dstnodata 0 -s_srs +init=epsg:26915 -t_srs
EPSG:4326 -te -93.5 43.8125 -93.4375 43.875 -rb -wm 250 --config
GDAL_ONE_BIG_READ ON -co "TILED=YES"
/home/swoodbridge/tiler-tiffs/30430-1226332146/src/tmp.vrt
/home/swoodbridge/tiler-tiffs/30430-1226332146/B-93_43/B-93_43_041.tif
gdalwarp: ../compressed/compressed.cpp:1724: bool
kd_tile::read_tile_part_header(): Assertion `tpart_body_length >= 0'
failed.
Creating output file that is 6029P x 6029L.
This does not happen on all image tiles that I try to extract, but does
happen on a significant number of them like nearly 50% in one case. I
looked at the pattern of failures and it looks like failures happen
within a row of the jp2, so extracted tiles are G=good, X=bad, .=empty
................
..GGGGGGGGG.....
..GGGGGGGGG.....
..GGGGGGGGG.....
..GXXXXXXXG.....
..GGGGGGGGG.....
..GXXXXXXXG.....
..GXXXXXXXG.....
..GXXXXXXXG.....
..GXXXXXXXG.....
...GXXXXXXXG....
................
Any thoughts on this?
Is there a way to verify its compression integrity?
I have try two different jp2 files of the 300+ friles that need to to be
chopped up and gotten similar results.
Thanks,
-Steve
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
