On Thu, 16 Oct 2008 01:40:27 -0700, "Tristram Gräbener" <[EMAIL PROTECTED]> wrote: > Hello, > > I think we'll have to develop two different formats : > * one binary with maybe indexes, some mmap-able structure, etc. For > dynamic loading of the graph etc. > * one more general > > I'm personnaly more interested in the general model (I'm working on > multimodal transportation, and I need different graph structures for > cycling, foot, car etc.) > What I would like is something exportable into a database (postgis for > example, but any should work) > > The tables would be > > Nodes[node_id, lon, lat] > Links[link_id, source*, target*, geometry, way] > Properties [way, key, value]
I guess you may want to have properties on nodes too. (Think of cities not represented by a polygon or highway=mini_roundabout having an impact on later driving-directions.) > The nodes isn't really needed. > What I call a link, would be le nodes of degree 2 merged (or ways > splitted) and thus the arcs needed for routing. > The geometry column is a format used by GIS databases (called "well > known text", generaly also in a binary format) allowing to use > geographical indexes I'm not a big fan of these geometry-classes as they rip apart all topology and violate the first normal form big time. But for a database there is no way around them. > The properties allow to handle any future property that will be added > to the osm data. > > This allows : > * using pgrouting (a cost and rcost column might be missing, but as > that cost depends on the user [distance ? time for a car, a bike ?] it > shouldn't be included by default agreed > * using ogr2ogr to convert to any other GIS format > * graphical rendering with the geometry information How do you think of doing this after having eleminated nodes of degree 2? e.g. every node of a forest-polygon has a degree of 2. > * using spatial sql-request if you have a spatial database > > It's quite versatile, there is no assumption about the future use of > the data (except routing). Of course it's not the best for embended > systems, and won't probably be well suited if you want to load the > graph progressively (routing through the world) Why do you think it would not be suited for that? You traverse links, loading target-nodes and essentially make 2 queries over and over: select * from Links where source = (currentNodeID) select * from Nodeswhere id = (currentNodeID) you never need to store any large part of the graph in memory and can leave caching to your database-system. I guess we can say that the indexing and storing of adresses (required to enter the target for routing) is out of the scope of this schema. I guess this is fine but wanted to mention it. _______________________________________________ Routing mailing list [email protected] http://lists.openstreetmap.org/listinfo/routing
