Re: [gdal-dev] GDAL 3.4.0 RC1 available

[Edzer Pebesma]

This may have nothing to do with this RC but more with PROJ, but I found 
it while doing checks with R spatial packages against this RC.


With a CRS shown below, calling OGRSpatialReference->GetName() resulted 
with PROJ 8.0.1 in "UTM Zone 25, Southern Hemisphere" ; with PROJ 8.1.1 
or 8.2.0 it results in "SOURCECRS". Is this intended, or is there a 
problem with the WKT, or an issue somewhere else?


BOUNDCRS[
SOURCECRS[
PROJCRS["UTM Zone 25, Southern Hemisphere",
BASEGEOGCRS["GRS 1980(IUGG, 1980)",
DATUM["unknown",
ELLIPSOID["GRS80",6378137,298.257222101,
LENGTHUNIT["metre",1,
ID["EPSG",9001,
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433,
ID["EPSG",9122,
CONVERSION["Transverse Mercator",
METHOD["Transverse Mercator",
ID["EPSG",9807]],
PARAMETER["Latitude of natural origin",0,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8801]],
PARAMETER["Longitude of natural origin",-33,
ANGLEUNIT["degree",0.0174532925199433],
ID["EPSG",8802]],
PARAMETER["Scale factor at natural origin",0.9996,
SCALEUNIT["unity",1],
ID["EPSG",8805]],
PARAMETER["False easting",50,
LENGTHUNIT["metre",1],
ID["EPSG",8806]],
PARAMETER["False northing",1000,
LENGTHUNIT["metre",1],
ID["EPSG",8807]]],
CS[Cartesian,2],
AXIS["easting",east,
ORDER[1],
LENGTHUNIT["metre",1,
ID["EPSG",9001]]],
AXIS["northing",north,
ORDER[2],
LENGTHUNIT["metre",1,
ID["EPSG",9001],
TARGETCRS[
GEOGCRS["WGS 84",
DATUM["World Geodetic System 1984",
ELLIPSOID["WGS 84",6378137,298.257223563,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
CS[ellipsoidal,2],
AXIS["geodetic latitude (Lat)",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["geodetic longitude (Lon)",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
USAGE[
SCOPE["Horizontal component of 3D system."],
AREA["World."],
BBOX[-90,-180,90,180]],
ID["EPSG",4326]]],
ABRIDGEDTRANSFORMATION["Transformation to WGS84",
METHOD["Position Vector transformation (geog2D domain)",
ID["EPSG",9606]],
PARAMETER["X-axis translation",0,
ID["EPSG",8605]],
PARAMETER["Y-axis translation",0,
ID["EPSG",8606]],
PARAMETER["Z-axis translation",0,
ID["EPSG",8607]],
PARAMETER["X-axis rotation",0,
ID["EPSG",8608]],
PARAMETER["Y-axis rotation",0,
ID["EPSG",8609]],
PARAMETER["Z-axis rotation",0,
ID["EPSG",8610]],
PARAMETER["Scale difference",1,
ID["EPSG",8611


On 01/11/2021 17:27, Even Rouault wrote:

Hi,

I have prepared a GDAL/OGR 3.4.0 release candidate.

Pick up an archive among the following ones (by ascending size):

   https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0rc1.tar.xz
   https://download.osgeo.org/gdal/3.4.0/gdal-3.4.0rc1.tar.gz
   https://download.osgeo.org/gdal/3.4.0/gdal340rc1.zip

A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.4.0/gdalautotest-3.4.0rc1.tar.gz
   https://download.osgeo.org/gdal/3.4.0/gdalautotest-3.4.0rc1.zip

A snapshot of the documentation is at:

   https://download.osgeo.org/gdal/3.4.0/gdal340doc.zip

GDAL-GRASS plugin:

   https://download.osgeo.org/gdal/3.4.0/gdal-grass-3.4.0.tar.gz

NEWS at:

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

I'll call for a vote promoting it to final later this week if no
serious problems are reported before.

Best regards,

Even



--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081
___
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

[Rahkonen Jukka (MML)]

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 roads layer.  administrative boundaries or other lines 
were in there. More lines are in the table created by osm2pgsql than the table 
created by ogr2ogr.



it looks like ogr2ogr would produce a similar approach if it would generate the 
polygon table.



Bruce







From: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Sent: Tuesday, November 2, 2021 11:11 AM
To: Clay, Bruce mailto:bc...@infoscitex.com>>; 
gdal-dev@lists.osgeo.org 
mailto:gdal-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons



Hi,



What layers does "ogrinfo country_pbf" list? Can you reproduce the error with 
some small OSM country file from 
http://download.geofabrik.de/?

What is your operating system and GDAL version? Do you use the default 
osmconf.ini file? GDAL OSM 

Re: [gdal-dev] Gdal-dev mail archive search sites?

[Matt.Wilkie]

> Hi Matt,
>
> mail-archive seems to be working now: 
> https://www.mail-archive.com/gdal-dev@lists.osgeo.org/

Oh that's excellent, they picked up the history as far back as April 2020 as 
well!

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

Re: [gdal-dev] current geolocation array implementation status

[Even Rouault]

Frederico,

Le 01/11/2021 à 23:22, Frederico Liporace a écrit :

Hello,

I'm debugging an artifact that I encountered while using geolocation arrays:
https://github.com/OSGeo/gdal/issues/4707

While searching I found this ticket mentioning that the backward map
implementation is broken and a new implementation is being considered:
https://trac.osgeo.org/gdal/ticket/6959

I could help with this implementation. Is there more context available
on why it is being reconsidered? It seems to me that the general case
for the backward implementation is very hard - for instance, what kind
of discontinuities (gaps, overlaps) would be allowed in the
geolocation array? Would it be expected to be robust enough to correct
the Landsat 7 ETM+ SLC-off for instance? My guess is not.


Yes the general case is likely hard and would probably require special 
techniques that could possibly be sensor specific. I guess the 
requirements for improvements on the existing code would be at least not 
degrade what works currently.


An idea for a new implementation would be to use an iterative process 
using the backward map as an initial guess and then iterating with the 
bilinear interpolation of the forward path to refine the solution up to 
convergence to some threshold of error to decide (could be 15% of a 
pixel size like the default setting of the gdalwarp approximate 
transformer of coordinate transformations)


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] [EXTERNAL] Re: ogr2ogr does not convert OSM polygons

[Rahkonen Jukka (MML)]

Hi,

I made a couple of quick tests with algeria-latest

ogrinfo algeria-latest.osm.pbf
INFO: Open of `algeria-latest.osm.pbf'
  using driver `OSM' successful.
1: points (Point)
2: lines (Line String)
3: multilinestrings (Multi Line String)
4: multipolygons (Multi Polygon)
5: other_relations (Geometry Collection)

ogr2ogr -f GPKG algeria.gpkg algeria-latest.osm.pbf
0...10...20...30...40...50...60...70...80...90...100 - done.

ogrinfo algeria.gpkg multipolygons -so
INFO: Open of `algeria.gpkg'
  using driver `GPKG' successful.

Layer name: multipolygons
Geometry: Multi Polygon
Feature Count: 725379

There are multipolygons in the data and ogr2ogr can convert them into 
"multipolygons" when the target is GeoPackage. Repeat the test. If you get the 
same result the issue must have a connection to PostGIS. If you get a different 
result then there is something else.  By GDAL is from gisinternals.com, version 
3.4.0dev.

-Jukka Rahkonen-

Lähettäjä: Clay, Bruce 
Lähetetty: tiistai 2. marraskuuta 2021 18.19
Vastaanottaja: Rahkonen Jukka (MML) 
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 roads layer.  administrative boundaries or other lines 
were in there. More lines are in the table created by osm2pgsql than the table 
created by ogr2ogr.

it looks like ogr2ogr would produce a similar approach if it would generate the 
polygon table.

Bruce



From: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Sent: Tuesday, November 2, 2021 11:11 AM
To: Clay, Bruce mailto:bc...@infoscitex.com>>; 
gdal-dev@lists.osgeo.org 
mailto:gdal-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons


Hi,



What layers does "ogrinfo country_pbf" list? Can you reproduce the error with 
some small OSM country file from 
http://download.geofabrik.de/?

What is your operating system and GDAL version? Do you use the default 
osmconf.ini file? GDAL OSM driver and osm2pgsql are creating quite different 
database schemas so they are not very comparable.



-Jukka Rahkonen-



Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Clay, Bruce
Lähetetty: tiistai 2. marraskuuta 2021 16.22
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] ogr2ogr does not convert OSM polygons



When I convert a OSM pbf file to postgres using the following script it does 
not create a multipolygon table



ogr2ogr -f PostgreSQL PG:"dbname='open_street_map' host='db-host' port='5432' 
user='postgres' password='pwd'" -lco schema=country country_pbf  --config 
OSM_MAX_TMPFILE_SIZE 1024



When I do the same thing using osm2pgsql (shown below) it creates the polygon 
table but not the other_relations table



osm2pgsql -H hostname -U postgres -d open_street_map 
--output-pgsql-schema=country --create --latlong -G --hstore 
--tag-transform-script 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.lua -C 2500 
--number-processes 5 -S 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.style 
country-latest.osm.pbf.



I did not see this problem when I Googled.



Is this a known issue and is there a work around?



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

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

[Rahkonen Jukka (MML)]

Hi,

What layers does "ogrinfo country_pbf" list? Can you reproduce the error with 
some small OSM country file from http://download.geofabrik.de/?
What is your operating system and GDAL version? Do you use the default 
osmconf.ini file? GDAL OSM driver and osm2pgsql are creating quite different 
database schemas so they are not very comparable.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Clay, Bruce
Lähetetty: tiistai 2. marraskuuta 2021 16.22
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] ogr2ogr does not convert OSM polygons

When I convert a OSM pbf file to postgres using the following script it does 
not create a multipolygon table

ogr2ogr -f PostgreSQL PG:"dbname='open_street_map' host='db-host' port='5432' 
user='postgres' password='pwd'" -lco schema=country country_pbf  --config 
OSM_MAX_TMPFILE_SIZE 1024

When I do the same thing using osm2pgsql (shown below) it creates the polygon 
table but not the other_relations table

osm2pgsql -H hostname -U postgres -d open_street_map 
--output-pgsql-schema=country --create --latlong -G --hstore 
--tag-transform-script 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.lua -C 2500 
--number-processes 5 -S 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.style 
country-latest.osm.pbf.

I did not see this problem when I Googled.

Is this a known issue and is there a work around?

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

[gdal-dev] ogr2ogr does not convert OSM polygons

[Clay, Bruce]

When I convert a OSM pbf file to postgres using the following script it does 
not create a multipolygon table

ogr2ogr -f PostgreSQL PG:"dbname='open_street_map' host='db-host' port='5432' 
user='postgres' password='pwd'" -lco schema=country country_pbf  --config 
OSM_MAX_TMPFILE_SIZE 1024

When I do the same thing using osm2pgsql (shown below) it creates the polygon 
table but not the other_relations table

osm2pgsql -H hostname -U postgres -d open_street_map 
--output-pgsql-schema=country --create --latlong -G --hstore 
--tag-transform-script 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.lua -C 2500 
--number-processes 5 -S 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.style 
country-latest.osm.pbf.

I did not see this problem when I Googled.

Is this a known issue and is there a work around?

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

Re: [gdal-dev] Gdal-dev mail archive search sites?

[Jeff McKenna]

Hi Matt,

mail-archive seems to be working now: 
https://www.mail-archive.com/gdal-dev@lists.osgeo.org/


-jeff



On 2021-11-01 3:31 p.m., matt.wil...@yukon.ca wrote:

 What about starting this archive?



https://marc.info/?q=about#Add


Thanks Markus,  I’ve asked MARC about adding gdal-dev.

I’ve done the same with Mail Archive[1] but the expected subscription 
confirmation doesn’t show up[2], though there is one dating back to 
2008[3]. Maybe the old one is getting in the way?


[1]: https://www.mail-archive.com/faq.html#newlist 



[2]: https://www.mail-archive.com/archive@mail-archive.com/maillist.html 



[3]: https://www.mail-archive.com/archive@mail-archive.com/msg16721.html 



I will follow up with gdal-dev-owner.

-Matt//


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




--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Hi: Bug report gdal_translate

[Rahkonen Jukka (MML)]

Hi,

I believe that you have found a bug in the Surfer documentation. You can see 
value 1.70141e+38, that is the maximum single precision float, used in for 
example
https://support.goldensoftware.com/hc/en-us/articles/226806408-How-do-I-make-all-Z-values-above-or-below-a-certain-threshold-value-transparent-in-Surfer-?mobile_site=false
 

The GDAL AAIGRID driver does not seem to have a default value for nodata 
https://gdal.org/drivers/raster/aaigrid.html. The driver copies the nodata from 
the source dataset if it exists 
https://github.com/OSGeo/gdal/blob/master/frmts/aaigrid/aaigriddataset.cpp#L1275.
 There is some nodata handling in the code:
// Cast to float and back for make sure the NoData value matches
// that expressed by a float value.  Clamps to the range of a float
// if the value is too large.  Preserves +/-inf and NaN.

Maybe there should be a default nodata value, - 
https://www.loc.gov/preservation/digital/formats/fdd/fdd000421.shtml
"Cells without actual values can be assigned a NoData value. The default value 
for NoData is - but a different value can be specified in the header as 
shown in example below."

I read the comment "NoData values appear as 1.71041e38" from 
http://surferhelp.goldensoftware.com/topics/ascii_grid_file_format.htm so that 
it is the value how nodata appears in Surfer. You can test it by creating some 
ASCII grid files with different nodata values and opening them with Surfer. 
Commands would look like this "gdal_translate -of AAIGRID -a_nodata -99".

There may be a bug in theAAIGRID driver if the nodata in your source data and 
the nodata transferrer into ASCII grid files are different. Check the nodata 
values with gdalinfo. If nodata remains the same there is no bug. If you have 
1.71041E+38 as nodata in your source data, what it the format and bit depth of 
the data?

-Jukka Rahkonen-
 
-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Dr. Felix 
Tritschler
Lähetetty: tiistai 2. marraskuuta 2021 8.32
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Bug report gdal_translate

Hello,

I stumbled across what appears to me as an typo in the gdal_translate function 
implemented in QGIS 3.18.2.
I performed a translation from a geotiff to a surfer (non-binary) .grd file 
without a specification of a NODATA-Value.

In the resulting .grd-file the NODATA value was 1.70141E+38.
But according to
http://surferhelp.goldensoftware.com/topics/ascii_grid_file_format.htm
the correct NODATA value for this filetype has to be 1.71041E+38.

I don't feel skilled enough to fix this bug on my own (even don't know if I 
could do this =o), so please feel free to check and fix if necessary.

Cheers
Felix

___
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] Bug report gdal_translate

[Dr. Felix Tritschler]

Hello,

I stumbled across what appears to me as an typo in the gdal_translate 
function implemented in QGIS 3.18.2.
I performed a translation from a geotiff to a surfer (non-binary) .grd 
file without a specification of a NODATA-Value.


In the resulting .grd-file the NODATA value was 1.70141E+38.
But according to 
http://surferhelp.goldensoftware.com/topics/ascii_grid_file_format.htm

the correct NODATA value for this filetype has to be 1.71041E+38.

I don't feel skilled enough to fix this bug on my own (even don't know 
if I could do this =o), so please feel free to check and fix if necessary.


Cheers
Felix

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