.
The VQ part would probably be best in a separate library.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
thub.bdezonia
zorbage-gdal
0.2.1
org.gdal
gdal
3.10.0
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
y, and allow consumers
to override the maven dependency if they need to.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Not quite what you asked for, but https://github.com/OSGeo/gdal/blob/master/autotest/gdrivers/nitf.py#L2101 might be another way to achieve what you need. Otherwise, some more details on exact TREs might be relevant. On 11 June 2024 8:11 pm, Marek Setnik via gdal-dev wrote:
Hello!
I'm h
at you took my words with that intent - it wasn't what I said, and
it wasn't what I meant. I was trying to provide a workaround.
In future, I'll try to remain silent.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https
st other
segments, possibly), which may not correspond directly to the JPEG 2000
codestream. In particular, if you have M8 compression, you may need to parse
the image mask table off the front of that data. Also, depending on what the
data is, the actual imagery may nee
id, it probably wouldn't be that hard to scan through the CMakeLists
with a
simple script and generate it.
Brad
[1] https://github.com/OSGeo/gdal/blob/master/frmts/CMakeLists.txt
[2] https://github.com/OSGeo/gdal/blob/master/ogr/ogrsf_frmts/
CMakeLists.txt#L53-L108
___
r size on disk, the GDAL API probably isn't the best option. Why not use
stat(2)/fstat(2)/lstat(2)? That will almost always be faster and at least as
accurate than anything you can calculate.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osge
ARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type",0.0],UNIT["Meter",1.0]]"""
srs2 = osr.SpatialReference(wkt=p2)
srs = osr.SpatialReference(wkt=p)
transform_func = osr.
eady identified a way to do this:
> > Use gdalinfo on your file to see the specific characteristics.
What does your file show?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
to pass the correct name to the open call.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Normally automatically
set." part isn't true.)
HTH
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ns, "ICORDS", "D" );
papszOptions = CSLSetNameValue( papszOptions, "IGEOLO",
"+28.563-080.578+28.563-080.577+28.562-080.577+28.562-080.578" );
and pass those options to your Create() call.
I'll say it again: creation options, not metadata.
Brad
options=["IC=C8", "FDT=20221129010203",
"FSCLSY=AS", "ISCLSY=AS", "IDATIM=20210617160900", "ICORDS=D",
"IGEOLO=+28.563-080.578+28.563-080.577+28.562-080.577+28.562-080.578",
"ICOM="])
dst_ds = None
Brad
_
On Monday, 30 January 2023 10:31:47 PM AEDT Aryan Landi wrote:
> Hi again,
>
> Not sure what you mean by “support files”.
There are two support files that translate vectors - see the documentation.
https://gdal.org/drivers/vector/s57.html
> The command line tool returns:
>
> ERROR 4: `US5LA26M.
de. Input of
hillshade is probably always going to give you weird results.
It might help to say what you're actually trying to achieve with this (as
opposed to how), but if you are looking for generic iso-lines of the
hillshade, try https://gdal.org/prog
{FE705F35-5AD1-4570-A0FD-E1E882A89496}
POLYGON ((6.62 44.06,9.21 44.06,9.21 46.450844727,6.62
46.450844727,6.62 44.06))
So its perhaps matching other_subjects or abstract field instead?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
system
where to get them from. Usually LD_LIBRARY_PATH environment variable or
something like that will help.
This isn't anything specific to GDAL.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
On Saturday, 7 May 2022 1:35:52 PM AEST Pei JIA wrote:
> Hi, all:
>
> It looks *libjpeg8-dev libjpeg-turbo8-dev* from Ubuntu 22.04's repo is *NOT
> compatible* with current GDAL git? Any suggestions?
I'm not seeing this. I just did a new install of kubuntu 22.04, installed
libjpeg8-dev and libjp
On Monday, 14 February 2022 1:13:47 PM AEDT ni hao wrote:
> it is missing %_nmake_opt_win64_% in the 2nd nmake commnad line.
I have no idea about the change, but you could submit a fix for this. See
https://gdal.org/contributing/developer.html#git-workflows-with-gdal
B
virtual raster to a GeoTIFF:
> 3. gdal_translate -of GTIFF ./output.vrt ./output.tif
I manually removed the NODATA part from the vrt, and it looks better. Possibly
the nodata value in the source is bad? Or you need to put something more
meaningful behind t
On Sunday, 29 August 2021 4:06:33 PM AEST aharon david wrote:
> I want to suggest an improvement in WFS Vector Layer.
You can make Pull Requests at https://github.com/OSGeo/gdal
Please check the CONTRIBUTING.md file in that repository (or your checkout)
first.
B
om.affineTransform.class (public AffineTransform(AffineTransform
> Tx) { this.m00 = Tx.m00; ) I have the gt-image module and matching .wld,
> .prj and .png.aux.xml files.
What is the exception?
Do you have a referencing jar loaded (or in the classpath)
-gdal_translate-scale
If that doesn't work, please show the full metadata dump from
gdalinfo.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Does that code compile for you? What are you expecting this line to do:
OGRLineString *poLine = (OGRLineString *) poGeometry;
?
Where is poGeometry even defined?
Brad
From: Ahmet Temiz
Sent: Sunday, 20 June 2021 6:30 PM
To: Brad Hards
Subject: Re: [gdal-dev] I couldn'
What is the `polyGeometry`?
Can you try to generate a compilable, minimal, self-contained example that
demonstrates the problem?
Brad
From: gdal-dev On Behalf Of Ahmet Temiz
Sent: Sunday, 20 June 2021 5:56 PM
To: gdal-dev
Subject: [gdal-dev] I couldn'
catered for in the ISO 19111:2007 or EPSG data
models."
(typo in the original)
What are you actually hoping to do with MGRS? If you can explain the use case,
maybe a more meaningful answer could be possible.
Brad
___
gdal-dev mailing list
gda
NITF_FSCODE=
NITF_FSCOP=0
NITF_FSCPYS=0
.
NITF_PVTYPE=INT
NITF_STYPE=BF01
NITF_TGTID=
Metadata (xml:DES):
Clearly you'll need to parse out the DESDATA part of the segment, using
STDI-0002 as a guide.
Brad
-Original Message-
maybe the back-end format and compression matters less than the access approach.
Difficult to see advanced codecs making much progress here.
Brad
From: gdal-dev On Behalf Of Kurt Schwehr
Sent: Wednesday, 31 March 2021 3:12 AM
To: Aaron Boxer
Cc: gdal dev
Subject: Re: [gdal-dev] Long Term
Perhaps
ogr2ogr -clipsrc polygon.shp -f MVT
If that doesn't do what you want, you might need to provide more info,
including a full description of the source data, the clipping
polygon you want to use, what you expect to happen, and what happens instead.
think this could
reasonably be decided either way.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
be more appropriate, please let me know.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
e you'd be better off calling out to a command
line utility instead. Then you can decouple the conversion from your C# code.
Brad
-Original Message-
From: gdal-dev On Behalf Of RejectKid
Sent: Thursday, 7 May 2020 11:47 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] New to Gdal
I doubt there is a NITF specific example, but it'll mostly look like other
format transforms.
What have you looked at already?
What have you tried?
What did you expect to happen?
What happened instead?
What debugging have you already tried?
Brad
-Original Message-
From: gdal-de
[Keeping on list]
The Daffodil framework may be relevant.
https://github.com/DFDLSchemas/NITF
And
http://dfdlschemas.github.io/
Brad
-Original Message-
From: Doug Gastonguay-Goddard
Sent: Wednesday, 6 May 2020 9:00 AM
To: Brad Hards
Subject: Re: [gdal-dev] Example NITF files with TRE
re of any (public) use of RES, and there will be TREs and DES that
are never public.
You might need to use gdal (or my equivalent approach) to create files for some
of the newer TREs/DESs (e.g. those using gzip compression).
Brad
-Original Message-
From: gdal-dev On Behalf Of Doug
Gasto
I think there could be value in adding CSSHPB with new code inside GDAL
NITF. See
https://github.com/OSGeo/gdal/blob/master/gdal/frmts/nitf/nitfdes.c#L209
Do GLAS/GFM later.
Brad
From: gdal-dev On Behalf Of Edson, Adam
Robert
Sent: Friday, 3 April 2020 2:53 AM
To: Even Rouault ; gdal
I think that cs2cs might be a suitable tool. Part of Proj, not GDAL, though.
https://proj.org/apps/cs2cs.html
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Lots of WPS implementations can use GDAL – it depends on how much you’re
expecting though.
Perhaps pyWPS (https://pywps.readthedocs.io/en/master/wps.html) or GeoServer
are worth a look, depending on what languages you are familiar with.
Brad
From: gdal-dev On Behalf Of Idan Miara
psNameNode;
CPLXMLNode* psValueNode;
(I think the pzVal might need to be changed to a union / class that has
char*, a double or an unsigned int; I haven't dug further than this yet).
Brad
From: Edson, Adam Robert
Sent: Thursday, 7 November 2019 6:34 AM
To: Brad H
called
type="IEEE754")
* Support for parsing / using the 32bit integer encoding (which I
called type="UINT")
* Support for the "&" condition operator (for bitmask tests)
* Unit tests
I think I can hack my unit test code to output some test files.
string encoded).
Happy to collaborate on this if you're interested.
Brad
From: Edson, Adam Robert
Sent: Monday, 14 October 2019 10:02 PM
To: Brad Hards ; gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] python GDAL issue
I am working on adding BANDSB and the other TREs listed
alue), and copy out the following 0 characters?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Can you make the NITF file available? Can you at least post the relevant
part of the BANDSB TRE from the file?
Brad
From: gdal-dev On Behalf Of Edson, Adam
Robert
Sent: Friday, 11 October 2019 6:09 AM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] python GDAL issue
I am trying to
Does your ogr actually support MSSQL driver? What does ogrinfo --formats show?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ackage? The extensions that make sense will
depend on the consumers of the file.
Brad
From: gdal-dev [mailto:gdal-dev-bounces@lists.osgeo.org]
On Behalf Of Gil
Sent: Saturday, 17 February 2018 7:12 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Building pyramids with gdaladdo
unds and sources should be
> the idea.
This is my main need. I was only looking for how to create a raster coverage
with different content at different zoom levels. I will try the gdalwarp
solution next, although I did make it work with a simple bash loop and some
spatialite SQL comm
I'm trying to find a way to append data to an existing geopackage raster
layer using GDAL.
The specific case is to use different sources (or different configurations
of a source like WMS) at different zoom levels, but extending an existing
table at the same zoom might also be useful.
As an exampl
Looks somewhat like it came from WRF/ARW forecast software.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ll parse of the file, and likely give you many more fields than you
possibly want in any case.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
To confirm, gdalinfo --formats shows:
HDF5 (ros): Hierarchical Data Format Release 5
HDF5Image (ro): HDF5 Dataset
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
with-cryptopp=yes --with-ogdi=yes --with-epsilon=yes --with-
> webp=yes --with-geos=yes --with-spatialite=yes
Some of those are pretty niche. Also, you don't need to duplicate entries.
> OGDI support: no
So you are probably missing the -dev packa
ixel_y_size for that zoom level.
That isn't true if we are doing something that doesn't fill the entire matrix
(e.g. we only need 20 blocks instead of 32 at zoom level 5. Still trying to
find a fix that works cleanly in a non-power of 2 matrix.
Brad
___
purpose if such constructs are
> found to be common.
Yes to the question about hard-coding it.
I haven't look into the nitffile.c enough to have a patch, but the two wrapper
TREs should be similar, except for the labelling.
I'll keep the
ata Wrapper TRE (FASYWA)
I would caution that it's a bit confusing the first time.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
, and
ignore FREESA which never has interesting content anyway.
Anyone have strong feeling about this, or suggestions that can make things
easier?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
> mmm,,,don't work.
Not very descriptive
> GDAL_PATH: C:\Program Files\GDAL
Maybe you need to quote the path, or use something with no space?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/li
No personal experience building on Android, but you may wish to post the error.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
, and gpkg_spatial_ref_sys can contain any EPSG code you
want to add. It works
in GDAL, just use -a_srs option to gdal_translate. Or reproject the source
data - whatever works for you.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ou trying to link to mod_spatialite or libspatialite ?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
de. So the output MBTiles file
> doesn't really function as supposed to in a MBTiles reader/viewer.
Perhaps you need to add the overviews.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
late out2.vrt /vsistdout/ -of aaigrid
> ncols2
> nrows2
> xllcorner440720.
> yllcorner3751200.
> cellsize 60.
> NODATA_value 0
> 0.0 123
> 115 132
Thanks - very nice solution.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
t I'm doing here, but it is actually explained
in the docs: "Note that, if the input dataset has a nodata value, this does
not cause pixel values that are equal to that nodata value to be changed to
the value specified with this option. "
Is there an easy way to do th
s-84-3/ for the 3D equivalent of 4326.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
argument, which
is ideal for this kind of case, where the options are too long for the shell.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
clearly not. Will fix ASAP.
The SENSRB stuff is really complex, and I did a lot of unit tests to check that
each optional element works, so I should get you that. Not sure how important
MENSRB is, but I'll put that in as well.
Brad
___
gdal-dev
ue, and
I believe that it would be ignored for GDAL. I'm mainly worried about other
users.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ormat (e.g. DXF, noting that will lose the
georeferencing)?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
y difficult and not very portable.
Why would you need ArcSDE support if you don't have an ESRI server license? If
you have the server license, you should be able to download the client side
libraries to match.
Brad
___
gdal-dev mail
[
That worked for me.
I'll spend a little more time on trying to work out what is going on, but not
sure how that will go.
In any case, thanks very much for the support on this - much appreciated.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
c being hidden when I build.
OK, so that is probably a different error.
> And if you just let the script run ? That works for me (GCC 4.7.0)
It looks like its an error in 4.9.0.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
o such file or directory
ar: creating ./libfx_agg.a.new
ar: agg_curves.o: No such file or directory
./configure --with-pdfium=/home/bradh/pdfium/install
I tried to remove that part, and then it looks like its OK, although gdal
complains about CFDF_Document::CreateNewDoc being hidden when I bu
here
> a way to generate these 200x200 tiles? I can generate them using
> gdal_retile but it can't generate the zoom levels.
I'd suggest just hacking the python script. Make a copy, and edit the
__init__() function to change the tileSize member init to be 200 vs
On Thu, 17 Sep 2015 11:19:47 AM Even Rouault wrote:
> Basically if you download
> https://github.com/rouault/pdfium/blob/build/build- lin.sh , run it, it
> will install pdfium to $HOME/pdfium/install
So there is no shared library or configuration data need he
l that the ./configure options will be obvious. However
if there is anything subtle, please feel free to point that out!
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
a run time (or debug time) error.
Please try to provide this. I'm not going to debug your code if you aren't
going to do the work.
Also, please don't keep providing the same email over and over.
Brad
___
gdal-dev mailing list
gdal-dev@lists.
g as filename?
Can you try posting an actual, compilable example?
Does the tutorial (just by itself, exactly as written) work on your machine?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
2.1 - MIL-STD-2500C) for two
reasons:
1. Tiling is mandatory above 8192 x 8192 (See Table A-10 Complexity Level 7 or
higher)
2. Tiles are allowed to be up to 2048 x 2048 (Complexity level 3) or 8192 x
8192 (Complexity level 5 or higher).
Brad
___
gd
On Fri, 5 Jun 2015 12:38:01 AM Stefan Keller wrote:
> We've finished the GeoCSV spec.
Does that mean: http://giswiki.hsr.ch/GeoCSV ?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ing around the
problem.
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
in OGR general, or in geopackage
format handler?
Brad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
On Mon, 6 Apr 2015 01:56:16 PM you wrote:
> Le lundi 06 avril 2015 13:26:11, Brad Hards a écrit :
> > The problematic part is that "PROJECTION" definition. I was originally
> > going to argue it should be Mercator_1SP, but it looks like the EPSG
> > decided to change
I'm looking at geopackage support, and particularly at the NGA's draft
"profile".
It defines (and references) some spatial reference systems, including some
interesting variations that will require more work later. For tonight, lets
look at just one case:
PROJCS["WGS 84 / World Mercator",
tories
>
>
> https://lists.fedoraproject.org/pipermail/package-announce/2014-March/130765.html
>
>
>
>
> On Thu, Jul 17, 2014 at 3:41 PM, Even Rouault
> wrote:
> Le jeudi 17 juillet 2014 17:38:06, brad a écrit :
> > I have gdal 1.9.2 on fedora 19, tha
I have gdal 1.9.2 on fedora 19, that appears to be the latest build
available from fedora.
I have a geo PDF, from US Topo which has several layers, including an
image layer. I would like to convert this to tiff without the image
layer. From what I can figure out, I need 1.10 to do this. Is that
with the latest versions of
ArcGIS- the old problem may have even been on ArcView 3.x. We'll do
some further testing and decide whether it seems risky at all.
Thanks again,
Brad
On Thu, Dec 15, 2011 at 11:01 AM, Even Rouault
wrote:
> Le jeudi 15 décembre 2011 18:21:11, bhmcrae a écrit
Frank,
I appreciate the response, but I finally found out that certain OGR-specific
variables were not being handled correctly, which caused a latent memory leak
leading to the problem I reported. I think those have all been tracked down
now.
Brad G.
-Original Message-
From: Frank
If I comment out the
DestroyFeature call, the ingestion succeeds, but I think it is opening a hole
for memory leaks. Sort of a "damned if you do, damned if you don't" situation.
Thanks in advance,
Brad G.
___
gdal-dev mailin
88 matches
Mail list logo
