3

I'm learning pgRouting, to validate if it can be used in a project. I have several doubts. Mostly related with how could I "fill the gap" between the "bricks" it provides and the real world applications based on routing I normally use. I will summarize the questions in a few ones. Sorry if they're too silly. I have little experience with topology.

EDIT: PolyGeo wisely suggests that I focus this question in one important topic, and leave the rest for different questions. I will reformulate my doubts to create a general question important for me. The already existent responses will still make sense. Anyway, I keep the original questions at the end.

My general doubt is about the topology creation process and how flexible is.

If my data consists in a bunch of lines, and I tell pgRouting to create a topology from that, is a node created at any intersection, apart from the nodes created at the beginning and end of any line? And what about intersections at different level? (for example: a bridge above a motorway: http://goo.gl/pVeE4j, that's not really an intersection) How are these handled? --> EDIT: I've already found this http://goo.gl/ojGmuH. I think it is a response. I need to investigate it.

Once the topology has been built, what do I do if I need new nodes for a query? Example: I want the shortest path from any arbitrary point in my route to another arbitrary point, not just from one existent node to another one (example: the Google Maps feature "give me directions from my current location to this marker I've just put in the map")

Regarding the topology, my last doubt is if the PostGIS topology and the pgRouting topology are related in any sense.

These are the original 6 questions I made:

  1. About creating the topology: you feed the engine with a few lines, as the base of the topology. I guess a new vertex is created every time two of these lines intersect, apart from the vertex created at the beginning and the end of each line. Am I right?

  2. When two lines intersect at different level, how is it handled? (if it's really handled). For example, a bridge above a motorway. Something like this: http://goo.gl/pVeE4j

  3. I've seen several examples using really simple data: a few lines forming a simple network. I've also seen examples using OSM data imported with osm2po or osm2pgrouting. OSM data is great, and complex. But what if I want an intermediate point? Not as simple as a single table with a few dozens of prepared linestrings and not as complex as OSM datasets. Sometimes, we need to work with data provided by public institutions (old digitized maps, cadastre datasets, etc). Is there any way to integrate data from different sources? Any method to ease the compliance of my data with the minimum requisites for pgRouting to create a topology based on it? So, to go from chaos (different sources, different methods to obtain the data...) to a polished set of PostgreSQL tables, ready to work with?

  4. The minimum path algorithms always need two nodes (from A to B). No problem if those points are actual vertices of my topology. But, what if I want to calculate a path from this exact point where I am right now to another arbitrary point? Like the Google Maps calculation: "give me the path from my current location to X". Creating new vertices every time an arbitrary path is requested and rebuilding the topology sounds like nonsense for me.

  5. About the turn restrictions, I find the underlying logic difficult to understand. What do the parameters of restriction SQL mean? In the example, a restrictions table is created. Why those fields?

  6. Do pgRouting topology and PostGIS topology know each other? If not, are they planning to converge/collaborate in any point?

So, summarizing, in my opinion pgRouting looks like a really great framework, but I think there are a lot of things to learn, understand and build in order to construct a routing engine using it.

  • You seem to be asking about 6 questions in this Question. The Q&A format of GIS SE works best if only one question is asked in each Question so my recommendation is that you edit this one to focus on that which is most important to you first. – PolyGeo Nov 30 '13 at 2:02
  • You're right. I've already changed, keeping the original questions at the end. – Jorge Arévalo Nov 30 '13 at 9:43
3

I'm trying to give a brief reply to your questions:

  1. The topology function assigns a source and a vertex ID for each road segment. To do this a vertex table is created, which contains all source and target IDs. You can use this vertex table, but it's not required.

  2. If there is no shared node at an intersection, then the topology script will not connect these 2 roads.

  3. You can use any network data you want.

  4. You need to handle intermediate points yourself. PostGIS provides various functions to find nearest roads and split them, see ST_LineLocatePoint or ST_LineSubstring. pgRouting is a set of basic functions, which add routing or network analysis functionality.

  5. Turn restrictions are complex. You should first start with something simple.

  6. PostGIS and pgRouting topology functions are different. pgRouting cares about a valid "network".

You probably best start with the pgRouting workshop.

  • Thanks for your responses. I just keep a doubt. About 1 and 2, my point is that I just start with a bunch of lines in my table. One per row. I guess pgr_createTopology works creating a node per each intersection between lines. So, it decides where the nodes are. And if I want to represent that two lines intersect at a different level, it shouldn't create a node at that point, because there's no real intersection (example: a bridge over a motorway). I don't think it can do it. – Jorge Arévalo Nov 30 '13 at 9:48
  • About the different level intersections, I think it's explained here: goo.gl/ojGmuH – Jorge Arévalo Nov 30 '13 at 10:07
1

It would have been more reasonable to put these into separate questions. You also might benefit from the topology part of the PGRouting Workshop docs.

The topology is not created by magic. You either need to provide it (where the topology is provided by identifiers), or you you need to have pgrouting create it (which is what pgr_createTopology() is for). So given your "few lines" defined by coordinates, they may or may not actually match up as a network (because coordinates won't match exactly - they'll likely be floating point number if nothing else); but you can coerce them into a network based on some tolerance.

If you want to handle lines that intersect, but don't want pgr_createTopology() to create a topological node, you'll have to make sure that there are no nodes within the specified tolerance; or you'll need to build the topology yourself.

There is no magical solution to turn random data into a sensible network topology. You'd need to convert each of them into the pgrouting topology. That isn't specific to pgrouting. One way might be to import them into OSM (which would be good for everyone), noting licensing issues. Or you could build the topology vertex by vertex.

You can't (sanely) route from an arbitrary coordinate to an arbitrary coordinate. Your network defines how you can route. That is how the algorithm works, and that matches the reality. You can't drive down some streets in both ways. You can't get across rivers in your car, you can't get from a carpark to a street except at the exit. If you want to route from it, there needs to be a node. If you want to route to it, there needs to be a node. Those nodes need to be connected by some set of directed edges. [There are hacks you can apply here, and later versions of pgrouting will help you with them; but under some cases, you're going to jump to a node and that won't be physically possible because there is a fence or a wall or a building or a country border in the way]

I'm skipping your turn restriction question - its too vague to answer. Try another question with much more detail.

Topology for routing is conceptually similar to; but is used for a different purpose to; topology for encoding geometries. Future directions are impossible to provide with any certainly, but I think its unlikely to have meaningful overlap.

  • Ok, many thanks. I just have one doubt, about the different level intersection: You say "you'll have to make sure that there are no nodes within the specified tolerance". But the point is I start with just a few lines, and I want pgr_createTopology that do the job, and create the necessary vertices to connect my network. I don't know anything about nodes. I just want to specify in some way: "Ey, do you see that point where those 2 lines cross? That's not an intersection. They're at different height. Please, don't create a node there". But I think the response is here goo.gl/ojGmuH – Jorge Arévalo Nov 30 '13 at 10:06
  • Perhaps that would be a new question? – BradHards Nov 30 '13 at 21:38
  • Yes, probably. But I think I have a better idea now, after reading the documentation and make a few tests. It seems that there's no automatic way of doing this. It's a question about how you define your data. – Jorge Arévalo Dec 1 '13 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.