Are all those advantages real?
It can actually do those things, if that's what you mean. It takes work from you to set the data up properly.
Isn't pgRouting a kind of a blackbox? There are just a few
tutorials on how to use it, and even
these tutorials introduce even more
unanswered questions. Isn't it simpler
to build the desired [Goal] system
from scratch?
The documentation isn't good, that's true. But, all of the source is there. It's hardly a black box and can keep things DRY.
What's the whole purpose of storing routable data the
PostgreSQL/PostGIS way (geometry
columns, strange database schema)
instead of having just two tables -
nodes and edges in a simple MySQL
database?
If MySQL does everything you need and you're familiar with it then use that. PostgreSQL/PostGIS is much more powerful from a relational database and spatial analysis perspective. That doesn't mean you have to use it or even that it's better for your application. If you want better performance, more features and strong spatial analysis functions, switch to PostgreSQL/PostGIS. If what you have works well enough, don't worry about it.
See also: Cross Compare of SQL Server, MySQL, and PostgreSQL
I'm currently exploring the same problem as you, for the purpose of research paper. Before I started to test these two databases, I had the same presumption as you. That Neo4j graph database would be perfect solution for this kind of problem. And partially it is, but with lot of problems.
First problem is that A-Star is only implemented if you are using embedded database, not via REST API (server). If you want to use Neo4j with REST API, then only Dijkstra algorithm is supported.
Second problem is hardware memory requirements for Neo4j. For routing (Dijkstra) on "larger" networks you need a lot of RAM. For large network I mean something like size of Germany OSM road database. I have run my tests on 6GB RAM server (that's all I have currently) and only smaller networks could be routed without OutOfMemory exception errors. "Small" networks in my test cases are for example, OSM road database for Austria or Croatia. Concurrent queries I still haven't tested with Neo4j.
All of these problems do not exist in pgRouting. Memory is not such an issue but concurrent queries increase needed amount of memory. For example, if you have two concurrent requests, double amount of memory is needed. This wasn't an issue even for a Germany OSM dataset, pgRouting routed without any problems all concurrent requests.
Performance: In most cases, Neo4j outperforms pgRouting. But only if there is enough memory for the given dataset and if all nodes and relationships are in memory (hot start). Increase/decrease in performance depends on lot of factors but mostly on size of network and distance (hops) between source and target node.
Your network size is quite small, so you shouldn't have any problems with memory. Probably Neo4j is not a bad choice but you have to adapt to a "little" different data model than in standard relation databases.
To answer you questions:
- In pgRouting you don't have to worry about AStar implementation in
sql, that allready implemented.
- Yes, pgRouting can give you list of nodes and edges
- I don't think that pgRouting can give you such information with out
some custom work around queries. But maybe I'm wrong, maybe somebody
has done this and can help you more about this question.
I dont know if it will help you directly, but one of the fastest routing server I found is osm2po. It works with OSM dataset and is quite fast. Only dijkstra is currently implemented but developer announced AStar also.
I hope that some of this will help you. :)
Best Answer
Yes, we have just implemented a turn restricted shortest path (trsp). I think it has been checked into a git branch at origin/trsp. It is not documented yet. If you have questions or need help ask on the pgrouting list, because that is where I hangout.
-Steve