This is wildly important for systems without internet access.
On 7/23/24 10:18, Greg Troxel via gdal-dev wrote:
In my view, docs should be part of a package build and installed so they
are available on the computer with the software.
___
gdal-dev
On debian 12:
/usr/include/c++/12/cstdlib, line 75. Context:
// Need to ensure this finds the C library's not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next is part of the c++ version 12. You can find it's usage
here on debian 12:
/usr/include/c++/12/cstdlib, line 75
On 6/24/24 11:03, Scott via gdal-dev wrote:
Yes, I saw that. It's the default code. I tried changing it to just
'include' early on and got a whole new set of errors
:
Scott, is it that you are using #include_next instead of #include?
#include_next makes assumptions about the environment that #include does
not.
On Mon, Jun 24, 2024 at 12:53 PM Scott via gdal-dev
mailto:gdal-dev@lists.osgeo.org>> wrote:
Thanks for the docker instructions. It buil
h?q=fatal+error%3A+stdlib.h%3A+No+such+file+or+directory+;
shows that this error message is quite common, although on quick reading, I
couldn't spot a common point/solution between all those occurrences
Even
Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
When building 3.9.1 rc1/r2 I get
reading, I
couldn't spot a common point/solution between all those occurrences
Even
Le 24/06/2024 à 18:39, Scott via gdal-dev a écrit :
When building 3.9.1 rc1/r2 I get the following when linking. If I
comment srsinfo out of the makefile, all other gdal/ogr apps build
fine with no issues.
uname
When building 3.9.1 rc1/r2 I get the following when linking. If I
comment srsinfo out of the makefile, all other gdal/ogr apps build fine
with no issues.
uname -a:
Linux MyHost 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1
(2024-05-03) x86_64 GNU/Linux
Thanks!
Build output below:
https://gdal.org/programs/gdal_calc.html
see the examples at the bottom. There are a number of numpy.* statements.
On 6/6/24 21:48, lefsky--- via gdal-dev wrote:
I know gdal_calc calculates using "python syntax" but I've never seen
documentation for using numpy functions within the calc
Thanks for the -E, -field_sep and -ignore_extra_input in gdallocationinfo!
It means we no longer have to pipe the input/output through paste -d or sed
On 5/6/24 06:43, Even Rouault via gdal-dev wrote:
Hi,
I have prepared a GDAL/OGR 3.9.0 release candidate.
NEWS at:
The bbox is created using the xmin,ymin,xmax,ymax found in the geometry.
Assuming every pixel can be represented as a geometry, that's your bbox.
On 5/3/24 13:18, Simon Eves via gdal-dev wrote:
Yes, but that's just the corners.
Consider, say, a raster that contains a satellite sweep which is
You might create a Cloud Optimized GeoTiff (COG) from ENVI for
frequently use band combinations, such as:
gdalwarp -f COG -co COMPRESSION=DEFLATE -t_srs EPSG:4326 \
-src_band 23 -dst_band 1 \
-src_band 130 -dst_band 2 \
-src_band 420 -dst_band 3 \
[envi file] new.tif
Now, you have a
24 à 17:24, Scott via gdal-dev a écrit :
It would be nice to have an open option to substitute a string of text
with some other value, treating .vrt something like a template. Such as:
-oo REPLACE="'sourceString'='targetString'"
Thoughts? Thanks
It would be nice to have an open option to substitute a string of text
with some other value, treating .vrt something like a template. Such as:
-oo REPLACE="'sourceString'='targetString'"
Thoughts? Thanks for listening!
Scott
--
www.postholer.com
Hi,
I'm trying to create a JPEG2000 file using the JP2ECW driver, but I'm getting
"WriteBlock() not supported...". The same code works using the PNM driver.
What am I missing?
Thanks,
Scott
Disclaimer
The information contained in this electronic message and any attachments to
this message
I'd check both files *before* all the processing. Something like:
gdallocationinfo -l_srs EPSG:4326 gribFile -110 40
gdallocationinfo -l_srs EPSG:4326 tiffFile -110 40
That will tell narrow it down.
On 1/31/24 15:53, Furuya, Takahiro via gdal-dev wrote:
Hi gdal-dev, I am Takahiro, a
tt
On 1/29/24 02:54, Even Rouault via gdal-dev wrote:
Hi,
no, the values of pixel function arguments are hardcoded in the VRT. If
someone wanted to implement what you mention, that should rather be done
as open option (-oo) of the VRT driver
Even
Le 29/01/2024 à 08:29, Scott via gdal-dev a é
With a python pixel function in a .vrt file, is it possible to pass
values from the command line?
Example:
gdal_translate ... -lco PixelFunctionArguments=? or -lco -kwargs=?
Basically I want to change the 'min' and 'max' values on the command line:
Thanks!
Scott
+10
I'll buy them a 12 pack of their favorite micro-brew.
On 1/19/24 09:32, Even Rouault via gdal-dev wrote:
A nice exercice for (Pythonist) contributors would be to add a -f VRT
capability to gdal_calc.py that would essentially automate the writing
of such VRT using Python pixel functions.
Over the network it takes 23 seconds:
time gdal_translate -oo OVERVIEW_LEVEL=NONE -outsize 219 226
/vsicurl/https://github.com/mdsumner/cog-example/raw/main/cog/sentinel-image.tif
net.tif
real 0m23.909s
user 0m4.374s
sys 0m1.021s
Saving the file locally and translating it's fractional
Yee haw! Thanks guys for all your hard work!
On 11/13/23 09:48, Even Rouault via gdal-dev wrote:
Hi,
On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 3.8.0. GDAL/OGR is a C++ geospatial data
access library for raster and vector file
Thanks for the info Even!
On 11/5/23 13:26, Even Rouault wrote:
Scott,
I don't reproduce anymore on master, and I strongly suspect this is the
same issue as
https://lists.osgeo.org/pipermail/gdal-dev/2023-November/057856.html
which I fixed post-beta1
Even
Le 05/11/2023 à 19:57, Scott via
Check that. This is only on 3.8beta. Apologies.
On 11/5/23 09:35, Scott via gdal-dev wrote:
On debian 10 linux, using gdal 3.7.1 or 3.8beta, built with apache arrow
12.0, I get a segfault immediately after running either of these commands:
ogr2ogr tst.gpkg
PARQUET:"/vsicurl/
On debian 10 linux, using gdal 3.7.1 or 3.8beta, built with apache arrow
12.0, I get a segfault immediately after running either of these commands:
ogr2ogr tst.gpkg
PARQUET:"/vsicurl/https://overturemapswestus2.blob.core.windows.net/release/2023-10-19-alpha.0/theme=admins;
ogr2ogr tst.gpkg
Looking at the release notes did #8262 make it in?
https://github.com/OSGeo/gdal/pull/8262
On 10/30/23 09:15, Even Rouault via gdal-dev wrote:
Hi,
I have prepared a GDAL/OGR 3.7.3 release candidate.
Pick up an archive among the following ones (by ascending size):
My first attempt was with adding
skipfailures, but I can't add any of the options I have listed because I
have no idea how to. I thought it would be gdal_tools.config_options()
but I get pylint tells me it is not callable
-Original Message-
From: gdal-dev <mailto:gdal-dev-boun
-nln is being ignored because the data layer you're -updating -appending
to exists. You can't rename a layer if it has a name. Remove -nln option
Next you are trying to write a collection as a linestring. Use
-explodecollections (if exists in your install) and/or use -nlt
PROMOTE_TO_MULTI
Hi,
I'm integrating GDAL in C++ with a system that defines its own asset types
stored on disk, and am writing a wrapper for datasets using this asset
system. To 'import' a dataset I call GDALOpenEx on it, CreateCopy() it to
some "/vsimem/foo.shp" path, GDALClose() the datasets to flush it, and
, 2023 at 3:18 PM Scott via gdal-dev
mailto:gdal-dev@lists.osgeo.org>> wrote:
Thanks for digging into that Even!
Can I create my new .fgb in sections?
If I limit the number of source rows with -sql, doing that multiple
times with -update, will it still build the entire R-tre
-64.639696737462
3 17.7221065273415,-64.639698399651 17.7221299263498,-64.6398064310524
17.7221228777942,-64.6398022655579 17.7220642396531,-64.6397672401299
17.7220665249078))
On 9/28/23 10:03, Even Rouault wrote:
Le 28/09/2023 à 18:47, Scott via gdal-dev a écrit :
I should have been more specif
I get the same error on OS AWS Linux 2.
Also, on either OS with source .parquet instead of .fgb.
On 9/28/23 10:17, Scott via gdal-dev wrote:
USA.fgb is 36 GB. I've renamed it from its original source which can be
found here:
https://beta.source.coop/vida/google-microsoft-open-buildings
6398022655579 17.7220642396531,-64.6397672401299
17.7220665249078))
On 9/28/23 10:03, Even Rouault wrote:
Le 28/09/2023 à 18:47, Scott via gdal-dev a écrit :
I should have been more specific.
One particular machine has 8GB of memory. When I try to do the most
simple ogr2ogr command on
I should have been more specific.
One particular machine has 8GB of memory. When I try to do the most
simple ogr2ogr command on large files, the host runs out of memory
(vmstat shows this) and ogr2ogr terminates with 'Killed', nothing more.
The data formats I have experienced this with are
Averaging rasters is a common task. Often I see developers write many
lines of python to do simple tasks like this. The following GDAL command
should give you the results you're looking for:
gdal_calc.py -A input1.tif -B input2.tif --outfile=result.tif
--calc="(A+B)/2"
The above command was
Any tips for using ogr2ogr to use only a specified amount of RAM? I'm
not having any luck.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
34 matches
Mail list logo