[RouterGeocoder] Re: [OSGeo-Discuss] Discussion on Routing

Stephen Woodbridge woodbri at swoodbridge.com
Wed Nov 19 01:02:34 EST 2008


Daniel Kastl wrote:
> Hi Stephen,
> 
> Thanks for the interesting post!
> I would like to comment some parts:

Comments are always welcome. Without them, I'm just muttering to myself :)

> Stephen Woodbridge schrieb:
>> [...]
>> 1) Granted everyone does not have access to Navteq data, but using a
>> schema similar to Navteq's or something that can be generated easily
>> from Navteq's description would be good.
> As far as I know there is some Navteq sample data available for
> download. What I don't know is if this dataset includes all the routing
> related attributes already or if I'm missing some important ones. Is
> that sample data comparable?

This is a good point. Anyone can sign up as a Navteq developer and 
download sample data and spec. The sample data is fully attributed, but 
it is a few quarters old. When I last downloaded it, it was very close 
to the current data, but the current data was under going some changes, 
but none that I can think materially would affect the routing model.

>> Why should we care about what Navteq does?
>> a) It is a well thought out model that is used by a very large number
>> of companies the license Navteq data for vehicle navigation and
>> companies the license it for routing applications.
>> b) As a result, it is mature and probably has already solved 99% of
>> the problems that we might not think about initially but users,
>> especially Navteq users, will run into in the future.
> In general I agree that Navteq's data model might be a good (maybe the
> best) example to look at. But having experience with other data
> providers those data models are often not "perfect" because they have to
> deal with previous versions and decisions that have been made in the
> past (I know about one data provider which mistook lat/lon in their
> first model, and it didn't change until today). Wouldn't it be nice to
> have a better one?

I am not suggesting the we use the Navteq model, but that we look at it 
and other to understand what data is available the impacts routing and 
we look at how it is structured because it might suggest ways that would 
be easy for us to represent that same data. If we are going to ignore or 
throw out some feature of the routing model then we should also 
understand what the impact of that decision is. Most of the free or low 
cost data is build around trivial models because the people that have 
developed them have not invested in building rich, robust data sets like 
Navteq and TeleAtlas.

I fully expect that every data source will need a data loader. That is 
some piece of code the reads the vendor data and reformats into the 
structures and tables that we ultimately end up using. This would be 
where you could correct flipped lat/lon values, or compute the length of 
segments if we needed that, etc.

>> c) I am not advocating that we violate any copyrights or what not, but
>> if we were to translate Navteq data into our format, what type of data
>> and fields would we need to account for.
> I suppose that Navteq might even appreciate if we take their data model
> as the reference model. And probably OSM community (and others) will try
> to convince everyone to follow their model.
>> [...] 
> Regarding OpenStreetMap I remember a long discussion in the OSM Routing
> mailing list last month about a "generalized routing format":
> http://www.nabble.com/Driving-directions-web-map-to19866110.html#a20003229

Yes, I'm sorry I did not include OSM in my comments before. We 
definitely need to look at that data model also.

We really do NOT care what format the data vendors use so much as that 
we need to understand the data model, with respect to street segments, 
zlevels at intersections, how turn and lane restrictions are 
represented, speeds, street directionality, etc. For example, how are 
HOV lanes represented, emergency vehicles lanes, pedestrian paths, rail 
or air routes represented, etc. And understanding that, how we want to 
model, store and use that information in our routing engine.

I will read up on the thread above, I have not seen that yet and it 
probably has a lot of good ideas, thanks for that and your comments.

Best regards,
   -Steve

> Daniel
> 



More information about the Routergeocoder mailing list