navit-project.org

forum for navit navigation tool
It is currently 21 Aug 2019, 14:18
View unanswered posts | View active topics


All times are UTC


Forum rules


Feel free to ask anything here related to the development process - coding, creating new features, fixing bugs and custom changes of Navit.

Note: For reporting bugs, use the bug tracker.



Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: Traffic and protected API between Navit core modules
PostPosted: 07 Dec 2017, 20:55 
Offline

Joined: 27 Sep 2014, 23:41
Posts: 17
Hi all,

Those of you who followed the IRC channel might know that jkoan and I are currently working on adding traffic (i.e. routing around traffic problems) to Navit. Some of it is outlined on the wiki at https://wiki.navit-project.org/index.php/Category:Traffic.

Currently I am working on matching traffic messages to map segments. A traffic message, simply put, tells us that there is a disruption, say, on the A9 from (coord1) to (coord2). As the source may use a different map than we do, coordinates are only approximate. Attributes (such as road names and categories) can be used to further narrow down the set of candidate ways.

After trying a couple of things, I realized that this will probably require borrowing some route functionality, such as building a route graph and calculating costs. Many of these things are very similar to what route.c does (to the point that some code could be reused), though some things are different.

(Of course there are also TMC location codes, if they are maintained in the map and the message was received via TMC, in which case we’re planning to use them. However, if that particular TMC code is not on the map, or if we’re getting traffic news from a completely different channel, we still need to be able to match coordinates and maybe a few attributes.)

Traffic currently lives in its own core module, traffic.c, with its corresponding header file, traffic.h. The route graph-related code is in route.c but not exported in route.h.

To be able to use this in the traffic module, I currently see three options:

1. Export everything we need, i.e. structs and function prototypes, through route.h: This would do the trick but may not be the cleanest solution.

2. Move all the traffic functionality into route.c/route.h: This would further fatten route.c (which is already quite huge) and is not very clean either, as traffic and route are two quite distinct functionalities that just happen to share some code

3. define a new header file, route_protected.h or the like, from which I export these declarations and which would be included by both route.c and traffic.c, while other modules would import only route.h: Probably cleanest but I’m not sure if this is in any way unexpected for fellow Navit devs.

I have since learned that there is no precedent for two Navit core modules sharing code with each other but not with the rest of the world, so this would be a first. I am leaning towards the third option but would like to hear what other people’s opinions are.


 Profile  
 
 Post subject: Re: Traffic and protected API between Navit core modules
PostPosted: 08 Dec 2017, 22:04 
Offline
User avatar

Joined: 06 Jan 2014, 19:34
Posts: 45
Location: Franken, Bayern, Germany
That's way over my head. Any variant that works would be greatly appreciated, though :-)

I'd opt for using shared code and a shared data model, as that should result in the smallest possible memory and CPU usage footprint. That's not an issue on my phone with 3GB of RAM and 8 cores, but it's very much an issue on my old 8" tablet with 1 active core and less than 1GB RAM. I prefer the latter for routing because the screen has twice the real estate, making it much easier to reed when driving.


Just my € 0,02

Ektus.


 Profile  
 
 Post subject: Re: Traffic and protected API between Navit core modules
PostPosted: 11 Dec 2017, 20:14 
Offline

Joined: 27 Sep 2014, 23:41
Posts: 17
Code and data model will be shared no matter which of the three options we choose—they are just a matter of refactoring.

For the moment, I’m sticking with option 3, as it is easiest to refactor if we eventually decide otherwise. That doesn’t mean comments are closed—feedback is highly appreciated!


 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Silver Orange 2.0.6 for IPB Designed by Skins and Hosting
Converted for phpBB3, based on Royal Blue template by BigB © 2007 2008 AEON KINGS