Using PostgreSQL and PostGIS I get an error when using ST_OffsetCurve for some specific line geometries:
"lwgeom_offsetcurve: noded geometry cannot be offset"
Example:
SELECT ST_OffsetCurve(ST_GeomFromText('LINESTRING(288249.918098328 5615135.51135102,288293.425429089 5615086.62800628,288231.885629119 5615155.77174104,288249.918098328 5615135.51135102)'), -5.6875)
This is a closed line and the last three points are on a straight line.
PostGIS version is 3.0 on Windows.
Changing any coordinates or even just the offset value slightly removes this error.
Is it possible to prevent the error without changing numeric values?
Update to PostGIS version 3.1 solved the issue.
maybe ST_MakeValid fix this problem
https://postgis.net/docs/ST_MakeValid.html
And it is also better to pass srid as second parametr in ST_GeomFromText
SELECT ST_OffsetCurve(ST_MakeValid(ST_GeomFromText(...., your srid)), -5.6875)
Related
Background
Ubuntu 18.04
Postgresql 11.2 in Docker
pgAdmin4 3.5
Have a column named alias with type character varying[](64). Values have already been set on some rows before using psycopg2. Everything was alright then.
SQL = 'UPDATE public."mytable" SET alias=%s WHERE id=%s'
query = cursor.mogrify(SQL, ([values] , id))
cursor.execute(query)
conn.commit()
Recently, when I want to add more value using pgAdmin GUI as shown in the first figure, the error in the second figure happens, which says Argument formats can't be mixed:
Well, it turns out if insert the values using script such as psql or query tool in pgAdmin, the error does not happen, i.e., it only happens if using GUI of pgAdmin.
Example script:
UPDATE public."mytable" SET alias='{a, b}' WHERE id='myid'
But as the GUI is much easier to modify values, so really want to figure it out. Any idea?
It's a bug in pgAdmin 4.17.
It looks like it happens whenever you edit a char(n)[] or varchar(n)[] cell in a table (although char[] and varchar[] are unaffected).
It should be fixed in 4.18.
In the meantime, you can fix it yourself without much trouble. The pgAdmin4 backend is written in Python, so there's no need to rebuild anything; you can just dive in and change the source.
Find the directory where pgAdmin4 is installed, and open web/pgadmin/tools/sqleditor/__init__.py in an editor. Find the line:
typname = '%s(%s)[]'.format(
...and change it to:
typname = '{}({})[]'.format(
You'll need to restart the pgAdmin4 service for the change to take effect.
I wasn't able to get this working with the Character Varying data type but it worked once I converted the column data type to Text.
I've tried to use PostGIS to retrieve the nearby points, however,
I've gotten an error message from the pgAdmin3.
Can you help me to debug the SQL queries (Postgresql+PostGIS) below?
Thank you for your kindness help.
I've used the 3826 geometry.
"ERROR: parse error - invalid geometry
HINT: "...79721.29349234176 2759680.13418412))" <-- parse error at position 44 within geometry" in the
SELECT * FROM pointslight
WHERE ST_DWithin(
ST_Transform(ST_GeomFromText('POINT(279721.29349234176 2759680.13418412))',3826),26986),
ST_Transform(location,26986), 50)
ORDER BY ST_Distance(ST_GeomFromText('POINT(279721.29349234176 2759680.13418412))',3826), location);
In the string defining the point, you have one opening parenthesis an two closing one. Remove one of the latter!
I am currently using SQL Server 2008R2.
I am using this script:
SELECT a.productname, a.orderdate, a.workarea
FROM database1table1 AS a
WHERE a.orderdate >='2016/08/01'
Which gives the output:
PRODUCT NAME ORDER DATE WORKAREA
x 2016/08/07 NULL
y 2016/08/09 HOLDING
z 2016/08/10 ACTION
a 2016/08/12 ACTION
My problem arises when I amend the above script to read,
...
WHERE a.orderdate >='2016/08/01'
**AND a.workarea NOT IN ('HOLDING')**
When I do this, not only does it remove 'HOLDING', but it also removes the NULL rows as well, which I definitely do not want.
Please can you suggest an amendment to the script to prevent the NULLS being removed - I only want to see the value 'HOLDING' taken out.
With many thanks!
You can try a workaround
AND ISNULL(a.workarea,'') NOT IN ('HOLDING')
It will transform all null a.workarea in the "where" the "not in" works correctly
We recently switched our definitions from the first to the second format, because OpenLayers threw exceptions on the first one.
The used definitions:
Old:
proj4.defs["EPSG:28992"] = "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 +units=m +no_defs";
New:
proj4.defs("EPSG:28992", "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.040,49.910,465.840,-0.40939,0.35971,-1.86849,4.0772 +units=m +no_defs")
Strange enough, the latter one does correctly transform points. Our points seem to be misaligned, and not by a specific offset, they seem to be just wrong positioned at all. We think this is due to the towgs84 property. Question now is, how is the first format parsed/ handled differently than the secondly? What are the differences? (I am using the same code and newest version of proj4js in both occasions).
I was accidentally loading pro4j twice, once trough potree, and once manually (for openlayers). Turned out one of the two was still on version 2.2.1...
I have noticed that when we use F_RoundToEven UDF from FreeAdhocUDF, that it fails to produce a correct result with certain numbers.
For example, the query:
select
F_RoundToEven(21.145, 2) Correct,
F_RoundToEven(215.145, 2) Fail
from Rdb$Database
produces the result:
CORRECT FAIL
21.14 215.15
Obviously these two number should both resolve to .14
Has anyone else come across this problem, and perhaps found a way around it?
I am using the latest version of FreeAdhocUDF with Firebird 2.1 and it fails on both Windows 32bit and Linux 64bit.
Thanks.