Hi Michael,
This error comes very deep inside libparquet, actually in libthrift. The
more natural assumption would be that it would be due to a corrupted
Parquet file. If you disabled multithreading (GDAL_NUM_THREADS=1) and
enabled --debug on, perhaps this would happen on the same file ? I was
Hi all,
I was converting the overture maps parquet data to geopackage and got this
error using gdal master (via conda).
GDAL_NUM_THREADS=ALL_CPUS CPL_TMPDIR=/data2 ogr2ogr -f gpkg
/data/overture_buildings.gpkg
/vsis3/overturemaps-us-west-2/release/2024-07-22.0/theme=buildings
"theme=bui
alberti 13
6718 Olivone
Phone: +41 79 360 72 83
Web: https://karten-werk.ch | E-Mail:
hkf...@karten-werk.ch<mailto:hkf...@karten-werk.ch>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.osgeo.org/pipermail/gdal-dev/attachments/20240730/3f0680d5/a
Please file at ticket about that at https://github.com/OSGeo/gdal/issues
Le 30/07/2024 à 10:57, Hanskaspar Frei via gdal-dev a écrit :
Hi everybody
We used an old GDAL Version (3.2.1) to load data to a postgis db with
ogr2ogr.
There was an automatic spatial index generation taking place, which
That seems to be an XYZ raster format
https://gdal.org/drivers/raster/xyz.html
Maybe some of the tests could help you:
gdal/autotest/gdrivers/xyz.py
Cheers
On Tue, 30 Jul 2024 at 11:03, Stefan Gofferje via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:
> Hi all,
>
> I'm still learning Python and G
Dear GDAL Team,I am writing to seek your assistance with an issue I encountered while using GDAL. When I convert a .geojson file containing point geometries to .dgn format and then convert it back to .geojson, the geometries are transformed into LineString instead of remaining as Point.I have attac
Hi all,
I'm still learning Python and GDAL.
I'm pulling the NOAA Aurora forecast in Python and create an array from
it in this format:
[ [lon, lat, value], [lon, lat, value], [lon, lat, value] ...]
like
[ [-180,-90,0], [-180,-89,0], ... , [359, 89, 0], [359, 90, 0] ]
I would like to write
Hi everybody
We used an old GDAL Version (3.2.1) to load data to a postgis db with
ogr2ogr.
There was an automatic spatial index generation taking place, which
seemed to have a logic to avoid duplicated index names.
Examples with GDAL 3.2.1:
For a table with the name
"ch059_liegenschaften_grunds
