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

[Daniel Kastl]

Hi Steven,

Thank you for posting my post to the list. ;-)

Stephen Woodbridge schrieb:
> [...]
>>> 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.
True. I completely agree.
>>> 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
>>
> c) I am not advocating that we violate any copyrights or what not, but
>
> Yes, I'm sorry I did not include OSM in my comments before. We
> definitely need to look at that data model also.
Not to be miss-understood: I'm not a big supporter of the OSM data
model. It doesn't look like it was made for spatial analysis. But there
might be a lot of people from the OSM community, who might want to
contribute and use an OpenRouter library.
> 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.
... which remembers me something I wanted to mention already earlier:
Talking about routing leads immediately to a discussion about road
networks, roads, lanes, highway hierarchy, speed, etc.. Of course
routing in road networks is the largest use case and it makes a quite
abstract topic easier to explain. But there are many other types of
networks, and I think a routing library (engine?) should also care about
those. You agree, don't you?

Daniel