Re: [gdal-dev] Motion: adopt GDAL 3.4.3 RC2

[Tamas Szekeres]

+1

Tamas

Even Rouault  ezt írta (időpont: 2022. máj. 1.,
V, 22:46):

> Hi,
>
> Motion:
>
> Adopt GDAL 3.4.3 RC2 as final 3.4.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] Motion: adopt GDAL 3.4.3 RC2

[Norman Barker]

+1

On Mon, May 2, 2022 at 10:57 AM Mateusz Loskot  wrote:

> +1
>
>
> On Mon, 2 May 2022, 16:12 Howard Butler,  wrote:
>
>>
>>
>> > On May 1, 2022, at 3:45 PM, Even Rouault 
>> wrote:
>> >
>> > Hi,
>> >
>> > Motion:
>> >
>> > Adopt GDAL 3.4.3 RC2 as final 3.4.3 release
>> >
>> > Starting with my +1
>>
>> +1
>>
>> Howard
>> ___
>> 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.4.3 RC2

[Mateusz Loskot]

+1


On Mon, 2 May 2022, 16:12 Howard Butler,  wrote:

>
>
> > On May 1, 2022, at 3:45 PM, Even Rouault 
> wrote:
> >
> > Hi,
> >
> > Motion:
> >
> > Adopt GDAL 3.4.3 RC2 as final 3.4.3 release
> >
> > Starting with my +1
>
> +1
>
> Howard
> ___
> 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.4.3 RC2

[Rahkonen Jukka (MML)]

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: sunnuntai 1. toukokuuta 2022 23.46
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: adopt GDAL 3.4.3 RC2

Hi,

Motion:

Adopt GDAL 3.4.3 RC2 as final 3.4.3 release

Starting with my +1

Even

-- 
https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com%2Fdata=05%7C01%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C9411504abdf94af7354408da2bb3a9e7%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C1%7C637870347908360125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=E1Zl2gSVYKoC%2F4ZaXz6KxEh6niuh1lcNrUeb6QlOmTE%3Dreserved=0
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgdal-devdata=05%7C01%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C9411504abdf94af7354408da2bb3a9e7%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C1%7C637870347908360125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=zfTisF68UV8xFQylaKmuX5kN5dn0KQ5d2Jo3DjGv4F4%3Dreserved=0
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt GDAL 3.4.3 RC2

[Howard Butler]

> On May 1, 2022, at 3:45 PM, Even Rouault  wrote:
> 
> Hi,
> 
> Motion:
> 
> Adopt GDAL 3.4.3 RC2 as final 3.4.3 release
> 
> Starting with my +1

+1

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

Re: [gdal-dev] CMake: undefined reference to symbol dlerror

[Javier Jimenez Shaw]

Hi Even

If I understood the example you mention correctly, it is a direct
dependency of GDAL: the executable test_cpp links directly with GDAL.
Our problem is that we have a library (ioimage), that links with GDAL. The
error appears when we try to compile/link tests_unit_ioimage, that depends
on ioimage, that depends on GDAL.

Cheers,
Javier
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 2 May 2022 at 10:29, Even Rouault 
wrote:

>
> Le 29/04/2022 à 11:30, Javier Jimenez Shaw a écrit :
>
> We have a link problem on Linux when using GDAL transiently. If we link
> the unit tests for a library which depends on GDAL, i.e. an executable
> which transiently depends on GDAL through our library, we get the following
> linker error:
>
> /usr/bin/ld:
> libs/ioimage/tests/CMakeFiles/tests_unit_ioimage.dir/unit/writers/test_geoTiffWriter.cpp.o:
> undefined reference to symbol 'dlerror@@GLIBC_2.2.5'
> /usr/bin/ld: /lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO
> missing from command line
>
> We need to add -ldl to the linker line after GDAL in order to resolve the
> linker problem. This can be done when adding the property
>
>   INTERFACE_LINK_LIBRARIES "dl"
>
> to the GDAL::GDAL imported target in GDAL-targets-release.cmake (this is
> a generated file); apparently it is not enough to add dl to the
> IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE property.
>
> Does GDAL depend publicly on dl?
>
> Not that I'm aware of.
>
> Our CI runs ./autotest/postinstall/test_cmake.sh which in particular has a
> ./autotest/postinstall/test_cpp/CMakeLists.txt that has GDAL has a
> dependency
>
> Perhaps you could check how your setup is different from that ?
>
> We do not find the proper way to patch GDAL's CMake code to add that
> dependency in the generated config file.
>
> Thanks
> Javier
>
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
> ___
> 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] Why gdal2tiles creates png.aux.xml files

[Even Rouault]

Just fixed in master

Le 28/04/2022 à 08:28, Rahkonen Jukka (MML) a écrit :


Hi,

I noticed this question in gis.stacexchange 
https://gis.stackexchange.com/questions/429896/how-to-not-generate-png-aux-xml-files-when-using-gdal2tiles. 
The current gdal2tiles.py really seems to write the aux.xml files 
except for the base tiles. I wonder if it is necessary and if there is 
another way to prevent it than setting GDAL_PAM_ENABLED=NO as 
suggested in the answer.


-Jukka Rahkonen-


___
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

Re: [gdal-dev] Moving GDAL GRASS driver in a dedicated repository ?

[Even Rouault]

Hi Markus,

looks good to me. So maybe now you can send a pull request to remove the 
drivers from OSGeo/GDAL and modify 
https://gdal.org/drivers/raster/grass.html & 
https://gdal.org/drivers/vector/grass.html to point to the new repo ? 
I'd like to issue a 3.5.0 release candidate this week.


Even

Le 28/04/2022 à 22:31, Markus Neteler a écrit :

Hi Even,

(back to your wish)

On Thu, Nov 18, 2021 at 7:12 PM Even Rouault  wrote:

Hi,

(writing to both GDAL and GRASS lists)

Working on the transition to CMake as the GDAL build system, the
particular status of the GRASS driver in GDAL raised my attention.

(The following is based on my understanding. It has been ages since I
didn't try this...)

This driver is a bit odd in the sense that there's a cyclic dependency
to work around, as GRASS links to GDAL , but the GDAL GRASS driver needs
to be linked against GRASS.

So the usual procedure is:

- build GDAL without the GRASS driver

- build GRASS against GDAL

- build the GDAL GRASS driver from the separate gdal-grass tarball that
GDAL distributes along its main tarball.

With the current GDAL autoconf build system, there's also the
possibility to rebuild GDAL with the GRASS driver builtin in libgdal,
but that's a bit odd, since you need to make sure that this new libgdal
is the one that GRASS will link against at runtime, otherwise chaos will
ensure. I'm not sure if that's used. This is typically something I would
*not* want to support in the new GDAL cmake build.

All in all, given the particular nature of that driver, I believe it
would be better in a dedicated repository, with its standalone build
scripts, whose initial version could be just the ones of
https://github.com/OSGeo/gdal/tree/master/frmts/grass/pkg, or evolve to
CMake or whatever the maintainers of that driver would prefer. I believe
this would make the situation clearer.

Opinions ? and people interested in setting up that dedicated repository ?

Yes and finally done that:

https://github.com/OSGeo/gdal-grass

Hope I got it right (history is preserved, I used

git filter-repo --path ogr/ogrsf_frmts/grass --path frmts/grass

and then moved the remaining needed files into the toplevel directory.
Hope I got it right.

Markus


--
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] spacial filter on ogrinfo does not work

[Lars Fricke]

  
  
I assumed '-spat 513306 5832130 514040
  5832803' is the filter (bbox)? It does work on other servers it
  seems? The default srs should be EPSG:25832 
  Am I getting this wrong?
  

  

Am 02.05.22 um 13:02 schrieb Clive
  Swan:


  
  Have you apied a spatial filter ie distance??
  
  
  Get 
  Outlook for Android
  
  From:
  gdal-dev  on behalf of
  Lars Fricke 
  Sent: Monday, May 2, 2022 12:00:38 PM
  To: gdal-dev@lists.osgeo.org
  
  Subject: [gdal-dev] spacial filter on ogrinfo does not
  work
 
  
  Dear List,

I am trying to make a spatially filtered call as:

ogrinfo -ro WFS:https://www.geobasisdaten.niedersachsen.de/doorman/noauth/WFS_boris_2022
boris:BR_BodenrichtwertZonal -spat 513306 5832130 514040 5832803

but that is trying to download 33938 Features where it should be
around 20 or so. I am on GDAL 3.3.2, released 2021/09/01, Ubuntu
20.04
"""
INFO: Open of `WFS:https://www.geobasisdaten.niedersachsen.de/doorman/noauth/WFS_boris_2022'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=BORIS 2022 WFS by XtraServer
  PROVIDER_NAME=Landesamt für Geoinformation und
Landesvermessung Niedersachsen (LGLN) - Landesbetrieb
Landesvermessung und Geobasisinformation
  TITLE=BORIS 2022 WFS

Layer name: boris:BR_BodenrichtwertZonal
Metadata:
  TITLE=boris_BR_BodenrichtwertZonal
Geometry: Polygon
Feature Count: 33938
"""
I interrupted the call before I get blacklisted by that
server...

I did try to set environment variable OGR_SKIP=NAS as this was a
hint I got. I'm not certain if that made any difference. If I
call other servers with the same logic, I am fine.


Any idea what could be wrong?

Thanks for any support.

Lars

  


  


OpenPGP_0x667E0B7B73E250FB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] spacial filter on ogrinfo does not work

[Clive Swan]

Have you apied a spatial filter ie distance??

Get Outlook for Android

From: gdal-dev  on behalf of Lars Fricke 

Sent: Monday, May 2, 2022 12:00:38 PM
To: gdal-dev@lists.osgeo.org 
Subject: [gdal-dev] spacial filter on ogrinfo does not work

Dear List,

I am trying to make a spatially filtered call as:

ogrinfo -ro 
WFS:https://www.geobasisdaten.niedersachsen.de/doorman/noauth/WFS_boris_2022 
boris:BR_BodenrichtwertZonal -spat 513306 5832130 514040 5832803

but that is trying to download 33938 Features where it should be around 20 or 
so. I am on GDAL 3.3.2, released 2021/09/01, Ubuntu 20.04
"""
INFO: Open of 
`WFS:https://www.geobasisdaten.niedersachsen.de/doorman/noauth/WFS_boris_2022'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=BORIS 2022 WFS by XtraServer
  PROVIDER_NAME=Landesamt für Geoinformation und Landesvermessung Niedersachsen 
(LGLN) - Landesbetrieb Landesvermessung und Geobasisinformation
  TITLE=BORIS 2022 WFS

Layer name: boris:BR_BodenrichtwertZonal
Metadata:
  TITLE=boris_BR_BodenrichtwertZonal
Geometry: Polygon
Feature Count: 33938
"""
I interrupted the call before I get blacklisted by that server...

I did try to set environment variable OGR_SKIP=NAS as this was a hint I got. 
I'm not certain if that made any difference. If I call other servers with the 
same logic, I am fine.


Any idea what could be wrong?

Thanks for any support.

Lars

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

[gdal-dev] spacial filter on ogrinfo does not work

[Lars Fricke]

  
  
Dear List,

I am trying to make a spatially filtered call as:

ogrinfo -ro
WFS:https://www.geobasisdaten.niedersachsen.de/doorman/noauth/WFS_boris_2022
boris:BR_BodenrichtwertZonal -spat 513306 5832130 514040 5832803

but that is trying to download 33938 Features where it should be
around 20 or so. I am on GDAL 3.3.2, released 2021/09/01, Ubuntu
20.04
"""
INFO: Open of
`WFS:https://www.geobasisdaten.niedersachsen.de/doorman/noauth/WFS_boris_2022'
  using driver `WFS' successful.
Metadata:
  ABSTRACT=BORIS 2022 WFS by XtraServer
  PROVIDER_NAME=Landesamt für Geoinformation und Landesvermessung
Niedersachsen (LGLN) - Landesbetrieb Landesvermessung und
Geobasisinformation
  TITLE=BORIS 2022 WFS

Layer name: boris:BR_BodenrichtwertZonal
Metadata:
  TITLE=boris_BR_BodenrichtwertZonal
Geometry: Polygon
Feature Count: 33938
"""
I interrupted the call before I get blacklisted by that server...

I did try to set environment variable OGR_SKIP=NAS as this was a
hint I got. I'm not certain if that made any difference. If I call
other servers with the same logic, I am fine.


Any idea what could be wrong?

Thanks for any support.

Lars

  


OpenPGP_0x667E0B7B73E250FB.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] About COG with multiple bands

[Javier Jimenez Shaw]

Thanks for the explanation and the link. I thought that the pixel
interleaving was defined in COG standard, but now I see it is only in GDAL
(so far).
Definitely depending on the use case, pixel or band interleaving is more
useful (as already commented on the issue you linked). I am not sure if the
COG readers are prepared for band interleave.

Cheers,
Javier.
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.



On Mon, 2 May 2022 at 10:09, Even Rouault 
wrote:

> Javier,
>
> up to now, GDAL has restricted the COG definition to pixel interleaved
> organization, a bit artificially admittedly. This issue was recorded in
> https://github.com/opengeospatial/CloudOptimizedGeoTIFF/issues/3 .
> There's no way to efficiently extract a subset of bands with pixel
> interleaved organization.
>
> Even
> Le 01/05/2022 à 11:10, Javier Jimenez Shaw a écrit :
>
> Hi
>
> In the event "Cloud Native Geospatial" Chris mentioned that a COG file
> allows to extract just a few bands. For instance, from a satellite image
> with 12 bands, you could extract only red, green and blue, not needing to
> download all the bands. In this example it would be a reduction factor of 4.
>
> If I understand correctly from https://gdal.org/drivers/raster/cog.html
> "Pixel interleaving for multi-band dataset" the optimization mentioned
> above could not be possible. Am I right? Is there any efficient way to read
> just one band?
>
> Thanks,
> Javier.
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
> Entre dos pensamientos racionales
> hay infinitos pensamientos irracionales.
>
>
> ___
> 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] CMake: undefined reference to symbol dlerror

[Even Rouault]

Le 29/04/2022 à 11:30, Javier Jimenez Shaw a écrit :
We have a link problem on Linux when using GDAL transiently. If we 
link the unit tests for a library which depends on GDAL, i.e. an 
executable which transiently depends on GDAL through our library, we 
get the following linker error:


/usr/bin/ld: 
libs/ioimage/tests/CMakeFiles/tests_unit_ioimage.dir/unit/writers/test_geoTiffWriter.cpp.o: 
undefined reference to symbol 'dlerror@@GLIBC_2.2.5'
/usr/bin/ld: /lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: 
DSO missing from command line


We need to add -ldl to the linker line after GDAL in order to resolve 
the linker problem. This can be done when adding the property


  INTERFACE_LINK_LIBRARIES "dl"

to the GDAL::GDAL imported target in GDAL-targets-release.cmake (this 
is a generated file); apparently it is not enough to add dl to the 
IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE property.


Does GDAL depend publicly on dl?


Not that I'm aware of.

Our CI runs ./autotest/postinstall/test_cmake.sh which in particular has 
a ./autotest/postinstall/test_cpp/CMakeLists.txt that has GDAL has a 
dependency


Perhaps you could check how your setup is different from that ?

We do not find the proper way to patch GDAL's CMake code to add that 
dependency in the generated config file.


Thanks
Javier

.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.


___
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

Re: [gdal-dev] Hints that a raster band represents a DEM?

[Even Rouault]

Hi Nyall,

you didn't miss anything. There's no standardized metadata to figure out 
if a band is DEM. A few drivers (at least USGSDEM, DTED, SRTMHGT, BLX, 
BT, Leveller, Terragen, SIGDEM, HF2) convey exclusively height related 
data, but most others can convey anything, often without a 
distinctive/normalized way of identifying the nature of the data.


Even

Le 30/04/2022 à 03:10, Nyall Dawson a écrit :

Hi list,

I'm looking for any tips on potential approaches I could use to
automagically guess that a particular band from a data source
represents an elevation surface.

I haven't been able to find any common metadata components in the
files I've investigated which could help indicate this, but maybe I'm
missing something. Right now the best approach I can think of would be
to test if the layer's CRS has a vertical component (but unfortunately
even among DEM layers I think this will be rare!).

Any suggestions?
Nyall
___
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

Re: [gdal-dev] About COG with multiple bands

[Even Rouault]

Javier,

up to now, GDAL has restricted the COG definition to pixel interleaved 
organization, a bit artificially admittedly. This issue was recorded in 
https://github.com/opengeospatial/CloudOptimizedGeoTIFF/issues/3 . 
There's no way to efficiently extract a subset of bands with pixel 
interleaved organization.


Even

Le 01/05/2022 à 11:10, Javier Jimenez Shaw a écrit :

Hi

In the event "Cloud Native Geospatial" Chris mentioned that a COG file 
allows to extract just a few bands. For instance, from a satellite 
image with 12 bands, you could extract only red, green and blue, not 
needing to download all the bands. In this example it would be a 
reduction factor of 4.


If I understand correctly from 
https://gdal.org/drivers/raster/cog.html "Pixel interleaving for 
multi-band dataset" the optimization mentioned above could not be 
possible. Am I right? Is there any efficient way to read just one band?


Thanks,
Javier.
.___ ._ ..._ .. . ._. .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.


___
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