Hi, I imported a large area from "planet.osm" file into a postgresql database using Osmosis. Is not really clear for me where in my database structure I should search for this two points.
For example if a user enters as starting point "London, UK" and as end point "Paris, France" where should I search for this two locations so I can start implementing my routing algorithm. My database structure as created by Osmosis contains the following tables: nodes, relation_members, relations, users, way_nodes and ways. I need some clear information on how the database is structured because I can not figure out where to start building my graph so I can implement A* algorithm. This routing algorithm is a part of my thesis so I can not use an allready built service. Thank you, asked 13 Jun '13, 08:50 raduzugravu |
The Snapshot database structure populated by Osmosis is very unsuitable for routing, at least in part because geometry for ways might not exist or be unsuitable and there is no geometry for relations. You really need to transform the data into a more suitable format. This data is really for people who want a pretty much exact copy of current data from the planet database for an area. I would start by reading the wiki. answered 13 Jun '13, 10:18 SK53 ♦ But how can I retrive my start and end locations from the list of nodes? Right now I do a search through the hsotore tags and compare name keys with the values introducted by the user. This is really slow. Is there a way to make a search through hstore keys faster? My database implementation uses Postgis functionality. My problem is in retrieving the start and end locations. Once I find my start and end points routing should be done easy using Postgis functions.
(13 Jun '13, 11:45)
raduzugravu
Then you probably need a nameserver like Nominatim, but I'm sceptical that you can use a raw snapshot schema. It's basically a Postgres schema not a PostGIS one (really only the nodes have location).
(13 Jun '13, 12:14)
SK53 ♦
|
OpenStreetMap data can be converted into many database structures, for many different purposes. You should decide the database structure that you require first, and then import the data into your chosen structure. By picking a schema without checking that it's suitable, then you're almost guaranteed to fail. It's like cementing bricks to one another, and then designing the house afterwards. Of course, if you don't want to design the database structure, then you can use one that's already designed for routing, and already has an importer, like osm2pgrouting - but that might not be the point of the exercise. answered 13 Jun '13, 14:15 Andy Allan |
There is no good way to do performant geocoding with a pgsnapshot database. If you do suitable partial indexes on (lower(tags -> 'name')) (lower(tags -> 'alt_name')) and similar tags you might be able to get some results, but writing a geocoder is a thesis in itself. pgsnapshot is written to preserve full OSM data, which is not what you want for routing. In any case, the three main tables are nodes, ways and relations. They contain the nodes, ways and relations imported into the DB with one row per object. Most of the columns for these are self-evident from the names, but tags is a hstore with the object tags. The table-specific columns are
The way_nodes and relation_members store membership in ways and relations and allow you to find the "parent" ways or relations for a node or other object. I suggest you decide if you're trying to write a geocoder or trying to write a routing engine. In either case, pgsnapshot is probably not the place to start. answered 14 Jun '13, 10:13 pnorman Hi, Thank you for your answer. What I am trying to write is a routing engine. I need to geocode start and end locations in order to know coordinates for locations introduced by the user. To obtain this coordinates I could make a request to nominatim. Theoretically it should be possible to write an A* algorithm on this set of data after I get my start and end coordinates, right?
(14 Jun '13, 11:09)
raduzugravu
1
yes but whether it will complete before heat-death of the universe is another matter
(14 Jun '13, 11:22)
SK53 ♦
Time is not that important. Of course it shouldn't take days to complete. I think somewhere under 1-2 minutes for locations not too far away one from another should be ok. I have one more question. In order to write my routing algorithm my start and end nodes should be part of a way, right?
(14 Jun '13, 11:32)
raduzugravu
I mean if someone introduces as starting node a cultural objective (for example the name of a museum) which is not part of a way then I have to find the closest node to that starting node which is part of a way. That can be done using postgis geometry functions?
(16 Jun '13, 07:28)
raduzugravu
|
Is there a way to access the graph underlying OSM api?
Pls create a new question and do not start new topics in comments.