Syncing Invalid Postgis Geometries with SymmetricDS - postgresql

My SymmetricDS 3.9.2 implementation syncs databases with postgis (2.2.2) geometry on a daily basis. There is invalid postgis geometry in some of the tables. When this data with a geometry column is moved, SymmetricDS gets an error while trying to convert the geometry data from EWKT back into geometry.
For example: failed: ERROR: geometry requires more points
Hint: "...G(268676.801767248 5977299.18090558)" <-- parse error at position 56 within geometry
Is there a way to sync the geometry without writing it to well known text and then converting it back into geometry?
-- this will fail because there is not enough data for a line, however, I don't want it to ever encounter this issue, I just want it to move the invalid geometry.
SELECT ST_GeomFromText('SRID=3401;LINESTRING(152735.018168789 6064398.3443075)');
Below is a geometry. Could we sync it like this so we do not care if it is invalid?
"01060000A0490D00000100000001030000800100000006000000763A90954362EC40C458D64A116056410000000000000000212DA53A9462EC40BB0CB3CF07605641000000000000000073EC95C3F267EC40DCAA4ADDE05F56410000000000000000BF4F7D4B3F74EC407A48E55CE45F56410000000000000000D409C190AF73EC40F052FA69116056410000000000000000763A90954362EC40C458D64A116056410000000000000000"

Related

ST_TRANSFORM not working correctly with non-standert srid

I have two tables with geometry data. One table has MULTIPOLYGON geometry in non-standard srid and another has POINT geometry in 4326. I have a spatial_ref_sys table with a correct description for my srid. Then I want to use st_contains for geometry from these tables. I use st_transform to convert geometry from one table to srid from another, but the function returns geometry under Africa (all geometry is on the territory of Europe). Also, I want to admit that I use proj description from QGIS, and in this program, all works correctly. I use PostGIS 3.2. Here is my code for st_contains:
select st_contains(st_transform(geom_multipolygon_in_4326, SRID_from_another_table), geom_point_in_non_standart_srid);
Here is my proj:
+proj=tmerc +lat_0=0 +lon_0=30 +k=1 +x_0=-10000 +y_0=-5540000 +ellps=krass +towgs84=23.92,-141.27,-80.9,0,0.35,0.82,-0.12000000004786 +units=m +no_defs
However, when I use PostGIS 2.2 all works correctly with an identical proj description. I don't understand what the problem is. Maybe someone can help me, because I only found a solution by creating a layer in qgis and then importing it into the database, but this is not a solution for me, because the point geometry is formed through a query to Google and I still need to transform it using st_transform.

PostGIS latitude incorrect when storing a linestring

I am attempting to store a LINESTRING using PostGIS into a column of type geography(LINESTRING, 4326). Here is my insert statement:
INSERT into routes (line) VALUES (st_linefromtext('LINESTRING(-35.3350743932 149.084182978,-35.3350306311 149.085041285)', 4326));
But when I run a query to get the line back out of the database.
SELECT st_astext(line) from routes;
Result:
LINESTRING(-35.3350743932 30.915817022,-35.3350306311 30.914958715)
The latitude coordinates come out completely differently from how I inputted them. Can anyone point out to me why this would be?
I am new to PostGIS - I think I must be missing something about the storage and retrieval of 4326 data. Any help appreciated.

Get PostGIS geometry field on Drill

I have a table with a geometry column and if I query it using PostGIS, it shows the records right:
PostGIS query image:
The problem is when I execute the query using Apache Drill, because it shows all the records fine except the geometry one, it shows as null.
Drill query image:
Reviewing the logs, it shows the following error:
WARN o.a.d.e.store.jdbc.JdbcRecordReader - Ignoring column that is
unsupported. org.apache.drill.common.exceptions.UserException:
UNSUPPORTED_OPERATION ERROR: A column you queried has a data type that
is not currently supported by the JDBC storage plugin. The column's
name was geom_multipolygon and its JDBC data type was OTHER
I tested creating the Drill storage plugin with postgis-jdbc-2.2.1.jar and postgresql-42.1.4.jar but the same error is shown.
If I use:
cast(geom_multipolygon as varchar(255))
it shows the varchar representation of the geometry, another option is getting the MULTIPOLYGON text and transform to Drill binary using ST_GeomFromText(geom), but we need the binary format directly from PostGIS, so those approaches can't be done.
We have seen this page: https://github.com/k255/drill-gis/issues/1 but the proposed solution doesn't work for us, so I think there is a way to achieve this.
UPDATE: I finally found the way that Drill can show the geo fields, is to change the data type in PostGIS from geometry to bytea. It seems to be a compatibility issue. With this way, we can perform geospatial queries on Drill, but in PostGIS those fields are no longer geometries, so they can not be indexed and treated as such.

ogr2ogr producing different results on different system

I'm trying to convert the shape file which represents the administrative area of Philippines into geojson. I'm getting the shape file from here . The file I'm trying to convert is this PHL_adm3.shp .
I'm using this bash script:
function shp2geojson() {
ogr2ogr -f GeoJSON "$1.geojson" "$1.shp"
}
for var in *.shp; do shp2geojson ${var%\.*}; done
I ran this script on my server and got the corresponding geojson file. Now I ran the same script on my local and the geometry for many cities were different in my local than what was on my server. Though the coordinates do not differ much, they only differ after 6-7 places of decimal, but they throw an exception when I try to insert them in PostGIS.
Here's an example of the geometry that is producing error on server while inserting it in PostGIS. I'm also posting the geometry that I'm getting on my local of the same city.
Server: Geometry
Local: Geometry
I also ran ST_IsValidReason on both geometries. I got the following error on my server.
SELECT ST_IsValidReason(ST_SetSRID(
ST_GeomFromGeoJSON(my_geometry),4326))
Server : Error [('Self-intersection[120.979159 14.71218]',)]
Local : [('Valid Geometry',)]
I tried the exact same thing on different countries like India, Japan Thailand and for all those countries that I tested, the same thing was happening. On local I didn't found any error but on my server I was getting Invalid geometry.
Can anyone explain what's wrong with my queries and how to fix this ?
P.S.- Both of my systems are 64 bit and running Ubuntu 14.04.

PostGIS geography query returns a string value

I have a strange issue. The lonlat column on my app works well on the development server –– its output is in the form of POINT(X Y). But when I move the data to the production server, the output is strange!
ActionView::Template::Error (undefined method `lon' for "0101000020E6100000541B9C887E7A52C02920ED7F80614440":String):
The lonlat value, which is encoded with SRID: 4326, is being read as a string. I am almost certain that there was a corruption in the data during migrating it from development to production because this was not a problem before the migration.
Does anyone know what about the database schema or column may cause this issue?
A geometry field stores its data as WKB. To see the WKT representation you need to change your query to something like
select ST_Astext(the_geom) as geometry from table
However, I don't know why in your development you have some kind of implicit conversion between WKB binary data and WKT strings. ¿What version of postgres and postgis are you using?
What lang is in your app server?
Is that ActiveRecord you're using?
I suggest you try something like
float ST_X(geometry a_point);
To make sure you can read the data properly and determinate if problem is on the data field or somewhere else.
I also would try doing the pg_dump in a single step if you determinate the problem is with the geometry column.
You can use pg_dump with option
--exclude-table-data=reg_expresion_ _tablename_
--exclude-table-data=schema.reg_expresion_ _tablename_
This will bring all the schema definition, but exclude the table data and bring only the data from table you need.
Turns out that when I killed the connection to the server to migrate the data, Rails did not set the schema search path (meaning didn't discover the postgis extension) upon reconnecting. I had to restart the server to solve this problem.