[OSM-talk] conclusions from my postgres / postgis experiments

[Richard Fairhurst]

raphael Jacquot <sxpert at sxpert.org> wrote:

> segments A-B, B-D, B-I, D-F  are on the same street, your routing  
> algorithm needs to have access to those segments as separate ways
> however, prior to doing the routing, you need to search for that  
> street's name. it's simpler if you have to look up only one record  
> for that street, even if it's composed of multiple segments.

Agreed absolutely, but I don't see why the core OSM db has to be  
structured around this.

When you use an in-car "satnav", or the route-planners on Google,  
www.theaa.com, or www.rac.co.uk (or your local equivalents), they're  
not working off the raw Ordnance Survey MasterMap database. They're  
using a heavily processed version of it.

Surely the same applies to OSM - anyone developing a routing  
application will do their own pre-processing to create a "lite",  
streamlined version of the db which will then be used by the client  
app. (In your Grenoble example, this would have a reference from the  
single street name to the four segments.) The processor-intensive  
stuff is done just once (or at the very most, once per planet.osm),  
not every time you plan a route. Given that the data is generally  
disseminated via planet.osm anyway, which requires some fairly  
heavy-duty deserialisation, it's not too much of a leap.

IMO the OSM db structure should facilitate the simplest, most accurate  
storage of geodata. Everything else is up to the client app, whether  
it be Mapnik, Osmarender, Free-Map, a route-planner, or whatever. (Hey  
- isn't it cool to have three such quality clients already?) Each  
client app will have its own needs and there's no single db structure  
which is ideal for all of them.

cheers
Richard