I am working on windows, and have enabled the extension postgis, pgrouting on database. I have postgreSQL 9.4 installed and i am using the data from boundless workshop (http://workshops.boundlessgeo.com/tutorial-routing/).
SELECT pgr_nodeNetwork('edges',0.001,'geom','gid','noded')
when I run this query, it runs about 1minute and after that time it results in FAIL. How can I solve this issue? My pgr_createTopology query has been successfully run.
NOTICE: PROCESSING:
NOTICE: pgr_nodeNetwork('edges',0.001,'geom','gid','noded')
NOTICE: Performing checks, pelase wait .....
NOTICE: Processing, pelase wait .....
ERROR: line_locate_point: 1st arg isnt a line
CONTEXT: SQL statement "create temp table inter_loc on commit drop as ( select * from (
(select l1id, l2id, st_linelocatepoint(line,source) as locus from intergeom)
union
(select l1id, l2id, st_linelocatepoint(line,target) as locus from intergeom)) as foo
where locus<>0 and locus<>1)"
PL/pgSQL function pgr_nodenetwork(text,double precision,text,text,text) line 184 at EXECUTE statement
********** Error **********
ERROR: line_locate_point: 1st arg isnt a line
SQL state: XX000
Context: SQL statement "create temp table inter_loc on commit drop as ( select * from (
(select l1id, l2id, st_linelocatepoint(line,source) as locus from intergeom)
union
(select l1id, l2id, st_linelocatepoint(line,target) as locus from intergeom)) as foo
where locus<>0 and locus<>1)"
PL/pgSQL function pgr_nodenetwork(text,double precision,text,text,text) line 184 at EXECUTE statement
I ran into this issue in my project and I was stuck on it for hours trying to figure out what was causing it AND how to fix it. I will describe my situation and how I fixed it so hopefully, it helps someone else in the future.
I am using ogr2ogr to import a Shapefile into my database and I was using the -nlt PROMOTE_TO_MULTI as one of my arguments during my import; this caused my geometries to be imported as MultiLineStrings.
From the behavior I've observed and what others have mentioned (and more people), the pgr_nodeNetwork() function does not play nicely with MutliLineStrings.
Since MultiLineStrings won't work for routing, I took the SQL from dkastl's answer and ran it on my data to see if I actually needed MultiLineStrings or if I could just work with LineStrings.
SELECT
COUNT(
CASE WHEN ST_NumGeometries(geom) > 1 THEN 1 END
) AS multi,
COUNT(geom) AS total
FROM network_nodes;
After running that, I found that I had zero need for MultiLineStrings so I reimported my Shapefile with ogr2ogr using -nlt LINESTRING instead and then was able to run pgr_nodeNetwork() without problems.
Related
This error has just started popping when I run queries against TABLE_A .......
ERROR: XX001: invalid page in block 38 of relation pg_tblspc/16402/PG_14_202107181/16404/125828
If I try a very simple query against the same table for example SELECT * FROM TABLE_A I get a similar error....
ERROR: invalid memory alloc request size 18446744073709551613
SQL state: XX000
Or another similar query select count(*) from TABLE_A gives me....
ERROR: could not access status of transaction 917520
DETAIL: Could not open file "pg_xact/0000": No such file or directory.
SQL state: 58P01
Based on this thread I tried this fix....
SET zero_damaged_pages = on;
VACUUM full TABLE_A;
REINDEX TABLE TABLE_A;
The 2nd command, VACUUM full TABLE_A produced another related error....
ERROR: found xmax 16384 from before relfrozenxid 379279265
SQL state: XX001
I think all these problems boil down to a simple case of file corruption at the OS level. I do have the ability to drop and re-create this table, but before I start I'd like to know if there's a quicker/simpler solution, and if there's any way of stopping this from happening again.
I have a trigger that takes a line, grabs its ST_StartPoint and ST_EndPoint and then grabs the nearest point to those endpoints, and assigns a node_id to a column. This Fiddle shows the trigger as well as some example data. When running this trigger, I am getting an error on QGIS stating the following:
Could not commit changes to layer pipes
Errors: ERROR: 1 feature(s) not added.
Provider errors:
PostGIS error while adding features: ERROR: Operation on mixed SRID geometries
CONTEXT: SQL statement "SELECT
j.node_id,
i.node_id
FROM ST_Dump(ST_SetSRID(NEW.geom,2346)) dump_line,
LATERAL (SELECT s.node_id,(ST_SetSRID(s.geom,2346))
FROM structures s
ORDER BY ST_EndPoint((dump_line).geom)<->s.geom
LIMIT 1) j (node_id,geom_closest_downstream),
LATERAL (SELECT s.node_id,(ST_SetSRID(s.geom,2346))
FROM structures s
ORDER BY ST_StartPoint((dump_line).geom)<->s.geom
LIMIT 1) i (node_id,geom_closest_upstream)"
PL/pgSQL function sewers."Up_Str"() line 3 at SQL statement
I have attempted to resolve the issue by editing the trigger to this but this has not fixed the problem. Any ideas would be greatly appreciated.
The line ORDER BY ST_EndPoint((dump_line).geom)<->s.geom (and the similar one for the start point) is likely the faulty one.
You could, again, declare the CRS of s.geom. Note that by doing this any spatial index on structures would not be used, it would have to be created on ST_SetSRID(geom,2346)
The clean way would be to set the CRS at the column level on the structures table
alter table structures alter column geom TYPE geometry(point,2346) using st_setSRID(geom,2346);
I was trying to follow the PostgreSQL guide to get children from an adjacency tree on PostgreSQL 9.6. For connivence I'll reproduce the command it suggests here:
WITH RECURSIVE tree AS (
SELECT id, ARRAY[]::INTEGER[] AS ancestors
FROM test WHERE parent_id IS NULL
UNION ALL
SELECT test.id, tree.ancestors || test.parent_id
FROM test, tree
WHERE test.parent_id = tree.id
) SELECT * FROM tree WHERE 3 = ANY(tree.ancestors);
My understanding was that you simply have to replace test with the name of the table you're trying to access, and parent_id with the name of the field that contains the parent id. So I did that for all instances. However, I am getting a super vague 'Syntax error at or near ")"' when trying to run this command.
What could be the possible causes of this?
This turned out to be a problem with my SQL client, DBeaver. When I run this command in psql, it worked exactly as expected.
First I set up the dream factory by "Bitnami Installer for Windows". Following to https://github.com/dreamfactorysoftware/dsp-core/wiki/Install-Microsoft-Windows
Then I follow this add-a-rest-api-to-any-sql-db-in-minutes to add Services to my Remote Postgres Database.
On the "API Docs" tab, it is success to call the GET /db operation. ( getTables() - List all table names).
I got the following error when trying to call GET /db/{table_name} operation ( getRecordsByFilter() - Retrieve one or more records by using a filter).
Please help
[app][ERROR ] CDbCommand::fetchAll() failed: SQLSTATE[42601]: Syntax error: 7 ERROR: syntax error at or near "field_name"
LINE 1: SELECT k.column_name field_name
^. The SQL statement executed was: SELECT k.column_name field_name
FROM "information_schema"."key_column_usage" k
LEFT JOIN "information_schema"."table_constraints" c
ON k.table_name = c.table_name
AND k.constraint_name = c.constraint_name
WHERE c.constraint_type ='PRIMARY KEY'
AND k.table_name = :table
AND k.table_schema = :schema.
Please check the version of PostgreSQL you are connecting to. It turns out that omission of as keyword is supported starting from 8.4.
Here's a quote from 8.4 release notes section E.23.3.3. Queries:
Allow AS to be optional when specifying a SELECT (or RETURNING) column
output label (Hiroshi Saito)
This works so long as the column label is not any PostgreSQL keyword;
otherwise AS is still needed.
Therefore SELECT k.column_name field_name is not valid for 8.3 and below, but SELECT k.column_name AS field_name would work.
If PostgreSQL version is the cause of your problem you have several options:
update the database to 8.4 and above;
patch the Dreamfactory codebase yourself to work around this problem;
raise a ticket in Dreamfactory's bug tracker and wait them to fix it for you.
I have a PostGIS query where I really need to have nested queries inside PostGIS function calls:
UPDATE raw.geocoding
SET the_geom = ST_Centroid(
ST_Collect(
SELECT the_geom
FROM raw.geocoding
WHERE hash = ((E'0101000020090C000081610F9CC5DC3341EE672E6E723B3241')::varchar),
SELECT the_geom
FROM raw.geocoding
WHERE hash = ((E'0101000020090C00002CF887E0C5DC3341C9E5B2DF2A383241')::varchar)
)
)
WHERE hash = ((E'3e638a27c6c38f05026252f4a0b57b2e')::varchar)
Unfortunately, this doesn't work. I get a syntax error at the beginning of the nested query:
ERROR: syntax error at or near "SELECT"
LINE 4: SELECT the_geom
^
********** Error **********
ERROR: syntax error at or near "SELECT"
SQL state: 42601
Character: 86
Looks like I cannot have a nested query as a PostGIS function parameter?
I've perused through the PostGIS documentation and cannot find any clear guidance for dealing with this.
It appears Postgres has a way of doing variables in pgSQL, but it's unclear to me how this would be pulled off in a standard query. This is a query that will be run tens or hundreds of thousands of times from a C# program. That aside, I could do a pgSQL stored procedure if required; just wanted to make sure there wasn't a simpler alternative first.
In case you were wondering, the query looks messy because it's the result of a npgsql-generated parameterized query. I think it's fair to say that npgsql is being extra-cautious with redundant typing and escaping.
I am running PostGIS 2.0.1, Postgres 9.1.5, and npgsql 2.0.12.
It sounds like you want a scalar subquery, an expression written like (SELECT ....) (note enclosing parentheses) that contains a query returning either zero rows (NULL result) or one field from one row.
You were most of the way there, you just needed the parens:
UPDATE raw.geocoding
SET the_geom = ST_Centroid(
ST_Collect(
(SELECT the_geom
FROM raw.geocoding
WHERE hash = ((E'0101000020090C000081610F9CC5DC3341EE672E6E723B3241')::varchar)),
(SELECT the_geom
FROM raw.geocoding
WHERE hash = ((E'0101000020090C00002CF887E0C5DC3341C9E5B2DF2A383241')::varchar))
)
)
WHERE hash = ((E'3e638a27c6c38f05026252f4a0b57b2e')::varchar)
Note that subqueries can be used in other places too - table returning subqueries can appear in FROM, for example. The PostgreSQL manual teaches about all this, and is well worth a cover-to-cover read.
If you're doing a lot of these updates, you may find it more efficient to formulate the UPDATE as a join using the PostgreSQL extension UPDATE ... FROM ... WHERE rather than running lots of individual UPDATEs over and over. I just wanted to raise the possibility. See from-list in UPDATE