I don't know how to do that without significant code. What you can do, given the right gdal build, is to extract the image and recompress it as JPEG 2000. That would have the advantage of working with just about any NITF compression method, not just C8/M8. Obviously that does involve more CPU and
Do you have the two support files in the same directory? What errors do you get with the command line tool?___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
I note that NITF JPEG is a bit different to what libjpeg puts out by default. See MIL-STD-188-198A.I would interested to see sample data with C5/M5 IC. What makes it?BradOn 17 Jun. 2021 04:07, Even Rouault wrote:
Le 16/06/2021 à 19:53, GeodudeKid a écrit :
> We can refer to this:
I did not set any additional environment variables or macros. I just used my usual gdal build. You are of course free to do whatever you like. BradOn 28 Apr 2021 11:01 am, jovajova24 wrote:Brad, sorry for pushing but I'm going in circles here. It looks like you and
Even had this discussion i.e.,
Ok. Have a nice day. On 27 Apr. 2021 04:45, jovajova24 wrote:Brad,
Thanks for the reply!
The objects I'm referring to are what I have listed i.e.,
NITFSegmentInfo
NITFDESGetXml
These objects were changed in the PR I have listed i.e.,
Not disagreeing with the overflow assessment, but to make it easier to find, I would like to see the metadata (or better still the original file, but that is usually hard). Can you show at least PVTYPE, NBPP, ABPP, CLEVEL, IC, IMODE, IREP?On 7 Apr. 2021 10:09, ni hao wrote:
gdalinfo output i:
Also if you can show the headers (e.g. from gdalinfo), that might provide indication of exactly which value is the issue.BradOn 7 Apr. 2021 04:00, Even Rouault wrote:
Please keep the mailing list copied (I re-added it)
This is not the most recent one (3.2.2 is), but skimming quickly
What are you getting for the GeoJSON, and what else are you expecting? In particular, how are you expecting the style information to be represented? On 9 Feb 2021 6:05 pm, MRRAJESH wrote:Hey,
I am trying to convert a kml-file with styles to a GeoJSON. Observed that
only data is converted but
Possibly you need to build with spatialite support?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
It might help if you can say how you built GDAL. For example, how did you
set up the build-time variables in nmake.opt?
https://github.com/OSGeo/gdal/blob/master/gdal/nmake.opt#L56
Does the DATADIR there point to the directory that contains the right data?
Brad
From: gdal-dev On Behalf
Looks like (line 59)
type.startswith('TEXT(') or type.startswith('BLOB(')
Should be
typ.startswith('TEXT(') or typ.startswith('BLOB(')
(i.e. remove the two "e" characters)
Brad
From: gdal-dev On Behalf Of Rahkonen
Jukka (MML)
Sent: Thursday, 29 November 2018 8:36 PM
To:
: Friday, 2 November 2018 11:44 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to Use Gdal in Microsoft Visual Studio C++
Hai Bradh,
Sorry I not use to C++, I only familiar with C#. I need to use C++ because Gdal
support it and i need to combine it to the Visual Studio C# (Wpf
The problem below is nothing to do with GDAL, you just need to initialise the
variable (probably by some kind of command line argument - argv[1] if nothing
else). If that doesn't make sense, is there another programming language that
you are more comfortable with?
Brad
-Original
Maybe you could just use ogrinfo to extract the layers, and then iterate over
those using a bash for loop.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Can you please show the exact command you are using, and tell us whether the
geopackage you are using already exists (i.e. this is an append, not a create)?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Even,
It is not my compression, and although it isn't formalised yet, I think its
probably too late to change. I'll take it back to the NTB in any case.
The specific case is for "good enough" compression of floating point data
without (further) loss.
Thanks for the CPLZLibDeflate() helper
I've been looking at how much work it might take to implement a new NITF
compression value (IC=CC and IC=MC) which is basically just ZLIB DEFLATE
encoded blocks.
I'm mostly following the pattern used for JPEG, and its down to the part
where I just need to do the compression:
int
Things with two dashes are general options, which apply to all tools, and are
described in http://www.gdal.org/gdal_utilities.html
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
I think you should feel free to make general improvements to the autotools
setup
Brad
-Original Message-
From: gdal-dev On Behalf Of Ben Elliston
Sent: Thursday, 8 March 2018 11:24 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] limiting drivers
Can you show exactly how you did the conversion and overviews, and the
dimensions of the original TIFF file. Are you trying to create tiles in JPEG or
PNG? If JPEG, possibly you need to fill your TIFF.
The part about gpkg_zoom_other is telling you that what you are asking for
can’t be done
Is there a way to invoke that “do all the dependency work for me”
(`find_anyproject`) from the cmake command line?
So if I clone your lib_gdal repo, it could build GDAL and any required
dependencies?
Brad
___
gdal-dev mailing list
You should be able to just use the normal subdataset referencing. I like
gdalinfo to get the syntax.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
22 matches
Mail list logo