Thank you Daniel…
Yes I increased the tolerance and it sounds to be working better. I just need to make sure that
Also the multilinestrings are linestrings… so no issue in this anymore
Just for benefit of all readers; I noticed that the tolerance in both pgr_nodeNetwork and pgr_createTopology shall be equal… otherwise you lose the benefit of setting higher value for only one function of both. This somehow applies to Shortest_Path plug-in when you export the network to the canvas.
If that may not be accurate, please comment
Thanks again for your both assistance
Regards,
Eyad
From: pgrouting-users-bounces@lists.osgeo.org [mailto:pgrouting-users-bounces@lists.osgeo.org] On Behalf Of Daniel Kastl
Sent: Tuesday, December 16, 2014 5:43 AM
To: pgRouting users mailing list
Subject: Re: [pgrouting-users] Cleaning multilinestring vector network for routing via kDijkstra
Hi Eyad,
As Steve already said, multilinestrings are not really something good for pgRouting.
But often there are no real multilinestrings at all, and you can change the geometry type.
How you can test, if your network has multilinestrings and how to get rid of them (if they don’t contain mutli-geometries), see this link:
http://gis.stackexchange.com/questions/116414/take-from-multilinestring-the-start-end-points/116444#116444
Also you mentioned that your network data is in unit “millimeters”, and you run the topology function like:
Select pgr_nodeNetwork (‘schema.table’, 0.0001, ‘id’, ‘geom’)
This means, that you have a snapping tolerance of 0.0001 mm if your network is not properly digitized. I would assume that CAD data is correct, but still a snapping tolerance of 0.0001mm is so small, that you could just increase it to 1 for example, or even higher. Check, if in your network edges are really connected.
Daniel
On Tue, Dec 16, 2014 at 4:35 AM, AUS - Eyad <b00038807@aus.edu> wrote:
Thanks Steve…
I tried using st_geometryn as follows:
pgr_kdijkstraCost(
‘SELECT id, source, target, (st_length(ST_GeometryN(geom,1)) * 0.001) as
cost FROM schema.table’,
id, (SELECT array_agg(id) FROM schema.table), false, false
) as cost
from schema.table
I got exactly same results as before… Cost=“-1” which means that there is
no connection
Looking forward for further assistance ASAP
Regards,
Eyad
-----Original Message-----
From: pgrouting-users-bounces@lists.osgeo.org
[mailto:pgrouting-users-bounces@lists.osgeo.org] On Behalf Of Stephen
Woodbridge
Sent: Monday, December 15, 2014 10:45 PM
To: pgrouting-users@lists.osgeo.org
Subject: Re: [pgrouting-users] Cleaning multilinestring vector network for
routing via kDijkstra
Eyad,
There has recently been a bug reported against pgr_nodeNetwork and it
contains a patch to fix that problem. See:
https://github.com/pgRouting/pgrouting/issues/280
If you have multilinestrings then you might want to try something like:
st_geometryn(multiline, 1)
so you just select the first linestring in the multilinestring.
-Steve
On 12/15/2014 12:24 PM, AUS - Eyad wrote:
Hi All,
As I’m still struggling to make my network routable, I tried using
pgr_nodeNetwork (instead of using v.clean), as follows:
Select pgr_nodeNetwork (‘schema.table’, 0.0001, ‘id’, ‘geom’)
But I got the following 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
I removed line 184 from my table but still getting same Error!
Afterward, I tried calculating the costs using pgr_kdijkstraCost, but
unfortunately most of the results are “-1” which means that there is no
connection!
Important note: my network is somehow accurate (done on CAD), but I
think this is a normal cleaning that every expert of you may take it for
granted
Please assist in resolving this issue (even by suggesting new
tool/function) because my time is becoming tight and this is my first
real/full application using pgRouting
Regards,
Eyad
*From:*AUS - Eyad [mailto:b00038807@aus.edu]
Sent: Monday, December 15, 2014 12:44 AM
To: ‘pgRouting users mailing list’
Subject: Cleaning multilinestring vector network for routing via
kDijkstra
Hi All,
I’m facing a serious issue preparing my multilinestring vector network
for routing.
I imported my vector network from CAD file. Obviously, there are some
areas where lines are intercrossing still not routable_through;
although, they are connected to each others!
I used V.Clean (advance) to clean the network before importing to the
database. I tried (break, snap, bpol, etc) alternatively but still not
sure which one is the proper tool. Also I’m finding it hard to set the
parameters because my vector network is obviously imported in
millimeters while the network is spread on a length reaching 700m from
start to destination from some ends.
I’m testing the results via shortest_path plugin before I import to
DataBase. In few successful cases using shortest_path, afterwards the
network gets to lose a lot of elements while importing to DB (i.e. 600
features only written from 700).
If there are other ways to make the network clean and routable, please
suggest
I’m using QGIS 2.4.0 and pgRouting pg93-binaries-2.4.0
Regards…
Eyad
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4235/8736 - Release Date: 12/14/14
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users
–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.info
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5577 / Virus Database: 4253/8745 - Release Date: 12/16/14