date:20211108

Re: [gdal-dev] Strange behavior opening CSVs

2021-11-08 Thread Rahkonen Jukka (MML)

Hi,

The trial with gdalinfo makes GDAL to try XYZ
https://gdal.org/drivers/raster/xyz.html?highlight=xyz. It is not a bad guess
at all. Ogrinfo tries CSV and finds the x, y, and val fields. I can’t say
anything about the second part.

-Jukka Rahkonen-

Lähettäjä: gdal-dev Puolesta Simon Eves
Lähetetty: tiistai 9. marraskuuta 2021 2.21
Vastaanottaja: gdal dev
Aihe: [gdal-dev] Strange behavior opening CSVs

I am currently implementing a better file identifier, and during the course of
development, I unintentionally let GDAL try to GDALOpenEx() the attached
trivial CSV file.

First, it reported "Ungridded dataset: At line 3, change of Y direction" (as a
warning to the registered error-handler) and the returned OGRDataSource* was
null.

When I tried again, it then claimed that I was trying to open the same file
recursively. implying that it had, in fact, opened it, even though it never
returned a valid handle, so I wouldn't have been able to close it again even if
I'd wanted to.

I can reproduce the first part with gdalinfo.

This is with GDAL 3.2.2 on Ubuntu 20.04 with GCC 9.

I'll poke at the GDAL code myself when I have a bit more time.

--
[http://www2.omnisci.com/l/298412/2018-09-18/3sqpg/298412/61753/OmniSci_Email_Header2.png]

Simon Eves

Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA

Email: simon.e...@omnisci.com | Cell:

+1 (415) 902-1996

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

Re: [gdal-dev] Driver DCAP flags

2021-11-08 Thread Simon Eves

Heh. Right.

On Mon, Nov 8, 2021 at 2:24 PM Even Rouault 
wrote:

>
> Le 08/11/2021 à 21:44, Simon Eves a écrit :
>
> Quick question...
>
> Is it a definitive check for whether a GDALDriver is a Vector or Raster
> driver to look for either DCAP_VECTOR=YES or DCAP_RASTER=YES in the default
> meta-data?
>
> They should . It is how gdalinfo --formats or ogrinfo --formats recognize
> them
>
>
> Is every (vector or raster) driver guaranteed to have one or other of
> those?
>
> always recall THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND, EXPRESS OR IMPLIED :-)
>
>
> TIA
>
> Simon
>
> --
> 
> Simon Eves
> Senior Graphics Engineer, Rendering Group
> 100 Montgomery St (5th Floor), San Francisco, CA 94104, USA
>
>
> Email: simon.e...@omnisci.com | Cell:  +1 (415) 902-1996
>
>
> ___
> 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.
>
>

-- 

Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA


Email: simon.e...@omnisci.com | Cell:  +1 (415) 902-1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Strange behavior opening CSVs

2021-11-08 Thread Simon Eves

I am currently implementing a better file identifier, and during the course
of development, I unintentionally let GDAL try to GDALOpenEx() the attached
trivial CSV file.

First, it reported "Ungridded dataset: At line 3, change of Y direction"
(as a warning to the registered error-handler) and the returned
OGRDataSource* was null.

When I tried again, it then claimed that I was trying to open the same file
recursively. implying that it had, in fact, opened it, even though it never
returned a valid handle, so I wouldn't have been able to close it again
even if I'd wanted to.

I can reproduce the first part with gdalinfo.

This is with GDAL 3.2.2 on Ubuntu 20.04 with GCC 9.

I'll poke at the GDAL code myself when I have a bit more time.

-- 

Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA


Email: simon.e...@omnisci.com | Cell:  +1 (415) 902-1996
x,y,val
1.0,28.0,0.01
2.0,55.0,0.1
3.0,43.0,0.2
4.0,91.0,0.3
5.0,81.0,0.4
6.0,53.0,0.5
7.0,19.0,0.6
8.0,87.0,0.7
9.0,52.0,0.8
10.0,48.0,0.9
11.0,24.0,0.99
12.0,49.0,0.9
13.0,87.0,0.8
14.0,66.0,0.7
15.0,17.0,0.6
16.0,27.0,0.5
17.0,68.0,0.4
18.0,16.0,0.3
19.0,49.0,0.2
20.0,15.0,0.1
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Driver DCAP flags

2021-11-08 Thread Even Rouault



Le 08/11/2021 à 21:44, Simon Eves a écrit :

Quick question...

Is it a definitive check for whether a GDALDriver is a Vector or 
Raster driver to look for either DCAP_VECTOR=YES or DCAP_RASTER=YES in 
the default meta-data?
They should . It is how gdalinfo --formats or ogrinfo --formats 
recognize them


Is every (vector or raster) driver guaranteed to have one or other of 
those?
always recall THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY 
KIND, EXPRESS OR IMPLIED :-)


TIA

Simon

--


Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA



Email: simon.e...@omnisci.com  | Cell: 
+1 (415) 902-1996





___
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] Driver DCAP flags

2021-11-08 Thread Simon Eves

Quick question...

Is it a definitive check for whether a GDALDriver is a Vector or Raster
driver to look for either DCAP_VECTOR=YES or DCAP_RASTER=YES in the default
meta-data?

Is every (vector or raster) driver guaranteed to have one or other of those?

TIA

Simon

-- 

Simon Eves
Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA


Email: simon.e...@omnisci.com | Cell:  +1 (415) 902-1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.4.0 is released

2021-11-08 Thread Jeff McKenna

All MapServer demo services (over 10+ OGC services) have been updated to 
GDAL 3.4.0 : https://demo.mapserver.org



-jeff



--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/




On 2021-11-08 9:42 a.m., Even Rouault wrote:

Hi,

On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 3.4.0. GDAL/OGR is a C++ geospatial data
access library for raster and vector file formats, databases and web 
services.

It includes bindings for several languages, and a variety of command line
tools.

    http://gdal.org/

The 3.4.0 release is a new feature release with the following highlights:

* [RFC 81](https://gdal.org/development/rfc/rfc81_coordinate_epoch.html):
   Support for coordinate epochs in geospatial formats.
   Implemented in FlatGeoBuf, GeoPackage, MEM, VRT
* New GDAL drivers:
   - [Zarr](https://gdal.org/drivers/raster/zarr.html):
     read/write support for ZarrV2 (and experimental V3), using 2D 
classic raster

     API or multidimensional API:
   - [STACIT](https://gdal.org/drivers/raster/stacit.html):
     Spatio-Temporal Asset Catalog Items as virtual mosaics
* Other improvements:
   - number of enhancements in file system operations of /vsigs/
   - NITF: additions to comply with NITF Version 2.1 Commercial Dataset
     Requirements Document (NCDRD)
   - ODBC and PGeo: multiple fixes and improvements
   - SAFE (Sentinel1): multiple improvements related to SLC/calibration 
(change

     subdataset naming)
   - multidimensional API: caching, and other improvements
* Code linting and security fixes
* MDB driver (Java based) mark as deprecated. Planned for removal for 
GDAL 3.5.
   ODBC driver is the preferred solution (with up-to-date MDBTools 
library on

   non-Windows platforms)
* Writing side of Tiger driver deprecated and will be removed in GDAL 3.5
* Remainder: DODS, JPEG2000(Jasper), JPEGLS, MG4LIDAR, FUJIBAS, IDA, 
INGR and
   vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, 
GEOMEDIA,
   GTM, INGRES, MONGODB, REC, WALK are planned for removal in GDAL 3.5. 
As well

   as Perl bindings

More complete information on the new features and fixes in the 3.4.0 
release can be found at:


   https://github.com/OSGeo/gdal/blob/v3.4.0/gdal/NEWS.md

The release can be downloaded from:
   * https://download.osgeo.org/gdal/3.4.0/gdal340.zip - source as a zip
   * https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0.tar.gz - source as 
.tar.gz
   * https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0.tar.xz - source as 
.tar.xz
   * https://download.osgeo.org/gdal/3.4.0/gdal-grass-3.4.0.tar.gz - 
GDAL-GRASS plugin
   * https://download.osgeo.org/gdal/3.4.0/gdalautotest-3.4.0.tar.gz - 
test suite
   * https://download.osgeo.org/gdal/3.4.0/gdal340doc.zip - 
documentation / website


Best regards,

Even



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

Re: [gdal-dev] WKID not set for reprojectionfrom WGS84 to GDA2020

2021-11-08 Thread Even Rouault


Abhay,

I've investigated a bit and the reason is that FileGDB SDK contains a 
catalog of geographic and projected CRS that doesn't contain GDA2020 / 
EPSG:7844. The SDK likely lags behind the capabilities of other Esri 
software.


I've just added in master a layer creation option (undocumented for now) 
to manually specify the WKID, like


ogr2ogr out.gdb in_dataset -t_srs EPSG:7844 -lco WKID=7844

The OpenFileGDB driver can make use of that code, but the FileGDB driver 
doesn't see it yet (but could potentially be modified to see it). I've 
no idea if other Esri software would probably recognize a layer with a 
SRS set this way. Feedback would be appreciated.


The official Docker images the project publishes don't contain 
close-source bits, hence no FileGDB driver.


Even

Le 08/11/2021 à 14:59, Abhay Duvvuri a écrit :

Hi,

I am trying to reproject ESRI file geodatabase data from WGS84 (3857) 
to GDA2020 (7844) with "FileGDB" driver option. The data is 
reprojected but WKID is not set.

ogr2ogr tool is being used to reproject data.
Please let me know what can be done here.

Also, is there a docker image readily available with FileGDB 
configured. I am able to build an image by following the steps from 
https://github.com/OSGeo/gdal/tree/master/docker 
 but wanted to check 
if there is an image readily available.

Any advice here is greatly appreciated.

Thanks and regards,
Abhay

___
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] Broken link in docs

2021-11-08 Thread Stefano Iacovella

Thanks Even,
I didn't see the edit feature, good to know for the next time :)

Stefano

Il giorno lun 8 nov 2021 alle ore 16:22 Even Rouault <
even.roua...@spatialys.com> ha scritto:

> Hi,
>
> I've just fixed it. But anyone with a github account can easily do such
> fixes by clicking on the "Edit on github" link at the top right of each doc
> pages.
>
> Even
> Le 08/11/2021 à 16:15, Stefano Iacovella a écrit :
>
> Hi all,
>
> I just noted a very small issue in this page:
>
> https://gdal.org/download.html#linux-docker-images
>
> After this period " Information on the content of the different
> configurations can be found at " there's this URL:
>
> https://github.com/OSGeo/gdal/tree/master/gdal/docker
>
> It's broken, the working one is:
>
> https://github.com/OSGeo/gdal/tree/master/docker
>
> I'm sorry I'm not able to fix this by myself.
>
> All the best
>
> Stefano
>
> ___
> 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

Re: [gdal-dev] Broken link in docs

2021-11-08 Thread Even Rouault


Hi,

I've just fixed it. But anyone with a github account can easily do such 
fixes by clicking on the "Edit on github" link at the top right of each 
doc pages.


Even

Le 08/11/2021 à 16:15, Stefano Iacovella a écrit :

Hi all,

I just noted a very small issue in this page:

https://gdal.org/download.html#linux-docker-images 



After this period " Information on the content of the different 
configurations can be found at " there's this URL:


https://github.com/OSGeo/gdal/tree/master/gdal/docker 



It's broken, the working one is:

https://github.com/OSGeo/gdal/tree/master/docker 



I'm sorry I'm not able to fix this by myself.

All the best

Stefano

___
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] Broken link in docs

2021-11-08 Thread Stefano Iacovella

Hi all,

I just noted a very small issue in this page:

https://gdal.org/download.html#linux-docker-images

After this period " Information on the content of the different
configurations can be found at " there's this URL:

https://github.com/OSGeo/gdal/tree/master/gdal/docker

It's broken, the working one is:

https://github.com/OSGeo/gdal/tree/master/docker

I'm sorry I'm not able to fix this by myself.

All the best

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

[gdal-dev] gdal2tiles.py - next step

2021-11-08 Thread Clay, Bruce

I am trying to add WMTS / TMS to our current WMS mapserver.  I have some map 
tiles generated by gdal2tiles.py that appear to be valid.  There is a 
tilemapresource.xml file in the root of each tile set.

I am not sure the correct forum to ask this question but how do I configure 
mapserver to serve one of these tile sets when there is not a corresponding 
original source to put in the mapserver configuration file? I added the 
mapcache.xml file as follows

   
 H:/ms4w/cache/BlueMarbleTiles_200401


   
  bluemarble_src
  bm_200401
  5 5
  PNG
  WGS84

  
Blue Marble 200401
Blue Marble - January 2004 - tiles

  Blue Marble
  tiles

  
   

   
  bluemarble_src
  bm_200401
  5 5
  PNG
  WGS84

  
Blue Marble 200401
Blue Marble - January 2004 - tiles

  Blue Marble
  tiles

  
   

When I select the tile set in QGIS using
http://localhost/mapcache/wmts?service=wmts=getcapabilities=1.0.0

All of the layers show as available layers but the only ones that show on the 
map are the ones that have an entry in the WMS map file.

>From my understanding the tilemapresource.xml file generate by gdal2tiles.py 
>specifies the zoom levels and resolution but it is not specified in any of the 
>configuration files.

Any suggestions would be greatly appreciated.

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

Re: [gdal-dev] [EXTERNAL] Re: ogr2ogr does not convert OSM polygons

2021-11-08 Thread Clay, Bruce

Jukka:
  I apologize for the delay getting back to you.  Thanks you for your help. I 
am posting this as the solution that worked for me in case it will help anyone 
else.

I created a batch file (CreateandLoadOsmSchema.bat) with the following calls:

"C:\Program Files\PostgreSQL\12\bin\psql" -h data-trust -d osm_%1  -p 5432 -U 
postgres -c "CREATE SCHEMA %2";

Z:\OpenStreetMap\release-1916-x64-gdal-mapserver\bin\ogr2ogr -f PostgreSQL 
PG:"dbname='osm_%1' host='port='5432' user='postgres' 
password=''" -lco schema=%2 %3  --config OSM_MAX_TMPFILE_SIZE 1024

then I created a separate batch file (CreateAndLoadAfricaOsm.bat) that 
contained:

set GDAL_DRIVER_PATH=Z:\OpenStreetMap\release-1916-x64-gdal-mapserver\bin
set PGPASSWORD=

cd ..\africa

CALL ..\scripts\CreateAndLoadOsmSchema algeria algeria-latest.osm.pbf
CALL ..\scripts\CreateandLoadOsmSchema angola angola-latest.osm.pbf

added a line for each PBF that I downloaded

This created a postgresql /postgis table for each dataset.

Bruce




From: Rahkonen Jukka (MML) 
Sent: Tuesday, November 2, 2021 3:35 PM
To: Clay, Bruce 
Cc: 'gdal-dev@lists.osgeo.org' 
Subject: Re: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons


Hi,



Please take care to send mail also to the list.



The error that you get means probably that the Proj coordinate transformation 
library finds an older version of the proj.db file. With the gisinternals 
installation that file is in [gdal_installation_directory]\bin\proj7\share. 
Environmental variable PROJ_LIB should point into there. How did you launch 
ogr2ogr after installation? If you installed from the zip file you must run 
first the batch file “sdkshell.bat” for setting the paths and environment 
variables. If you used installer then you should launch GDAL command window 
from the shortcuts. In both cases when settings are OK you can run ogr2ogr 
simply as “ogr2ogr”.



Other_relations contain geometries which are of geometry type 
“GeometryCollection”. Unfortunately QGIS has very little support for 
GeometryCollections. You can see the attributes but not the geometries. If you 
are interested in the relations you must use some workarounds with QGIS or use 
other programs. For example OpenJUMP can do pretty well with relations but it 
is not so well documented.



-Jukka Rahkonen-



Lähettäjä: Clay, Bruce 
Lähetetty: tiistai 2. marraskuuta 2021 20.35
Vastaanottaja: Rahkonen Jukka (MML) 
Aihe: Re: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons



Jukka:

  I upgraded to 3.4.0 from sysinternals.  All tables appear to be going in ok 
but I do get an error message for each table (shown below).  QGIS shows the 
SRID is 4326.  "other_relations" has a geometry column and it loads in QGIS but 
the geometry does not show.  It appears I can get what I need for my task, just 
annoying messages.



Should "other_relations" show in QGIS?



Thanks for you help.



Bruce



Z:\OpenStreetMap\release-1916-x64-gdal-mapserver\bin\ogr2ogr -f PostgreSQL 
PG:"dbname='open_street_map' host='hostname' port='5432' user='postgres' 
password='pwd'" -lco schema=algeria algeria-latest.osm.pbf  --config 
OSM_MAX_TMPFILE_SIZE 1024

0...10...20...30...40.ERROR 1: PROJ: proj_create_from_database: cannot build 
geodeticCRS 4326: SQLite error on SELECT extent.description, extent.south_lat, 
extent.north_lat, extent.west_lon, extent.east_lon, scope.scope, (CASE WHEN 
scope.scope LIKE '%large scale%' THEN 0 ELSE 1 END) AS score FROM usage JOIN 
extent ON usage.extent_auth_name = extent.auth_name AND usage.extent_code = 
extent.code JOIN scope ON usage.scope_auth_name = scope.auth_name AND 
usage.scope_code = scope.code WHERE object_table_name = ? AND object_auth_name 
= ? AND object_code = ? ORDER BY score, usage.auth_name, usage.code: no such 
table: usage

..50...60...70...80...90...100 - done.



From: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Sent: Tuesday, November 2, 2021 12:32 PM
To: Clay, Bruce mailto:bc...@infoscitex.com>>
Subject: VS: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons



Actually, it was GDAL 3.3.1 from OSGeo4W installer.



-Jukka-



Lähettäjä: Clay, Bruce mailto:bc...@infoscitex.com>>
Lähetetty: tiistai 2. marraskuuta 2021 18.19
Vastaanottaja: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Aihe: Re: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons



Jukka:

  Thanks for your reply.



I was in the progress of loading all OSM so I started with Africa and saw the 
same thing for all pbf files.  You can pick a small one such as 
algeria-latest.osm.pbf.  In my post I  just replaced the country name with the 
word "country" to be generic.  All of the files came from the website you 
mentioned.



I am using the OSGeo shell on Windows 10.  gdalinfo show version is 3.0.4

I did not change the osmconf.ini file.



After looking deeper into the table osm2pgsql created I noticed roads are not 
actually put in the osm

[gdal-dev] WKID not set for reprojectionfrom WGS84 to GDA2020

2021-11-08 Thread Abhay Duvvuri

Hi,

I am trying to reproject ESRI file geodatabase data from WGS84 (3857) to
GDA2020 (7844) with "FileGDB" driver option. The data is reprojected but
WKID is not set.
ogr2ogr tool is being used to reproject data.
Please let me know what can be done here.

Also, is there a docker image readily available with FileGDB configured. I
am able to build an image by following the steps from
https://github.com/OSGeo/gdal/tree/master/docker but wanted to check if
there is an image readily available.
Any advice here is greatly appreciated.

Thanks and regards,
Abhay
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 3.4.0 is released

2021-11-08 Thread Even Rouault


Hi,

On behalf of the GDAL/OGR development team and community, I am pleased to
announce the release of GDAL/OGR 3.4.0. GDAL/OGR is a C++ geospatial data
access library for raster and vector file formats, databases and web 
services.

It includes bindings for several languages, and a variety of command line
tools.

   http://gdal.org/

The 3.4.0 release is a new feature release with the following highlights:

* [RFC 81](https://gdal.org/development/rfc/rfc81_coordinate_epoch.html):
  Support for coordinate epochs in geospatial formats.
  Implemented in FlatGeoBuf, GeoPackage, MEM, VRT
* New GDAL drivers:
  - [Zarr](https://gdal.org/drivers/raster/zarr.html):
    read/write support for ZarrV2 (and experimental V3), using 2D 
classic raster

    API or multidimensional API:
  - [STACIT](https://gdal.org/drivers/raster/stacit.html):
    Spatio-Temporal Asset Catalog Items as virtual mosaics
* Other improvements:
  - number of enhancements in file system operations of /vsigs/
  - NITF: additions to comply with NITF Version 2.1 Commercial Dataset
    Requirements Document (NCDRD)
  - ODBC and PGeo: multiple fixes and improvements
  - SAFE (Sentinel1): multiple improvements related to SLC/calibration 
(change

    subdataset naming)
  - multidimensional API: caching, and other improvements
* Code linting and security fixes
* MDB driver (Java based) mark as deprecated. Planned for removal for 
GDAL 3.5.
  ODBC driver is the preferred solution (with up-to-date MDBTools 
library on

  non-Windows platforms)
* Writing side of Tiger driver deprecated and will be removed in GDAL 3.5
* Remainder: DODS, JPEG2000(Jasper), JPEGLS, MG4LIDAR, FUJIBAS, IDA, 
INGR and
  vector driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, 
GEOMEDIA,
  GTM, INGRES, MONGODB, REC, WALK are planned for removal in GDAL 3.5. 
As well

  as Perl bindings

More complete information on the new features and fixes in the 3.4.0 
release can be found at:


  https://github.com/OSGeo/gdal/blob/v3.4.0/gdal/NEWS.md

The release can be downloaded from:
  * https://download.osgeo.org/gdal/3.4.0/gdal340.zip - source as a zip
  * https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0.tar.gz - source as 
.tar.gz
  * https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0.tar.xz - source as 
.tar.xz
  * https://download.osgeo.org/gdal/3.4.0/gdal-grass-3.4.0.tar.gz - 
GDAL-GRASS plugin
  * https://download.osgeo.org/gdal/3.4.0/gdalautotest-3.4.0.tar.gz - 
test suite
  * https://download.osgeo.org/gdal/3.4.0/gdal340doc.zip - 
documentation / website


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

Re: [gdal-dev] Motion: promote GDAL 3.4.0RC3 as final issue

2021-11-08 Thread Even Rouault

I declare this motion passed with +1 from PSC members JukkaR, MateuszL, 
HowardB, DanielM and me.


Even

Le 04/11/2021 à 13:33, Even Rouault a écrit :

Hi,

RC3 should be the last iteration needed to allow 3.4.0 to be released.

Motion:

Adopt GDAL 3.4.0 RC3 as final 3.4.0 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

Re: [gdal-dev] Strange behavior opening CSVs

Re: [gdal-dev] Driver DCAP flags

[gdal-dev] Strange behavior opening CSVs

Re: [gdal-dev] Driver DCAP flags

[gdal-dev] Driver DCAP flags

Re: [gdal-dev] GDAL 3.4.0 is released

Re: [gdal-dev] WKID not set for reprojectionfrom WGS84 to GDA2020

Re: [gdal-dev] Broken link in docs

Re: [gdal-dev] Broken link in docs

[gdal-dev] Broken link in docs

[gdal-dev] gdal2tiles.py - next step

Re: [gdal-dev] [EXTERNAL] Re: ogr2ogr does not convert OSM polygons

[gdal-dev] WKID not set for reprojectionfrom WGS84 to GDA2020

[gdal-dev] GDAL 3.4.0 is released

Re: [gdal-dev] Motion: promote GDAL 3.4.0RC3 as final issue

15 matches

Site Navigation

Mail list logo

Footer information