Re: [gdal-dev] Issues specifying PostGIS connection details - possibly related to special characters in passwords?
Hi, Hmm, I’m sure I tried escaping it before - but putting a \ in front of it fixed it - obviously I didn’t try properly before. Possibly I only tried quoting it in various ways. Thanks for the solution! Now the thing I’m intrigued about is why it was working with the postgresql:// connection string but not the PG connection string… Best regards, Robin On 2 July 2024 at 17:08:18, Daniel Evans (daniel.fred.ev...@gmail.com) wrote: Hi Robin, Is this a shell issue, rather than a GDAL one? The dollar sign makes me suspect that a Unix shell is interpreting "robin$42" as "the string 'robin' and the value of variable $42" before it gets into GDAL. My terminal would interpret it as the following: $ echo robin$42 robin and I'd need to escape the dollar symbol to get the text verbatim: $ echo robin\$42 robin$42 Cheers, Daniel On Tue, 2 Jul 2024 at 16:35, Robin Wilson via gdal-dev wrote: Hi, I’m using ogr2ogr to load a GeoPackage file into a PostGIS database. I initially tried using a command like this: ogr2ogr --debug ON -f PostgreSQL PG:"host= user= password=robin$42 dbname=data sslmode=require" file.gpkg -nln table_name However, this doesn’t work, and I always get an error: FATAL: password authentication failed for user “" If I restructure the command to use the alternative postgresql:// connection string like this, then it works: ogr2ogr --debug ON -f PostgreSQL 'postgresql://:robin$42@/data?sslmode=require’ file.gpkg -nln table_name I don’t remember running into this problem before when connecting to PostGIS databases using the PG: connection string, so I’m wondering whether my shell is doing something strange with my password? Obviously I don’t want to share my actual password, but it has a $ in it, and I wonder whether somehow this is causing problems - but only when using the PG: connection string. Any suggestions welcome, Best regards, Robin Dr Robin Wilson www.rtwilson.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] Issues specifying PostGIS connection details - possibly related to special characters in passwords?
Hi, I’m using ogr2ogr to load a GeoPackage file into a PostGIS database. I initially tried using a command like this: ogr2ogr --debug ON -f PostgreSQL PG:"host= user= password=robin$42 dbname=data sslmode=require" file.gpkg -nln table_name However, this doesn’t work, and I always get an error: FATAL: password authentication failed for user “" If I restructure the command to use the alternative postgresql:// connection string like this, then it works: ogr2ogr --debug ON -f PostgreSQL 'postgresql://:robin$42@/data?sslmode=require’ file.gpkg -nln table_name I don’t remember running into this problem before when connecting to PostGIS databases using the PG: connection string, so I’m wondering whether my shell is doing something strange with my password? Obviously I don’t want to share my actual password, but it has a $ in it, and I wonder whether somehow this is causing problems - but only when using the PG: connection string. Any suggestions welcome, Best regards, Robin Dr Robin Wilson www.rtwilson.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Hanging (or very slow) when ogr2ogr appending to PostGIS table
Hi, I’ve been using ogr2ogr to import vector datasets into PostGIS tables. I originally tried this using a local Postgres server, and ran the following commands to import one file into a PostGIS table, and then append the contents of another file to the same table: ogr2ogr --debug ON -f PostgreSQL PG:”host=localhost user=postgres password=blah dbname=test_db" buildings1.gpkg -nln ogr_test ogr2ogr -append -update --debug ON -f PostgreSQL PG:”host=localhost user=postgres password=blah dbname=test_db" buildings2.gpkg -nln ogr_test This works fine, and both commands run quickly. I then tried the same thing, but with a PostGIS server hosted on Azure. Obviously I expect things to take longer when accessing across the internet, but this time the first command completed quickly, but the second command seems to hang. Looking at the debug output, it shows: GPKG: GeoPackage v1.2.0 GDAL: GDALOpen(buildings2.gpkg, this=0x131011800) succeeds as GPKG. PG: Client encoding: 'UTF8' PG: PostGIS schema: 'public' PG: PostgreSQL version string : 'PostgreSQL 15.4 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit' PG: PostGIS version string : '3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1' GDAL: GDALOpen(PG:, this=0x140f25850) succeeds as PostgreSQL. PG: Primary key name (FID): fid, type : int4 PG: Using column 'fid' as FID for table 'ogr_test' OGR2OGR: Using WriteArrowBatch() and then nothing else. I’m intrigued as to why it seems to hang, and what it is doing, or trying to do. I’ve tried adding buildings2.gpkg to a new table on the Azure PostGIS server and it completes very quickly, so it’s not just that buildings2 is larger and takes a long time to upload. Similarly, merging the two buildings files with ogrmerge.py and then running the ogr2ogr command to import to PostGIS also works, and runs quickly. I’m also intrigued as to why this only seems to be happening with the Azure server - is there some configuration option I need to set? I’ve tried connecting as the ‘postgres’ root user, so it shouldn’t be a permissions issue. Any ideas or suggestions of things to try? Any help gratefully received, Best regards, Robin___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Trouble reprojecting feature that crosses antimeridian
Thank you everyone for the responses, and Even for the bug fix.
Best regards,
Robin
On 29 March 2022 at 22:33:49, Even Rouault (even.roua...@spatialys.com) wrote:
Was a bug. Fix queued in https://github.com/OSGeo/gdal/pull/5543
Le 29/03/2022 à 22:30, Robin Wilson a écrit :
Hi,
I’ve been running into problems creating STAC items for images that cross the
antimeridian. The geometries for the images are coming out as spanning the
width of the whole world (from -180 to +180 degrees). With the help of the
author of the tool I was using to create the STAC items (rio-stac), I’ve
narrowed it down to a simple test case of reprojecting geometries (which is
what the tool is doing internally).
If you put the following GeoJSON for an antimeridian-crossing polygon in WGS 84
/ UTM zone 1N in a file called test_32601.geojson:
```
{"type":"Polygon","coordinates":[[[377120,7577600],[418080,7577600],[418080,7618560],[377120,7618560],[377120,7577600]]]}
```
and then run the following:
```
ogr2ogr -f GeoJSON -s_srs epsg:32601 -t_srs epsg:4326 out_4326.geojson
test_32601.geojson
```
The contents of the output file will be:
```
{ "type": "Polygon", "coordinates": [ [ [ -179.018099960087909,
68.666857319910392 ], [ -178.985579869598382, 68.299719485120988 ], [
-179.976982644969041, 68.284942315413858 ], [ 179.974309855567753,
68.651801088224246 ], [ 180.0, 68.652259945574556 ], [ 180.0,
68.652259945541758 ], [ 180.0, 68.652259944541754 ], [ -180.0,
68.652259944541754 ], [ -180.0, 68.652259945541758 ], [ -180.0,
68.652259945610126 ], [ -179.018099960087909, 68.666857319910392 ] ] ] }
```
In that output geometry there are longitudes of 180 and -180, so when plotted
on a map it spans the whole width of the world.
The author of the rio-stac library did a PR to try and fix this problem
(https://github.com/developmentseed/rio-stac/pull/30), but it doesn’t seem to
have fixed it for this example, as the underlying GDAL code used by his library
(through rasterio, I believe) is giving this result.
I find this result unexpected, but I have no knowledge of how GDAL deals with
the antimeridian. Is this to be expected, or is this potentially a bug? If it
isn’t a bug, is there any way around this?
Best regards,
Robin
Dr Robin Wilson
www.rtwilson.com
___
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] Trouble reprojecting feature that crosses antimeridian
Hi,
I’ve been running into problems creating STAC items for images that cross the
antimeridian. The geometries for the images are coming out as spanning the
width of the whole world (from -180 to +180 degrees). With the help of the
author of the tool I was using to create the STAC items (rio-stac), I’ve
narrowed it down to a simple test case of reprojecting geometries (which is
what the tool is doing internally).
If you put the following GeoJSON for an antimeridian-crossing polygon in WGS 84
/ UTM zone 1N in a file called test_32601.geojson:
```
{"type":"Polygon","coordinates":[[[377120,7577600],[418080,7577600],[418080,7618560],[377120,7618560],[377120,7577600]]]}
```
and then run the following:
```
ogr2ogr -f GeoJSON -s_srs epsg:32601 -t_srs epsg:4326 out_4326.geojson
test_32601.geojson
```
The contents of the output file will be:
```
{ "type": "Polygon", "coordinates": [ [ [ -179.018099960087909,
68.666857319910392 ], [ -178.985579869598382, 68.299719485120988 ], [
-179.976982644969041, 68.284942315413858 ], [ 179.974309855567753,
68.651801088224246 ], [ 180.0, 68.652259945574556 ], [ 180.0,
68.652259945541758 ], [ 180.0, 68.652259944541754 ], [ -180.0,
68.652259944541754 ], [ -180.0, 68.652259945541758 ], [ -180.0,
68.652259945610126 ], [ -179.018099960087909, 68.666857319910392 ] ] ] }
```
In that output geometry there are longitudes of 180 and -180, so when plotted
on a map it spans the whole width of the world.
The author of the rio-stac library did a PR to try and fix this problem
(https://github.com/developmentseed/rio-stac/pull/30), but it doesn’t seem to
have fixed it for this example, as the underlying GDAL code used by his library
(through rasterio, I believe) is giving this result.
I find this result unexpected, but I have no knowledge of how GDAL deals with
the antimeridian. Is this to be expected, or is this potentially a bug? If it
isn’t a bug, is there any way around this?
Best regards,
Robin
Dr Robin Wilson
www.rtwilson.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] wrapper_GDALWarpDestName returned NULL without setting an error - from Python gdalwarp interface
Hi,
I'm very much enjoying the new feature in GDAL that gives programmatic access
to the command-line tools. However, I've run into a problem using gdal.Warp
from within Python.
In the example IPython session below, you can see that I try to run gdal.Warp
and get an error, but using the equivalent parameters for the command-line (run
with the ! at the beginning from within IPython), it works fine.
In [15]: gdal.Warp('data.vrt', 'robin2.tif', srcSRS = 'EPSG:4326', dstSRS =
'EPSG:27700', geoloc=True)
---
SystemError Traceback (most recent call last)
in ()
> 1 gdal.Warp('data.vrt', 'robin2.tif', srcSRS = 'EPSG:4326', dstSRS =
'EPSG:27700', geoloc=True)
/Users/robin/anaconda3/lib/python3.5/site-packages/osgeo/gdal.py in
Warp(destNameOrDestDS, srcDSOrSrcDSTab, **kwargs)
547
548 if _is_str_or_unicode(destNameOrDestDS):
--> 549 return wrapper_GDALWarpDestName(destNameOrDestDS, srcDSTab,
opts, callback, callback_data)
550 else:
551 return wrapper_GDALWarpDestDS(destNameOrDestDS, srcDSTab, opts,
callback, callback_data)
SystemError: returned NULL without
setting an error
In [16]: !gdalwarp data.vrt robin2.tif -geoloc -s_srs "EPSG:4326" -t_srs
"EPSG:27700"
Creating output file that is 1240P x 1162L.
Processing input file data.vrt.
0...10...20...30...40...50...60...70...80...90...100 - done.
Am I doing something wrong here in how I set the parameters for the gdal.Warp
call?
Thanks,
Robin
Dr Robin Wilson
Research Fellow
University of Southampton, UK
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
