I have a database that was using postgis 2.2.1 extension on postgresql 9.5 database on server A. But, recently I have upgraded this to 2.5.5 and copied this database to new server B which also has postgis 2.5.5. Result of Postgis_full_version() on A is:
POSTGIS="2.5.5" [EXTENSION] PGSQL="95" GEOS="3.7.1-CAPI-1.11.1 27a5e771" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 1.11.3, released 2015/09/16" LIBXML="2.9.3" LIBJSON="0.11.99" LIBPROTOBUF="1.2.1" RASTER
and same for server B is:
POSTGIS="2.5.5" [EXTENSION] PGSQL="95" GEOS="3.8.0-CAPI-1.13.1 " PROJ="Rel. 6.3.1, February 10th, 2020" GDAL="GDAL 3.0.4, released 2020/01/28" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" RASTER
On server B, the database is throwing error when using ESPG 27200 in ST_transform queries but working for other ESPG projections.
For example, when I am executing query:
select st_asText(st_transform(st_geomfromtext('POINT(172 -43)', 4326), 27200));
I am getting this error:
NOTICE: PostGIS was unable to transform the point because either no grid shift files were found, or the point does not lie within the range for which the grid shift is defined. Refer to the ST_Transform() section of the PostGIS manual for details on how to configure PostGIS to alter this behaviour.
ERROR: transform: couldn't project point (172 -43 0): failed to load datum shift file (-38)
SQL state: XX000
Difference between server A and server B config is A is running on GDAL 1.11
I am a newbie to postgresql and postgis, so I am not sure how to fix the problem.
Related
I have 4 servers with the same versions of OS (Ubuntu 20.04), Postgis and Postgre:
POSTGIS="3.2.1 5fae8e5" [EXTENSION] PGSQL="130" GEOS="3.10.1-CAPI-1.16.0" PROJ="6.3.1" LIBXML="2.9.10" LIBJSON="0.13.1" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)"
PostgreSQL 13.6 (Ubuntu 13.6-1.pgdg20.04+1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, 64-bit
The query below works on any server except one:
`
SELECT
st_asgeojson(st_transform("table-name".geom, 4326)) AS way
FROM "table-name"
`
The server with the issue responds this error:
SQL Error [XX000]: ERROR: could not form projection (LWPROJ) from 'srid=7801' to 'srid=4326'
I upgraded the postgis server to 3.3.2 but the result is the same.
Can you help me?
I recently ran a full update on my Manjaro-System, afterwards, when I tried to run a small script I use to start and automatically save my Postgres-DB I get the following error in the shell.
pg_dump: error: query failed: ERROR: could not load library
"/usr/lib/postgresql/postgis-3.so": /usr/lib/postgresql/postgis-3.so:
undefined symbol: list_make1_impl
pg_dump: error: query was:
SELECT
a.attnum,
a.attname,
a.atttypmod,
a.attstattarget,
a.attstorage,
t.typstorage,
a.attnotnull,
a.atthasdef,
a.attisdropped,
a.attlen,
a.attalign,
a.attislocal,
pg_catalog.format_type(t.oid, a.atttypmod) AS atttypname,
a.attgenerated,
CASE WHEN a.atthasmissing AND NOT a.attisdropped THEN a.attmissingval ELSE null END AS attmissingval,
a.attidentity,
pg_catalog.array_to_string(ARRAY(SELECT pg_catalog.quote_ident(option_name) || ' ' || pg_catalog.quote_literal(option_value) FROM pg_catalog.pg_options_to_table(attfdwoptions) ORDER BY option_name), E',
') AS attfdwoptions,
CASE WHEN a.attcollation <> t.typcollation THEN a.attcollation ELSE 0 END AS attcollation,
array_to_string(a.attoptions, ', ') AS attoptions
FROM pg_catalog.pg_attribute a LEFT JOIN pg_catalog.pg_type t ON a.atttypid = t.oid
WHERE a.attrelid = '18597'::pg_catalog.oid AND a.attnum > 0::pg_catalog.int2
ORDER BY a.attnum
Also, when I start the database in pgAdmin I can open all the tables except the one which holds the geography-column, which needs PostGIS. It shows me the following error instead:
ERROR: could not load library /usr/lib/postgresql/postgis-3.so: /usr/lib/postgresql/postgis-3.so: undefined symbol: list_make1_impl SQL state: 58P01
Apparently something in the proj-package is messed up. According to this thread, it could have something to do with this package being installed several times. However, I reinstalled proj manually, from the Official Repo as well as from the AUR each time with a different version and cleaned the old version every time. The error is still there.
Currently the version setup is:
QGIS: Version 3.16.5
Postgres: Version 12.6-1
PostGIS: Version 3.0.3-1
proj: Version 6.3.2-1
Manjaro: KDE-Plasma 5.21.3
Kernel: 4.19.183-1-Manjaro
Does anyone have a solution for this?
Thanks to the local Linux User Group I found a solution to the problem. It turned out, that PostGIS was updated in the background and the new version did not correspond with PostgreSQL 12.6 any more. Since PostGIS was already installed, it did not show me this but the error message above instead.
To check if PostGIS is still compatible with PostgreSQL, I create a new database and then tried to add the PostGIS extension. I got the following message, that cleared things up:
test=# CREATE EXTENSION postgis;
ERROR: could not open extension control file "/usr/share/postgresql/extensionpost.control": No such file or directory
test=# CREATE EXTENSION postgis;
ERROR: PostGIS built for PostgreSQL 13.0 cannot be loaded in PostgreSQL 12.6
So I updated PostgreSQL, set up a new database cluster and used pg_restore on the last .sql from my automatic pg_dump to recreate the database. It now works as before again.
I set up a connection to a Hive server using the Hortonworks ODBC Driver for Apache Hive. Version info is below:
OS: Windows Server 2012 R2 Standard
Hive: 1.2.1000.2.6.5.4-1
Hadoop: 2.7.3.2.6.5.4-1
Hortonworks ODBC Driver for Apache Hive
ODBC Version: 03.80
Driver Version: 2.1.12.1017
Bitness: 64-bit
Locale: en_US
I can run the queries below using the connector that I configured in Teradata SQL Assistant with no issues. I set up my DSN as a linked server in SSMS. However, when I attempt to run the queries in SSMS using openquery, I have some issues. Info on my SQL Server is below:
Microsoft SQL Server 2016 (SP2-CU3) (KB4458871) - 13.0.5216.0 (X64) Sep 13 2018 22:16:01 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 <X64> (Build 9600: ) (Hypervisor)
Here is some info on the table that I am querying:
Table Name: instrumentapps_event
Using OPENQUERY, I am capable of querying the Hive DB through SSMS with the following query:
SELECT * FROM OPENQUERY(KMhivehttp, 'select * from dmfwk_gold.instrumentapps_event')
The above query returns the contents of the desired table. However, the query below produces an error:
SELECT * FROM OPENQUERY(KMhivehttp, 'select * from dmfwk_gold.instrumentapps_event WHERE to_date(from_unixtime(UNIX_TIMESTAMP(load_ts,''yyyy/MM/dd''))) >= to_date(''2019-03-01'')')
The error is as follows:
Msg 7355, Level 16, State 1, Line 1
The OLE DB provider "MSDASQL" for linked server "KMhivehttp" supplied inconsistent metadata for a column. The name was changed at execution time.
How can I fix this?
While I'm unsure how to fix the problem that I previously faced (I suspect it to be a bug with the Hortonworks ODBC driver), I did discover a workaround.
Instead of running:
SELECT * FROM OPENQUERY(KMhivehttp,
'SELECT *
FROM dmfwk_gold.instrumentapps_event
WHERE to_date(from_unixtime(UNIX_TIMESTAMP(load_ts,''yyyy/MM/dd''))) >=
to_date(''2019-03-01'')
')
I now use:
SELECT * FROM OPENQUERY(KMhivehttp, 'select * from dmfwk_gold.instrumentapps_event')
WHERE load_ts >= CAST('2019-03-01' AS DATE);
This allows me to avoid any metadata errors.
I recently upgraded my Amazon PostgreSQL RDS to version 10.3 but while fetching the projections I am getting error:
ERROR: transform_geom: couldn't parse proj4 output string: '3857': projection not named
CONTEXT: SQL function "st_transform" statement 1
Same records i am able to fetch prior to version 9.5.xx
My PostGIS version is 2.4.2 which is compatible to RDS intance.
I perhaps faced the same problem after upgrading from postgis 2.2 to 2.3, some of my queries did no work anymore.
Old-query:
SELECT ST_X(ST_TRANSFORM(ST_SETSRID(ST_MAKEPOINT($1,$2),$3),$4));
query-params $1...$4:
602628,6663367,3857,3857
error message:
"transform_geom: couldn't parse proj4 output string: '3857': projection not named"
Reason:
ST_TRANSFORM comes in multiple flavours, two of them:
public.st_transform(geometry, integer)
public.st_transform(geometry, text)
Latter one, I assume new in postgis 2.3, caused my problem, because $4 (3857) was regarded as (proj4-) string and not as (SRID-) integer.
Workaround in my case: type-hint for param $4
SELECT ST_X(ST_TRANSFORM(ST_SETSRID(ST_MAKEPOINT($1,$2),$3),$4::int));
I am trying to generate a Liquibase change log by running the command generateChangeLog, but I get the following error:
Starting Liquibase at Fri, 20 Apr 2018 14:26:14 GMT (version 3.6.1
built at 2018-04-11 08:41:04)
Unexpected error running Liquibase:
liquibase.exception.DatabaseException:
com.ibm.as400.access.AS400JDBCSQLSyntaxErrorException: [SQL0204]
REFERENCES in SYSCAT type *FILE not found.
liquibase.exception.LiquibaseException:
liquibase.command.CommandExecutionException:
liquibase.exception.DatabaseException:
liquibase.exception.DatabaseException:
com.ibm.as400.access.AS400JDBCSQLSyntaxErrorException: [SQL0204]
REFERENCES in SYSCAT type *FILE not found.
at
liquibase.integration.commandline.CommandLineUtils.doGenerateChangeLog
(CommandLineUtils.java:279)
at liquibase.integration.commandline.Main.doMigration(Main.java:1043)
at liquibase.integration.commandline.Main.run(Main.java:191)
at liquibase.integration.commandline.Main.main(Main.java:129)
My environment is:
DB2 UDB for AS/400 version 07.01.0000 V7R1m0
AS/400 Toolbox for Java JDBC Driver 10.2
liquibase 3.6.1
Java 8
Maven 3.3.3
syscat.references is not available on Db2 for i. Actually Db2 for i doesn't have a schema named SYSCAT at all.
qsys2.syscstdep seems to be the closest match...
INFORMATION_SCHEMA is the ANSI & ISO standard name for the DB catalog schema. On Db2 for i, it is an alias for QSYS2.
Edit
From the comment by #jmarkmurphy on the OP, it appears there's an Db2 for i Liquibase extension. I don't know for sure, but I'd suspect that installing that would redirect the query to the correct Db2 for i schema & table.