Posted by: Daria
navigation revisited - 09/12/2005 00:25
Try out RoadNav (http://roadnav.sourceforge.net/). The navigation functionality is in a library released under the LGPL.
navigation revisited
Posted by: wfaulk
Re: navigation revisited - 09/12/2005 13:27
Quote:
Roadnav uses the free TIGER/Line files from the US Census Bureau to build the maps
Which we've determined doesn't have accurate enough data, missing things like one-way roads.
Posted by: siberia37
Re: navigation revisited - 09/12/2005 15:32
Quote:
Try out RoadNav (http://roadnav.sourceforge.net/). The navigation functionality is in a library released under the LGPL.
Looks pretty sweet- have to check that one out. It will take some code examination to see if it's up to the challenge of running on the Empeg (with no Math Coprocessor!). And of course, Navigation will never be great with TIGER but I think we can always do our point-to-point directions with Google maps and be happy.
Posted by: tfabris
Re: navigation revisited - 09/12/2005 16:11
I seem to recall they said they also used a second data source in addtiion to Tiger. Perhaps it's worth a look.
Posted by: siberia37
Re: navigation revisited - 09/12/2005 21:31
Quote:Quote:
Try out RoadNav (http://roadnav.sourceforge.net/). The navigation functionality is in a library released under the LGPL.
Looks pretty sweet- have to check that one out. It will take some code examination to see if it's up to the challenge of running on the Empeg (with no Math Coprocessor!). And of course, Navigation will never be great with TIGER but I think we can always do our point-to-point directions with Google maps and be happy.
An examination of the code reveals lots of floating point operations- it's main base point unit seems to be represented by a double. This is opposed to RoadMap where the main base unit is an Integer- Roadmap isn't exactly quick, so I can't Imagine RoadNav would be doable on the Empeg. At least not without some code changes..
Posted by: tfabris
Re: navigation revisited - 09/12/2005 21:37
Aren't there a whole lot of FP-to-Integer libraries that could be grafted in? I mean, yes, I know those aren't as fast as an FPU, but how much FP math are we talking about?
Posted by: tman
Re: navigation revisited - 09/12/2005 23:51
Quote:
Aren't there a whole lot of FP-to-Integer libraries that could be grafted in? I mean, yes, I know those aren't as fast as an FPU, but how much FP math are we talking about?
You can either let the kernel emulate the FP instructions or link in a library which handles it for you. Either one isn't going to be as fast as if you used integers in the first place.
Posted by: genixia
Re: navigation revisited - 08/01/2006 04:26
User-space FP emulation is doable - I've even done in-kernel FP emulation on the empeg. You'd take the performance hit though if you're doing a lot of FP operations. I suspect that would be the case here.
Posted by: mlord
Re: navigation revisited - 08/01/2006 13:10
The default Empeg and Hijack kernels already include floating-point support, emulated in software.
-ml
-ml
Posted by: tfabris
Re: navigation revisited - 08/01/2006 15:28
So Derrick, how much FP are we talking about in that code? 
Posted by: wfaulk
Re: navigation revisited - 09/01/2006 13:53
If the main unit is a floating point figure, as stated, I'd guess nearly all of them.