--- Log opened Sat Nov 08 00:00:34 2014
00:08 -!- mvglasow [4d046978@gateway/web/freenode/ip.77.4.105.120] has quit [Quit: Page closed]
01:13 -!- mvglasow [4d046978@gateway/web/freenode/ip.77.4.105.120] has joined #navit
01:14 -!- mvglasow [4d046978@gateway/web/freenode/ip.77.4.105.120] has quit [Client Quit]
01:21 -!- curious [~curious@ejb106.internetdsl.tpnet.pl] has quit [Ping timeout: 244 seconds]
01:22 -!- curious [~curious@ejb106.internetdsl.tpnet.pl] has joined #navit
01:26 -!- KaZeR [~KaZeR@64.201.252.132] has quit [Remote host closed the connection]
01:41 -!- KaZeR [~KaZeR@75.144.20.73] has joined #navit
01:41 -!- mode/#navit [+o KaZeR] by ChanServ
05:17 -!- drlizau [~liz@billiau.net] has joined #navit
06:01 -!- xenos1984 [~quassel@131-237-196-88.dyn.estpak.ee] has joined #navit
06:09 -!- noradtux [~noradtux@2a02:8108:28bf:fc94::1] has quit [Ping timeout: 260 seconds]
06:09 -!- noradtux_ [~noradtux@2a02:8108:28bf:fc94:edd0:f070:6da9:fdb0] has joined #navit
06:09 -!- noradtux_ is now known as noradtux
07:25 -!- xenos1984 [~quassel@131-237-196-88.dyn.estpak.ee] has quit [Remote host closed the connection]
07:54 -!- udovdh [~udovdh@pindarots.xs4all.nl] has joined #navit
08:07 -!- bafplus [~bafplus@5ED0A3EE.cm-7-1c.dynamic.ziggo.nl] has joined #navit
08:48 -!- jandegr [50c837a8@gateway/web/freenode/ip.80.200.55.168] has joined #navit
08:52 -!- KaZeR [~KaZeR@75.144.20.73] has quit [Remote host closed the connection]
08:56 -!- KaZeR [~KaZeR@75.144.20.73] has joined #navit
08:56 -!- mode/#navit [+o KaZeR] by ChanServ
09:13 -!- KaZeR [~KaZeR@75.144.20.73] has quit [Remote host closed the connection]
09:37 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection]
09:48 -!- Cirox [4f0de10a@gateway/web/freenode/ip.79.13.225.10] has joined #navit
09:49 #navit: < Cirox> hello
09:51 #navit: < Cirox> im using Navit on nokia N900 with maemo5. we have a repo but sometimes id like to build latest navit myself. im taking a look to the building scripts here http://bokomoko.de/~rd/navit/build_navit_n900.tgz
09:51 #navit: < Cirox> they get latest navit sources from svn,build in scratchbox and post on bokomoko repo
09:52 #navit: < Cirox> bit complicated as im not expert in all the commands and why something must be build in x86 target instead of armel  any expert in debian package building can suggest a guide/how to build navit locally on scratchbox based from the commands in the scripts?
09:52 #navit: < Cirox> Usul suggested me to ask pini ;)
09:52 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has joined #navit
09:52 -!- mode/#navit [+o KaZeR] by ChanServ
09:54 -!- rd [~rd@pD9E7C770.dip0.t-ipconnect.de] has joined #navit
09:54 -!- rd is now known as Guest17252
09:59 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has quit [Ping timeout: 245 seconds]
10:01 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has joined #navit
10:02 -!- mode/#navit [+o KaZeR] by ChanServ
10:11 #navit: < Cirox> i will read irc logs
10:11 -!- Cirox [4f0de10a@gateway/web/freenode/ip.79.13.225.10] has left #navit []
10:50 -!- tryagain [~quassel@178.216.76.72] has joined #navit
10:58 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
10:59 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has joined #navit
10:59 -!- mode/#navit [+o KaZeR] by ChanServ
11:04 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
11:25 -!- udovdh [~udovdh@pindarots.xs4all.nl] has quit [Quit: Leaving]
12:19 -!- Guest17252 [~rd@pD9E7C770.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds]
12:26 -!- Guest17252 [~rd@pD9E7C770.dip0.t-ipconnect.de] has joined #navit
13:51 -!- Guest17252 [~rd@pD9E7C770.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
13:53 -!- Guest17252 [~rd@pD9E7C770.dip0.t-ipconnect.de] has joined #navit
13:59 -!- xenos1984 [~quassel@131-237-196-88.dyn.estpak.ee] has joined #navit
14:30 -!- mvglasow [5d86cb9d@gateway/web/freenode/ip.93.134.203.157] has joined #navit
14:31 #navit: < mvglasow> Hi tryagain, do you have a few minutes? I have some questions on the data structures of the route graph map (navigation.c)...
14:33 #navit: < jandegr> hi mvglasow nice to see you here : a screenshot of a few novelties I am working on in navigation.c https://db.tt/SYOz4QE9
14:34 #navit: < mvglasow> Hi jandegr, nice work!
14:34 #navit: < jandegr> = merge onto highway, take exit and yes Navit now can go straight instead of giving a false 'go right' instruction
14:35 #navit: < jandegr> since you work on navigation.c as well, maybe we can work together some day
14:36 #navit: < mvglasow> sure, in fact I had been planning some related stuff to fix #694 and #795
14:37 #navit: < mvglasow> but currently I'm still in the middle of #660, i.e. when to announce a maneuver at all, and after that I would have tackled the content of those maneuvers
14:39 #navit: < jandegr> the canges I made cover (partially or on whole) : #1265, #1271, #1174, #921, #795, #694 and #660
14:40 #navit: < jandegr> it is usefull to scrape all related tickets together and have a look at the big picture instead of focussing on individual tickets, IMHO
14:42 #navit: < jandegr> next topic for me : it now says 'take the exit' but it must be more polite and say 'take exit 24 paris nord'
14:43 #navit: < mvglasow> yep, that's what I'd been discussing witk kazer earlier, but didn't get around to doing
14:43 #navit: < mvglasow> not yet, that is
14:44 #navit: < mvglasow> #660 turned out to be trickier that I'd expected
14:45 #navit: < mvglasow> the latest incarnation of the patch (not merged yet) works quite well, it eliminates a few cases of missing or superfluous maneuvers, except for one case...
14:46 #navit: < mvglasow> ...when turn restrictions eliminate all but one option – I'm still working on suppressing maneuvers for those cases
14:47 #navit: < mvglasow> jandegr, do you have your code available somewhere? patch, git repo or the like?
14:48 #navit: < mvglasow> since you mentioned #660, I'm curious to know if there are any changes in maneuver_required()
14:48 #navit: < jandegr> some time next week, right now my code looks like worldwar I started over again :)
14:48 #navit: < mvglasow> all right, I'll wait and see :)
14:50 #navit: < mvglasow> is it OK for you if in the meantime I commit the latest #660 patch (as attached to the ticket)?
14:50 #navit: < jandegr> and now I am trying to document as much as possible in a 'work version' of the code
14:54 #navit: < jandegr> you can commit whenever you want, I temporary don't update from SVN anymore because I find it difficult to work on or study code that changes by external influence.
14:55 #navit: < mvglasow> yeah, that does introduce some complexity :-)
14:57 #navit: < jandegr> anyway, I was about to stop for today and just wanted to throw in a screenshot for some of the sceptics over here
14:57 #navit: < jandegr> nice meeting you, some time next week for a more in depth conversation ?
15:01 #navit: < mvglasow> sure, weekend is probably best, maybe I'll manage to be around in the evenings as well (except Wednesday)
15:06 #navit: < jandegr> ok, last word on the screenshot, notice the first instruction shown is 'merge onto' and yet the osd already has name_systematic available in the textfield on the top of the screen :)
15:07 #navit: < jandegr> clarify : that is name_systematic of the highway we are going to merge onto
15:11 -!- jandegr [50c837a8@gateway/web/freenode/ip.80.200.55.168] has quit [Quit: Page closed]
15:56 #navit: < tryagain> mvglasow dont ask to ask, just ask :)
15:56 #navit: < mvglasow> ah, there you are :-)
15:57 #navit: < mvglasow> in a nutshell: I'm working on #660, fixed most cases in which no announcement is required, except for one...
15:58 #navit: < mvglasow> when there are multiple ways and all but one are ruled out by turn restrictions - for this I need to (re-)parse turn restrictions in navigation.c
15:58 #navit: < mvglasow> I've tried two things, but both to no avail:
16:00 #navit: < mvglasow> First attempt: edit navigation_itm_ways_update() to add only those ways which are ot forbidden by a turn restriction
16:01 #navit: < mvglasow> problem here: calling item_coord_rewind() or item_coord_get() on the street_item of a rg_segment occasionally segfaults
16:01 #navit: < mvglasow> most of the time it works, but occasionally it'll segfault
16:01 #navit: < mvglasow> when it does return coordinates, they look correct
16:02 #navit: < mvglasow> it might be a bug in the implementation in binfile.c (that's where the segfault happens), but I'm not famliar enough with the code to figure that out
16:03 #navit: < mvglasow> Second attempt: add a new function is_maneuver_allowed(nav, old, new) which gets called from maneuver_required2
16:04 #navit: < mvglasow> I pass nav and old just as maneuver_required2() gets them, new is the way to examine
16:04 #navit: < mvglasow> maneuver_required then should search the map for turn restrictions
16:05 #navit: < tryagain> you have to get item before you call its member functions. There can be only one active item in each map_rect. Are you sure you use an active item?
16:06 #navit: < tryagain> * that was a comment for the first attempt
16:06 #navit: < mvglasow> thanks, problem with 2nd attempt: when I do
16:06 #navit: < mvglasow> graph_map = route_get_graph_map(nav->route);
16:06 #navit: < mvglasow> g_rect = map_rect_new(graph_map, &coord_sel);
16:07 #navit: < mvglasow> and query the map, it doesn't contain any turn restrictions
16:10 #navit: < mvglasow> so I figure I'd need to add the turn restrictions to the map somewhere – where would I do that?
16:11 #navit: < mvglasow> However, inactive map item sounds like that was the issue
16:12 #navit: < mvglasow> but anyways I'm not sure dropping ways from the navigation_itm is the way to go, I'm a bit worried about side effects
16:13 #navit: < mvglasow> so I'd prefer the second approach (is_maneuver_allowed), but I'd need to get the turn restrictions into the route graph map, just need to know what part of the code I'd need to plug into
16:14 #navit: < tryagain> i see the code in navigation.c which attempts to work with turn restrictions returnet from route graph map. But i'm unsure ifthey ever could be returned by route (or route graph) map...
16:15 #navit: < tryagain> actually we have two maps, route and route graph. Probably route graph could have them while route map does not. Have to read the code to catch that.
16:16 #navit: < tryagain> Another way could be rading the underlaying map at a given point to analyse all items near it. Not an elegant solution.
16:17 #navit: < tryagain> Though corresponding tiles should be already in memory cache, unzipped, so performance impact is not too big.
16:18 #navit: < mvglasow> you mean navigation_itm_ways_update in navigation.c? That (currently) has some code to skip turn restrictions, and after extensive fiddling I know for a fact that this code does encounter turn restrictions...
16:18 #navit: < mvglasow> ...parsing them is a bit tricky, but all the information is there
16:19 #navit: < tryagain> yes, we're talking about same function
16:20 #navit: < tryagain> So if you put that code in a different place, it does not return restrictions? Or maybe you code works with route map, not with route graph one?
16:22 #navit: < mvglasow> if I run this in a function that gets called from maneuver_required2(), using route_get_graph_map(nav->route), I get a rg_point and a list of rg_items (including the old and the new way), but not a single turn restriction
16:22 #navit: < mvglasow> the code is the same (copied in), just the map may be a different one
16:24 #navit: < mvglasow> what if I gave navigation_itm_ways_update() an additional navigation argument (passed from caller) and copied all turn restrictions I encounter in one map to the other?
16:29 #navit: < tryagain> hm. The map should be the same, route_get_graph_map and route_get_map_helper do the trick by caching map in route->graph_map
16:29 -!- Guest17252 [~rd@pD9E7C770.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds]
16:29 #navit: < tryagain> and there's no problem in changing footprint of static function
16:29 -!- Guest17252 [~rd@pD9E7C770.dip0.t-ipconnect.de] has joined #navit
16:33 -!- jandegr [50c837a8@gateway/web/freenode/ip.80.200.55.168] has joined #navit
16:33 #navit: < mvglasow> I just found something else... there's route_get_graph_map() and route_get_map(). I've used the first, let's see what the second one does (that's the call from which navigation_itm_ways_update() seems to get its map)
16:33 #navit: < mvglasow> I'll test this, hang on...
16:35 #navit: < tryagain> sure, there are two maps, one containing the whole graph, another only path
16:35 #navit: < mvglasow> ...nope, this doesn't even contain any rg_point items
16:39 #navit: < tryagain> can you share your curent patch in which you try to clone navigation_itm_ways_update way of getting route graph map?
16:46 #navit: < mvglasow> hang on, I'll push to github
16:55 #navit: < mvglasow> code is at: https://github.com/mvglasow/navit/blob/trac660/navit/navit/navigation.c#L1200
16:55 #navit: < mvglasow> the function gets called in maneuver_required2(), line 1517
17:05 #navit: < tryagain> mvglasow in original code it uses sitem (value of attr_street_item), your code seems to use value returned directly from route graph
17:06 #navit: < mvglasow> look a little further, there are two similar snippets of code
17:06 #navit: < mvglasow> the one you mean is in line 1337
17:07 #navit: < mvglasow> line 1281 is for handling a data structure as we'd get it from the underlying map
17:08 #navit: < tryagain> ah,  i should have read a bit more
17:10 #navit: < tryagain> so it never reach line 1339?
17:19 #navit: < mvglasow> apparently not, else one of the printf()s would generate some output, but I never see any
17:27 #navit: < tryagain> hm it segfaulted for me  in is_maneuver_allowed at line 1389 (minus 3 lines added by me, so in your code is at line 1386), deeper is binfile_coord_get
17:35 #navit: < mvglasow> ok, that's improper use of item_coord_rewind() and item_coord_get() again, you can just comment out this portion for now
17:36 #navit: < mvglasow> more interesting is that you got there, which means you apparently got some turn restrictions out of the map
17:42 #navit: < mvglasow> mdankov: how did you do that?
17:42 #navit: < mvglasow> tryagain how did you do that
17:53 #navit: < tryagain> just some random long route on a map i have
17:56 #navit: < mvglasow> did you modify the code to get turn restrictions? I'm not getting any, and I know for a fact there are some on the way
18:02 #navit: < tryagain> i only have added min and max definitions (it was failing to link) and a printf before 1339.
18:10 #navit: < tryagain> http://pastebin.com/Lm8TmypT
18:11 #navit: < tryagain> It's map around Munchen, but no success to segfault with default pre-shipped map. You'll need a fresher one.
18:12 #navit: < tryagain> It segfaults on almost any route for me.
18:16 #navit: < mvglasow> Did you modify the printf() calls I had in the turn restriction code? I'm surprised that I don't see any output from them, although there seem to be turn restrictions
18:17 #navit: < mvglasow> also, the min() and max() stuff is strange, I'm pretty sure I've added that to the code (r5929 and up)
18:17 #navit: < mvglasow> navit, compile
18:18 #navit: < tryagain> http://pastebin.com/jxEktf64 my current navigation.c
18:19 #navit: < tryagain> hm, my current codebase is 5928
18:20 #navit: < tryagain> navit is spelled Navit and it won't compile for you till it finish with map build (or maptool die)
18:20 #navit: < tryagain> Navit, jump
18:20 #navit: < Navit> How high?
18:21 #navit: < mvglasow> ah, thx for the heads up :-)
18:23 #navit: < mvglasow> did you clone my git repo or did you just paste my navigation.c on top of 5928? in the latter case, we got the reason for the missing min() and max()
18:24 #navit: < mvglasow> otherwise it might mean that r5929 is also botched and would need fixing
18:25 #navit: < tryagain> i have just pasted your navigation.c on top of 5928
18:26 #navit: < mvglasow> ok, so I don't have to worry about the code in SVN
18:26 #navit: < mvglasow> looking at pastebin, I notice I overlooked some output
18:27 #navit: < mvglasow> can you give me the start and end points of your route? I have a fairly recent (Sep 30) map that includes Munich
18:31 #navit: < tryagain> http://pastebin.com/1f7qMT7u new log with two bookmarks
18:33 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has joined #navit
18:33 -!- mode/#navit [+o KaZeR] by ChanServ
18:33 #navit: < jandegr> tryagain and mvglasow , why no tell it to drive straight if delta=0 ?
18:35 #navit: < tryagain> actually, i was going to ask a similar question before gone into debugging, why not announce turn when going straight is prohibited
18:37 #navit: < jandegr> I actually mean the bug that it can not go straigt, if you look at show_maneuver() you will see right away it has a 'go right' bug
18:37 #navit: < tryagain> what if we have some area mapped with access=destination in front of the driver, but there's no road sign or it has passed invisible to driver
18:38 #navit: < tryagain> *that comment was related to my case
18:38 #navit: < mvglasow> hm, true... in that case we probably still want to announce the turn, even if it's the only option
18:39 #navit: < jandegr> hi kazer, in case you did not read logs (and tryagain : it goes straight) https://db.tt/SYOz4QE9
18:39 #navit: < mvglasow> I had assumed that wherever entry into a street is prohibited, there are signs telling drivers about this
18:41 #navit: < jandegr> mvglasow in that cas I still want Navit to assist me in choosing the correct road and instruct me accordingly
18:41 #navit: < mvglasow> and as for "what to announce" – there are separate pieces of code, the one I'm currently working on just decides whether or not to make an announcement
18:42 #navit: < mvglasow> the rest is definitely a candidate for fixing too, but I'll get to that later
18:42 #navit: < mvglasow> jandegr I'll have a look at that again, but it's tricky business
18:43 #navit: < mvglasow> there are plenty of cases in which I don't want an announcement for the only allowed maneuver
18:44 #navit: < mvglasow> example: dual-carriageway road becomes single carriageway, U turns are prohibited – but I don't need Navit to tell me that I need to go straight
18:44 #navit: < mvglasow> maybe we should consider forbidden ways only if they are "straighter" than the route
18:45 #navit: < tryagain> "straighter case" should be announced. i'd probably begin to jump in the chair (or at least look at the navdevice) if i see a straight road where i can't turn but navigational device is silent
18:46 #navit: < tryagain> *where i can't drive, and have to make a turn
18:47 #navit: < mvglasow> ok, I'll look into that
18:48 #navit: < mvglasow> anyway, I'll be mostly AFK for a while but check the screen when I return
18:48 #navit: < tryagain> isn't "dual-carriageway road becomes single carriageway" already handled by the code not announcing "go straight" maneuvers?
18:50 #navit: < jandegr> tryagain it can technically not tell you to drive straight, take the case where we decide on line 1794 to
18:50 #navit: < jandegr> *reason="yes: highway changed name";
18:50 #navit: < mvglasow> I have an example where I'm getting a maneuver. It's a ramp, though, and I've deliberately made Navit a bit chattier when ramps are involved, as motorway interchanges can get quite confusing
18:50 #navit: < jandegr> and we have delta is zero degrees, it tells you to go to the right !
18:51 -!- gringo [~gringo@unaffiliated/gringo] has joined #navit
18:52 #navit: < jandegr> in fact it does not really matter what was decided where, enter show_maneuver() with delta=0 and it tells you to go to the right
18:54 #navit: < jandegr> an if you have strength needed, zero degrees becomes 'easily right'
18:58 #navit: < tryagain> jandegr i agree, we probably need some code to make some turns into "go straight" for some deltas. Delta range could be adjusted, based on existing turn possibilities... I bet i've seen some patch (from mvglasow?) for this...
19:00 #navit: < jandegr> i use a range from -9 to +9 degrees to evaluate to straight, the number nine can be discussed or even dynamically modified, but
19:00 #navit: < jandegr> I say it again zero is never to be announced as to the right !!!
19:02 #navit: < mvglasow> jandegr agree, maneuver_required2 has a local variable turn_limit=25, anything less than that is considered straight
19:02 #navit: < mvglasow> but it's used only in maneuver_required2, we might want to turn it into a globally used constant
19:03 #navit: < jandegr> right you get my point, decide whatever you want wherever you want, show_maneuver() turns it into 'go right'
19:03 #navit: < jandegr> unless delta is negative
19:04 #navit: <@KaZeR> hey guys
19:04 #navit: < mvglasow> anything less than the threshold should be "go straight"... unless there are two or more options going straight
19:05 #navit: < mvglasow> then we'd need to decide based on what the other options are and say something like "keep left" or "keep right"
19:05 #navit: < jandegr> and let the icon for straigh that I use already be present in the code on SF
19:05 #navit: <@KaZeR> jandegr: nice, i like the multiple annouces. we can probably also make them visible depending of the distance between them. for example 3rd maneuver is not mandatory if it is 10 kms after the second
19:06 #navit: < jandegr> agree mvglasow but priority number one must be 'zero is not to the right'
19:06 #navit: < jandegr> kazer If I say i'll do it , then I do it, despite the sceptics over here :)
19:07 #navit: <@KaZeR> jandegr: haha
19:07 #navit: < jandegr> kazer the third maneuver (the straight arrow) is announced as 'go right' by the vanilla code, get my drift ?
19:08 #navit: <@KaZeR> jandegr: have you seen our attempts to log, debug and compare routes ? http://trac.navit-project.org/ticket/1268
19:08 #navit: <@KaZeR> jandegr: yes correct
19:09 #navit: < jandegr> brb
19:09 -!- gringo [~gringo@unaffiliated/gringo] has quit [Ping timeout: 244 seconds]
19:11 #navit: <@KaZeR> since a couple of folks are working on the announcements, i think that now is a good time to start building a functional test script for routes. at first we can use a simple bash script with dbus calls
19:12 #navit: <@KaZeR> we can probably put it in navit/tools for now
19:16 -!- [1]bafplus [~bafplus@5ED0A3EE.cm-7-1c.dynamic.ziggo.nl] has joined #navit
19:16 #navit: < mvglasow> I have one working, wih a couple of test cases, we can start working on that
19:17 #navit: < mvglasow> give me an hour or so, and I'll publish it on my repo
19:17 #navit: < mvglasow> we can use that as a starting point
19:17 -!- bafplus [~bafplus@5ED0A3EE.cm-7-1c.dynamic.ziggo.nl] has quit [Ping timeout: 245 seconds]
19:17 -!- [1]bafplus is now known as bafplus
19:20 #navit: < jandegr> I have no idea how #1268 actually works but it would be nice if you can drive a route side by side on a vanilla navigation.c, mine, mvglasow's and any other version
19:26 #navit: < jandegr> kazer I made it show 3 maneuvers because I have a piece  of a route where at some point the 3 new tricks (merge, exit and straight) actually appear in one screenshot :)
19:27 -!- woglinde [~henning@f053032061.adsl.alicedsl.de] has joined #navit
19:27 #navit: <@KaZeR> mvglasow: excellent thanks
19:27 #navit: < jandegr> but you are completely right about not showing the next-after next if it is several kilometers away, this was for demo  purposes
19:28 #navit: <@KaZeR> sure jandegr. and your idea of side by side is really good. my primary intent was to detect differences, but simultaneous review of different routes is a great idea. and it is quite easy to do
19:31 #navit: < jandegr> kazer I actually meant same route on 2 or more versions of the software at the same time, I suppose that is really easy for you too :)
19:46 #navit: < mvglasow> test script is up: https://github.com/mvglasow/navit-goodies/tree/master/scripts/routetest
19:46 #navit: < mvglasow> right now it's very basic, you wll probably need to edit some variables at the beginning of the file to match your setup
19:47 #navit: < mvglasow> the specification has one line for each test case, format is:
19:47 #navit: < mvglasow> name start_lon start_lat dest_lon dest_lat
19:48 #navit: < mvglasow> the testcases in the file provided are the ones I've been using while working on #660
19:48 #navit: <@KaZeR> nice thanks mvglasow. i'll try it on my github to setup the export and will push it in the trunk
19:50 #navit: <@KaZeR> jandegr: yes i meant same route ( as in same origin and same destination )  but generated with different routing parameters, which would end up producing different routes ( aka path that you should follow ) :)
19:51 #navit: <@KaZeR> mvglasow: i'm surprised about this : # quit Navit (currently this crashes Navit rather than exiting gracefully, but it serves our purpose)
19:51 #navit: <@KaZeR> on my own test suite it quits gracefully i believe. will have to double check
19:51 #navit: <@KaZeR> have to go afk a few, back asap
19:51 #navit: < mvglasow> ok, I got a crash every time I did this
19:51 #navit: < mvglasow> but hey, Navit exits :-)
19:52 #navit: < mvglasow> and it's really quick-and-dirty code that could definitely use some improvements, feel free to embrace and extend :-)
19:53 #navit: <@KaZeR> sure, it's great to have a starting point finally
19:54 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
19:54 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has joined #navit
19:54 -!- mode/#navit [+o KaZeR] by ChanServ
19:58 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
20:06 -!- gringo [~gringo@unaffiliated/gringo] has joined #navit
20:07 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has joined #navit
20:07 -!- mode/#navit [+o KaZeR] by ChanServ
20:17 -!- gringo [~gringo@unaffiliated/gringo] has quit [Ping timeout: 244 seconds]
20:35 #navit: < mvglasow> tryagain, in the meantime I have tried a few more things about the turn restrictions
20:35 #navit: < mvglasow> I tried going through the underlying maps and indeed did see some turn restrictions (didn't parse them yet)
20:36 #navit: < mvglasow> the code I use to iterate through the maps is as follows:
20:36 #navit: < mvglasow> ms = navit_get_mapset(nav->navit);
20:36 #navit: < mvglasow> msh = mapset_open(ms);
20:36 #navit: < mvglasow> for (graph_map = mapset_next(msh, 1); graph_map; graph_map = mapset_next(msh, 1))
20:36 #navit: < mvglasow> all map processing goes in the for loop
20:37 #navit: < mvglasow> this has worked for a while, but all of a sudden I'm just getting one or two maps for each call to the function
20:37 #navit: < mvglasow> different maps each time – it seems like I'm just iterating over a subset of the maps
20:38 #navit: < mvglasow> what am I doing wrong?
20:39 #navit: < mvglasow> I have two binfile maps, plus the route, so I should be iterating over three maps at least (I remember seeing even more than three)
20:42 #navit: < mvglasow> edit... forget what I sid, guess I misinterpreted my debug output
20:50 #navit: < tryagain> mvglasow actually there usually no need to iterate through all maps, street_item->map should give you the map to which an item belongs, and it most probably is worthless to look for corresponding turn restriction in different map
20:51 #navit: < tryagain> ...unless someone will decide to store turn restrictions in separate map
20:52 #navit: < mvglasow> thx, I'll look into it
20:52 #navit: < tryagain> map iterating code looks good, but i would use while((graph_map = mapset_next(msh, 1))!=NULL) instead of for()
20:53 #navit: < tryagain> btw have you succeeded to crash navit in Munich?
20:55 -!- KaZeR [~KaZeR@c-67-161-64-186.hsd1.ca.comcast.net] has quit [Ping timeout: 244 seconds]
20:57 #navit: < mvglasow> haven't tried that part of Munich, I'm currently trying a route from the western end of Verdistraße via A8 to the exit at Langwieder See (with a turn restriction in the exit)
20:57 #navit: < mvglasow> and Navit just won't find any turn restrictions... will try Waldfriedhofstraße
21:03 #navit: < mvglasow> I tried your example, with g_rect = map_rect_new(old->way.item.map, &coord_sel); and again no turn restrictions
21:03 #navit: < tryagain> hm...
21:04 #navit: < mvglasow> will try again with:
21:04 #navit: < mvglasow> graph_map = route_get_graph_map(nav->route);
21:04 #navit: < mvglasow> g_rect = map_rect_new(graph_map, &coord_sel);
21:04 -!- drlizau [~liz@billiau.net] has joined #navit
21:08 #navit: < tryagain> now applied your navigation.c on top of svn 5930, will try with it
21:08 #navit: < mvglasow> interesting... this way I am getting a bunch of turn restrictions now, and Navit is not crashing
21:09 #navit: < mvglasow> so apparently with the navigation.c I gave you, I do get turn restrictios, but some are missing
21:09 #navit: < mvglasow> as for parsing the underlying map: that would have one advantage
21:10 #navit: < mvglasow> as the binfile has turn restrictions in one piece, i.e. with three coordinates (one for from, one or two for via, one for to)...
21:10 #navit: < mvglasow> ...whereas in the route_graph map they are broken into pieces of 2 coordinates each...
21:11 #navit: < mvglasow> ...and a lot of the code you're seeing just deals with putting them back together
21:13 -!- gringo [~gringo@unaffiliated/gringo] has joined #navit
21:15 #navit: < tryagain> it sometimes works fine, sometimes crashes, always reports some turn restrictions. Crash seems to be starting-point dependent.
21:18 #navit: < tryagain> btw another ticket on turn restrictions handling http://trac.navit-project.org/ticket/1215 It requires some maptool change
21:20 #navit: < mvglasow> that would be for turn restrictions where the via member is a way rather than a node
21:21 #navit: < mvglasow> I didn't quite figure out how routing processes them
21:22 #navit: < mvglasow> luckily, for the purpose of generating maneuvers we can skip these cases because we're just looking at single maneuvers
21:22 #navit: < mvglasow> and such complex turn restrictions involve 2 subsequent maneuvers, each of which may be perfectly permissible, just not both in sequence
21:24 #navit: < mvglasow> I think I'll look at sifting through the map file, as I said turn restrictios should be even easier to process
21:24 #navit: < mvglasow> and when I'm done, I'll run this through my stress test (Warsaw–Lisbon) to see how it affects performance
21:34 -!- jandegr [50c837a8@gateway/web/freenode/ip.80.200.55.168] has quit [Quit: Page closed]
21:41 #navit: < tryagain> my ticket is actually not about "via" ways. There's a picture describing it. Maptool just does not store enough info to distinguish in turn restriction two different ways which share common starting and end points.
21:45 -!- KaZeR [~KaZeR@75.144.20.73] has joined #navit
21:45 -!- mode/#navit [+o KaZeR] by ChanServ
21:51 #navit: < mvglasow> ok, I get what you mean
21:53 #navit: < mvglasow> what would the turn restrictions in OSM look like? no_*_turn from (p_way) to (d_way) via (acb_way)? or no_left_turn from (p_way) to (acb_way) via a?
22:14 #navit: < mvglasow> tryagain I tried retrieving turn restrictions from the underlying map, I get a bunch of them but the coordinates don't match for any of them... do the maps use different projections?
22:59 #navit: < tryagain> no_left_turn from (p_way) to (acb_way) via a: https://www.openstreetmap.org/relation/2348347#map=17/51.65917/36.06526
23:00 #navit: < tryagain> mvglasow they can have different projections, but binfile and route graph shouldn't
23:01 #navit: < tryagain> gn
23:01 -!- tryagain [~quassel@178.216.76.72] has quit [Remote host closed the connection]
23:02 -!- mvglasow [5d86cb9d@gateway/web/freenode/ip.93.134.203.157] has quit [Quit: Page closed]
23:06 -!- xenos1984 [~quassel@131-237-196-88.dyn.estpak.ee] has quit [Remote host closed the connection]
23:09 -!- mvglasow [5d86cb9d@gateway/web/freenode/ip.93.134.203.157] has joined #navit
23:10 -!- mvglasow [5d86cb9d@gateway/web/freenode/ip.93.134.203.157] has quit [Client Quit]
23:53 #navit: < Navit> kazer_ * r5925 /trunk/navit/po/es.po.in /trunk/navit/po/fi.po.in /trunk/navit/po/fr.po.in /trunk/navit/po/fr_CH.po.in /trunk/navit/po/mk.po.in /trunk/navit/po/nb.po.in: Update:Core:massive translation update from launchpad, and removed some header to reduce noise during importation http://sourceforge.net/p/navit/code/5925/
23:56 -!- Guest17252 [~rd@pD9E7C770.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
23:58 #navit: < Navit> mvglasow * r5930 /trunk/navit/navit/attr.c /trunk/navit/navit/item.c /trunk/navit/navit/route.c: Refactoring:core:Add doxygen comments http://sourceforge.net/p/navit/code/5930/
--- Log closed Sun Nov 09 00:00:35 2014