-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, thanks for giving me something to google. :) I have a few more questions now that I've had more time to sit with this problem, also after having read your message.
1. My problem isn't routing, but rather providing accurate street-level information. Does that change the situation any? I'm wondering how much information on routing would apply here. 2. As a blind pedestrian, I'm not likely to travel faster or slower on streets of different types. Vehicular navigation of course is another story, but in this instance, vehicular nav is secondary. Also, whether or not a street is one-way is immaterial. Same with dead-ends. Do I have anything to gain from examining way tags, or am I dismissing that avenue too soon? It seems to me like my approach would need to be purely mathematical in this case. 3. In dusting off my disused (and never that good to begin with :) math skills from over a decade in my past, I'm thinking that a vector-based solution might work. I am already calculating a node's neighbors if it is on one or more ways, so I think that if I create vectors between the nearest node and each of its neighbors, then determine which segment has the least distance to the user's current location, then I've figured out the user's new way with minimal complexity. Before I go off and implement this (or rather, before I figure out which vector operations apply here and *then* implement this :) can anyone tell me why this may be a bad idea? Thanks again. On 06/27/2010 01:44 PM, Eric Marsden wrote: >>>>>> "nd" == Nolan Darilek <no...@thewordnerd.info> writes: > > nd> Basically, if a user reaches an intersection and turns onto a new > nd> street, I'd like to provide feedback that he is on a new way as soon as > nd> I can. Granted, GPS inaccuracy makes instantly doing so impossible, but > nd> when the user is a few meters from a given intersection, I should be > nd> able to pretty quickly establish what way he is on. Unfortunately, my > nd> current method leaves a lot to be desired. > > This problem is called "map matching" in the literature. As you > suggest, you can do better than looking for the nearest way if you > take into account routing information included in the OSM data > (highway types, oneway tags, turn restrictions, etc.) > > A student (Lukas Kabrt) is working on a similar problem (without the > "real time" element) for OSM in the Google Summer of Code. He has some > bibliographic references and C# code available at > > http://wiki.openstreetmap.org/wiki/Routing/Travel_Time_Analysis > > Otherwise, projects like Navit and Gosmore do this map matching (using > simpler methods) in realtime; their source code is available. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwn6MkACgkQIaMjFWMehWLA7ACffYQptmGY8shzkMg/98u1/pdr 2EoAmwVmzRanAtXpnYKx7OLnW56hYY2S =g77z -----END PGP SIGNATURE----- _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
