[RouterGeocoder] Routing Data Schema

[Stephen Woodbridge]

Daniel Kastl wrote:
> Hi Steve,
> 
> Still no others than pgRouting users here, but anyway ...

Well we do have some potential developers that have been asking question 
and I'm hoping that we might get some active development going. I don't 
know if you are also on the PAGC list, but we have put together some 
projects proposals to refactor it and add support for Navteq data. We 
are actively looking for some funding for those proposals. It might take 
a few months to get it, but I believe we will be able to move that 
forward. I would like to see the same model happen here.

>> I have no objections to supporting general network analysis. As you
>> say our primary use case is vehicle routing. Some useful variants to
>> that are things like:
>>
>> Chinese postman - IIRC which is useful for planning snow plow routes
> This almost made it into pgRouting through some project/sponsorship.
> It's for sure an interesting extension.
> 
>> Minimum Spanning tree - for Cable/Telephone/Fiber installation
>> Isochrons - for drive time analysis
> Which is probably just a variant of the "driving distance" function in
> pgRouting. Another good idea for the SoC, also the Traveling Sales Man.
> 
>> Navteq has a complete model. It is very normalized and sometimes a
>> pain to deal with. TeleAtlas also has a good model but I'm less
>> familiar with that.
>>
>> With respect to Navteq, go to the http://www.navteq.com/ and follow
>> the links to the developers section. Sign up as a developer (costs
>> nothing) and you can download specs and sample data.
> Steve, I already did this and even printed out most of the papers long
> time ago. It's huge and takes time to get through. But so far for Anton
> and me working for a Japanese company with Japanese customers Navteq
> data (or TeleAtlas data) wasn't an option, because they have no data
> available for Japan.

Yeah, I hear you. I only know it because I had to work with it for five 
years and you tend to pick up most of the important parts in that time.

>> I'm happy with either, but I think we should focus on our areas of
>> strength and expertise. I would like to see us do an outreach for
>> other use cases and to have experts in these discuss the direction we
>> are going and what changes we need to better support them.
>>
>> My concern is that if we try to be all things to all people -- we will
>> end up being nothing useful for anyone. We should work from our areas
>> of core competence and strength.
> True ... we don't need architecture astronauts.
> 
>> Which gets me back to my questions :) How does this proposal look with
>> respect to:
>>
>> 1) vehicle routing problems? What is missing that we might need?
> For the basic network information I like your schema proposal.
> I don't think we can miss something very important if you took the
> Navteq model here as a reference.

Only off the top of my head. I should probably make a pass through the 
docs and update the model.

> But then there are a view attributes which are quite road specific.
> SPEED
> VEHICLE_CLASS
> are probably the ones.

Well yes by their names. But SPEED could also hold FLOWRATE, PIPE 
DIAMETER, or any other attribute that might make sense or be NULL. This 
attribute is more for convenience as it is used to compute COST, but 
otherwise not needed and could be done away with.

I'm somewhat thinking of the process of loading the data into this 
schema that you need to load the basic network segments, then compute 
costs, nodeids, add restrictions, etc. and having some data like SPEED 
handing can facilitate the basic computations without an additional 
lookup, but this is an optimization without warrant at the moment.

VEHICLE_CLASS was picked over CLASS because it is a reserved world in 
some SQL engines, but it could just be CLASS. Again the idea being, the 
different objects traversing a network segment can have different 
characteristics and attributes. So when preparing or loading data into 
the network evaluation engine you might need to select from an 
appropriate CLASS of objects. An example in piping networks one needs to 
model pipe diameter and fluid viscosity.

Also I have to say that this is not needed if we are only talking about 
pgRouting, because what I have described is pretty close to the process 
of loading and preparing your data for pgRouting today. Other than the 
fact that turn restriction really need to be reworked to be useful in 
pgRouting if you need more than one defined at a node and I think that 
is the case for Navteq and TeleAtlas.

-Steve

> Daniel
>