Re: [gdal-dev] NEWS.md for last release

[Javier Jimenez Shaw via gdal-dev]

I find it strange. There is a long list of news ... but it covers only
things that were added exactly in the x.y.0 releases. All the changes that
happened in "bugfix releases" (that is x.y.z for z>0) is only on that
branch.
You can compare these two pages
https://github.com/OSGeo/gdal/blob/release/3.8/NEWS.md
https://github.com/OSGeo/gdal/blob/release/3.9/NEWS.md

However most of the changes are done in master and some back-ported to the
current release branch. That is, if I do a PR in master today that is not
breaking any API, it will be probably backported to 3.9, and released in
3.9.2. It will appear in the news for 3.9... but it will not appear in the
long list of news for 3.10 and later releases.
Is that what is happening? If yes, do we want to change that?

Javier

On Tue, 16 Jul 2024 at 11:12, Laurențiu Nicola  wrote:

> Try https://github.com/OSGeo/gdal/blob/release/3.9/NEWS.md, I think the
> patch release changes either get folded into the next minor changelogs or
> don't get included at all. But the release branch always has the full set
> of changes.
>
> Laurentiu
>
> On Tue, Jul 16, 2024, at 12:09, Javier Jimenez Shaw via gdal-dev wrote:
>
> Hi
>
> I noticed that https://github.com/OSGeo/gdal/blob/master/NEWS.md is
> telling about 3.9.0, while the last release is 3.9.1
>
> Is that intentional?
>
> Cheers,
> Javier
>
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] NEWS.md for last release

[Javier Jimenez Shaw via gdal-dev]

Hi

I noticed that https://github.com/OSGeo/gdal/blob/master/NEWS.md is telling
about 3.9.0, while the last release is 3.9.1

Is that intentional?

Cheers,
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.9.1 RC2 is available, and motion to approve it

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Mon, 24 Jun 2024 at 17:09, Howard Butler via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> Howard
>
> On Jun 24, 2024, at 9:46 AM, Tamas Szekeres via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
> +1
>
> Tamas
>
>
> Even Rouault via gdal-dev  ezt írta (időpont:
> 2024. jún. 23., V, 0:13):
>
>> I've issued a 2nd release candidate for 3.9.1 with the following
>> additional fixes:
>> - GDALSieveFilter(): avoid assert() when all pixels are masked (3.9.0
>> regression)
>>(raster/rasterio#3101)
>> - Overview generation: fix multi-threaded bug, resulting in
>> locks/crashes with
>>GeoPackage in particular (#10245)
>> - VRT: fix serialization of separatable kernel in
>> VRTKernelFilteredSource (#10253)
>> - Zarr: SerializeNumericNoData(): use CPLJSonObject::Add(uint64_t) to
>> avoid potential
>>undefined behavior casts
>> - OGR SQL: fix crash when the ON expression of a JOIN contains OGR special
>>fields (in particular feature id)
>> - OGR layer algebra: honour PROMOTE_TO_MULTI=YES for Points
>> - OGRFeature::SetField(int, double): avoid UndefinedBehavior when
>> passing NaN
>> - OGRFeature::SetField(int, GIntBig): avoid UndefinedBehavior when
>> passing value
>>close to INT64_MAX
>> - OGRLayer::WriteArrowBatch(): avoid UndefinedBehavior when trying to
>> convert
>>NaN to Int64
>> - GeoParquet: always write version=1.1.0
>> - SQLite/GPKG: detect UNIQUE constraints expressed as a ', CONSTRAINT
>> name UNIQUE (column_name)'
>>at the end of CREATE TABLE (qgis/QGIS#57823)
>> - GDALRasterBand::ComputeStatistics(): fix bad progress percentage
>> computation (3.9.1rc1 regression)
>> - OGRSpatialReference::importFromUSGS(): avoid out-of-bounds access to
>> array (3.9.1rc1 regression)
>>
>> Pick up an archive among the following ones (by ascending size):
>>
>>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.xz
>>https://download.osgeo.org/gdal/3.9.1/gdal-3.9.1rc2.tar.gz
>>https://download.osgeo.org/gdal/3.9.1/gdal391rc2.zip
>>
>> A snapshot of the gdalautotest suite is also available:
>>
>> https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.tar.gz
>>https://download.osgeo.org/gdal/3.9.1/gdalautotest-3.9.1rc2.zip
>>
>> The NEWS file is here:
>>
>> https://github.com/OSGeo/gdal/blob/v3.9.1RC2/NEWS.md
>>
>> Even
>>
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Adopt GDAL 3.9.1RC1 as 3.9.1 release

[Javier Jimenez Shaw via gdal-dev]

Javier +1

On Thu, 20 Jun 2024 at 14:52, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> Motion:
>
> Adopt GDAL 3.9.1RC1 as 3.9.1 release
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Thread-safe raster access

[Javier Jimenez Shaw via gdal-dev]

If the purpose of multithreading is performance, a mutex will ruin that
performance.
Opening different datasets solves that already.

For writing, allowing different synchronous writers is... scary.

On Mon, 3 Jun 2024, 16:12 Chris Toney via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi Andrew,
> Some related comments and links are in:
> https://github.com/OSGeo/gdal/issues/9091
>
> Chris
>
> On Mon, Jun 3, 2024 at 7:44 AM Andrew Bell via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
>> Hi,
>>
>> I am aware that there isn't thread-safe raster access with the current
>> GDAL interface for various reasons. Given the state of processors, I was
>> wondering if it would be valuable to take a look at providing the ability
>> to do Raster I/O (at least reads) in a thread-safe way. This could be done
>> through a new set of API calls or perhaps by modifications to what
>> currently exists -- I don't know what makes sense at this point. I would be
>> happy to spend some time looking at this if there is interest, but I would
>> also like to learn from existing experience as to what kinds of things that
>> I'm surely not considering would have to be dealt with.
>>
>> Thanks,
>>
>> --
>> Andrew Bell
>> andrew.bell...@gmail.com
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL WMTS get tiles no documentation

[Javier Jimenez Shaw via gdal-dev]

On Wed, 29 May 2024 at 08:59, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
>
>
> When you have a RasterBand  from the WMTS data source, it is abstracted
> and you can read the raster data just like from any other data source and
> raster band
> https://gdal.org/tutorials/raster_api_tut.html#reading-raster-data “There
> are a few ways to read raster data, but the most common is via the
> GDALRasterBand::RasterIO() method. This method will automatically take care
> of data type conversion, up/down sampling and windowing.” GDAL knows which
> tiles to read.
>
>
>
> I do not know if the WMTS driver can do parallel tile downloads. If not,
> it is possible to run many RasterIO() at the same time, each reading data
> from a different window like in this rasterio document
> https://rasterio.readthedocs.io/en/latest/topics/concurrency.html.
>

Jukka, are you sure you can run several RasterIO in parallel (on the same
dataset)? in GDAL GeoTIFF you cannot: the cache may be corrupted. In that
case I open several datasets over the same file. I do not know about WMTS.


>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Michal
> Kowalczuk via gdal-dev
> *Lähetetty:* keskiviikko 29. toukokuuta 2024 9.08
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] GDAL WMTS get tiles no documentation
>
>
>
> Hi GDAL fellows
>
> This is my first post on this mailing list, so I'm asking for
> understanding.
>
>
>
> As all we know the purpose of using WMTS over WMS, I'd like to implement
> parallel downloading tiles from service using C API.
>
> In my opinion GDAL documentation (
> https://gdal.org/drivers/raster/wmts.html) says nothing on this topic.
>
> I can get capabilities from WMTS, I can open the selected subdataset but
> how to get tiles for given extent? I could not find any information how to
> do it, even in the GDAL tests on github.
>
>
>
> I am kindly asking for tips. It also can be in python. How using pure GDAL
> API fetch tiles to dynamically complete the displayed map. This is my goal.
>
>
>
> Thank you!
>
> Michal
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Using vscode to develop GDAL

[Javier Jimenez Shaw via gdal-dev]

Hi

I am using vscode to edit (and build and debug) gdal. So far so good.
The compilation works with a simple task that runs a shell (see code below
if you need it). Debug also works fine.

My problem is syntax highlighting. Apparently it does not realize that
"GDAL_COMPILATION" is defined, so some variables appear as errors with
something like
identifier "GUIntptr_t" is undefined
To configure it I just did
cmake .. -DBUILD_PYTHON_BINDINGS=ON  -DCMAKE_BUILD_TYPE=Debug

Does anybody uses visual studio code and had/solved this problem?
Thanks.
Javier

PS: this is my tasks.json:
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "cmake",
"args": ["--build", "build", "-j", "12"],
"problemMatcher": [
"$gcc"
],
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"revealProblems": "onProblem",
}
}
]
}
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Conda failure in GA

[Javier Jimenez Shaw via gdal-dev]

Thanks!

On Mon, 20 May 2024 at 20:17, Even Rouault 
wrote:

>
> As suggested in the comment of #939, attempting
> https://github.com/rouault/gdal/commit/1000cfaa950a18bd14b0c72109439cad58c789d5
>
> That fixed it. Merged into master
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Conda failure in GA

[Javier Jimenez Shaw via gdal-dev]

Hi

The github actions on a branch I created two days ago is failing in Conda
environment, and I do not understand the reason

https://github.com/jjimenezshaw/gdal/actions/runs/9161579309/job/25186735095#step:8:244

I think it is not related to my code.

Does anybody know what is it about?

Thanks.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Discrepancy in reported Spatial Reference b/n gdalinfo and arcpy

[Javier Jimenez Shaw via gdal-dev]

Your file prj.adf is

ProjectionLAMBERT_AZIMUTHAL
Units METERS
ZunitsNO
Xshift0.0
Yshift0.0
Parameters6378137.0  6378137.0
6378137.0 /* radius of the sphere of reference
  20  0  0.0 /* longitude of center of projection
   5  0  0.0 /* latitude of center of projection
0.0 /* false easting (meters)
0.0 /* false northing (meters)

Looking at the code at
https://github.com/OSGeo/gdal/blob/158e538d63458414a5348dae12ddf820f62cf30d/ogr/ogr_srs_esri.cpp#L421
it is reading the parameters in order 2, 1, 3 and 4.

That code is 13 years old, changed due to
https://trac.osgeo.org/gdal/ticket/4302

As you can see, the content of the prj.adf is different than the example in
the ticket. Yours includes an extra one at the beginning, the radius of the
sphere.

I do not know if there is any documentation from esri about that specific
format for LAMBERT_AZIMUTHAL. It would be great.
And also I am surprised that in 13 years nobody complained.

If you remove the line with "6378137.0 /* radius of the sphere of reference"
it works, but probably it is not what you need.

Cheers,
Javier.

On Sun, 12 May 2024 at 01:07, Liyuneh Gebre via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
> I've encountered a discrepancy in the outputs of GDAL and arcpy. While
> using gdalinfo on an arcGrid file with a user-defined projection, the
> reported latitude and longitude of natural origin and False easting seems
> to be incorrect. However, when accessing the same file with arcpy and
> examining its spatialReference it seems to align with the prj.adf file and
> is correct. How can I resolve this discrepancy?
> For your reference link to the file.
>
> https://u.pcloud.link/publink/show?code=XZvlVj0ZWHt5AMCJnjHl4pKMmozOJh8RYVE7
>
> best regards
>
> --
> *Liyuneh Gebre**, **Associate Researcher*
>
> *Ethiopian Institute of Agricultural Research,EIAR*
>
> *Cell Phone:+251 911858155*
>
> *linkedIn: https://www.linkedin.com/in/liyuneh-gebre-b842b440/
> *
> *skype:liyenew_1*
> *Addis Ababa, Ethioipa*
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: approve GDAL 3.9.02RC2 as final release

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 8 May 2024 at 13:15, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> Lähetetty: keskiviikko 8. toukokuuta 2024 14.13
> Vastaanottaja: gdal-dev@lists.osgeo.org
> Aihe: [gdal-dev] Motion: approve GDAL 3.9.02RC2 as final release
>
> Hi,
>
> Motion:
>
> Adopt GDAL 3.9.0RC2 as final 3.9.0 release
>
> Starting with my +1
>
> Even
>
> --
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Efficient raster bounding box transformation?

[Javier Jimenez Shaw via gdal-dev]

Now I think I understand what you mean.
One effective way is to convert the four sides of the image. To avoid the
conversion of every pixel, you can start a partition process. Then compare
the difference between the transformed central point and just the mid point
between the extremes. If that different is bigger than an certain
threshold, keep subdividing each side. With that you have a good
approximation of the borders of the image transformed, and then you can
compute your bounding box.
The idea is not mine. Even Rouault mentioned it last year in FOSS4G. IIRC,
it is used by gdalwarp to not reproject every single point; once the
subdivision is enough, then it does linear interpolation.

On Fri, 3 May 2024 at 22:18, Simon Eves  wrote:

> Yes, but that's just the corners.
>
> Consider, say, a raster that contains a satellite sweep which is not
> axis-aligned but forms a "windshield wiper" shape in lon/lat space. The
> bounding box of ALL the pixels is not just the bounding box of the corners.
>
> On Fri, May 3, 2024 at 1:09 PM Javier Jimenez Shaw 
> wrote:
>
>> Maybe I don't understand your question, but in gdalinfo you have the four
>> corners as lat-lon
>>
>> On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev, <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> So we are trying to optimize our raster import process, and particularly
>>> the steps to derive the final WGS84/4326 bounding box for a raster file or
>>> tile thereof.
>>>
>>> Obviously in the general case, the transform is from integer pixel
>>> coordinate through the Affine Transformation matrix and then whatever
>>> OGRCoordinateTransformation is required to get to WGS84/4326, and perhaps a
>>> GCP-based mesh transformation too.
>>>
>>> Currently we are deriving the bounding box by passing all pixels of the
>>> four edges of the file/tile through the full transform, except in the
>>> simple Affine-only case where we just transform the four corners.
>>>
>>> Is there any shortcut API provided by GDAL or PROJ to allow the bounding
>>> box to be computed (or at least safely over-estimated) in the general case?
>>> I'm assuming that even a non-GCP  OGRCT could still be non-linear such that
>>> just transforming the corners is insufficient.
>>>
>>> Thanks in advance,
>>>
>>> Simon
>>>
>>> --
>>> Simon Eves
>>> Senior Rendering Engineer
>>> +1 (415) 902-1996
>>> simon.e...@heavy.ai
>>>
>>> 
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Efficient raster bounding box transformation?

[Javier Jimenez Shaw via gdal-dev]

Maybe I don't understand your question, but in gdalinfo you have the four
corners as lat-lon

On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev, 
wrote:

> So we are trying to optimize our raster import process, and particularly
> the steps to derive the final WGS84/4326 bounding box for a raster file or
> tile thereof.
>
> Obviously in the general case, the transform is from integer pixel
> coordinate through the Affine Transformation matrix and then whatever
> OGRCoordinateTransformation is required to get to WGS84/4326, and perhaps a
> GCP-based mesh transformation too.
>
> Currently we are deriving the bounding box by passing all pixels of the
> four edges of the file/tile through the full transform, except in the
> simple Affine-only case where we just transform the four corners.
>
> Is there any shortcut API provided by GDAL or PROJ to allow the bounding
> box to be computed (or at least safely over-estimated) in the general case?
> I'm assuming that even a non-GCP  OGRCT could still be non-linear such that
> just transforming the corners is insufficient.
>
> Thanks in advance,
>
> Simon
>
> --
> Simon Eves
> Senior Rendering Engineer
> +1 (415) 902-1996
> simon.e...@heavy.ai
>
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal2tiles for floating point images

[Javier Jimenez Shaw via gdal-dev]

I know that this is not what you want... but have you considered to use
COG? Openlayers supports it, Leaflet I am not sure (I hope it does, at
least via plugin).
To improve performance, I warped to web mercator with GDAL, so Openlayers
is not wasting time on the reprojection.

On Tue, 30 Apr 2024 at 15:37, Michael Sumner via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Ok so my naive edits are clearly not enough, they still get written as
> Byte so it's deeper in the target spec and spread across a few places I'm
> not ready to get across yet.
>
> Happy to pursue in the longer term though.
>
> Cheers, Mike
>
>
> On Tue, Apr 30, 2024 at 7:00 AM Michael Sumner  wrote:
>
>>
>>
>> On Fri, Apr 26, 2024 at 5:37 AM lefsky--- via gdal-dev <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> I'd like to have a version of gdal2tiles that handles image types other
>>> than uint8. Is there a reason why it doesn't handle those types of images?
>>> It appears I'd have to modify the output format from png to tiff.  I have
>>> never modified gdal source before and I'm wondering if this modification
>>> (which appears straightforward to a naive user) hasn't been done before.
>>>
>>
>>
>> Hello, it appears to be sufficient to add GTiff to tiledriver options,
>> handle the file extension, and add an option to override the error/message
>> that advises conversion to Byte:
>>
>>
>> https://github.com/OSGeo/gdal/compare/master...dis-organization:gdal:gdal2tiles-nonbyte
>>
>> I wanted this myself as I'm working on a version of the tiling in an R
>> package, and I'm not confident enough about it without being able to
>> compare to gdal2tiles.py.
>>
>> It will need care to prepare it and merge into GDAL itself, with some
>> thought about documentation, implications for html output (it's compleltely
>> incompatible with the html produced I expect), and tests, but if you want
>> to use it locally it seems ok and I'm happy to follow up off-list.
>>
>> Note that you can use VRT to reference such a tiled output for numeric
>> data, I used it for a tiled global elevation source here (so if we fold
>> this into GDAL that could be a nice option to include, VRT for reading as
>> TMS):
>>
>> https://github.com/hypertidy/sds/blob/main/R/sources.R#L41
>>
>> Cheers, Mike
>>
>>
>>
>>
>>>
>>> Michael
>>>
>>>
>>> --
>>> Michael Lefsky (He/His)
>>> Home Location: HVHF+GH
>>> Cell: 970-980-9036
>>> http://www.researcherid.com/rid/A-7224-2009
>>>
>>> *“for being prematurely, and worse, intuitively right — there’s a heavy
>>> price. But for being wrong — no, not so long as you’re wrong in a pack."
>>> Gary Brecher / Portis*
>>>
>>> *I acknowledge that I live and work on stolen land. This is the land of
>>> the Cheyenne, Arapaho, Ute, and Ocheithi Sakowin people. To learn more
>>> about these nations, please visit;
>>> http://www.utemountainutetribe.com/
>>> http://www.cheyennenation.com/
>>> https://cheyenneandarapaho-nsn.gov/
>>> https://native-land.ca/
>>>
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
>>
>> --
>> Michael Sumner
>> Software and Database Engineer
>> Australian Antarctic Division
>> Hobart, Australia
>> e-mail: mdsum...@gmail.com
>>
>
>
> --
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsum...@gmail.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Reading interpolated values on DSM

[Javier Jimenez Shaw via gdal-dev]

Hi all

Thanks for your answers

Just to get some values, the VRT was enough to get an idea. Thanks Jukka.
The questions was more like "this should be somewhere, and I do not find
it", but apparently "it was not there".
I see that GDALRasterInterpolateAtPoint could be useful (I am surprised it
was was not needed before). I will try to add it at some point.

Best regards,
Javier.

On Wed, 24 Apr 2024 at 15:16, Even Rouault 
wrote:

>
> Le 24/04/2024 à 15:00, Michael Sumner a écrit :
>
> Or a grouping function that returned the cell index for neighbours and
> weighting that are involved in whatever calculation summary is wanted.
>
> That doesn't seem super user friendly, as users would still be left to do
> the raster value extraction and applying the weights, taking into account
> nodata, etc. Not trivial. What is the advantage of this compared to
> returning the interpolated value? The only one I see is to potentially save
> a bit of computation if you need to interpolate values at the same location
> in multiple bands, but the performance gain would probably be marginal (or
> if not, then a variant of the function dealing with multiple bands could be
> offered)
>
>
> Maybe the warper could return this as a starting point rather than doing
> the "task at hand". ?
>
> The warper code has indeed a "FilterFuncType
> GWKGetFilterFunc(GDALResampleAlg eResampleAlg)" method that returns a
> function that returns interpolation weights and int
> GWKGetFilterRadius(GDALResampleAlg eResampleAlg). The code in
> GDALRPCGetDEMHeight() has an interesting logic where it caches a window of
> interest around the first queried pixel so that subsequent queries in the
> neighbouroud can be honoured without going to RasterIO(). This
> substantially improves performance in the RPC case, in particular during
> reverse transformation where you use an iterative method and thus may need
> a lot of DEM extraction to compute a single point.
>
>
>
>
> On Wed, Apr 24, 2024 at 8:51 PM Even Rouault via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
>> Hi,
>>
>> I guess this discussion, and past similar ones, calls for an enhancement.
>> A new API function, like CPLErr
>> GDALRasterInterpolateAtPoint(GDALRasterBandH, double dfPixel, double
>> dfLocation, GDALRIOResampleAlg eInterpolation, double *pdfValue), that
>> could be used by a new mode of gdallocationinfo. The GDALRPCGetDEMHeight()
>> function in alg/gdal_rpc.cpp is a plausible candidate implementation for
>> bilinear and bicubic (we could potentially restrict to that at the moment).
>>
>> Even
>> Le 24/04/2024 à 10:33, Javier Jimenez Shaw via gdal-dev a écrit :
>>
>> Hi
>>
>> I would like to read in QGIS or GDAL an interpolated value in a DSM
>> (well, actually it is a geoid model, but it is the same behaviour). See
>> that I do not want the pixel value, but the linear interpolation among the
>> neighbour pixels, assuming that the pixel value is in the center of the
>> pixel.
>> For instance, this file
>> https://www.isgeoid.polimi.it/Geoid/Asia/Japan/japan2000_g.html
>>
>> Is there any way to get it (without implementing the interpolation
>> myself)?
>> If I understood correctly gdallocationinfo is not interpolating, just
>> giving the pixel value.
>>
>> Thanks
>>
>> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>>
>> ___
>> gdal-dev mailing 
>> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> -- http://www.spatialys.com
>> My software is free, but my time generally not.
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
> --
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsum...@gmail.com
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] don't search side car files on s3 with gdalinfo

[Javier Jimenez Shaw via gdal-dev]

Thanks Michael and Even

GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR works perfectly for me, in gdalinfo
and QGIS. Great.

Even. No, I was not setting GDAL_DISABLE_READDIR_ON_OPEN at all. I think I
do not have directory listing permission in that folder/bucket (that is why
it returns a 403, and not a 404, right?)

Cheers,
Javier.

On Sat, 27 Apr 2024 at 13:48, Even Rouault 
wrote:

> yes, GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR is the trick to both disable
> directory listing and preventing individual file probing.
>
> Javier, do you have GDAL_DISABLE_READDIR_ON_OPEN=YES also set? Otherwise
> if GDAL_DISABLE_READDIR_ON_OPEN is not set, GDAL will normally issue a S3
> directory listing call, which should prevent later individual file probing
> (if we have the list of files in the directory, we just need to check the
> list, and don't need to do individual open()/GET attempts). But that
> director listing is sometimes still undesirable if doing it in a folder
> with a large number of files hence GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR.
> Or maybe you don't have directory listing permission in that folder/bucket?
>
> Related to that, Howard filed https://github.com/OSGeo/gdal/issues/9443
> recently. but it is not that simple to find a different default behavior
> that doesn't result in functional regressions.
>
> I was wondering if a solution, restricted to COG, couldn't be to put a
> hint in the so-called "header ghost area" (
> https://gdal.org/drivers/raster/cog.html#header-ghost-area), like
> SIDECAR_FILES=NO, that could be used by the GTiff driver. Not sure if it is
> the right way to address the issue however (and would work only for new
> files of course, and probably only on explicit user choice at file
> creation, because there could be scenarios where a user would want to
> provide side car files)
> Le 27/04/2024 à 13:12, Michael Smith via gdal-dev a écrit :
>
> Javier,
>
>
>
> You can control with the GDAL_DISABLE_READDIR_ON_OPEN configuration
> parameter (https://gdal.org/user/configoptions.html). Typically, I set
> GDAL_DISABLE_READDIR_ON_OPEN=EMPTY_DIR which will disable this.
>
>
>
> Mike
>
>
>
>
>
> --
>
> Michael Smith
>
> Remote Sensing/GIS Center
>
> US Army Corps of Engineers
>
>
>
>
>
> *From: *gdal-dev 
>  on behalf of Javier Jimenez Shaw via
> gdal-dev  
> *Reply-To: *Javier Jimenez Shaw  
> *Date: *Saturday, April 27, 2024 at 7:01 AM
> *To: *gdal dev  
> *Subject: *[gdal-dev] don't search side car files on s3 with gdalinfo
>
>
>
> Hi
>
>
>
> I am accessing a big file in S3. All works fine (when I learned how to set
> the authentication environment variables), but gdalinfo is checking for a
> lot of files that do not exist. I know there is only a GeoTIFF - COG (no
> side car files)
>
>
>
> However gdalinfo is trying to find several side car files, that are not
> there. S3 returns a 403. It takes its time to search for all those files.
>
>
>
> Is there a way to tell to gdalinfo that it should not check for those
> files?
>
>
>
> Bonus: QGIS is also taking time to open it (just using 'qgis' instead of
> 'gdalinfo' in the command line). I think it is for the same reason. It
> there a hack there as well?
>
>
>
> Thanks.
>
>
>
> $ AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=...
> gdalinfo /vsis3/blah/folder/ortho.tiff
> Driver: GTiff/GeoTIFF
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.tiff.aux.xml: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.aux: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.AUX: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.tiff.aux: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.tiff.AUX: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.tiff.ovr: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.tiff.OVR: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.tiff.msk: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.tiff.MSK: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.XML: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.xml: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.IMD: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/ortho.imd: 403
> Warning 1: HTTP response code on
> https://blah.s3.amazonaws.com/folder/orth

[gdal-dev] don't search side car files on s3 with gdalinfo

[Javier Jimenez Shaw via gdal-dev]

Hi

I am accessing a big file in S3. All works fine (when I learned how to set
the authentication environment variables), but gdalinfo is checking for a
lot of files that do not exist. I know there is only a GeoTIFF - COG (no
side car files)

However gdalinfo is trying to find several side car files, that are not
there. S3 returns a 403. It takes its time to search for all those files.

Is there a way to tell to gdalinfo that it should not check for those files?

Bonus: QGIS is also taking time to open it (just using 'qgis' instead of
'gdalinfo' in the command line). I think it is for the same reason. It
there a hack there as well?

Thanks.

$ AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=...
gdalinfo /vsis3/blah/folder/ortho.tiff
Driver: GTiff/GeoTIFF
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.tiff.aux.xml: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.aux: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.AUX: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.tiff.aux: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.tiff.AUX: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.tiff.ovr: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.tiff.OVR: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.tiff.msk: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.tiff.MSK: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.XML: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.xml: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.IMD: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.imd: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.RPB: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.rpb: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.PVL: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.pvl: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_rpc.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_RPC.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_metadata.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_METADATA.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_MTL.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_MTL.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/METADATA.DIM: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/metadata.dim: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_metadata.xml: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho_METADATA.XML: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.RPC: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.rpc: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.pass: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/ortho.PASS: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/summary.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/SUMMARY.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/HDRdisplay.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/HDRdisplay.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/HDRho_display.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/HDRho_display.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/RPCdisplay.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/RPCdisplay.TXT: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/RPCho_display.txt: 403
Warning 1: HTTP response code on
https://blah.s3.amazonaws.com/folder/RPCho_display.TXT: 403
Files: /vsis3/blah/folder/ortho.tiff
...

.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Bumping TileDB minimum from 2.7 to 2.15 for GDAL 3.9?

[Javier Jimenez Shaw via gdal-dev]

Not knowing any detail about TileDB, I find good this bump in GDAL 3.9.0,
that is already changing many other dependency minimum versions.

On Wed, 24 Apr 2024 at 20:45, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> A future TileDB version will remove various deprecated API that the GDAL
> TileDB driver currently uses. https://github.com/OSGeo/gdal/pull/9725
> migrates away from those deprecated APIs, but that causes the minimum
> requirement from TileDB to go from 2.7 to 2.15. It would probably be
> wise to backport this cleanup in the 3.9 branch, so that it doesn't
> cause later packaging issues, typically with conda-forge builds as soon
> as they will package the future TileDB version removing the deprecated
> APIs, which might occur during the GDAL 3.9.x life cycle. Does anyone
> see an issue in doing this bump? The few distributions I'm aware of
> shipping TileDB meet the >= 2.15 requirement: Conda-forge already ships
> TileDB 2.22, Alpine Linux is a 2.17.4.
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Reading interpolated values on DSM

[Javier Jimenez Shaw via gdal-dev]

I think it is not QGIS 3 compatible. It is very old (yes, I tried to
install from the zip,.. and failed)

On Wed, 24 Apr 2024 at 10:51, Paul Harwood  wrote:

> If you want to do it in QGIS ...
>
> https://plugins.qgis.org/plugins/rasterinterpolation/
>
> On Wed, 24 Apr 2024, 09:33 Javier Jimenez Shaw via gdal-dev, <
> gdal-dev@lists.osgeo.org> wrote:
>
>> Hi
>>
>> I would like to read in QGIS or GDAL an interpolated value in a DSM
>> (well, actually it is a geoid model, but it is the same behaviour). See
>> that I do not want the pixel value, but the linear interpolation among the
>> neighbour pixels, assuming that the pixel value is in the center of the
>> pixel.
>> For instance, this file
>> https://www.isgeoid.polimi.it/Geoid/Asia/Japan/japan2000_g.html
>>
>> Is there any way to get it (without implementing the interpolation
>> myself)?
>> If I understood correctly gdallocationinfo is not interpolating, just
>> giving the pixel value.
>>
>> Thanks
>>
>> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Reading interpolated values on DSM

[Javier Jimenez Shaw via gdal-dev]

Hi

I would like to read in QGIS or GDAL an interpolated value in a DSM (well,
actually it is a geoid model, but it is the same behaviour). See that I do
not want the pixel value, but the linear interpolation among the neighbour
pixels, assuming that the pixel value is in the center of the pixel.
For instance, this file
https://www.isgeoid.polimi.it/Geoid/Asia/Japan/japan2000_g.html

Is there any way to get it (without implementing the interpolation myself)?
If I understood correctly gdallocationinfo is not interpolating, just
giving the pixel value.

Thanks

.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Question on building multi band composite and going back to RGB GeoTiff

[Javier Jimenez Shaw via gdal-dev]

In addition to all the previous, what about gamma correction?
Maybe your RGB images are gamma corrected, while the other bands are not.
In that case you will be comparing apples and oranges (in addition to the
scaling problems described before).
That also means that using the multispectral images (even if you had a Blue
one) without gamma correction will have a strange color for us humans using
a monitor.

What I did in the past was to "fake" blue as a combination of red and green
(yes, it is not perfect, but better than nothing), and apply a gamma of 2
to all the bands.

Other "nice" option is to display them as CIR
https://www.mngeo.state.mn.us/chouse/airphoto/cir.html

Cheers
Javier

On Mon, 22 Apr 2024 at 17:49, Andrew C Aitchison via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> On Mon, 22 Apr 2024, Raley, Nathan via gdal-dev wrote:
>
> > Hmm, good catch.  Looking at the stats for the red band:
> >
> > Band 1 Block=128x128 Type=UInt16, ColorInterp=Gray
> >  Min=130.000 Max=36265.000
> >  Minimum=130.000, Maximum=36265.000, Mean=10415.962, StdDev=3502.933
> >  NoData Value=0
> >  Metadata:
> >STATISTICS_MAXIMUM=36265
> >STATISTICS_MEAN=10415.961859513
> >STATISTICS_MINIMUM=130
> >STATISTICS_STDDEV=3502.9325925887
> >STATISTICS_VALID_PERCENT=49
> >
> > So, is there no way to actually do this via command line, or am I going
> to have to write a python lib to actually read through these and determine
> what they should be scaled to?
>
> There is gdal_transform -scale (and -scale_2 etc.)
>
> What are you going to do with the resulting file ?
> QGIS allows you to make these sorts of adjustments at view-time.
>
> Remember that the max and min values present in an image may not represent
> the full range and the next-door image may have a larger or smaller range
> (or just a shifted range). Imagine a row of three tiles; the middle on on
> the edge of a glacier, the first entirely on the glacier and the last
> entirely off the glacier. You may wish to apply the same scaling to all
> three.
>
> > From: Daniel Evans 
> > Sent: Monday, April 22, 2024 9:29 AM
> > To: Raley, Nathan 
> > Cc: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) <
> gdal-dev@lists.osgeo.org>
> > Subject: [External] Re: [gdal-dev] Question on building multi band
> composite and going back to RGB GeoTiff
> >
> > Hi Nathan, My initial suspicion might just be that the scaling the data
> provider did to go from the raw data to a human-eye-friendly RGB composite
> isn't the conversion you're assuming. I know that with the data I regularly
> work with,
> >
> > Hi Nathan,
> >
> > My initial suspicion might just be that the scaling the data provider
> did to go from the raw data to a human-eye-friendly RGB composite isn't the
> conversion you're assuming.
> >
> > I know that with the data I regularly work with, it may be provided as
> Uint16, but the data range doesn't extend all the way to 65535.
> >
> > If you compare the values in the separate R and G images to the RGB
> composite, do they appear to match the conversion you're assuming, or is
> there a different scaling (and possibly offset)?
> >
> > Cheers,
> > Daniel
> >
> > On Mon, 22 Apr 2024, 15:20 Raley, Nathan via gdal-dev, <
> gdal-dev@lists.osgeo.org> wrote:
> > I currently have a RGB geotiff composite image that has a Byte
> datatype.  I also have individual band images for R, G, Redge, and NIR that
> are UInt16 datatypes.  Since I’m missing the Blue band from the individual
> bands, I was attempting to extract the blue band from the RGB composite
> image, scale it up to the UInt16 datatype, and build a composite VRT with
> R, G, B, NIR, RE bands included in it.  I was then attempting to extract
> the RGB bands from the multispec VRT in order to see if the process was
> working as intended, but I’m getting an extremely blue image.
> >
> > Can anyone shed some light as to what I may be doing wrong here?
> >
> > I started by building a VRT for each band:
> > gdal_translate source_RGB.tif b.vrt -ot UInt16 -of VRT -b 3 -scale 0 255
> 0 65535
> > gdalbuildvrt -b 1 r.vrt source_R.tif
> > gdalbuildvrt -b 1 g.vrt source_G.tif
> > gdalbuildvrt -b 1 nir.vrt source_NIR.tif
> > gdalbuildvrt -b 1 re.vrt source_RE.tif
> >
> > I then merged the VRTs:
> > gdalbuildvrt -separate multispec.vrt r.vrt g.vrt b.vrt nir.vrt re.vrt
> >
> > I now have a multispec.vrt with the R, G, B, NIR, and RE bands, all with
> a UInt16 datatype.
> >
> > Now, I attempted to rebuild a RGB GeoTiff from the composite VRT with
> something like:
> > gdal_translate -ot Byte -of GTiff -b 1 -b 2 -b 3 -scale 0 65535 0 255
> -co PHOTOMETRIC=RGB multispec.vrt multispec.tif
> >
> > Viewing the result in QGIS appears overly blue.  What am I doing wrong
> here?
> >
> > Thanks,
> > Nathan
> >
> > 
> > This email transmission, including any attachments, is intended solely
> for the addressee named above, and may contain confidential or privileged
> 

Re: [gdal-dev] Merging Multi-Band Drone Imagery

[Javier Jimenez Shaw via gdal-dev]

Hi Nathan

Unfortunately there is not ColorInterp for NIR or RedEdge. But you can use
the "Description" of the bands. QGIS will use that name. I do not know how
to do it in gdal_merge (I did in C++).

About computing the NDVI, as far as I know there is no trick to do it in
the "Layer Styling". If anybody knows how to do it, please tell us! So the
solution is to use a raster calculator, and do the maths there.

Representing the "true" colors in QGIS of such images is not easy. Are they
radiometrically corrected? QGIS will try to adjust the min and max value of
each band, that are usually very different. You should adjust it properly.

Cheers

On Fri, 19 Apr 2024 at 23:52, Raley, Nathan via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> I have individual TIFS from the different sensors on the drone.
> Currently, I have the R, G, NIR, and Redge bands.  Is the correct method to
> merge these into a multi-band image that I can then view as NDVI or apply
> other algorithms against just to use:
>
> gdal_merge.py -separate R.TIF G.TIF NIR.TIF RE.TIF -o multispec.tif
>
> I noticed that only the first band is listing as:
> Band 1 Block=2580x1 Type=UInt16, ColorInterp=Gray
> whereas all the others are listing:
> Band 2 Block=2580x1 Type=UInt16, ColorInterp=Undefined
>
> Any attempts to define them as ColorInterp=Gray through gdal_edit fails to
> yield any results.
>
> I was just wanting to confirm I have the correct workflow here.  I haven’t
> had any luck viewing the multispec.tif within QGIS by applying any
> RasterCalculations on the bands in the multispec.tif, so I was wanting to
> confirm I’m not doing anything incorrectly.
>
> I’ve also attempted to pull out the blue band from the RGB camera, and add
> that to the multispec.tif as well, after scaling it from the 0-255 to the
> 0-65535, and that displays the blue band in there.  I can then ColorInterp
> bands 1, 2, and 3 as red, green, and blue, then it appears to let me
> specify the 4 and 5 bands as gray, but the colors are way off.
>
> Can anyone offer some assistance?
>
>
>
> Thanks,
>
> Nathan
>
>
> --
> This email transmission, including any attachments, is intended solely for
> the addressee named above, and may contain confidential or privileged
> information. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution or use of the contents of this e-mail is
> prohibited. If you have received this e-mail in error, please notify the
> sender immediately by reply email and destroy the message and its
> attachments.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How do I add a projection to proj 8?

[Javier Jimenez Shaw via gdal-dev]

On Sat, 13 Apr 2024 at 17:35, Stephen Woodbridge via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Thanks, this is NOT the standard Web Mercator projection. I am aware of
> EPSG:90013 and EPSG:3857. This projection is used with HYCOM data that I
> have extracted into geotif files so that I can accurately project that onto
> EPSG:3857. It took some fiddling with the values to get to overlay visually
> correctly. HYCOM data is weird in that it uses two different projections
> based on if the data is above or below some latitude.
>
I found something like that in the Internet. But I was not sure it was the
right one https://polar.ncep.noaa.gov/global/about/ It didn't specify the
projections, just a short description as Arctic bi-polar patch north of
47N, and Mercator south of it.

I do not know if you can specify a projection "in parts" respect to
parallel 47. Maybe in WKT2.

Where did you found those parameters for the datum and projection? They are
quite strange.

For the ellipsoid there are a few already with a similar radius:

SELECT * from ellipsoid where semi_major_axis BETWEEN 6371000 and 6371010

EPSG 7035 Sphere
PROJ EARTH 6371000.0 EPSG 9001
6371000.0 1
EPSG 7048 GRS 1980 Authalic Sphere
PROJ EARTH 6371007.0 EPSG 9001
6371007.0 0
ESRI 107047 Sphere_GRS_1980_Mean_Radius Sphere with mean radius based on
GRS80 PROJ EARTH 6371008.7714 EPSG 9001 0.0
0

And datums

SELECT * from geodetic_datum where ellipsoid_code in (7035, 7048, 107047)

EPSG 6035 Not specified (based on Authalic Sphere)
EPSG 7035 EPSG 8901




1
EPSG 6047 Not specified (based on GRS 1980 Authalic Sphere)
EPSG 7048 EPSG 8901




1
ESRI 106047 D_Sphere_GRS_1980_Mean_Radius GRS 1980 Mean Radius Sphere ESRI
107047 EPSG 8901




0

and geographic crs

SELECT * from geodetic_crs where datum_code in (6035, 6047, 106047)

EPSG 4035 Unknown datum based upon the Authalic Sphere
geographic 2D EPSG 6402 EPSG 6035
1
EPSG 4047 Unspecified datum based upon the GRS 1980 Authalic Sphere
geographic 2D EPSG 6422 EPSG 6047
1
ESRI 104047 GCS_Sphere_GRS_1980_Mean_Radius
geographic 2D EPSG 6422 ESRI 106047
0

See that EPSG ones are deprecated. (surprisingly the ellipsoid EPSG:7048 is
not deprecated, but the datum that uses it is deprecated).

On 4/13/2024 4:19 AM, Javier Jimenez Shaw via gdal-dev wrote:
>
> If what you need is really EPSG:3857, yes, use it.
>
> However I have seen strange parameters on your projection. The radius of
> the sphere is the "average" 3671 km, and you set a false easting and
> northing of just 4.4 km. Is that trying to correct the radius of the
> sphere? I do not know why you need that.
>
> Bas, are they really equivalent?
>
> In proj you can convert to WKT1 (see that I added +type=crs):
>
> projinfo "+proj=merc +a=6371001 +b=6371001 +lat_ts=0.0 +lon_0=0.0
> +x_0=-4448 +y_0=-4448 +k=1.0 +units=m +over +nadgrids=@null +no_defs
>  +type=crs" -o wkt1_gdal
>
> Ok I get this adding by +type=crs but how do I add it to the proj
> database so I can access it referencing it by something like EPSG:90014?
>
>
Is a WKT string enough?

PROJCS["unknown",
GEOGCS["unknown",
DATUM["unknown using nadgrids=@null",
SPHEROID["unknown",6371001,0]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",-4448],
PARAMETER["false_northing",-4448],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
EXTENSION["PROJ4","+proj=merc +a=6371001 +b=6371001 +lat_ts=0.0
+lon_0=0.0 +x_0=-4448 +y_0=-4448 +k=1.0 +units=m +over +nadgrids=@null
+no_defs"]]

(generated with the projinfo line from prev email) Using a geographic CRS
as described above will make it nicer, and probably more compatible.

You can use it in QGIS for instance. I am not sure how does it behave in a
GeoTIFF, as it has some special tags. You can try to generate the geotiff
with gdal with that WKT, and see that happens.

About adding to proj.db as EPSG:900914, I am not sure of all the steps. But
I would say that you have to create a datum and a geographic crs (or use
one of the above), in addition to the projection (conversion, parameters,
etc) and the projected crs. And then "compile" the database.
Is it worth it?
In case you modify proj.db, instead of using EPSG, you can create your own
authority, or use "PROJ" authority. It will be cleaner.



> Thanks,
>   -Steve
>
>
> On Sat, 13 Apr 2024 at 06:17, Sebastiaan Cou

Re: [gdal-dev] How do I add a projection to proj 8?

[Javier Jimenez Shaw via gdal-dev]

Yes, such CRS was used until EPSG:3857 was added
(900913 tries to mimic Google letters with numbers, as it was used by
google maps).

But the parameters given by Stephen are a bit different. Probably that's
why the number ends with 4

You can see the (deprecated) proj4 string of 900913 at
https://spatialreference.org/ref/epsg/900913/proj4.txt

On Sat, 13 Apr 2024 at 11:12, Sebastiaan Couwenberg via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> On 4/13/24 10:19 AM, Javier Jimenez Shaw via gdal-dev wrote:
> > Bas, are they really equivalent?
> As far as I know they are, where one used to use EPSG:900913 they should
> now be using EPSG:3857, as 900913 is deprecated.
>
>   https://wiki.openstreetmap.org/wiki/Web_Mercator
>
> Kind Regards,
>
> Bas
>
> --
>   GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How do I add a projection to proj 8?

[Javier Jimenez Shaw via gdal-dev]

If what you need is really EPSG:3857, yes, use it.

However I have seen strange parameters on your projection. The radius of
the sphere is the "average" 3671 km, and you set a false easting and
northing of just 4.4 km. Is that trying to correct the radius of the
sphere? I do not know why you need that.

Bas, are they really equivalent?

In proj you can convert to WKT1 (see that I added +type=crs):

projinfo "+proj=merc +a=6371001 +b=6371001 +lat_ts=0.0 +lon_0=0.0
+x_0=-4448 +y_0=-4448 +k=1.0 +units=m +over +nadgrids=@null +no_defs
 +type=crs" -o wkt1_gdal


On Sat, 13 Apr 2024 at 06:17, Sebastiaan Couwenberg via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> On 4/12/24 11:24 PM, Stephen Woodbridge via gdal-dev wrote:
> > and was able to access it in gdal, mapserver, postgis, etc with
> > "EPSG:900914"
>
> I used to do that too, but switched to EPSG:3857 its non-deprecated
> equivalent. I would recommend that instead of trying to keep using a
> non-standard projection.
>
> Kind Regards,
>
> Bas
>
> --
>   GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.5RC1 available, and motion to adopt it

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Tue, 2 Apr 2024 at 14:49, Howard Butler via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> Howard
>
> > On Apr 2, 2024, at 6:09 AM, Rahkonen Jukka via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
> >
> > +1
> >
> > -Jukka Rahkonen-
> >
> > -Alkuperäinen viesti-
> > Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> > Lähetetty: tiistai 2. huhtikuuta 2024 13.17
> > Vastaanottaja: gdal-dev@lists.osgeo.org
> > Aihe: [gdal-dev] GDAL 3.8.5RC1 available, and motion to adopt it
> >
> > Hi,
> >
> > I have prepared a GDAL/OGR 3.8.5 release candidate. This is likely to be
> the last bug fix release in the 3.8.x series, with 3.9.0 coming beginning
> of May.
> > ...
> >
> > Motion: adopt 3.8.5RC1 as final 3.8.5
> >
> > Starting with my +1
> >
> > Best regards,
> >
> > Even
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [EXTERNAL] [BULK] Re: Experience with slowness of free() on Windows with lots of allocations?

[Javier Jimenez Shaw via gdal-dev]

for tcmalloc do you need master? this recent release seems to have CMake
https://github.com/gperftools/gperftools/releases/tag/gperftools-2.15

Of course, I do not mean to force the usage of it. But could be a
suggestion in case we do not find anything better and a user has problems.
Or a way to inspire later research.

For us it is definitely helping.

Cheers,
Javier

On Thu, 21 Mar 2024 at 14:59, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> I've played with VirtualAlloc(NULL, SINGLE_ALLOC_SIZE, MEM_COMMIT |
> MEM_RESERVE, PAGE_READWRITE), and it does avoid the performance issue.
> However I see that VitualAlloc() allocates by chunks of 64 kB, so depending
> on the size of a block, it might cause significant waste of RAM, so that
> can't be used as a direct replacement of malloc().
>
> My inclination would be to perhaps have an optional config option like
> GDAL_BLOCK_CACHE_USE_PRIVATE_HEAP that could be set, and when doing so it
> would use HeapCreate(0, 0, GDAL_CACHEMAX) to create a heap only used by the
> block cache. Not ideal, since that would reserve the whole GDAL_CACHEMAX
> (but for a large enough processing, you'll end up consuming it), but it has
> the advantage of not being extremely intrusive either... and could be
> easily ditched/replaced by something better in the future.
>
> Regarding tcmalloc, I've had to use it on Linux too, but only on scenarios
> involving multithreading where it helps reducing RAM fragmentation: cf
> https://gdal.org/user/multithreading.html#ram-fragmentation-and-multi-threading
> . I've just tried quickly to use it on Windows to test it on the scenario,
> but didn't really manage to make it work. Even building it was challenging.
> Actually I tried https://github.com/gperftools/gperftools and I had to
> build from master since the latest tagged version doesn't build with CMake
> on Windows. But then nothing happens when linking tcmalloc_minimal.lib
> against my toy app. I probably missed something.
>
> Anyway I don't really think we can force tcmalloc to be used in GDAL, as a
> library. Unless there would be a way to have its allocator to be optionnaly
> used at places that we control (ie explicitly call tc_malloc / tc_free),
> and not replace the default malloc / free etc, which might be undesirable
> when GDAL is just a component of a larger application.
>
> Disabling entirely the block cache (or setting it to a minimum value) is
> only a workable option for uncompressed formats, or if you use per-band
> blocks (INTERLEAVE=BAND in GTiff language) and not one block for all bands
> (INTERLEAVE=PIXEL), otherwise you'll pay multiple time the decompression.
> Le 21/03/2024 à 14:38, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
> APPLICATIONS INC] via gdal-dev a écrit :
>
> +1.  We use a variety of hand-rolled VirtualAlloc based (for basic tasks,
> a simple pointer bump, and for more elaborate needs, a ‘buddy’) allocators,
> some of which try to be smart about memory usage via de-committing
> regions.  In our work, we tend to disable the GDAL cache entirely and rely
> on the file system’s file cache instead, which is a simplification we can
> make but is surely untenable in general here.
>
>
>
> *From: *gdal-dev 
>  on behalf of Abel Pau via gdal-dev
>  
> *Reply-To: *Abel Pau  
> *Date: *Thursday, March 21, 2024 at 4:51 AM
> *To: *"gdal-dev@lists.osgeo.org" 
>  
> *Subject: *[EXTERNAL] [BULK] Re: [gdal-dev] Experience with slowness of
> free() on Windows with lots of allocations?
>
>
>
> *CAUTION:* This email originated from outside of NASA.  Please take care
> when clicking links or opening attachments.  Use the "Report Message"
> button to report suspicious messages to the NASA SOC.
>
>
>
> Hi Even,
>
>
>
> you’re right. We also know that. When programming the driver I took it in
> consideration. Our solution is not rely on windows to make a good job with
> memory and we try to reuse as memory as possible instead of use calloc/free
> freely.
>
>
>
> For instance, in the driver, for each feature I have to get or write the
> coordinates. I could do it every time I have to, so lots of times: create
> memory for reading, and then put them on the feature, and then free... so
> many times. What I do? When opening the layer I create some memory blocs of
> 250 Mb (due to the format itself) and I use that created memory to manage
> whatever I need. And when closing, I free it.
>
>
>
> While doing that I observed that sometimes I have to use GDAL code that
> doesn’t take it in consideration (CPLRecode() for instance). Perhaps it
> could be improves as well.
>
>
>
> Thanks for noticing that.
>
>
>
> *De:* gdal-dev 
>  *En nombre de *Javier Jim

Re: [gdal-dev] Experience with slowness of free() on Windows with lots of allocations?

[Javier Jimenez Shaw via gdal-dev]

In my company we confirmed that "Windows heap allocation mechanism sucks."
Closing the application after using gtiff driver can take many seconds due
to memory deallocations.

One workaround was to use tcmalloc. I will ask my colleagues more details
next week.

On Thu, 21 Mar 2024, 01:55 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> while investigating
> https://github.com/OSGeo/gdal/issues/9510#issuecomment-2010950408, I've
> come to the conclusion that the Windows heap allocation mechanism sucks.
> Basically if you allocate a lot of heap regions of modest size with
> malloc()/new[], the time spent when freeing them all with corresponding
> free()/delete[] is excruciatingly slow (like ~ 10 seconds for ~ 80,000
> allocations). The slowness is clearly quadratic with the number of
> allocations. You only start noticing it with ~ 30,000 allocations. And
> interestingly, another condition for that slowness is that each
> individual allocation much be strictly greater than 4096 * 4 bytes. At
> exactly that value, perf is acceptable, but add one extra byte, and it
> suddenly drops. I suspect that there must be a threshold from which
> malloc() starts using VirtualAlloc() instead of the heap, which must
> involve slow system calls, instead of a user-land allocation mechanism.
>
> Anyone has already hit that and found solutions? The only potential idea
> I found until now would be to use a private heap with HeapCreate() with
> a fixed maximum size, which is a bit problematic to adopt by default,
> basically that would mean that the size of GDAL_CACHEMAX would be
> consumed as soon as one use the block cache.
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Internal libtiff version

[Javier Jimenez Shaw via gdal-dev]

Probably here:
https://github.com/OSGeo/gdal/blob/master/frmts/gtiff/libtiff/tiffvers.h

On Mon, 18 Mar 2024 at 11:28, Luí­s Moreira de Sousa via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi all,
>
> I am currently facing the error "PREDICTOR=2 is only supported with 64
> bit samples starting with libtiff > 4.3.0" with GDAL 3.6.4. Libtiff 4.3.0
> was released in 2022, about a year before that version of GDAL. Is there a
> way to know which version of Libtiff is included with which version of
> GDAL? I searched the web site but could not find it.
>
> Thank you.
>
> --
> Luís
>
>
> Sent with Proton Mail  secure email.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Using a "standard" argument parser for command line utilities?

[Javier Jimenez Shaw via gdal-dev]

I don't like that the behaviour of a command line depends on the
configuration of the user (that is usually not aware of). So a command that
works for me doesn't work for you. That is bad.
I don't know in GDAL, but in proj there is the option --bbox, that has
comma separated coordinates. That can be -10.5,5.1,-9.5,6.3

On Fri, 8 Mar 2024 at 18:27, Even Rouault 
wrote:

>
> >
> > In principle the idea sounds good.
> >
> > How is it parsing the numbers? is it locale agnostic? I think it is
> > not, because it is using "strtod". That means that if I have my locale
> > in Spanish, French, German, ... it will expect "," as the decimal
> > separator, right?
> if running under a non-C locale, and without modification, yes
> > ... well, how is GDAL expecting floating values?
>
> Only if the utilities enables setlocale(LC_ALL, ""), which they don't by
> default. That said as the command line utility parsing is also used for
> the utility-as-C-function, we may run under a non-C locale (that is a
> Spanish/French/whatever locale) in some contexts.
>
> > Is GDAL locale agnostic?
> Grep'ping I see that we use both CPLAtof() which is locale-agnostic and
> assume dot as decimal separator or CPLAtofM() which accept dot or comma
> as decimal separator. I don't think there is a particular reason in
> using any of them. Inconsistency likely due to doing the work manually
> and depending on the mood of the developer. Not totally sure of the
> behavior we want: should we always require dot as the decimal separator,
> or be lenient and accept both dot and comma (wondering if there wouldn't
> be situations where we would take a "a,b,c" string, with a, b, c being
> floating point numbers, in which case obviously we would have to require
> dot. But I'm not sure if that can happen)
> >
> > Do you want to add it as a dependency, or just copy-paste the header
> > file into gdal repo?
>
> yes, copy-paste and potentially with a few changes for our needs, like
> using CPLAtof or CPLAtofM.
>
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Using a "standard" argument parser for command line utilities?

[Javier Jimenez Shaw via gdal-dev]

Hi Even.

In principle the idea sounds good.

How is it parsing the numbers? is it locale agnostic? I think it is not,
because it is using "strtod". That means that if I have my locale in
Spanish, French, German, ... it will expect "," as the decimal separator,
right?
... well, how is GDAL expecting floating values? Is GDAL locale agnostic?

Do you want to add it as a dependency, or just copy-paste the header file
into gdal repo?

On Fri, 8 Mar 2024 at 16:40, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> Our command line C++ utilities use ad-hoc manual parsing, which means that:
>
> -  the usage message must be manually composed,
>
> -  you must take care to check that there are enough remaining arguments
> for the ones that take value to avoid out-of-bounds accesses (tests like
> argc + 1 < argn)
>
> - detection for duplicated arguments when only a single occurrence is
> allowed must be manually done, nd thus is often not done, confusing users,
> cf https://github.com/OSGeo/gdal/issues/9415
>
> - etc.
>
> I've come across https://github.com/p-ranav/argparse which fit all my
> requirements at first sight: compatible with our C++ requirements (C++17),
> MIT license, easily usable (single header), well documented, and enough
> feature-full. From a quick testing, it seems to work well. It looks also as
> it has taken some inspiration from the Python argparse module.
>
> I'd be tempted to give that a try to retrofit our existing utilities
> (probably starting with the ones with the less options :-)). Opinions? I
> guess there must be a plethora of similar projects, due to the absence of a
> std::argparse module... At least I see it is in the list of (9)
> alternatives mentioned at
> https://en.cppreference.com/w/cpp/links/libs?source=post_page---#Configuration:Command_Line
>
> CLI11 looked like a candidate too, but reading
> https://github.com/CLIUtils/CLI11?tab=readme-ov-file#features-not-supported-by-this-library
> "There are some other possible "features" that are intentionally not
> supported by this library:... Non-standard variations on syntax, like
> -long options. This is non-standard and should be avoided, so that is
> enforced by this library." . Fair enough, but we use that extensively in
> GDAL.
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Testing the driver

[Javier Jimenez Shaw via gdal-dev]

I hate that.
I never use "long" exactly for that problem. When the size is important,
uint64_t and friends are very useful, and well defined.

On Fri, 8 Mar 2024 at 10:16, Abel Pau via gdal-dev 
wrote:

> FINALLY!
>
> I discovered the problem.
>
>
>
> I was using “unsigned long” as 4 bytes variable. On windows it’s like that.
>
>
>
> BUT on linux this kind of variable has a 8-bytes size.
>
>
>
> This caused a mess in linux (but not in wondows).
>
> So, mistery closed!
>
>
>
> Thanks you all.
>
>
>
> *De:* gdal-dev  *En nombre de *Abel Pau
> via gdal-dev
> *Enviado el:* dijous, 7 de març de 2024 23:42
> *Para:* Even Rouault ; Andrew C Aitchison <
> and...@aitchison.me.uk>; Daniel Evans 
> *CC:* 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) <
> gdal-dev@lists.osgeo.org>
> *Asunto:* Re: [gdal-dev] Testing the driver
>
>
>
> Hi,
>
> It’s in debug mode, yes, as you suggested.
>
>
>
> yes, it crashes in the same way. Same big number.
>
>
>
> It crashes because of the variable is not read from the file (this
> variable should be 1).
>
> But debugging in windows (where not crashes) this variable is set when
> opening the layer, and then I suppose has the value corrupted at some point.
>
> So I am going to put my old fashion printf on.
>
>
>
> Thanks again!
>
>
>
>
>
>
>
> *De:* Even Rouault 
> *Enviado el:* dijous, 7 de març de 2024 23:32
> *Para:* Abel Pau ; Andrew C Aitchison <
> and...@aitchison.me.uk>; Daniel Evans 
> *CC:* 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) <
> gdal-dev@lists.osgeo.org>
> *Asunto:* Re: [gdal-dev] Testing the driver
>
>
>
>
>
> At #10 we can see the variable nNum set to a non-sense megabignumber.
>
> Is it on a -DCMAKE_BUILD_TYPE=Debug build ? Otherwise stack traces and
> variable content in the debugger might look like garbage because of
> optimizations.
>
> If it is a debug build, then there's likely some memory corruption or
> uninitialized variable in your code. Valgrind is generally a great tool to
> spot that. Otherwise add good old printf() statements to track down where
> the corruption starts. And given your Python sample code, I assume you
> could more easily reproduce the issue in a pure native context, just
> running "ogrinfo -al -q
> autotest/ogr/data/miramon/Polygons/SimplePolygons/SimplePolFile.pol" (if it
> doesn't crash, try running it under gdb or valgrind)
>
> --
>
> http://www.spatialys.com
>
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Some problems after updating

[Javier Jimenez Shaw via gdal-dev]

I am not an expert in Windows at all. But the message says that cannot find
"TransformWithErrorCodes...blablah" in ogr2gr.exe. Could it be that this
method is actually in a dll, and the dll is not found? can be a PATH
problem? There are tools to see the exported methods from a dll. Check that
it does exist, and that is findable by ogr2ogr.exe.

On Tue, 27 Feb 2024 at 10:43, Abel Pau  wrote:

> In *one month* ago gdal code the error persists.
>
> So I have to conclude that this error is related to my vcpkg update with,
> so I’m sad because it’s not something easy to solve.
>
>
>
> *De:* gdal-dev  *En nombre de *Abel Pau
> via gdal-dev
> *Enviado el:* dimarts, 27 de febrer de 2024 10:29
> *Para:* Javier Jimenez Shaw 
> *CC:* gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Ups, forget this compilation error (not the first one).
>
> The directory exists and another program (by error) had it opened causing
> the compiler couldn’t delete it.
>
> So, it was my mistake.
>
> So, I’m going to proceed with that one:
>
>
>
>
>
>
> *De:* Javier Jimenez Shaw 
> *Enviado el:* dimarts, 27 de febrer de 2024 10:18
> *Para:* Abel Pau 
> *CC:* gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> o, Windows debug. That was not easy (when I worked in Windows, more
> than 10 years ago). It is using different names for libraries in debug and
> release.
>
>
>
>  'ogr_VDV.dir\Debug\ogr_VDV.lib':  could you check that is the content of
> that directory? I wouldn't be surprised if the library file there has a
> slightly different name.
>
>
>
> On Tue, 27 Feb 2024 at 10:06, Abel Pau  wrote:
>
> Hi Javier,
>
> I did two changes at the same time (bad  bad, never do that!): one
> updating the code from repo (as usual) and the other one updating vcpkg
> (cause there like 1000 changes in their Git and I though that was a good
> idea).
>
> I suspect the code is good but I’ll make sure doing that bisection method.
>
> Even though this error is rare:
>
>
>
> 3>LINK : fatal error LNK1104: cannot open file
> 'ogr_VDV.dir\Debug\ogr_VDV.lib'
>
> 3>Done building project "ogr_VDV.vcxproj" -- FAILED.
>
>
>
> I wonder why it is not writing (ogr_VDV it’s the only one that have the
> error).
>
> Thanks!
>
>
>
> *De:* Javier Jimenez Shaw 
> *Enviado el:* dimarts, 27 de febrer de 2024 9:57
> *Para:* Abel Pau 
> *CC:* gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Hi Abel,
>
>
>
> If you have clear when it started happening, maybe you can try to find the
> reason using https://git-scm.com/docs/git-bisect
>
> specially as you are reproducing it in your computer (CI is working fine,
> so that should be something related to your configuration).
>
> Replicate it working fine with an older checkout from the repo, then
> replicate it failing today, and look for the change that "breaks" it.
>
> If you cannot replicate the correct behaviour with an older checkout...
> then the problem is not the source code.
>
>
>
> Cheers,
>
> Javier.
>
>
>
> On Tue, 27 Feb 2024 at 09:15, Abel Pau via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
> Hi again,
>
> I built and compiled the Gdal version in GitHub (without my changes) and
> the error is NOT gone.
>
> Anyone has compiled very recently and is capable to call ogr2ogr with no
> problems?
>
>
>
> Thanks
>
>
>
> *De:* gdal-dev  *En nombre de *Abel Pau
> via gdal-dev
> *Enviado el:* dilluns, 26 de febrer de 2024 18:17
> *Para:* Even Rouault ;
> gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Done but it doesn’t work.
>
> The error is the same.
>
> Any other idea?
>
>
>
> *De:* Even Rouault 
> *Enviado el:* dilluns, 26 de febrer de 2024 17:55
> *Para:* Abel Pau ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Perhaps try the good old methods: run the "clean" target and do a full
> rebuild
>
> Le 26/02/2024 à 17:48, Abel Pau via gdal-dev a écrit :
>
> It even now doesn’t work from Visual Studio itself.
>
> I don’t understand what have changed from yesterday to today (apart from
> updating vcpkg and gdal code itself).
>
>
>
>
>
>
>
> *De:* gdal-dev 
>  *En nombre de *Abel Pau via gdal-dev
> *Enviado el:* dilluns, 26 de febrer de 2024 17:42
> *Para:* Even Rouault 
> ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Hi Even, thanks for your answer.
>
>
>
> I paste here some of my variables:
>
> After too many months perhaps there are things that are not necessary, but
> the one you sais is there:
>
>
>
> *GDAL_DATA *
>
> D:\GitHub-repository\GDAL\build\data
>
>
>
> *PATH *
>
> PATH%;
>
> D:\GitHub-repository\GDAL\build\Debug;
>
> C:\Users\a.pau\AppData\Local\GitHubDesktop\bin;
>
> C:\Program Files\Graphviz\bin;
>
> D:\GitHub-repository\odbc-cpp-wrapper\build\src\odbc\Release;
>
> D:\mapes\programes\make-3.81-bin\bin;
>
>
>
> But same error appears :(
>
>
>
>
>
> *De:* Even Rouault 
> 

Re: [gdal-dev] Some problems after updating

[Javier Jimenez Shaw via gdal-dev]

o, Windows debug. That was not easy (when I worked in Windows, more
than 10 years ago). It is using different names for libraries in debug and
release.

 'ogr_VDV.dir\Debug\ogr_VDV.lib':  could you check that is the content of
that directory? I wouldn't be surprised if the library file there has a
slightly different name.

On Tue, 27 Feb 2024 at 10:06, Abel Pau  wrote:

> Hi Javier,
>
> I did two changes at the same time (bad  bad, never do that!): one
> updating the code from repo (as usual) and the other one updating vcpkg
> (cause there like 1000 changes in their Git and I though that was a good
> idea).
>
> I suspect the code is good but I’ll make sure doing that bisection method.
>
> Even though this error is rare:
>
>
>
> 3>LINK : fatal error LNK1104: cannot open file
> 'ogr_VDV.dir\Debug\ogr_VDV.lib'
>
> 3>Done building project "ogr_VDV.vcxproj" -- FAILED.
>
>
>
> I wonder why it is not writing (ogr_VDV it’s the only one that have the
> error).
>
> Thanks!
>
>
>
> *De:* Javier Jimenez Shaw 
> *Enviado el:* dimarts, 27 de febrer de 2024 9:57
> *Para:* Abel Pau 
> *CC:* gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Hi Abel,
>
>
>
> If you have clear when it started happening, maybe you can try to find the
> reason using https://git-scm.com/docs/git-bisect
>
> specially as you are reproducing it in your computer (CI is working fine,
> so that should be something related to your configuration).
>
> Replicate it working fine with an older checkout from the repo, then
> replicate it failing today, and look for the change that "breaks" it.
>
> If you cannot replicate the correct behaviour with an older checkout...
> then the problem is not the source code.
>
>
>
> Cheers,
>
> Javier.
>
>
>
> On Tue, 27 Feb 2024 at 09:15, Abel Pau via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
>
> Hi again,
>
> I built and compiled the Gdal version in GitHub (without my changes) and
> the error is NOT gone.
>
> Anyone has compiled very recently and is capable to call ogr2ogr with no
> problems?
>
>
>
> Thanks
>
>
>
> *De:* gdal-dev  *En nombre de *Abel Pau
> via gdal-dev
> *Enviado el:* dilluns, 26 de febrer de 2024 18:17
> *Para:* Even Rouault ;
> gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Done but it doesn’t work.
>
> The error is the same.
>
> Any other idea?
>
>
>
> *De:* Even Rouault 
> *Enviado el:* dilluns, 26 de febrer de 2024 17:55
> *Para:* Abel Pau ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Perhaps try the good old methods: run the "clean" target and do a full
> rebuild
>
> Le 26/02/2024 à 17:48, Abel Pau via gdal-dev a écrit :
>
> It even now doesn’t work from Visual Studio itself.
>
> I don’t understand what have changed from yesterday to today (apart from
> updating vcpkg and gdal code itself).
>
>
>
>
>
>
>
> *De:* gdal-dev 
>  *En nombre de *Abel Pau via gdal-dev
> *Enviado el:* dilluns, 26 de febrer de 2024 17:42
> *Para:* Even Rouault 
> ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Hi Even, thanks for your answer.
>
>
>
> I paste here some of my variables:
>
> After too many months perhaps there are things that are not necessary, but
> the one you sais is there:
>
>
>
> *GDAL_DATA *
>
> D:\GitHub-repository\GDAL\build\data
>
>
>
> *PATH *
>
> PATH%;
>
> D:\GitHub-repository\GDAL\build\Debug;
>
> C:\Users\a.pau\AppData\Local\GitHubDesktop\bin;
>
> C:\Program Files\Graphviz\bin;
>
> D:\GitHub-repository\odbc-cpp-wrapper\build\src\odbc\Release;
>
> D:\mapes\programes\make-3.81-bin\bin;
>
>
>
> But same error appears :(
>
>
>
>
>
> *De:* Even Rouault 
> *Enviado el:* dilluns, 26 de febrer de 2024 17:30
> *Para:* Abel Pau ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> hi,
>
> perhaps make sure that your PATH environment variable includes a directory
> that contains the gdal.dll of *your* build (should likely be
> D:\GitHub-repository\GDAL\build\Debug) before the one potentially coming
> from vcpkg
>
> Even
>
> Le 26/02/2024 à 17:20, Abel Pau via gdal-dev a écrit :
>
> Hi,
>
>
>
> usually (and always works) I call this two sentences from command line in
> Windows:
>
>
>
> cmake -B D:\GitHub-repository\GDAL\build -S .
> -DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake
>
> cmake --build D:\GitHub-repository\GDAL\build
>
>
>
> The first one generates all projects that I can open with Visual Studio
>
> The second one compilates all files, and it ens with no problems.
>
>
>
> To test is works I’ve been using lots of line commands, for example this
> one (using the program ogr2ogr):
>
>
>
> D:\GitHub-repository\GDAL\build\apps\Debug\ogr2ogr.exe
> D:\mapes\2023\GDAL\Versions\Misteri_V20_a_V11.pol
> D:\mapes\2023\GDAL\Versions\Misteri_V20.pol -progress -lco Version=V1.1
> --config CPL_DEBUG ON
>
>
>
> It’s been working untiel today when next error appears:
>
> 

Re: [gdal-dev] Some problems after updating

[Javier Jimenez Shaw via gdal-dev]

Hi Abel,

If you have clear when it started happening, maybe you can try to find the
reason using https://git-scm.com/docs/git-bisect
specially as you are reproducing it in your computer (CI is working fine,
so that should be something related to your configuration).
Replicate it working fine with an older checkout from the repo, then
replicate it failing today, and look for the change that "breaks" it.
If you cannot replicate the correct behaviour with an older checkout...
then the problem is not the source code.

Cheers,
Javier.

On Tue, 27 Feb 2024 at 09:15, Abel Pau via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi again,
>
> I built and compiled the Gdal version in GitHub (without my changes) and
> the error is NOT gone.
>
> Anyone has compiled very recently and is capable to call ogr2ogr with no
> problems?
>
>
>
> Thanks
>
>
>
> *De:* gdal-dev  *En nombre de *Abel Pau
> via gdal-dev
> *Enviado el:* dilluns, 26 de febrer de 2024 18:17
> *Para:* Even Rouault ;
> gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Done but it doesn’t work.
>
> The error is the same.
>
> Any other idea?
>
>
>
> *De:* Even Rouault 
> *Enviado el:* dilluns, 26 de febrer de 2024 17:55
> *Para:* Abel Pau ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Perhaps try the good old methods: run the "clean" target and do a full
> rebuild
>
> Le 26/02/2024 à 17:48, Abel Pau via gdal-dev a écrit :
>
> It even now doesn’t work from Visual Studio itself.
>
> I don’t understand what have changed from yesterday to today (apart from
> updating vcpkg and gdal code itself).
>
>
>
>
>
>
>
> *De:* gdal-dev 
>  *En nombre de *Abel Pau via gdal-dev
> *Enviado el:* dilluns, 26 de febrer de 2024 17:42
> *Para:* Even Rouault 
> ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> Hi Even, thanks for your answer.
>
>
>
> I paste here some of my variables:
>
> After too many months perhaps there are things that are not necessary, but
> the one you sais is there:
>
>
>
> *GDAL_DATA *
>
> D:\GitHub-repository\GDAL\build\data
>
>
>
> *PATH *
>
> PATH%;
>
> D:\GitHub-repository\GDAL\build\Debug;
>
> C:\Users\a.pau\AppData\Local\GitHubDesktop\bin;
>
> C:\Program Files\Graphviz\bin;
>
> D:\GitHub-repository\odbc-cpp-wrapper\build\src\odbc\Release;
>
> D:\mapes\programes\make-3.81-bin\bin;
>
>
>
> But same error appears :(
>
>
>
>
>
> *De:* Even Rouault 
> *Enviado el:* dilluns, 26 de febrer de 2024 17:30
> *Para:* Abel Pau ; gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Some problems after updating
>
>
>
> hi,
>
> perhaps make sure that your PATH environment variable includes a directory
> that contains the gdal.dll of *your* build (should likely be
> D:\GitHub-repository\GDAL\build\Debug) before the one potentially coming
> from vcpkg
>
> Even
>
> Le 26/02/2024 à 17:20, Abel Pau via gdal-dev a écrit :
>
> Hi,
>
>
>
> usually (and always works) I call this two sentences from command line in
> Windows:
>
>
>
> cmake -B D:\GitHub-repository\GDAL\build -S .
> -DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake
>
> cmake --build D:\GitHub-repository\GDAL\build
>
>
>
> The first one generates all projects that I can open with Visual Studio
>
> The second one compilates all files, and it ens with no problems.
>
>
>
> To test is works I’ve been using lots of line commands, for example this
> one (using the program ogr2ogr):
>
>
>
> D:\GitHub-repository\GDAL\build\apps\Debug\ogr2ogr.exe
> D:\mapes\2023\GDAL\Versions\Misteri_V20_a_V11.pol
> D:\mapes\2023\GDAL\Versions\Misteri_V20.pol -progress -lco Version=V1.1
> --config CPL_DEBUG ON
>
>
>
> It’s been working untiel today when next error appears:
>
> ---
>
> ogr2ogr.exe - No se encuentra el punto de entrada
>
> ---
>
> No se encuentra el punto de entrada del procedimiento
> ?TransformWithErrorCodes@OGRCoordinateTransformation@@UEAAH_KPEAN111PEAH@Z
> en la biblioteca de vínculos dinámicos
> D:\GitHub-repository\GDAL\build\apps\Debug\ogr2ogr.exe.
>
> ---
>
> D'acord
>
> ---
>
>
>
> What is the diference between today and yesterday?
> I’ve done 2 things:
>
> 1.   Download and Install VCPKG (the method that worked for me)
>
> 2.   .\vcpkg\bootstrap-vcpkg.bat
>
> 3.   .\vcpkg integrate install
>
> 4.   .\vcpkg install gdal --triplet=x64-windows
>
>
>
> And, of course, download lasts codes from GDAL to be on date before
> finishing the job I’m doing.
>
>
>
> So, can anyone put some light to this mistery? What I am doing wrong this
> time?
>
> There is some dependence I am using wrong?
>
>
>
> I am a little desperate with that kind of errors.
>
>
>
> Thanks a lot!
>
>
>
>
>
>
>
> *Abel Pau Garcia*
>
> *GIS developer*
>
> [image: https://www.creaf.cat/sites/default/files/creaf-signature.png]
>
> *a@creaf.uab.cat* 
>
> *Let's chat on Teams!*
> 

[gdal-dev] Warp with non-square pixels in C++

[Javier Jimenez Shaw via gdal-dev]

The origin of this question is this ticket in QGIS:

https://github.com/qgis/QGIS/issues/56288

The summary is that with rasters ordered bottom-up, QGIS is doing a Warped
VRT. But Warp us using square pixels... that is distorting too much the
image in some cases (and I would say it is more expensive, but that is not
the problem).
I know, looking at gdalwarp, that the warp can be done with different pixel
size for X and Y.
for instance, with this command:
gdalwarp -tr 0.2 0.1 bottom-up.xyz warped.xyz

I want to provide the pixel size of the original image. And I could use
"GDALWarpAppOptions" dfXRes and dfYRes for that.

However in the code in QGIS (mentioned in the ticket)
https://github.com/qgis/QGIS/blob/3a18496f7c25a00cb26cb5abe0e53b2a13b3de68/src/core/providers/gdal/qgsgdalprovider.cpp#L3590
I only have access to "GDALWarpOptions" (see that there is no "App" in the
name).

I don't see how to provide that data to "GDALAutoCreateWarpedVRT".

Any idea?

Thanks.
Javier

.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Adopt GDAL 3.8.4RC1 as 3.8.4 release

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Fri, 9 Feb 2024 at 10:13, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> Motion:
>
> Adopt GDAL 3.8.4RC1 as 3.8.4 release
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] axis order in gdal_translate

[Javier Jimenez Shaw via gdal-dev]

Thank you.

Yes, I got confused with gdal.VectorTranslate and gdal_translate, when I
really meant ogr2ogr. But you realized that already. Great catch.

On Wed, 7 Feb 2024 at 18:09, Even Rouault 
wrote:

> Javier,
>
>
> Is there a way to tell gdal.VectorTranslate that transformation is
> "always_xy", and I do not have to do the swaps manually? Or maybe there is
> a better way to do it?
>
> If you specify a pipeline, you need to make sure it is written in a way
> where its input coordinates are in the order of the input CRS and its
> output in the order of the axis of the output CRS. The rationale being that
> you copy blindly a pipeline that projinfo -s FOO -t BAR would output.
>
> https://gdal.org/programs/ogr2ogr.html#cmdoption-ogr2ogr-ct : "It must
> take into account the axis order of the source and target CRS."
>
> There's no way to override this.
>
>
> What about the command line gdal_translate?
>
> Same as ogr2ogr / gdal.VectorTranslate
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] axis order in gdal_translate

[Javier Jimenez Shaw via gdal-dev]

Hi

I am calling the python method osgeo.gdal.VectorTranslate to convert a
GeoJSON (with CRS) to shapefile.
To keep consistency among EPSG versions, I have the pipeline of the
conversion, using what in pyproj was "always_xy=True"

gdal.VectorTranslate(
dst_file,
src_file,
coorindateOperation=coordinateOperation,
dstSRS="EPSG:4326",
)

with something like this:
coordinateOperation="+proj=pipeline +step +inv +proj=tmerc +lat_0=44
+lon_0=144.25 +k=0. +x_0=0 +y_0=0 +ellps=GRS80 +step +proj=unitconvert
+xy_in=rad +xy_out=deg"

the srcSRS is taken automatically from the GeoJSON.

The first thing I noticed is that EPSG:4326 is left handed, and I have to
swap the axes. Ok, it is easy to add " +step +proj=axisswap +order=2,1"

In the case of EPSG:2455 (left handed CRS in Japan) I should do the swap
also for the input values, that is a bit uglier. (I have to do some parsing
of the pipeline that was generated time ago, and know that EPSG:2455 is
left handed).

Is there a way to tell gdal.VectorTranslate that transformation is
"always_xy", and I do not have to do the swaps manually? Or maybe there is
a better way to do it?

What about the command line gdal_translate?

Thank you.
Javier

.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] core dump on dir info

[Javier Jimenez Shaw via gdal-dev]

Could you set up your VMs to include those SSE instructions? I think that
keeping VMs that "old" configured is a source of problems using
pre-compiled binaries.
The same way GDAL updates dependencies of compilers and other libraries to
something more modern (but not too modern), those SSE instructions should
be updated.

@Even knowing now that the "old" hardware is "virtually old", should we
remove AVX2 compatibility from ubuntu-full-latest? I do not know how much
is the performance impact.

Cheers,
Javier.

On Mon, 5 Feb 2024 at 21:54, Michael Sumner  wrote:

> yes, jammy VM on openstack is the host (and is where I run pretty much
> everything, though will increasingly use AWS).
>
> Thanks for the note, I'll try on other systems too. We need a
> security-allow set for vsicurl to work so if there are other little details
> I'll be keen to flush them out.
>
> Cheers, Mike
>
> On Mon, 5 Feb 2024, 18:44 Javier Jimenez Shaw,  wrote:
>
>> Hi Mike
>>
>> Out of curiosity, are run running it in a virtual machine?
>> A few year ago I had problems running a program in a virtual machine
>> (virtualbox, but I read it happens in others) due to a missing SSE
>> instruction. The solution there was to "enable" the missing instructions in
>> the virtual machine configuration (that I don't know why it was not the
>> default).
>>
>> Cheers
>>
>>
>> On Mon, 5 Feb 2024, 02:04 Even Rouault via gdal-dev, <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> ghcr.io/osgeo/gdal:ubuntu-full-latest has been regenerated with the
>>> rebuild of TileDB without AVX2. I've also enabled the
>>> drivers-with-external-depencies-built-as-plugin GDAL build mode, so it is
>>> easy to just remove a given plugin by deleting the corresponding .so in
>>> /usr/lib/x86_64-linux-gnu/gdalplugins
>>>
>>> Even
>>> Le 04/02/2024 à 22:51, Michael Sumner a écrit :
>>>
>>> indeed there's no avx2:
>>>
>>> cat /proc/cpuinfo|grep sse|head -n 1
>>> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>>> mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt
>>> pdpe1gb rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni
>>> pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes
>>> xsave avx f16c hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a
>>> misalignsse 3dnowprefetch osvw xop fma4 tbm perfctr_core ssbd ibpb vmmcall
>>> tsc_adjust bmi1 virt_ssbd arat npt nrip_save arch_capabilities
>>>
>>> Cheers, Mike
>>>
>>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] core dump on dir info

[Javier Jimenez Shaw via gdal-dev]

Hi Mike

Out of curiosity, are run running it in a virtual machine?
A few year ago I had problems running a program in a virtual machine
(virtualbox, but I read it happens in others) due to a missing SSE
instruction. The solution there was to "enable" the missing instructions in
the virtual machine configuration (that I don't know why it was not the
default).

Cheers


On Mon, 5 Feb 2024, 02:04 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> ghcr.io/osgeo/gdal:ubuntu-full-latest has been regenerated with the
> rebuild of TileDB without AVX2. I've also enabled the
> drivers-with-external-depencies-built-as-plugin GDAL build mode, so it is
> easy to just remove a given plugin by deleting the corresponding .so in
> /usr/lib/x86_64-linux-gnu/gdalplugins
>
> Even
> Le 04/02/2024 à 22:51, Michael Sumner a écrit :
>
> indeed there's no avx2:
>
> cat /proc/cpuinfo|grep sse|head -n 1
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt pdpe1gb
> rdtscp lm rep_good nopl cpuid extd_apicid tsc_known_freq pni pclmulqdq
> ssse3 fma cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx
> f16c hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse
> 3dnowprefetch osvw xop fma4 tbm perfctr_core ssbd ibpb vmmcall tsc_adjust
> bmi1 virt_ssbd arat npt nrip_save arch_capabilities
>
> Cheers, Mike
>
>
>
> On Sun, Feb 4, 2024 at 10:55 PM Even Rouault 
> wrote:
>
>> ok, so I believe this is the AVX2 issue I was talking about, as I realize
>> that enabling AVX2 is the default mode when TileDB is built from source
>> (which the Docker image does), and must be explicitly disabled with
>> "./bootstrap --disable-avx2" (I've just changed the build recipe to include
>> that, will take effect next time the images are refreshed)
>>
>> To confirm, can you send or just check the output of : cat
>> /proc/cpuinfo|grep sse|head -n 1
>>
>> If there is no "avx2" in it, this is at 99.9% the reason of the issue.
>>
>> Even
>> Le 04/02/2024 à 06:20, Michael Sumner a écrit :
>>
>> skipping TileDB does fix:
>>
>> ogr2ogr /tmp/newdir
>> https://github.com/SymbolixAU/geojsonsf/raw/master/inst/examples/geo_melbourne.geojson
>>  -f
>> "ESRI Shapefile"
>> export GDAL_SKIP=TileDB
>> ogrinfo /tmp/newdir/
>> INFO: Open of `/tmp/newdir/'
>>   using driver `ESRI Shapefile' successful.
>> 1: geo_melbourne (Polygon)
>>
>> unset GDAL_SKIP
>> ogrinfo /tmp/newdir/
>> Illegal instruction (core dumped)
>>
>> I failed to explain that I'm using gdal containers from the repo:
>>
>> docker run --rm -ti ghcr.io/osgeo/gdal:ubunt
>>
>> u-full-latest
>>
>> apt update
>> apt install -y gdb
>>
>> Here's the output of under gdb as you suggested, there was a lot so I put
>> it on a gist:
>> https://gist.github.com/mdsumner/839ae6e05ededf640b65bfee3a20a4c0
>>
>> gdb --args ogrinfo /tmp/newdir/
>> > run
>> > thread apply all bt
>>
>> Thanks!
>>
>>
>>
>>
>>
>> On Sat, Feb 3, 2024 at 7:49 PM Even Rouault 
>> wrote:
>>
>>> - When it crashes under gdb, type "thread apply all bt" to get the stack
>>> trace of all threads
>>>
>>> - I suspect there is a connection with
>>> https://github.com/OSGeo/gdal/pull/9170 , but that pull request
>>> wouldn't help here as "/tmp/newdir" could be a valid connection to TileDB
>>>
>>> - how did you get TileDB installed? It looks to be packaged? Which
>>> distribution do you use?
>>>
>>> - SIGILL reminds me of issues with some TileDB builds using the AVX2
>>> instruction set by default, which could cause some crash on host CPUs that
>>> don't have AVX2 (unlikely on recent hardware though)
>>>
>>> - Setting GDAL_SKIP=TileDB should be a workaround
>>>
>>>
>>> Le 03/02/2024 à 07:15, Michael Sumner a écrit :
>>>
>>> Thanks Even, so there's something about tiledb under gdb (or maybe I am
>>> mangling the context,  I will try variants of the host I'm using). Run with
>>> valgrind included below.
>>>
>>> gdb --args ogrinfo /tmp/newdir/
>>> ...
>>> (gdb) run
>>> Starting program: /usr/local/bin/ogrinfo /tmp/newdir/
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library
>>> "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>> [New Thread 0x7fffe7757640 (LWP 988)]
>>> [New Thread 0x7fffe6f56640 (LWP 989)]
>>> [New Thread 0x7fffde755640 (LWP 990)]
>>> [New Thread 0x7fffd5f54640 (LWP 991)]
>>> [New Thread 0x7fffc5753640 (LWP 992)]
>>> [New Thread 0x7fffc4f52640 (LWP 993)]
>>> [New Thread 0x7fffb4751640 (LWP 994)]
>>> [New Thread 0x7fffabf50640 (LWP 995)]
>>> [New Thread 0x7fffab74f640 (LWP 996)]
>>> [New Thread 0x7fffa2f4e640 (LWP 997)]
>>> [New Thread 0x7fff9a74d640 (LWP 998)]
>>> [New Thread 0x7fff91f4c640 (LWP 999)]
>>> [New Thread 0x7fff8974b640 (LWP 1000)]
>>> [New Thread 0x7fff78f4a640 (LWP 1001)]
>>> [New Thread 0x7fff78749640 (LWP 1002)]
>>> [New Thread 0x7fff6f5ff640 (LWP 1003)]
>>>
>>> Thread 1 "ogrinfo" received signal SIGILL, Illegal instruction.
>>> 0x73773c9e in 

Re: [gdal-dev] vector NODATA for Z values?

[Javier Jimenez Shaw via gdal-dev]

What about NaN?

On Thu, 25 Jan 2024, 18:07 Abel Pau via gdal-dev, 
wrote:

> Hi,
>
> there is any value in GDAL for VECTORS that indicates that a concrete
> value of a Z is not known (z nodata value)?
>
> I couldn’t find it anywhere.
>
>
>
> In MiraMon format we use one concrete number documented in our format pdf (
> -1.0E+300) an in the driver it’s planned to translate it to the same
> number. I could translate it to the one I am asking. And the same for
> detecting nodata Z and translate them to -1.0E+300 when reading another
> format.
>
>
>
> Thanks!
>
>
>
>
>
> *Abel Pau Garcia*
>
> *GIS developer*
>
> [image: https://www.creaf.cat/sites/default/files/creaf-signature.png]
>
> *a@creaf.uab.cat* 
>
> *Let's chat on Teams!*
> 
>
> *Tel. +34 934814277*
>
> [image: https://www.creaf.cat/sites/default/files/so-en-signature.png]
>
> [image:
> https://www.creaf.cat/sites/default/files/twitter-icon-signature.png]
> [image:
> https://www.creaf.cat/sites/default/files/linkedin-icon-signature.png]
> [image:
> https://www.creaf.cat/sites/default/files/youtube-icon-signature.png]
> [image:
> https://www.creaf.cat/sites/default/files/instagram-icon-signature.png]
> 
>
> *www.creaf.cat* * | **http://blog.creaf.cat*
> 
>
> [image: https://www.creaf.cat/sites/default/files/uab_logo_signatura.png]
>
> CREAF. Campus UAB. Edifici C. 08193 Bellaterra (Barcelona)
>
>
> Before printing this electronic message, think about the environment.
>
> [image: http://www.creaf.uab.cat/_signatura/line.gif]
>
>
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Inquiry about Elevation Values in DXF Conversion using ogr2ogr

[Javier Jimenez Shaw via gdal-dev]

If I remember correctly, DXF does not support multipolygons with different
elevations.

On Wed, 24 Jan 2024 at 16:15, Abel Pau via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> HI,
>
> I’ve checked that your file is correct but for some reason DXF does not
> get this capacity of variable elevation.
>
> Sorry for not being more helpful.
>
>
>
> Exporting with QGis also doesn’t work.
>
>
>
> Perhaps is a matter of the format itself. Have you tried with other files
> and did it worked sometime?
>
>
>
> *De:* Shahrukh Mirza Nawandish 
> *Enviado el:* dimecres, 24 de gener de 2024 15:19
> *Para:* Abel Pau 
> *CC:* gdal-dev@lists.osgeo.org
> *Asunto:* Re: [gdal-dev] Inquiry about Elevation Values in DXF Conversion
> using ogr2ogr
>
>
>
> Hi,
>
>
>
> Thank you for your prompt response. I'm attaching the data file to this
> email for your convenience.
>
>
>
>
>
> Appreciate your assistance.
>
>
>
> 24.01.2024, 17:02, "Abel Pau" :
>
> Hi,
>
>
>
> can you send us the file but not attached because it’s not allowed too
> much size in attachments.
>
>
>
> Have you converted to another format to see if it’s a matter of KML or
> it’s general?
>
> I’ll try to convert to MiraMon to test the elevations.
>
>
>
> Thanks
>
>
>
> *De:* gdal-dev  *En nombre de *Shahrukh
> Mirza Nawandish via gdal-dev
> *Enviado el:* dimecres, 24 de gener de 2024 14:13
> *Para:* gdal-dev@lists.osgeo.org
> *Asunto:* [gdal-dev] Inquiry about Elevation Values in DXF Conversion
> using ogr2ogr
>
>
>
> Dear GDAL Team,
>
>
>
> I hope this email finds you well. I'm encountering an issue when
> converting GeoJSON or KML files to DXF using ogr2ogr—specifically, the
> generated DXF file assigns a uniform elevation to all coordinates.
>
>
>
> Your assistance in resolving this matter is highly appreciated.
>
>
>
> Thank you,
>
>
>
> --
>
> Saygılarımla / Kind Regards
>
>
>
> *Shahrukh Mirza NAWANDISH*
>
> Havacılık Bilgi Sistemleri / Aeronautical Information Systems
>
> Yazılım Geliştirme Uzm. Yrd. / Software Development Assist. Specialist
>
> Bilgisayar Programcısı / Computer Programmer MCA
>
> 
>
> *T:*+90 312 266 66 98
>
> *M**:*+90 538 519 72 67
>
> * E:*mirza.nawand...@haritaevi.com
>
> *▶**:* Ankara-Istanbul-Bucharest
> 
>
> *www.haritaevi.com *
>
> *www.obstacleanalyze.com *
>
> *www.aixm.haritaevi.com *
>
> *www.aerodatamarket.com *
>
> 
> 
> 
> 
> 
>   
> 
> 
> 
>
>
>
>
>
>
>
> --
>
> Saygılarımla / Kind Regards
>
>
>
> *Shahrukh Mirza NAWANDISH*
>
> Havacılık Bilgi Sistemleri / Aeronautical Information Systems
>
> Yazılım Geliştirme Uzm. Yrd. / Software Development Assist. Specialist
>
> Bilgisayar Programcısı / Computer Programmer MCA
>
> Cumhuriyetimizin 100. Yılı Kutlu Olsun
>
> Happy 100th Anniversary of Our Republic.
>
> 
>
> *T:*+90 312 266 66 98
>
> *M**:*+90 538 519 72 67
>
> * E:*mirza.nawand...@haritaevi.com
>
> *▶**:* Ankara-Istanbul-Bucharest
> 
>
> *www.haritaevi.com *
>
> *www.obstacleanalyze.com *
>
> *www.aixm.haritaevi.com *
>
> *www.aerodatamarket.com *
>
> 
> 
> 
> 
> 
>   
> 
> 
> 
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [EXTERNAL] Re: Lack of srs importFromESRI integer function

[Javier Jimenez Shaw via gdal-dev]

This is the discussion I have with my colleagues every time (but with
EPSG). The wanted to use an integer, and I ask them again and again to use
a better notation like "EPSG:{code}". The method that Even mentions,
SetFromUserInput, works with "EPSG:code", with "ESRI:code", with a WKT,
with a PROJJSON, etc. It makes the management of the CRS much easier. When
you need something more complicated than an ESRI code, if your API is only
ready for an integer value... you have a lot of things to refactor (months
of work, I can tell you).

Technically ESRI and EPSG there are overlapping. As you can see in this
link there are some non-deprecated ESRI codes below 33000:
https://crs-explorer.proj.org/?ignoreWorld=false=false=ESRI=PROJECTED_CRS,GEOGRAPHIC_2D_CRS,GEOGRAPHIC_3D_CRS,GEOCENTRIC_CRS,GEODETIC_CRS,VERTICAL_CRS,COMPOUND_CRS=osm

And many more if you "Allow deprecated".

On Wed, 10 Jan 2024 at 19:01, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

>
> Le 10/01/2024 à 18:52, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
> APPLICATIONS INC] a écrit :
>
> Thanks Even, we’ll try that.
>
>
>
> Are there any known integer values that ESRI and EPSG conflate?  If not,
> it would be convenient to simply pass in an integer to a single API
> function and be done with it.
>
> I believe not. Codes in the [1,32767] range should lead to equivalent
> definitions under both authorities. But when they are really the same, to
> save space and confusion to users, they are not imported under the ESRI
> authority and are only available under the EPSG ones. So codes in the
> [1,32767] under the ESRI authorities are basically for CRS names that are
> slightly different spelled by ESRI (but otherwise with a definition
> compatible of the EPSG one). There are also very ancient deprecated CRS
> that were imported from EPSG, but were deprecated by EPSG so long ago that
> they are not in the EPSG database anymore (like
> https://spatialreference.org/ref/esri/31491/).
>
> But there's no only EPSG and ESRI in life :-) The IAU authority for
> example uses numeric code in the ranges of what could be used by EPSG or
> ESRI.
>
> So it is really the tuple (authority_name,code) that conveys a primary key.
>
>
>
> Jesse
>
>
>
> *From: *Even Rouault 
> 
> *Date: *Wednesday, January 10, 2024 at 12:48 PM
> *To: *"Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND APPLICATIONS
> INC]"  ,
> "gdal-dev@lists.osgeo.org" 
>  
> *Subject: *[EXTERNAL] Re: [gdal-dev] Lack of srs importFromESRI integer
> function
>
>
>
> *CAUTION:* This email originated from outside of NASA.  Please take care
> when clicking links or opening attachments.  Use the "Report Message"
> button to report suspicious messages to the NASA SOC.
>
>
>
> Jesse,
>
> You can use SetFromUserInput("ESRI:")  . ImportFromEPSG(code) more or
> less does SetFromUserInput("EPSG:{code}")
>
> Even
>
> Le 10/01/2024 à 18:44, Meyer, Jesse R. (GSFC-618.0)[SCIENCE SYSTEMS AND
> APPLICATIONS INC] via gdal-dev a écrit :
>
> Hi,
>
>
>
> Our team has moved away from providing geographic / projected CRS codes as
> strings and prefer using integers where possible.  However, in the C++ API,
> I only see an integer based importFromEPSG function, which doesn’t appear
> to accept ESRI codes (crs not found error message).  We’re targeting an
> Albers projection which is distinguished by an ESRI integer.
>
>
>
> Curiously, the proj database doesn’t seem to make this distinction – the
> table column is simply ‘code’ and I can find the projection row manually,
> alongside EPSG projections.
>
>
>
> Can such a function be provided by the API (if it doesn’t already exist –
> I couldn’t find it – there are no integer overloads of importFromESRI)?
>
>
>
> Please advise -- thanks,
>
> Jesse
>
>
>
> ___
>
> gdal-dev mailing list
>
> gdal-dev@lists.osgeo.org
>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
>
> http://www.spatialys.com
>
> My software is free, but my time generally not.
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.3 RC3 is available, and motion to approve it (Re: GDAL 3.8.3 RC1 is available, and motion to approve it)

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Thu, 4 Jan 2024, 19:32 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> A third (and hopefully final) release candidate for 3.8.3 with the
> following additional fixes on top of RC2:
> - re-enable multi-threaded ArrowArray interface in GPKG driver now that
> the issue has been reproduced and fixed
> (https://github.com/OSGeo/gdal/pull/9026)
> - Internal libjson: resync random_seed.c with upstream, and use
> getrandom() implementation when available (#9024)
> - Fix build of optional utility gdal2ogr
>
> Pick up an archive among the following ones (by ascending size):
>
>https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc3.tar.xz
>https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc3.tar.gz
>https://download.osgeo.org/gdal/3.8.3/gdal383rc3.zip
>
> A snapshot of the gdalautotest suite is also available:
>
> https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc3.tar.gz
>https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc3.zip
>
> The NEWS file is here:
>
> https://github.com/OSGeo/gdal/blob/v3.8.3RC3/NEWS.md
>
> 
>
> Retracting previous motion to approve RC2, and replacing it with:
>
> Motion: adopt 3.8.3 RC3 as final 3.8.3 release
>
> Starting with my +1,
>
> ~
>
> Even
>
> --
>
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.3 RC2 is available, and motion to approve it (Re: GDAL 3.8.3 RC1 is available, and motion to approve it)

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 3 Jan 2024, 21:46 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> I've issued a 2nd release candidate for 3.8.3 with the following
> additional fixes:
> - ogr2ogr: do not use ArrowArray interface if -clipsrc, -clipdst, -gcp
> or wrapdateline are specified (#9013)
> - GPKG driver: disable by default multi-threaded ArrowArray interface.
> Make it opt-in with the OGR_GPKG_NUM_THREADS config option (cf
> https://github.com/OSGeo/gdal/pull/9018)
> - fix build with sqlite 3.36.x (#9021)
>
> Pick up an archive among the following ones (by ascending size):
>
>https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc2.tar.xz
>https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc2.tar.gz
>https://download.osgeo.org/gdal/3.8.3/gdal383rc2.zip
>
> A snapshot of the gdalautotest suite is also available:
>
> https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc2.tar.gz
>https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc2.zip
>
> The NEWS file is here:
>
> https://github.com/OSGeo/gdal/blob/v3.8.3RC2/NEWS.md
>
> 
>
> Retracting previous motion to approve RC1, and replacing it with:
>
> Motion: adopt 3.8.3 RC2 as final 3.8.3 release
>
> Starting with my +1,
>
> ~
>
> Even
>
> Le 02/01/2024 à 12:56, Even Rouault via gdal-dev a écrit :
> > Hi,
> >
> > I have prepared an advanced-of-time GDAL/OGR 3.8.3 release candidate,
> > mostly
> > to fix a 3.8.0 regression that has been reported lately
> > (https://github.com/OSGeo/gdal/issues/8998), that causes content of
> > boolean
> > fields in GeoPackage or FlatGeobuf datasets to be incorrectly read
> > when using
> > the ArrowArray interface, for example when used as source datasets in
> > ogr2ogr
> > workflows.
> >
> > Pick up an archive among the following ones (by ascending size):
> >
> >   https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc1.tar.xz
> >   https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc1.tar.gz
> >   https://download.osgeo.org/gdal/3.8.3/gdal383rc1.zip
> >
> > A snapshot of the gdalautotest suite is also available:
> >
> > https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc1.tar.gz
> >   https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc1.zip
> >
> > The NEWS file is here:
> >
> >   https://github.com/OSGeo/gdal/blob/v3.8.3RC1/NEWS.md
> >
> > Motion: adopt 3.8.3 RC1 as final 3.8.3 release
> >
> > Starting with my +1,
> >
> > Best regards,
> >
> > Even
> >
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] COG via HTTP POST

[Javier Jimenez Shaw via gdal-dev]

Thanks Even.

I will tell them about the missing SRS

On Tue, 2 Jan 2024, 13:39 Even Rouault,  wrote:

> Javier,
>
> According to https://httpwg.org/specs/rfc7233.html#header.range , HTTP
> Range requests only apply to GET requests.  So COGs delivered through POST
> can indeed only be usable after full download.
>
> BTW, someone should ask CNIG to include GeoTIFF SRS tags. At least, for
> file pnt_sentinel2_2020_invierno_mosaico_islas_canarias_b843_hu28_8bits.tif
> which has only ModelTiepointTag and ModelPixelScaleTag geotiff keys giving
> the geospatial extent, but no CRS keys.
>
> Even
> Le 02/01/2024 à 13:14, Javier Jimenez Shaw via gdal-dev a écrit :
>
> Hi
>
> Does it make any sense to provide COG via HTTP POST method?
> If I understand correctly, the "magic" of downloading only what is needed
> from the server is done with HTTP Range requests. But I am not sure if that
> works in POST method (it does work in GET method, when enabled ;).
> In case it could work with POST, I do not know how to tell GDAL or QGIS to
> use a POST method.
>
> Why am I asking this? the CNIG (Natial Center of Geographic Information in
> Spain) is doing it.
> https://centrodedescargas.cnig.es/CentroDescargas/index.jsp The link is
> just the starting point. Unfortunately they do not provide link to the
> final page where you can download the files (yes, ugly).
>
> So for now I have to download the full file, and do whatever I want later.
>
> Thanks
> Javier
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.3 RC1 is available, and motion to approve it

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Tue, 2 Jan 2024, 12:56 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> I have prepared an advanced-of-time GDAL/OGR 3.8.3 release candidate,
> mostly
> to fix a 3.8.0 regression that has been reported lately
> (https://github.com/OSGeo/gdal/issues/8998), that causes content of
> boolean
> fields in GeoPackage or FlatGeobuf datasets to be incorrectly read when
> using
> the ArrowArray interface, for example when used as source datasets in
> ogr2ogr
> workflows.
>
> Pick up an archive among the following ones (by ascending size):
>
>https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc1.tar.xz
>https://download.osgeo.org/gdal/3.8.3/gdal-3.8.3rc1.tar.gz
>https://download.osgeo.org/gdal/3.8.3/gdal383rc1.zip
>
> A snapshot of the gdalautotest suite is also available:
>
> https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc1.tar.gz
>https://download.osgeo.org/gdal/3.8.3/gdalautotest-3.8.3rc1.zip
>
> The NEWS file is here:
>
>https://github.com/OSGeo/gdal/blob/v3.8.3RC1/NEWS.md
>
> Motion: adopt 3.8.3 RC1 as final 3.8.3 release
>
> Starting with my +1,
>
> Best regards,
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] COG via HTTP POST

[Javier Jimenez Shaw via gdal-dev]

Hi

Does it make any sense to provide COG via HTTP POST method?
If I understand correctly, the "magic" of downloading only what is needed
from the server is done with HTTP Range requests. But I am not sure if that
works in POST method (it does work in GET method, when enabled ;).
In case it could work with POST, I do not know how to tell GDAL or QGIS to
use a POST method.

Why am I asking this? the CNIG (Natial Center of Geographic Information in
Spain) is doing it.
https://centrodedescargas.cnig.es/CentroDescargas/index.jsp The link is
just the starting point. Unfortunately they do not provide link to the
final page where you can download the files (yes, ugly).

So for now I have to download the full file, and do whatever I want later.

Thanks
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.2 RC1 is available, and motion to approve it

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Sat, 16 Dec 2023, 15:01 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> I have prepared an advanced-of-time GDAL/OGR 3.8.2 release candidate,
> mostly
> to fix a 3.8.0 regression that has been reported lately
> (https://github.com/OSGeo/gdal/issues/8967), which caused an excessive
> use of
> RAM when translating a VRT with many VRTComplexSource (typically used when
> nodata or mask are involved), making such use cases unworkable.
>
> Pick up an archive among the following ones (by ascending size):
>
>https://download.osgeo.org/gdal/3.8.2/gdal-3.8.2rc1.tar.xz
>https://download.osgeo.org/gdal/3.8.2/gdal-3.8.2rc1.tar.gz
>https://download.osgeo.org/gdal/3.8.2/gdal382rc1.zip
>
> A snapshot of the gdalautotest suite is also available:
>
> https://download.osgeo.org/gdal/3.8.2/gdalautotest-3.8.2rc1.tar.gz
>https://download.osgeo.org/gdal/3.8.2/gdalautotest-3.8.2rc1.zip
>
> The NEWS file is here:
>
>https://github.com/OSGeo/gdal/blob/v3.8.2RC1/NEWS.md
>
> Motion: adopt 3.8.2 RC1 as final 3.8.2 release
>
> Starting with my +1,
>
> Best regards,
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Setting TIFFTAG_* in COG

[Javier Jimenez Shaw via gdal-dev]

Thanks!

On Mon, 4 Dec 2023 at 16:46, Even Rouault 
wrote:

> Javier,
>
> TIFFTAG_DATETIME or AREA_OR_POINT are copied by the COG/GTiff drivers from
> the source dataset metadata.
>
> So using gdal_translate / GDALTranslate(), you may set them with the "-mo
> KEY=VALUE" option.
>
> If using an intermediate VRT as the source for GDALCreateCopy(), then you
> may call SetMetadataItem("KEY", "VALUE") on the VRT. I don't see an option
> in GDALBuildVRT() to do that, but you can definitely open the VRT after it
> has been created and call SetMetadataItem() on it
>
> Even
> Le 04/12/2023 à 16:14, Javier Jimenez Shaw via gdal-dev a écrit :
>
> Hi
>
> I am trying to convert a "normal" tiff file into a COG. For that I am
> using an intermediate vrt file to add the geolocation parameters, and
> finally copy the vrt into a COG.
> I am doing it in C++, but it should be similar doing it on the command
> line I hope. (In some cases I am using also other parameters of the
> gdalbuildvrt).
>
> My problem is how are the "magic words" to set the TIFFTAG_* (like
> TIFFTAG_DATETIME) in the final COG. I guess I could use the option "-oo"
> for the options in GDALBuildVRT, or in the options of the method
> "CreateCopy" for COG driver.
> Is that doable that way? Should I prefix "TIFFTAG_..." with something like
> "GDALMETADATA:"? (I tried, unsuccessfully)
> Is that the same for AREA_OR_POINT?
>
> Thanks.
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Setting TIFFTAG_* in COG

[Javier Jimenez Shaw via gdal-dev]

Hi

I am trying to convert a "normal" tiff file into a COG. For that I am using
an intermediate vrt file to add the geolocation parameters, and finally
copy the vrt into a COG.
I am doing it in C++, but it should be similar doing it on the command line
I hope. (In some cases I am using also other parameters of the
gdalbuildvrt).

My problem is how are the "magic words" to set the TIFFTAG_* (like
TIFFTAG_DATETIME) in the final COG. I guess I could use the option "-oo"
for the options in GDALBuildVRT, or in the options of the method
"CreateCopy" for COG driver.
Is that doable that way? Should I prefix "TIFFTAG_..." with something like
"GDALMETADATA:"? (I tried, unsuccessfully)
Is that the same for AREA_OR_POINT?

Thanks.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 98: Build requirements for GDAL 3.9

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Fri, 1 Dec 2023 at 16:32, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> Motion: adopt RFC 98: Build requirements for GDAL 3.9
>
> https://github.com/OSGeo/gdal/pull/8802
>
> Starting with my +1,
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.1RC3 is available & motion to approve it

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Tue, 28 Nov 2023 at 17:29, Howard Butler via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1 Howard
>
> > On Nov 28, 2023, at 9:57 AM, Rahkonen Jukka via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
> >
> > +1
> >
> > -Jukka-
> >
> > -Alkuperäinen viesti-
> > Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> > Lähetetty: tiistai 28. marraskuuta 2023 17.33
> > Vastaanottaja: gdal-dev@lists.osgeo.org
> > Aihe: [gdal-dev] GDAL 3.8.1RC3 is available & motion to approve it
> >
> > Hi,
> >
> > well, another annoying 3.8.0 regression related to ogr2ogr GPKG ->
> Shapefile when field names are longer than 10 characters (ah
> > Shapefile!!!) popped up today, so here's a RC3 (crossing fingers it's
> the good one):
> > ...
> > A snapshot of the gdalautotest suite is also available:
> > ...
> > The changes since RC2 are:
> >
> > * CMake: make GDAL_USE_LIBKML and GDAL_USE_OPENJPEG honor
> GDAL_USE_EXTERNAL_LIBS
> > * Detect failure in installation of the Python bindings
> > * Fix installation issue with Python 3.12 on Debian
> > * GDALOverviewDataset::IRasterIO(): use parent dataset when possible for
> more
> >   efficiency
> > * gdal_footprint: fix wrong taking into account of alpha band (#8834)
> > * gdal_footprint: fix taking into account of individual bands that have
> nodata
> > * COG: for JPEG compression, convert single band+alpha as single band
> JPEG + 1-bit mask band
> > * GTIFF SRS reader: include VertCRS name from EPSG in CompoundCRS name
> if there's no citation geokey
> > * ogr2ogr: fix GPKG -> Shapefile when field names are truncated (#8849,
> > 3.8.0 regression)
> > * CSV writer: do not quote integer fields by default (only if
> STRING_QUOTING=ALWAYS is specified)
> > * GPX: make detection of extensions element more robust (#8827)
> > * Shapefile: recognize '  0' as a null date, fix writing an invalid
> "/00/00" date
> > * Python bindings: add a combineBands option to gdal.Footprint()
> >
> >
> > Withdrawing previous motion and:
> >
> > ==> Motion: adopt 3.8.1 RC3 as final 3.8.1 release
> >
> > Starting with my +1,
> >
> > Even
> >
> > --
> > My software is free, but my time generally not.
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.1 RC2 is available (was Re: GDAL 3.8.1 RC1 is available, and motion to approve it)

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Mon, 27 Nov 2023 at 17:30, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> Lähetetty: perjantai 24. marraskuuta 2023 13.06
> Vastaanottaja: Sebastiaan Couwenberg ;
> gdal-dev@lists.osgeo.org
> Aihe: [gdal-dev] GDAL 3.8.1 RC2 is available (was Re: GDAL 3.8.1 RC1 is
> available, and motion to approve it)
>
> Hi,
>
> OK, I've reverted that change. I'll guess someone will have to figure out
> how to have both .py scripts and .exe/.sh launchers at the same time...
>
> Pick up an archive among the following ones (by ascending size):
> ...
>
> Withdrawing previous motion and:
>
> Motion: adopt 3.8.1 RC2 as final 3.8.1 release
>
> Starting with my +1,
>
> Even
>
> Le 24/11/2023 à 06:34, Sebastiaan Couwenberg via gdal-dev a écrit :
> > On 11/23/23 22:56, Even Rouault via gdal-dev wrote:
> >>  From a packaging point of view, the following change might have
> >> impacts on build recipes:
> >
> > The Python utilities are no longer installed with the .py extension,
> > this broke their use in QGIS when we removed this in the Debian
> > package some time ago. Don't know if that's still the case. Either
> > way, this doesn't seem like an appropriate change for a .1 patch release.
> >
> > usr/bin/__init__ is now also installed which not correct.
> >
> > Kind Regards,
> >
> > Bas
> >
> --
> http://www.spatialys.com/
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL Maintainers Meeting Minutes

[Javier Jimenez Shaw via gdal-dev]

>   * use TILED=YES by default in GTiff driver
>
> Was that decided? As some people pointed (including me) a big tiled
geotiff without overviews take ages to load in QGIS.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems compiling in Mac

[Javier Jimenez Shaw via gdal-dev]

My colleague (I have only Linux) will give more info.

On Thu, 23 Nov 2023 at 16:25, Even Rouault 
wrote:

>
>
>> I thought that it was enough disabling GDAL_USE_EXTERNAL_LIBS (we are not
>> enabling explicitly arrow or kml). Am I wrong?
>>
>> He might have to remove CMakeCache.txt because it could contain the
>> GDAL_USE_LIBKML=ON declaration that was set before turning off
>> GDAL_USE_EXTERNAL_LIBS
>>
> He started from an empty directory.
>
> We are using conan, that is python, and setting
> GDAL_USE_EXTERNAL_LIBS=False . This is the result after searching for that
> string:
>
> and what is the value of GDAL_USE_LIBKML and GDAL_USE_ARROW ? and what is
> the exact error message?
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problems compiling in Mac

[Javier Jimenez Shaw via gdal-dev]

On Thu, 23 Nov 2023 at 15:01, Even Rouault 
wrote:

>
> Le 23/11/2023 à 14:53, Javier Jimenez Shaw via gdal-dev a écrit :
>
> Hi
>
> A colleague of mine is compiling in Mac. I am aware of the problems with
> arrow and libkml:
> https://gdal.org/development/building_from_source.html#building-on-macos
>
> But we are compiling with GDAL_USE_EXTERNAL_LIBS=OFF
>
> However he has those problems with arrow and libkml, and had to unistall
> them from his computer.
>
> I thought that it was enough disabling GDAL_USE_EXTERNAL_LIBS (we are not
> enabling explicitly arrow or kml). Am I wrong?
>
> He might have to remove CMakeCache.txt because it could contain the
> GDAL_USE_LIBKML=ON declaration that was set before turning off
> GDAL_USE_EXTERNAL_LIBS
>
He started from an empty directory.

We are using conan, that is python, and setting
GDAL_USE_EXTERNAL_LIBS=False . This is the result after searching for that
string:

$ rg  -C3 GDAL_USE_EXTERNAL_LIBS
9e1a1eccb8f4704e0053d8d98cd817cbba03c366/CMakeCache.txt
1010-
1011-//Whether detected external libraries should be used by default.
1012-// This should be set before CMakeCache.txt is created.
1013:GDAL_USE_EXTERNAL_LIBS:BOOL=False
1014-
1015-//Set ON to use FREEXL
1016-GDAL_USE_FREEXL:BOOL=OFF
--
2419-GDAL_ENABLE_PLUGINS_NO_DEPS-ADVANCED:INTERNAL=1
2420-//ADVANCED property for variable: GDAL_USE_CPL_MULTIPROC_PTHREAD
2421-GDAL_USE_CPL_MULTIPROC_PTHREAD-ADVANCED:INTERNAL=1
2422://Previous value of GDAL_USE_EXTERNAL_LIBS
2423:GDAL_USE_EXTERNAL_LIBS_OLD_CACHED:INTERNAL=False
2424-//STRINGS property for variable: GDAL_USE_INTERNAL_LIBS
2425-GDAL_USE_INTERNAL_LIBS-STRINGS:INTERNAL=ON;OFF;WHEN_NO_EXTERNAL
2426-//Set ON to use Rasterlite2



>
> Thanks.
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Problems compiling in Mac

[Javier Jimenez Shaw via gdal-dev]

Hi

A colleague of mine is compiling in Mac. I am aware of the problems with
arrow and libkml:
https://gdal.org/development/building_from_source.html#building-on-macos

But we are compiling with GDAL_USE_EXTERNAL_LIBS=OFF

However he has those problems with arrow and libkml, and had to unistall
them from his computer.

I thought that it was enough disabling GDAL_USE_EXTERNAL_LIBS (we are not
enabling explicitly arrow or kml). Am I wrong?

Thanks.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 97: OGRFeatureDefn, OGRFieldDefn and OGRGeomFieldDefn "sealing"

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 22 Nov 2023 at 18:18, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> Lähetetty: keskiviikko 22. marraskuuta 2023 14.06
> Vastaanottaja: gdal-dev@lists.osgeo.org
> Aihe: [gdal-dev] Motion: adopt RFC 97: OGRFeatureDefn, OGRFieldDefn and
> OGRGeomFieldDefn "sealing"
>
> Hi,
>
> Motion: adopt RFC 97: OGRFeatureDefn, OGRFieldDefn and OGRGeomFieldDefn
> "sealing"
>
> ...
>
> Starting with my +1,
>
> Even
>
> --
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 96: Deferred C++ plugin loading

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 15 Nov 2023 at 21:44, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> Lähetetty: keskiviikko 15. marraskuuta 2023 11.52
> Vastaanottaja: gdal-dev@lists.osgeo.org
> Aihe: [gdal-dev] Motion: adopt RFC 96: Deferred C++ plugin loading
>
> Hi,
>
> Motion: adopt RFC 96: Deferred C++ plugin loading
> ...
> Starting with my +1,
>
> Even
>
> --
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt GDAL 3.8.0RC2 as 3.8.0 release

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Thu, 9 Nov 2023, 11:19 Rahkonen Jukka via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> Lähetetty: torstai 9. marraskuuta 2023 12.12
> Vastaanottaja: gdal-dev@lists.osgeo.org
> Aihe: [gdal-dev] Motion: adopt GDAL 3.8.0RC2 as 3.8.0 release
>
> Retracting the motion to adopt 3.8.0RC1 and updating it to:
>
> Motion:
>
> Adopt GDAL 3.8.0RC2 as 3.8.0 release
>
> Starting with my +1
>
> Even
>
> Le 08/11/2023 à 09:39, Even Rouault via gdal-dev a écrit :
> > Hi,
> >
> > Motion:
> >
> > Adopt GDAL 3.8.0RC1 as 3.8.0 release
> >
> > Starting with my +1
> >
> > Even
> >
> --
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Transforming from EPSG:29902 to EPSG:4326 at the limit of the area of use.

[Javier Jimenez Shaw via gdal-dev]

Assuming that it does not happen in the main area of Ireland...I guess it
is because it is outside of the area of usage of the datum transformation
https://epsg.org/transformation_1641/TM65-to-WGS-84-2.html
Probably (this is just a guess) gdalwarp is not taking it into
consideration, making a ballpark transformation between TM65 and WGS84,
while ogr2ogr doesn't.

On Wed, 8 Nov 2023 at 13:35, Sam Hall via gdal-dev 
wrote:

> I have some data that covers the whole of the Republic of Ireland,
> including the Blasket Islands off the West Coast, situated around 24439,
> 95540 in EPSG:29902. These islands straddle the western boundary of the
> area of use of the coordinate system -10.56° W.
>
> When transforming a raster dataset from EPSG:29902 to EPSG:4326 using
> gdalwarp at gdal >= 3.5.2, there seems to be a roughly 50 m shift in the
> data at the area of use boundary, while if I use ogr2ogr on a vector copy
> of this data, I don't see this shift.
>
> I have a reproducible example of this at
> https://gitlab.com/Sam.Hall1/29902_gdalwarp_vs_ogr2ogr.git. In this
> example I created a rectangular polygon with interpolated points and saved
> it to a shapefile, then used gdal_rasterize to create a GeoTiff. gdalwarp
> gives the desired result using a gdal 3.5.1 docker image. The full commands
> are in the docker-compose.yml in the repository but the parameter's I'm
> using are:
>
> gdalwarp -t_srs EPSG:4326 -tr 0.45 0.45 -tap -overwrite input.tif
> output.tif
> ogr2ogr -t_srs EPSG:4326 output.shp input.shp
>
> I've also seen similar results when transforming from EPSG:27700 to
> EPSG:4326 in Jersey and Guernsey in the English Channel but I'd have to use
> a much earlier version of gdal to reproduce the desired result.
>
> Is there a gridshift file or any additional parameters that I could use to
> get the output to look more continuous across the area of use line?
>
> Sam
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Adopt GDAL 3.8.0RC1 as 3.8.0 release

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 8 Nov 2023, 10:16 Rahkonen Jukka via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> Lähetetty: keskiviikko 8. marraskuuta 2023 10.39
> Vastaanottaja: gdal-dev@lists.osgeo.org
> Aihe: [gdal-dev] Motion: Adopt GDAL 3.8.0RC1 as 3.8.0 release
>
> Hi,
>
> Motion:
>
> Adopt GDAL 3.8.0RC1 as 3.8.0 release
>
> Starting with my +1
>
> Even
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] oblique cuts on a raster using python GDAL

[Javier Jimenez Shaw via gdal-dev]

This is producing something nicer, without those "white pixels". It is
adding an alpha band:
gdalwarp 3635_rasters_agreges.jp2 salida.jp2 -cutline
geometry_extraction.shp -crop_to_cutline -cl geometry_extraction -overwrite
-dstalpha

On Mon, 6 Nov 2023 at 14:05, Javier Jimenez Shaw  wrote:

> This is working for me (and also in gdal 3.8.0):
>
> gdalwarp 3635_rasters_agreges.jp2 salida.tif -cutline
> geometry_extraction.shp -crop_to_cutline -dstnodata 0 -cl
> geometry_extraction -overwrite -of GTiff
>
> About the "white" pixels inside the image, it could be that a single band
> has a value of 0 (not that strange). Then it is transparent, and you see
> the background color. (to avoid those "color misunderstandings" I have a
> pink background color, that is not white).
>
> On Mon, 6 Nov 2023 at 12:35, Naima Dambrine 
> wrote:
>
>> Hi Javier,
>>
>> Thank you, good news ...
>>
>> I'm on Ubuntu 20.04 with gdal 3.6.2. Yes, the original raster format is
>> JP2, but my output format is GTiff. Here is exactly what I do :
>>
>> cut_ds = gdal.Warp(outfile, jp2_ds, format='GTiff',
>> cutlineDCName=shape_file_path,
>> cropToCutline=True,
>> copyMetadat=True,
>> dstNodata=0)
>>
>> What I see is that there are still black pixels around the image, as well
>> as white pixels inside the image.
>> Another point to consider is that, despite the use of compression, the
>> output file is 75.3 MB, compared with around 14 MB with a JP2 format. Why
>> is this?
>>
>> my output :
>>
>>
>>
>>
>> Le lun. 6 nov. 2023 à 11:33, Javier Jimenez Shaw  a
>> écrit :
>>
>>> Hi Naima
>>>
>>> I have been testing with your dataset. To me, using the GDAL in Ubuntu
>>> 22.04 (3.4.1) seems to be a problem with the JP2 output format. If you
>>> output as geotiff it works fine.
>>>
>>> On Sun, 5 Nov 2023 at 19:43, Rahkonen Jukka via gdal-dev <
>>> gdal-dev@lists.osgeo.org> wrote:
>>>
 Hi,



 Please add gdalinfo of the source image. Even better if you can share
 the image.



 -Jukka Rahkonen-



 *Lähettäjä:* gdal-dev  *Puolesta *Naima
 Dambrine via gdal-dev
 *Lähetetty:* sunnuntai 5. marraskuuta 2023 17.35
 *Vastaanottaja:* gdal-dev@lists.osgeo.org
 *Aihe:* [gdal-dev] oblique cuts on a raster using python GDAL



 Hi ,



 I have problems with oblique cuts on a raster using python GDAL (3.6.2)



 - with this line i obtain black borders around :

 gdal.warp('raster-dst' , raster-src',
 cutLineDSName='geometry-extraction.shp', cropToCutline=True)



 - with this one, the crop is not clean on closer inspection: residual
 black pixels around image and white pixels appear in the image.

 gdal. warp( 'raster-dst' , raster-src',
 cutLineDSName='geometry-extraction.shp', cropToCutline=True,
 copyMetaData=True, dstNodata=0)


 I tried, without success, to refine with outputBounds=[minX, maxX,
 minY, maxY], under QGIS directly ….
 I've run out of ideas :/
 A (naive) question comes to mind: Is it possible to make oblique cuts
 with gdal.warp() & co?

 Naïma
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 https://lists.osgeo.org/mailman/listinfo/gdal-dev

>>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] oblique cuts on a raster using python GDAL

[Javier Jimenez Shaw via gdal-dev]

This is working for me (and also in gdal 3.8.0):

gdalwarp 3635_rasters_agreges.jp2 salida.tif -cutline
geometry_extraction.shp -crop_to_cutline -dstnodata 0 -cl
geometry_extraction -overwrite -of GTiff

About the "white" pixels inside the image, it could be that a single band
has a value of 0 (not that strange). Then it is transparent, and you see
the background color. (to avoid those "color misunderstandings" I have a
pink background color, that is not white).

On Mon, 6 Nov 2023 at 12:35, Naima Dambrine  wrote:

> Hi Javier,
>
> Thank you, good news ...
>
> I'm on Ubuntu 20.04 with gdal 3.6.2. Yes, the original raster format is
> JP2, but my output format is GTiff. Here is exactly what I do :
>
> cut_ds = gdal.Warp(outfile, jp2_ds, format='GTiff',
> cutlineDCName=shape_file_path,
> cropToCutline=True,
> copyMetadat=True,
> dstNodata=0)
>
> What I see is that there are still black pixels around the image, as well
> as white pixels inside the image.
> Another point to consider is that, despite the use of compression, the
> output file is 75.3 MB, compared with around 14 MB with a JP2 format. Why
> is this?
>
> my output :
>
>
>
>
> Le lun. 6 nov. 2023 à 11:33, Javier Jimenez Shaw  a
> écrit :
>
>> Hi Naima
>>
>> I have been testing with your dataset. To me, using the GDAL in Ubuntu
>> 22.04 (3.4.1) seems to be a problem with the JP2 output format. If you
>> output as geotiff it works fine.
>>
>> On Sun, 5 Nov 2023 at 19:43, Rahkonen Jukka via gdal-dev <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Please add gdalinfo of the source image. Even better if you can share
>>> the image.
>>>
>>>
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>>
>>> *Lähettäjä:* gdal-dev  *Puolesta *Naima
>>> Dambrine via gdal-dev
>>> *Lähetetty:* sunnuntai 5. marraskuuta 2023 17.35
>>> *Vastaanottaja:* gdal-dev@lists.osgeo.org
>>> *Aihe:* [gdal-dev] oblique cuts on a raster using python GDAL
>>>
>>>
>>>
>>> Hi ,
>>>
>>>
>>>
>>> I have problems with oblique cuts on a raster using python GDAL (3.6.2)
>>>
>>>
>>>
>>> - with this line i obtain black borders around :
>>>
>>> gdal.warp('raster-dst' , raster-src',
>>> cutLineDSName='geometry-extraction.shp', cropToCutline=True)
>>>
>>>
>>>
>>> - with this one, the crop is not clean on closer inspection: residual
>>> black pixels around image and white pixels appear in the image.
>>>
>>> gdal. warp( 'raster-dst' , raster-src',
>>> cutLineDSName='geometry-extraction.shp', cropToCutline=True,
>>> copyMetaData=True, dstNodata=0)
>>>
>>>
>>> I tried, without success, to refine with outputBounds=[minX, maxX, minY,
>>> maxY], under QGIS directly ….
>>> I've run out of ideas :/
>>> A (naive) question comes to mind: Is it possible to make oblique cuts
>>> with gdal.warp() & co?
>>>
>>> Naïma
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] oblique cuts on a raster using python GDAL

[Javier Jimenez Shaw via gdal-dev]

Hi Naima

I have been testing with your dataset. To me, using the GDAL in Ubuntu
22.04 (3.4.1) seems to be a problem with the JP2 output format. If you
output as geotiff it works fine.

On Sun, 5 Nov 2023 at 19:43, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
>
>
> Please add gdalinfo of the source image. Even better if you can share the
> image.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Naima
> Dambrine via gdal-dev
> *Lähetetty:* sunnuntai 5. marraskuuta 2023 17.35
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] oblique cuts on a raster using python GDAL
>
>
>
> Hi ,
>
>
>
> I have problems with oblique cuts on a raster using python GDAL (3.6.2)
>
>
>
> - with this line i obtain black borders around :
>
> gdal.warp('raster-dst' , raster-src',
> cutLineDSName='geometry-extraction.shp', cropToCutline=True)
>
>
>
> - with this one, the crop is not clean on closer inspection: residual
> black pixels around image and white pixels appear in the image.
>
> gdal. warp( 'raster-dst' , raster-src',
> cutLineDSName='geometry-extraction.shp', cropToCutline=True,
> copyMetaData=True, dstNodata=0)
>
>
> I tried, without success, to refine with outputBounds=[minX, maxX, minY,
> maxY], under QGIS directly ….
> I've run out of ideas :/
> A (naive) question comes to mind: Is it possible to make oblique cuts with
> gdal.warp() & co?
>
> Naïma
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Advice on `GDALCreateAndReprojectImage` and destination no-data value.

[Javier Jimenez Shaw via gdal-dev]

I do not know that code. But having a look I have the impression that you
have to set the nodata also to papszCreateOptions, so the created dataset
has it.

On Fri, 3 Nov 2023 at 21:36, Fitch, Simeon via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> I'm one of the maintainers at the `georust/gdal` bindings project. 
>
> I'm currently working on exposing some of the GDAL Warp functionality in
> Rust, starting with a simple wrapper around `GDALCreateAndReprojectImage`.
> I'm having trouble getting the output file to include a no-data value in
> the band's metadata, despite the Warp operation properly respecting no-data
> values specified in `GDALWarpOptions`.
>
> My C++ skills are very "rusty", so I'm hoping I can get away with
> explaining my problem with some Rust code that is pretty close to being 1:1
> with the C API. My suspicion is I'm missing a step in the `GDALWarpOptions`
> setup.
>
> This is the CLI operation I'm trying to replicate:
>
> gdalwarp -t_srs EPSG:4269 -dstnodata 255 -r near input.tif output.tif
>
> Here's the bare-bones Rust bindgen version:
>
> 
>
> The single band in `input.tif` is described by `gdalinfo` like this:
>
> Band 1 Block=186x44 Type=Byte, ColorInterp=Gray
>   NoData Value=255
>   Metadata:
> CLASSES=3
>
> After running the Rust code, the results are correct (including Warp
> numerically respecting source and destination no-data values) _except_
> `output.tif` does not have a no-data value in the band metadata. Here's
> what `gdalinfo` on `output.tif` shows:
>
> Band 1 Block=210x39 Type=Byte, ColorInterp=Gray
>
> The only way I've been able to get the behavior I need is to open the
> written dataset from the filesystem and set the no-data value explicitly in
> the band, which is inefficient and awkward. Given the CLI version does the
> right thing, it's obviously possible. I've spent several hours visually
> inspecting the C++ source code, but the CLI version doesn't call
> `GDALCreateAndReprojectImage` directly; rather it constructs the Warp
> pipeline itself.
>
> Anyone have tips that might help me run this down? Am I missing a no-data
> handling step required when working with Warp routines? Could
> `GDALCreateAndReprojectImage` have a bug?
>
> Thanks,
>
> Simeon
>
> --
> Simeon Fitch
> Co-founder & CTO
> Astraea, Inc.
>
>
> The content of this email is intended for the person or entity to which it
> is addressed only. This email may contain confidential information. If you
> are not the person to whom this message is addressed, be aware that any
> use, reproduction, or distribution of this message is strictly prohibited.
> If you received this in error, please contact the sender and immediately
> delete this email and any attachments.
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.8.0beta1 available for testing

[Javier Jimenez Shaw via gdal-dev]

Wow Even. There's a lot of new things there! Thanks to all the contributors!

On Fri, 3 Nov 2023, 18:53 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

>
> > I've prepared a beta1 of GDAL 3.8.0 to get feedback from earlier testers.
> >
> > Sorry no updated NEWS.md file yet
> ==> now available at https://github.com/OSGeo/gdal/blob/master/NEWS.md
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Adopt GDAL 3.7.3RC1 as 3.7.3 release

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 1 Nov 2023 at 12:19, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> +1
>
> -Jukka Rahkonen-
>
> -Alkuperäinen viesti-
> Lähettäjä: gdal-dev  Puolesta Even
> Rouault via gdal-dev
> Lähetetty: keskiviikko 1. marraskuuta 2023 13.14
> Vastaanottaja: gdal-dev@lists.osgeo.org
> Aihe: [gdal-dev] Motion: Adopt GDAL 3.7.3RC1 as 3.7.3 release
>
> Hi,
>
> Motion:
>
> Adopt GDAL 3.7.3RC1 as 3.7.3 release
>
> Starting with my +1
>
> Even
>
> --
> http://www.spatialys.com/
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: OSGeo Community Sprint Financial Support

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Tue, 31 Oct 2023, 18:04 Even Rouault via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> +1 Even
>
> Le 31/10/2023 à 17:59, Howard Butler via gdal-dev a écrit :
> > Dear PSC,
> >
> > Sorry for the short notice, but I would like to motion that the GDAL
> Sponsorship Program financially support GDAL PSC members who wish to attend
> the OSGeo Community Sprint in Vienna [1] next week. Support level is capped
> at 1000€ for European attendees and 1500€ for others.
> >
> > Howard
> >
> > [1] https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2023
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Tag for units in GeoTIFF

[Javier Jimenez Shaw via gdal-dev]

Thanks!

On Thu, 26 Oct 2023 at 12:27, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Javier,
> Le 26/10/2023 à 11:59, Javier Jimenez Shaw via gdal-dev a écrit :
>
> Hi
>
> Using a GeoTIFF with a single band and float values can be very useful to
> show any distribution over the terrain. One typical example is DSM (digital
> surface model), where the value is the elevation on every point.
>
> Is there any standard (or accepted) metadata to say the units of those
> values?
>
> API wise in GDAL, you should use the GDALRasterBand::SetUnitType() to set
> the unit
>
> For TIFF, this will be encoded in the GDAL_METADATA TIFF tag like the
> following:
>
> 
>   foo
> 
>
> Regarding the value itself, it is mostly unspecified by GDAL. It could be
> a good practice to suggest to use strings recognized by the "udunits"
> package (when possible), like done in the netCDF CF conventions (
> http://cfconventions.org/Data/cf-conventions/cf-conventions-1.10/cf-conventions.html#units
> )
>
> Even
>
>
> In the typical case of DSM it is usually "meter" or "foot". But it can be
> something else, like "people/km2" for population, or "mm" for rain
> precipitation, or "kg/ha" for agricultural yield.
>
> Thanks
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>
> ___
> gdal-dev mailing 
> listgdal-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Tag for units in GeoTIFF

[Javier Jimenez Shaw via gdal-dev]

Hi

Using a GeoTIFF with a single band and float values can be very useful to
show any distribution over the terrain. One typical example is DSM (digital
surface model), where the value is the elevation on every point.

Is there any standard (or accepted) metadata to say the units of those
values?

In the typical case of DSM it is usually "meter" or "foot". But it can be
something else, like "people/km2" for population, or "mm" for rain
precipitation, or "kg/ha" for agricultural yield.

Thanks
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Happy Birthday GDAL!

[Javier Jimenez Shaw via gdal-dev]

GDAL got 25 years old on 2023-10-17 !
I found it in this post
https://geoobserver.wordpress.com/2023/10/17/25-jahre-gdal-happy-birthday/
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Notice: issue about multi-threaded GTiff compression+decompression

[Javier Jimenez Shaw via gdal-dev]

Thanks Even for notifying this.
I see the fix will be included in the next releases 3.7.3 and 3.8.0, both
planned for November 1st (just in a couple of weeks)
https://github.com/OSGeo/gdal/milestones

On Mon, 16 Oct 2023 at 16:42, Even Rouault via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> For GDAL 3.6.0 to 3.7.2, use of multi-threaded GTiff
> compression+decompression, in particular within the same file, as for
> example in a "gdalwarp -co COMPRESS=... -co NUM_THREADS=..." workflow
> can lead to deadlocks (process stalled forever) and/or data corruption
> (sometimes without errors at generation). Cf
> https://github.com/OSGeo/gdal/issues/8470 for a reproducer. The fix is
> in https://github.com/OSGeo/gdal/pull/8561
>
> The issue is particularly visible on Windows, or more generally any
> operating system (or file system where the output file is located) which
> has no VSIVirtualHandle::PRead() implementation, but it can also be
> occasionally reproduced on Linux (at least as a deadlock).
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Reading a shapefile containing multi-parts Polyline from OGR (C++ API)

[Javier Jimenez Shaw via gdal-dev]

Do you mean a MultiLineString?

This piece of code is working for me (I hope without any bug).

if (wkbFlatten(poGeometry->getGeometryType()) == wkbMultiLineString)
multiLineStringGeometry(poGeometry);
...
multiLineStringGeometry(OGRGeometry* poGeometry)
{
OGRMultiLineString* multiLine =
dynamic_cast(poGeometry);
int numGeometries = multiLine->getNumGeometries();
for (int i = 0; i < numGeometries; i++)
{
OGRGeometry* eachGeometry =
multiLine->getGeometryRef(i);
OGRLineString* line =
dynamic_cast(eachGeometry);
// do whatever with that LineString
}
}

On Mon, 16 Oct 2023 at 12:14, Roland Baviere via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi all,
>
>  I hope this e-mel finds you well.
>
> I am trying to read a shapefile layer from OGR from a C++ application
> following the tutorial found here:
> https://gdal.org/tutorials/vector_api_tut.html#reading-from-ogr
>
> We have difficulties with a layer containing PolyLines with several parts.
>
> The pre-existing code works fine for polylines having a unique part.
>
> Do you have any example or advice to help me implement a version that
> works for polylines containing several parts. My intention is to display
> each shape on a map, so I need to retrieve the coordinates of points and
> draw segment between points when relevant.
>
> Thanks a lot for your help.
>
> Kind regards,
>
> Roland
>
>
>
>  CODE THAT WORKS for "simple" polylines but fails when dealiing with a
> polyline containing several parts
>
> int o = 0;
> for(auto y : poGeometry->toLineString()) {
> if (o == 0) {
> line.mInCoord = QGeoCoordinate(y.getX(),
> y.getY());
> } else if (o ==
> (poGeometry->toLineString()->getNumPoints() - 1)) {
> line.mOutCoord = QGeoCoordinate(y.getX(),
> y.getY());
> } else {
>
> line.mPath.addCoordinate(QGeoCoordinate(y.getX(), y.getY()));
> }
> qDebug() << o;
> o++;
> }
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Performance regression testing/benchmarking for CI

[Javier Jimenez Shaw via gdal-dev]

Hi Even. Thanks, it sounds good.
However I see a potential problem. I see that you use once "SetCacheMax".
We should not forget about that in the future for sensible tests. The cache
of gdal is usually a percentage of the total memory, that may change among
the environments and time.

On Wed, 11 Oct 2023, 07:53 Laurențiu Nicola via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
> No experience with pytest-benchmark, but I maintain an unrelated project
> that runs some benchmarks on CI, and here are some things worth mentioning:
>
>  - we store the results as a newline-delimited JSON file in a different
> GitHub repository (
> https://raw.githubusercontent.com/rust-analyzer/metrics/master/metrics.json,
> warning, it's a 5.5 MB unformatted JSON)
>  - we have an in-browser dashboard that retrieves the whole file and
> displays them: https://rust-analyzer.github.io/metrics/
>  - we do track build time and overall run time, but we're more interested
> in correctness
>  - the display is a bit of a mess (partly due to trying to keep the setup
> as simple as possible), but you can look for the "total time", "total
> memory" and "build" to get an idea
>  - we store the runner CPU type and memory in that JSON; they're almost
> all Intel, but they do upgrade from time to time
>  - we even have two AMD EPYC runs, note that boost is disabled in a
> different way there (we don't try to disable it, though)
>  - we also try to measure the CPU instruction count (the perf counter),
> but it doesn't work on GitHub and probably in most VMs
>  - the runners have been very reliable, but not really consistent in
> performance
>  - a bigger problem for us was that somebody actually needs to look at the
> dashboard to spot any regressions and investigate them (some are caused by
> external changes)
>  - in 3-5 years we'll probably have to trim down the JSON or switch to a
> different storage
>
> Laurentiu
>
> On Tue, Oct 10, 2023, at 21:08, Even Rouault via gdal-dev wrote:
> > Hi,
> >
> > I'm experimenting with adding performance regression testing in our CI.
> > Currently our CI has quite extensive functional coverage, but totally
> > lacks performance testing. Given that we use pytest, I've spotted
> > pytest-benchmark (https://pytest-benchmark.readthedocs.io/en/latest/)
> as
> > a likely good candidate framework.
> >
> > I've prototyped things in https://github.com/OSGeo/gdal/pull/8538
> >
> > Basically, we now have a autotest/benchmark directory where performance
> > tests can be written.
> >
> > Then in the CI, we checkout a reference commit, build it and run the
> > performance test suite in --benchmark-save mode
> >
> > And then we run the performance test suite on the PR in
> > --benchmark-compare mode with a --benchmark-compare-fail="mean:5%"
> > criterion (which means that a test fails if its mean runtime is 5%
> > slower than the reference one)
> >
> >  From what I can see, pytest-benchmark behaves correctly if tests are
> > removed or added (that is not failing, just skipping them during
> > comparison). The only thing one should not do is modify an existing test
> > w.r.t the reference branch.
> >
> > Does someone has practical experience of pytest-benchmark, in particular
> > in CI setups? With virtualization, it is hard to guarantee that other
> > things happening on the host running the VM might not interfer. Even
> > locally on my own machine, I initially saw strong variations in timings,
> > which can be reduced to acceptable deviation by disabling Intel
> > Turboboost feature (echo 1 | sudo tee
> > /sys/devices/system/cpu/intel_pstate/no_turbo)
> >
> > Even
> >
> > --
> > http://www.spatialys.com
> > My software is free, but my time generally not.
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] layer.GetSpatialRef() fails on linux for shapefiles

[Javier Jimenez Shaw via gdal-dev]

Are you running pycharm under the conda environment? If you lose any
setting while combining both it can be a problem.

Have you tried setting PROJ_DEBUG=3 ?
It will show some traces from PROJ, like the location of proj.db used. The
point is if you can see the std out.

On Wed, 11 Oct 2023, 15:18 Jonathan Moules via gdal-dev, <
gdal-dev@lists.osgeo.org> wrote:

> Hi List,
>
> So, after more investigation:
>
> * Using Python Anaconda on either Mac or Linux for GDAL (3.7.1),
> `GetSpatialRef` triggers a RunTime Error for all shapefiles (but only
> shapefiles).
>
> * This happens on Ubuntu (two machines), and a Mac, but only under PyCharm.
>
> * Using the exact same `conda` environment as triggers the above:
> running it directly from the terminal works fine.
>
> So there's something about the combination of conda and Pycharm that
> breaks this aspect of GDAL shapefile handling on *nix and Mac.
>
> Any thoughts? Also, who do I actually report this bug to? Is it GDAL,
> Conda, Pycharm, something else?
>
> Cheers,
>
> Jonathan
>
>
> On 2023-09-28 14:58, Jonathan Moules via gdal-dev wrote:
> > Well, it seems that PROJ_DATA isn't set in their environment. But it's
> > not set in mine either (`print(os.environ['PROJ_DATA']`)! So no idea
> > why mine works just fine without it (Windows 11 thing?).
> >
> > Creating a PROJ_DATA env var didn't fix anything. Even adding it
> > explicitly in Python.
> >
> > Their log file does have this in at a WARNING level:
> >
> > `PROJ: proj_create_from_database: Open of
> > /home/user/anaconda3/envs/env1/share/proj failed`
> >
> > That path has: `drwxrwxr-x` permissions.
> >
> > To answer Even's earlier question:
> >
> > `ogrinfo /path/to/shape.shp` works fine on their system.
> >
> >
> >
> > On 2023-09-28 12:37, Rahkonen Jukka wrote:
> >> Hi,
> >>
> >> Then they should add that environment if they do not know that they
> >> do not belong to "most users"
> >> https://proj.org/en/9.3/usage/environmentvars.html
> >>
> >> -Jukka Rahkonen-
> >>
> >> -Alkuperäinen viesti-
> >> Lähettäjä: gdal-dev  Puolesta
> >> Jonathan Moules via gdal-dev
> >> Lähetetty: torstai 28. syyskuuta 2023 14.10
> >> Vastaanottaja: gdal-dev@lists.osgeo.org; Even Rouault
> >> 
> >> Aihe: Re: [gdal-dev] layer.GetSpatialRef() fails on linux for shapefiles
> >>
> >> Hi Even,
> >>
> >> The colleague doesn't have either a PROJ_LIB or a PROJ_DATA
> >> environment variable.
> >>
> >> I asked another colleague to try it; they're on Ubuntu 20.04, and it
> >> worked for them. I believe using the same setup instructions.
> >>
> >> Cheers,
> >>
> >> Jonathan
> >>
> >> On 2023-09-24 22:37, Jonathan Moules via gdal-dev wrote:
> >>> Thanks Even. I don't have access to the machine either as the
> >>> colleague is moving to another project. I'll have to see if it fails
> >>> for another *nix user.
> >>>
> >>> On 2023-09-24 22:35, Even Rouault wrote:
>  Le 24/09/2023 à 23:22, Jonathan Moules via gdal-dev a écrit :
> >> Also check if the environment isn't messed up regarding PROJ and
> > the PROJ_LIB/PROJ_DATA environment variable
> >
> > Thanks Even; sorry, what does this line mean? I'm guessing you're
> > referring to:
> > https://proj.org/en/9.3/usage/environmentvars.html - what would a
> > "messed up" one look like?
> >
>  Hard to say without access to the machine. Perhaps just try to
>  recreate a new Conda env from scratch
> 
> 
> >>> ___
> >>> gdal-dev mailing list
> >>> gdal-dev@lists.osgeo.org
> >>> https://list/
> >>> s.osgeo.org%2Fmailman%2Flistinfo%2Fgdal-dev=05%7C01%7Cjukka.rahko
> >>> nen%40maanmittauslaitos.fi%7C1f6517888cb34fa40aed08dbc01389dd%7Cc4f8a6
> >>> 3255804a1c92371d5a571b71fa%7C0%7C0%7C638314962370381350%7CUnknown%7CTW
> >>> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> >>> Mn0%3D%7C3000%7C%7C%7C=3fVru6K6Ndpkv35FnAbMOlT%2BM96USO7wywqx550
> >>> uRUs%3D=0
> >> ___
> >> gdal-dev mailing list
> >> gdal-dev@lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Annual Contracts for Maintainers

[Javier Jimenez Shaw via gdal-dev]

+1 Javier

On Wed, 11 Oct 2023 at 21:09, Howard Butler via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Yes. Well "up to", of course, but Alessandro is providing us some more
> capacity.
>
> > On Oct 11, 2023, at 1:56 PM, Sean Gillies 
> wrote:
> >
> > Hi Howard,
> >
> > To be clear, this is a 50% time increase for Alessandro, yes? I think
> that's great!
> >
> > +1
> >
> > On Wed, Oct 11, 2023 at 10:16 AM Howard Butler via gdal-dev <
> gdal-dev@lists.osgeo.org> wrote:
> > PSC,
> >
> > I'm a little late but I would like to make the following motions in
> regards to GDAL maintainers:
> >
> > * Authorize Alessandro Pasotti for up to 30 hrs/month with a rate
> increase of 10 euros/hr until 30 NOV 2024.
> > * Authorize Even Rouault for up to 90 hrs/month with a rate increase of
> 10 $/hr until 30 JUL 2024
> >
> > Howard
> >
> > --
> > Sean Gillies
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Creation of a new driver from scratch

[Javier Jimenez Shaw via gdal-dev]

I never used that env bastante before, but it seems to be what you
describe. See that it is enabled also in the tests, as Even says in the
pull 2666

I'm curious. Why do you need to do something different on GDAL compilation?
(I assume it is in a exported header)

On Thu, 21 Sept 2023, 15:56 Abel Pau via gdal-dev, 
wrote:

> Hello again!
>
> I need to know that some shared code is being compiled in GDAL project. I
> can see that GDAL_COMPILATION  (at Preprocessor definition i Visual Studio
> Project) is everywhere.
>
> It's apropiate to use that variable to know if I am compiling in GDAL or
> not?
> #ifdef GDAL_COMPILATION
> I'm in GDAL
> #else
> I can ignore that code in gdal
> #endif
>
> I'm not using that in the code, only in some .h
>
> Thanks!!!
>
>
> -Mensaje original-
> De: Abel Pau
> Enviado el: dimarts, 5 de setembre de 2023 15:26
> Para: Even Rouault ; gdal-dev@lists.osgeo.org
> Asunto: RE: [gdal-dev] Creation of a new driver from scratch
>
> Hi again,
> after looking for that in the code, I think that versions depends on
> layer, so -lco is working fine (instead of -dsco, les used).
> So, if there is no inconvenience, I'll use -lco Version=V20, etc...
>
> Thanks again
>
> -Mensaje original-
> De: Abel Pau 
> Enviado el: dimarts, 5 de setembre de 2023 10:43
> Para: Abel Pau ; Even Rouault <
> even.roua...@spatialys.com>; gdal-dev@lists.osgeo.org
> Asunto: RE: [gdal-dev] Creation of a new driver from scratch
>
> Sorry
> there was a mistake. I meant: ogr2ogr src dst -dsco Version=V11 ...
>
> -Mensaje original-
> De: gdal-dev  En nombre de Abel Pau
> Enviado el: dimarts, 5 de setembre de 2023 10:26
> Para: Even Rouault ; gdal-dev@lists.osgeo.org
> Asunto: Re: [gdal-dev] Creation of a new driver from scratch
>
> Hi Everyone,
>
> Even, after a meeting with the team, we have took in consideration your
> opinion and we have discard the option of writing V1.1 and change to V2.0
> in the middle of writing.
> We have a long tradition with V1.1 and we can't ignore that now but we are
> going to offer both possibilities: read both and write V1.1 and V2.0
> according to user's choice (default 2.0).
> If V1.1 is not enough for its limitations we are going to show a message:
> "MiraMon format limitations." and "Try V2.0 option." and return
> OGRERR_FAILURE;
>
> Can you confirm that is enough a -f parameter like?
> For version 1.1:   ogr2ogr src dst - dsco=V11
> For version 2.0:   ogr2ogr src dst - dsco=V20
> For last version (to make it simple for possible future
> versions):  ogr2ogr src dst - dsco=last_version
>
> Thanks a lot for all your kind support.
>
> -Mensaje original-
> De: Even Rouault  Enviado el: dimecres, 30
> d’agost de 2023 22:57
> Para: Abel Pau ; gdal-dev@lists.osgeo.org
> Asunto: Re: [gdal-dev] Creation of a new driver from scratch
>
> Abel,
> >
> > I am interested in proportionate 3 ways of proceeding when a used calls
> translation from one format to our format.
> > way 1: force to write V1.1 and stop writing features if the limit is
> reached.
> > way 2: force to write V2.0 (and stop writing features if the limit is
> reached (it will no happen in a near future, I think)).
> > way 3: leave that the program decides if V1.1 is not enough and then it
> changes automatically to V2.0. It does it in the middle of the process,
> when FID or some used internal offset gets the limit.
>
> Not knowing anything about the ecosystem of the miramon format, but
> ideally I would bend on the side of simplicity if possible, and I would
> just write V2.0 if V1.1 can be considered as a legacy format, that deserves
> perhaps only read-only support (at our times of terabytes+ storage
> capacity, the saving of 4 bytes per feature seems like a anachronic
> concern). But if you really want to use V1.1 when possible and V2.0 only
> when possible, and provided that you implement the writing of the final
> file only at dataset closing as it was my understanding, then you know
> already the max(FID) of features that have been passed to CreateFeature, so
> you could decide automatically the version needed. I would strongly
> discourage starting writing a V1.1 file and then switching to V2.0 in the
> middle of the writing. That sounds like a serious complication.
>
> >
> > So, my questions:
> > 1.- Which ogr2ogr parameter is the best for doing that?
> >   -f? specificating "MiraMon V1.1" or "MiraMonV2.0" or "MiraMon"
> (automatic way).
>
> If you really need to implement the 2 formats, a dataset creation option
> in a single driver would probably be better.
>
>
> >Or there is another way I haven't seen (I've read all options
> > in https://gdal.org/programs/ogr2ogr.html#ogr2ogr)
> >
> > 2.- When using -progress some points appear on screen informing the
> progress. At the end of the progress (or sometimes driver requires) there
> is a gap of time that driver is writing some pendant information.
> -progress works by counting the number of features in