[pgrouting-dev] PostGIS 2 Release
Stephen Woodbridge
woodbri at swoodbridge.com
Sat Feb 11 11:36:56 EST 2012
On 2/11/2012 10:46 AM, Steve Horn wrote:
> Was wondering what impact, if any does the pending PostGIS 2 release
> have on the pgRouting project?
>
> I noticed that PostGIS 2 will include the ability to create network
> topology (similar to pgRouting's assign_vertex_id???). Are there other
> potential replacement functions included up that anyone knows of?
This question came up on the postGIS list not too long ago and the
answer was probably does not help pgRouting. As some background on how
pgRouting works, a request is handle like this:
1. request is passed start and end and a SQL query for the edges of the
network
2. internally, we read the edges and build a graph
3. we solve the graph using the appropriate algorithm
4. we return the results
5. we destroy the graph and other internal structures
The problem with passing the topology to pgRouting is that while it is a
graph, it is not in a form that we can easily and quickly access from a
solvers point of view. In the above, it normally takes more time to read
the graph data and build the graph than it does to solve the graph. So
it would be nice to have a persistent graph, but then you have other
issues, like:
Do you keep the whole graph? or only the part needed for the solution?
If you keep the whole graph, then where do you cache it? how fast is it
to access the graph when you need it? how to you update the graph if you
want to change the edge weights, or the topology? If you want to keep
only a portion of the graph, how do you cache and will you have a high
enough cache hit rate to make it worth you effort?
And these are only a few of the issues, so you can see it is not a
trivial problem. The current method of building the graph based on the
bounding box or some other tricks to get the data needed for a given
request is fast and it has the added flexibility of allowing the request
to be high dynamic. For example I have implemented, realtime traffic
feeds where the cost values are updated based on the feed data. And we
can modify the edge set based on the vehicle class such as car, truck,
emergency vehicle, or pedestrian.
That said, the dev team is aware that there is a need for solutions that
might not be as highly dynamic but need better performance and we are
discussing what it would take to build a route server using a saved
graph that would probably exist outside of postgresql. I don't know if
we will ever do this or not, but it is possible and straight forward if
it were funded. But we really need to fix some bugs and cut a new
release of the existing code before we do anything else.
-Steve
More information about the pgrouting-dev
mailing list