[RouterGeocoder] building different layer for routing.

Stephen Woodbridge woodbri at swoodbridge.com
Tue Mar 31 16:23:52 EDT 2009


Ashraf Hossain wrote:
> Hi Steve,
> I must want to work with Nestor if I  have the opportunity.
> I have also a research group with one of my close friend.
> We both are interested and we will be honoured if we can contribute.

That would be really great. We may need to get SVN setup and some other 
collaboration tools, but we should be able to make some progress without 
them in place anyway.

> We already started our study about the performance for huge number of vertices.
> I think soon we can send some updates in this group, though we do not
> have huge big layer like USA and CANADA.
> If you have some suggestion about this please let me know.

For starters you probably need data. Free sources for data are:

US Census Tiger data that is not really suitable for drivable routes, 
but you could use it for just a large network, for performance and 
sizing tests.
http://www.census.gov/geo/www/tiger/
You can down load the data, but there is a lot of file but you might 
only need tl_*_*edges.zip (~3300 files) You would need to filter the 
edges by the mtfcc to only get the street segments.

If you have a documented format that you need data in, I can probably 
build the tools to read the Tiger data and put it in a format that you 
can work with more easily.

Tiger has about 30M street segments. Canada has about 2M segments. I 
don't have the number for Mexico. Navteq for US and Canada has about 27M 
street segments. So for testing large networks, using Tiger would 
probably be representative in size.

What Tiger is lacking is:
1) no turn restrictions
2) no oneway streets
3) no zlevels at intersections to separate underpass from overpass

I can point you to data for Canada if you need links. I think OSM might 
be the only open source for data for Mexico, but I have not looked at 
what kind of coverage they have.

> And another issue I have to know that if any operator updated their
> graph with USA and CANADA but if he want to add mexico(as a different
> layer) what should be our plan.
> Because if we make it as different graph then we have to start our
> plan in different way.

I think this will have to do with how the user of the network wants to 
present it to their clients. They can build it all as a single graph 
which would give cross border routing, assuming the nodes at the borders 
matchup. Or they might build separate graphs and require the client to 
select the graph to use.

I currently do not thing that we need to have multiple graphs and to 
have routes that can jump from one graph to another and continue the 
solution. Although that might be interesting, I'm not sure anyone has 
done much research on this specific technique. At least I have not seen 
papers to this effect.

> And another one research about hybrid routing which is being used in
> google transit.
> If a user want to minimize bus route + taxi + walking in a single
> routing path generation,
> I already started thinking about this but the main problem is that how
> can we have the data?

This is interesting and might be a good feature to plan for. Data is 
always going to be the problem. We might be able to find this data for a 
given city. OSM might also be collection this data. This specific 
problem requires have schedules for all the services, and planning 
around a specific start or end time. It is a very time dependent problem.

> If anyone have some suggestions please let me know.

Can you tell us a little more about your current efforts?
Do you have code already?
What language is it in?
Does it have dependencies on other libraries? Which?
Can it be downloaded? Where?
What features does it have? Are there any docs or notes?
What OpenSource License are you using?
Do you have a plan for what you want to do next?

Best regards,
   -Steve

> With Regards
> Roni
> _______________________________________________
> Routergeocoder mailing list
> Routergeocoder at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/routergeocoder



More information about the Routergeocoder mailing list