I am currently working in the field of isochrones and the underlying algorithms. What now causes problems is not the calculation if the isochrone itself, but the visualization of the results.
The result of my isochrone algorithm are points and edges. In fact I do have a working solution, but for 3873 edges and for 1529 nodes things seem to take forever (around 2.0 seconds on my Lenovo T440s laptop which contains a 2015 Core i7 CPU and a pretty fast SSD). Instead of seconds I want something more like msec
.
Maybe someone can help me to reduce the calculation time needed to build the polygons which visualize the reachable areas.
But wait... first things first!
Here is a visualization of the edges that I are the calculation result of my isochrone:
These edges are stored in a PostGIS database table and are simple linestrings.
What I want to show to the user looks like this:
Note the disconnected areas in the very south and very east of the picture. These should be drawn as separate areas (so no merging allowed here )
Currently I am using this query:
SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM ( SELECT ST_MakePolygon(ST_ExteriorRing(ST_GeometryN(segments, generate_series(1, ST_NumGeometries(segments))))) AS polygons FROM ( SELECT ST_Union(ST_Buffer("GEOMETRY", 20, 'quad_segs=2')) AS segments FROM my_edges AS a ) AS b) AS cI already did some experimenting and I also read a lot of documentation, but I just can't find a better solution.
In my eyes the big problem is the usage of ST_Union (as stated in the docs this function can be slow). The very interesting thing is that replacing it with ST_Collect seems to slow down the ST_Buffer calculation so that all-in-all the following query takes even longer, although it does not fill the areas between the edges (it only creates a buffer around the lines):
SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM ( SELECT ST_Buffer(ST_Collect(ST_LineMerge("GEOMETRY")), 20, 'quad_segs=2') AS polygons FROM bz_iso_edges_0 AS a) AS bThis takes around 3.8 seconds on my system (so nearly twice the time).My first conclusion out of this little benchmark is that ST_Buffer gets unexpectedly slow when it comes to MultiLineStrings (even slower than when creating buffers for each line and merging the buffers - which in my eyes is just weird)
I also tried to use alpha-shapes (using the implementation from pgRouting), but since there is no alpha value to set (and in fact I would not really now to which value to set such a value) I just get one great polygon (so I'd lose the regions in the very south and east as separate regions which is not what I want).
Also ST_Polygonize (which was the first thing that came in my mind) did not produce any usable results, but maybe I missed something here...
Is there a better way to create the area shown in PostGIS? Maybe also by using java code (jts) or client side javascript code (jsts)? In fact I could live with loosing some detail as long as the areas shown in my result stay separated and the calculation gets (much) faster...
Cheers,
Niko
أكثر...
The result of my isochrone algorithm are points and edges. In fact I do have a working solution, but for 3873 edges and for 1529 nodes things seem to take forever (around 2.0 seconds on my Lenovo T440s laptop which contains a 2015 Core i7 CPU and a pretty fast SSD). Instead of seconds I want something more like msec
.Maybe someone can help me to reduce the calculation time needed to build the polygons which visualize the reachable areas.
But wait... first things first!
Here is a visualization of the edges that I are the calculation result of my isochrone:
What I want to show to the user looks like this:
)Currently I am using this query:
SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM ( SELECT ST_MakePolygon(ST_ExteriorRing(ST_GeometryN(segments, generate_series(1, ST_NumGeometries(segments))))) AS polygons FROM ( SELECT ST_Union(ST_Buffer("GEOMETRY", 20, 'quad_segs=2')) AS segments FROM my_edges AS a ) AS b) AS cI already did some experimenting and I also read a lot of documentation, but I just can't find a better solution.
In my eyes the big problem is the usage of ST_Union (as stated in the docs this function can be slow). The very interesting thing is that replacing it with ST_Collect seems to slow down the ST_Buffer calculation so that all-in-all the following query takes even longer, although it does not fill the areas between the edges (it only creates a buffer around the lines):
SELECT ST_AsGeoJson(St_Transform(ST_Multi(ST_Collect(polygons)), 4326)) AS coverage FROM ( SELECT ST_Buffer(ST_Collect(ST_LineMerge("GEOMETRY")), 20, 'quad_segs=2') AS polygons FROM bz_iso_edges_0 AS a) AS bThis takes around 3.8 seconds on my system (so nearly twice the time).My first conclusion out of this little benchmark is that ST_Buffer gets unexpectedly slow when it comes to MultiLineStrings (even slower than when creating buffers for each line and merging the buffers - which in my eyes is just weird)
I also tried to use alpha-shapes (using the implementation from pgRouting), but since there is no alpha value to set (and in fact I would not really now to which value to set such a value) I just get one great polygon (so I'd lose the regions in the very south and east as separate regions which is not what I want).
Also ST_Polygonize (which was the first thing that came in my mind) did not produce any usable results, but maybe I missed something here...
Is there a better way to create the area shown in PostGIS? Maybe also by using java code (jts) or client side javascript code (jsts)? In fact I could live with loosing some detail as long as the areas shown in my result stay separated and the calculation gets (much) faster...
Cheers,
Niko
أكثر...