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
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
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/
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):
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
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
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
-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
, 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
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
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
-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
+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
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
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 é
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
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
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
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
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:
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
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
26 matches
Mail list logo
