Thanks for the pointer. I opened an issue.
-erik
> On Jul 21, 2025, at 10:17, Even Rouault wrote:
>
> Erik,
>
> I don't think it is really worth sozip'ing a zipped Zarr, given that zarr is
> made of many relatively small files, and sozip shines with big compresse
I am using GDAL to create a multidimensional zarr file that is sozip
compressed. I see this error when creating the file:
ERROR 1: dish_positions..zarr/zarr.json already exists in ZIP file
ERROR 8: Open file
/vsizip/data/fengine_init_pathfinder/cx66_dish_positions..zarr.zip/dish_
Joaquim
Thanks for the notice. I was getting very worried that the many small
allocations (a few per value) and finalizers were somehow incredibly expensive.
Apparently they do have a cost, but just a reasonable one.
-erik
> On Jun 24, 2025, at 16:28, Joaquim Manuel Freire Luís wr
counting. Even, is that what you had in mind?
-erik
> On Jun 24, 2025, at 11:01, Even Rouault via gdal-dev
> wrote:
>
> Hi,
>
> I don't know anything about Julia but I'd suspect that there must be
> something particularly slow in the way it interacts with C. Fo
is is working
quite well in practice. One big advantage is that the resulting Julia bindings
look "natural" in Julia, close to as if GDAL had been implemented directly on
Julia.
-erik
> On Jan 31, 2025, at 17:31, Howard Butler via gdal-dev
> wrote:
>
> On Jan 31, 202
I move to adopt RFC 100 (adding support for the float16 data type).
The pull request for RFC 100 is here: https://github.com/OSGeo/gdal/pull/10146 .
A candidate implementation is here: https://github.com/OSGeo/gdal/pull/11180 .
I vote +1.
-erik
vote.
-erik
> On Jun 6, 2024, at 11:43, Erik Schnetter wrote:
>
> I am interested in GDAL supporting float16 values (i.e. IEEE 16-bit
> floating point values) natively. If this suggestion succeeds I will
> most likely be able to provide such an implementation.
>
> I have
ull/10146/files>. This spells out
details of my suggestion. I am looking for comments.
-erik
--
Erik Schnetter
http://www.perimeterinstitute.ca/personal/eschnetter/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/li
I think there are many users.
Nils Erik Jørgensen
Fra: gdal-dev På vegne av nagyrobi_r--- via
gdal-dev
Sendt: tirsdag 14. november 2023 20:54
Til: Sebastiaan Couwenberg ; Sebastiaan Couwenberg via
gdal-dev
Emne: Re: [gdal-dev] Is the SOSI Norwegian driver still useful?
Hi all!
I
:)
Erik
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
x27;m inclined to
say, this has been working in the past. But I am not sure.
gdal_translate on the contrary leaves scale and offset intact.
Maybe, someone can look into this. Thank you.
Best regards,
Erik
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
, each value being a 32
bit floating point number in radians, with east to west lines, from south to
north.
Regards,
Erik Sørngård
R&D Manager
Gundersen & Løken AS
E: erik.sorng...@gl-instrumenter.no
P: +47 22 81 39 94
-Original Message-
From: Even Rouault [mailto:e
ed file formats:
http://www.gdal.org/formats_list.html
Where can we find the CTable2 documentation?
Regards,
Erik Sørngård
R&D Manager
Gundersen & Løken AS
E: erik.sorng...@gl-instrumenter.no<mailto:erik.sorng...@gl-instrumenter.no>
P: +47 22 81 39 94
___
this a known issue? Is there a solution?
I could provide sample files per E-mail on request. Public distribution is
probably not allowed - my knowledge of French is too limited to be sure
about that.
Thanks in advance, and best regards,
Erik
___
k you, and best regards,
Erik
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
27;s in gdal_translate and
then warped in the original projection. Maybe this isn't enough? In the
ozi2geotiff.py script I see he does a second translate with several creation
options (-co) for tiled, block(x,y)size, compress and predictor. As well as
some ot
http://blog.oldmapsonline.org/2008/06/georeferencing-images-by-control-points.html
> or very simple python script doing the calculation as well:
>
> http://code.google.com/p/oldmapsonline/source/browse/trunk/gcps2wld/python-no-dep/gcps2wld.py
>
> 2009/3/30 erik :
> > Hello,
>
hem directly.
Or is there another way to achieve this without specifying the coord
corners? (The calibration points are not corner-based)
One solution would be to calculate the corners myself programmatically (from
the pixels), but this would be the least good sol
18 matches
Mail list logo
