[gdal-dev] [PROPOSAL] Add CADRG write support via RPFTOC/NITF drivers
Patrik Sylve
patrik.sylve at t-kartor.com
Thu Jun 12 01:47:43 PDT 2025
Thank you all for the inputs!
Our use cases are also within defense applications, so the format is indeed still in active use.
Frank, good point. I'll definitely keep that in mind. Some scripting approach sounds like a reasonable approach if it turns out to be too tedious to get full support working directly in the driver.
As for VQ-compression, yes, this will be an interesting challenge. I came across this paper referenced in the CADRG standard, looks like promising reading https://apps.dtic.mil/sti/tr/pdf/ADA283396.pdf.
Thanks again, I'll keep the list updated as things progress
Best regards / Vänliga hälsningar
Patrik Sylve
Software Developer
E: patrik.sylve at t-kartor.com
www.t-kartor.com
________________________________________
From: Frank Warmerdam <warmerdam at pobox.com>
Sent: Wednesday, June 11, 2025 16:26
To: Patrik Sylve <patrik.sylve at t-kartor.com>
Cc: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] [PROPOSAL] Add CADRG write support via RPFTOC/NITF drivers
You don't often get email from warmerdam at pobox.com. Learn why this is important
Patrik,
I have no objection to such a proposal, but in my experience with specific NITF based product profiles it is often not worth trying to support completely based on write support built into the GDAL drivers themselves. For producing NCDRD compliant NITF files our approach at Planet has been to produce many of the auxilary segments (TREs and DESs) in python code ourselves and then pass via the GDAL NITF TRE= and DES= creation options. We did of course have to have some core header field construction logic supported in the NITF driver, and JPEG2000 write support.
Anyways, depending on how complex you find your CADRG driver write support gets, you might want to consider doing parts of the work externally --- ideally as an example python or similar script that could be shared, and customized with others without having to implement full generalized write support within the drivers themselves.
Like Even I was surprised to see CADRG creation capability was still relevant in 2025.
I am curious if there are many folks out there with an interest in NCDRD compliant NITF production (and also SNIP production -- an upcoming project). I'm wondering if it would be worth a blog post, or perhaps a presentation at FOSS4G one day. I will offer I am happy to chat with folks going through similar projects.
Best regards,
Frank
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | USA: +1 650-701-7823
and watch the world go round - Rush | CAN: +1 343-550-9984
More information about the gdal-dev
mailing list