--- Log opened Sat Mar 03 00:00:17 2018
00:16 -!- Horwitz [~mich1@p200300800E242600022268FFFE64E7C4.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
00:28 #navit: < Navit> The following compiles failed: http://download.navit-project.org/logs/navit/android_armv5te/svn/navit-svn-.failed http://download.navit-project.org/logs/navit/osm-exp/svn/navit-svn-.failed http://download.navit-project.org/logs/navit/src/svn/navit-svn-.failed http://download.navit-project.org/logs/navit/openmoko/svn/navit-svn-.failed http://download.navit-project.org/logs/navit/win32/svn/navit-svn-.failed http://download.navit-project.org/logs/navit/n
00:28 #navit: < Navit> oad.navit-project.org/logs/navit/android_armv4t/svn/navit-svn-.failed http://download.navit-project.org/logs/navit/android_x86/svn/navit-svn-.failed http://download.navit-project.org/logs/navit/tomtom/svn/navit-svn-.failed
00:29 #navit: < Navit> See compile results history at http://download.navit-project.org/logs/navit/stats.html
00:29 -!- Horwitz [~mich1@p200300800E2C5600022268FFFE64E7C4.dip0.t-ipconnect.de] has joined #navit
00:29 -!- mode/#navit [+o Horwitz] by ChanServ
01:30 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has quit [Ping timeout: 256 seconds]
01:38 -!- j_f-f [~quassel@rs-7.jff-webhosting.net] has joined #navit
03:37 -!- noradtux [~noradtux@134.101.197.176] has quit [Ping timeout: 260 seconds]
03:37 -!- noradtux [~noradtux@port-10967.pppoe.wtnet.de] has joined #navit
04:54 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has joined #navit
04:54 -!- mode/#navit [+v xenos1984] by ChanServ
12:32 #navit: <+ilovekiruna> hi all
12:32 #navit: <+ilovekiruna> KaZeR: I would now submit expenses. Who is admin of navit collective?
14:24 #navit: <+ilovekiruna> seems like opencollective can just reimburse via paypayl
14:26 #navit: <+ilovekiruna> not sure if opencollective then makes too much of sense
17:12 #navit: <@KaZeR> ilovekiruna: expense approved
17:13 #navit: <@KaZeR> opencollective will only make sense if we can grow our number of contributors there
17:13 #navit: <@KaZeR> ilovekiruna: you still owe me pictures :)
17:14 #navit: <+ilovekiruna> KaZeR: it just means to get reimbursed I first need to get a paypal account
17:14 #navit: <+ilovekiruna> without I wont get any money
17:22 #navit: <@KaZeR> ilovekiruna: yeah i see an iban there but not sure i can use that
17:23 #navit: <@KaZeR> the pictures was about the shirt or fosdem, or something for social media ;)
17:25 #navit: <+ilovekiruna> KaZeR: I got an email from collective
17:25 #navit: <+ilovekiruna> they say, ONLY paypal
17:26 #navit: <+ilovekiruna> I understand the question for pictures, I just have no picture of myself at FOSDEM
17:37 #navit: <+ilovekiruna> plus according to the FAQ, I need to fill a US-Form
17:38 #navit: <+ilovekiruna> https://www.irs.gov/pub/irs-pdf/fw8ben.pdf
17:40 #navit: <+ilovekiruna> or did i misunderstand sth?
18:58 -!- mvglasow [~mvglasow@ipservice-092-211-143-103.092.211.pools.vodafone-ip.de] has joined #navit
19:25 -!- mvglasow [~mvglasow@ipservice-092-211-143-103.092.211.pools.vodafone-ip.de] has quit [Ping timeout: 260 seconds]
19:37 -!- mvglasow [~mvglasow@dslb-188-104-111-252.188.104.pools.vodafone-ip.de] has joined #navit
20:15 #navit: < mvglasow> hi folks
20:33 #navit: <+ilovekiruna> hi mvglasow
20:34 #navit: <@KaZeR> hi mvglasow !
20:35 #navit: <@KaZeR> ilovekiruna: shit i wasn't aware of that
20:35 #navit: < mvglasow> hi ilovekiruna, KaZeR
20:36 #navit: < mvglasow> can any of you guys provide me with some information on the following:
20:37 #navit: < mvglasow> related to the traffic branch - currently traffic distortions are inherently bidirectional
20:38 #navit: < mvglasow> unless the road in question has separate carriageways, being able to have traffic distortions that are different for both directions requires some extra coding
20:38 #navit: < mvglasow> we already have access flags expressing that for ways
20:39 #navit: < mvglasow> conceptual difference: ways indicate where we can go, the oneway flags specify exceptions
20:40 #navit: < mvglasow> while traffic distortions indicate where we can't (or can't easily) go
20:40 #navit: < mvglasow> in a way, they're similar to turn restrictions
20:40 #navit: < mvglasow> so the question is: how do we currently handle directionality for turn restrictions?
20:41 #navit: < mvglasow> are they always directional?
20:42 #navit: <@KaZeR> mm that's a good question
20:43 #navit: <@KaZeR> iirc, ways
20:44 #navit: <@KaZeR> iirc, ways's direction are defined by the vector coordinates. we should be able to leverage that for traffic too
20:44 #navit: <@KaZeR> how do you currently know which direction is impacted for a traffic report/information?
20:45 #navit: < mvglasow> traffic reports have two coordinate pairs and a flag for directionality (unidirectional or bidirectional)
20:46 #navit: < mvglasow> that is, the traffic API has a way to supply that information, the question is how to translate it into traffic_distortion items
20:46 #navit: < mvglasow> for ways, there are the access flags, which can set AF_ONEWAY or AF_ONEWAYREV
20:47 #navit: < mvglasow> if none is set, the way is passable in either direction
20:47 #navit: < mvglasow> AF_ONEWAY indicates the way can only be passed in the order of its points, not in the reverse order
20:47 #navit: < mvglasow> AF_ONEWAYREV indicates the opposite
20:48 #navit: < mvglasow> we could introduce the same for traffic distortions
20:48 #navit: < mvglasow> which, at the map level, are essentially ways
20:49 #navit: <@KaZeR> exactly. so the two coordinate pairs of traffic reports allow you to know the direction of the report.. so it matches how it's done for ways today
20:50 #navit: < mvglasow> right, the only question...
20:50 #navit: < mvglasow> ...if I have a traffic distortion with a maxspeed of 0 (indicating a closure) and AF_ONEWAY...
20:51 #navit: < mvglasow> what is the more logical interpretation?
20:51 #navit: <@KaZeR> 0 meaning that it's actually closed, or that the reported speed is really close to 0 ?
20:51 #navit: < mvglasow> that the closure applies only when travelling in the order of the points? or that it applies when travelling against it?
20:52 #navit: < mvglasow> 0 technically results in the segment being given a weight of INT_MAX
20:52 #navit: < mvglasow> which is the same as a segment closed to the current vehicle type
20:52 #navit: <@KaZeR> i believe that the closure applies only when travelling in the order of the points.. at least that's my understanding
20:52 #navit: < mvglasow> thus it is an actual closure
20:53 #navit: < mvglasow> "that's my understanding"... well, it's not implemented yet, my question was how to best implement this
20:53 #navit: < mvglasow> or is there a better way to do this than with access flags?
20:55 #navit: <@KaZeR> i meant "closure should apply" :)
20:55 #navit: < mvglasow> hence my question on how directionality is implemented for turn restrictions
20:58 #navit: <@KaZeR> i think that turn restrictions are a bit different, in the sense that they affect a relationship between ways
20:59 #navit: <@KaZeR> a turn restriction will prevent you to route from way A to way B, but would allow from B to A
21:00 #navit: <@KaZeR> so the directionality of ways isn't considered, only the sequence of ways
21:00 #navit: <@KaZeR> makes sense?
21:01 #navit: < mvglasow> indeed, that's what I suspected
21:02 #navit: < mvglasow> then how about this:
21:02 #navit: < mvglasow> for ways, access flags determine what vehicles can use the way, and in which direction
21:03 #navit: < mvglasow> for traffic distortions, access flags determine which vehicles and directions the traffic distortion applies to
21:04 #navit: < mvglasow> so if the current vehicle profile is "car", then traffic distortions which do not have "AF_CAR" set are ignored
21:05 #navit: <@KaZeR> makes total sense. a traffic jam shouldn't affect pedestrians
21:06 #navit: < mvglasow> we could make it affect pedestrians by setting AF_PEDESTRIAN... in theory
21:06 #navit: < mvglasow> though that's likely to be rare in reality
21:07 #navit: <@KaZeR> yep, unless we can get informations about closed walkways for example
21:08 #navit: < mvglasow> that's up to the plugin developers and their data sources
21:08 #navit: <@KaZeR> exactly. i'm currently unaware of a datasource that would provide that, but the implementation you suggest would directly allow it
21:08 #navit: < mvglasow> anyways, my point is: for ways the access flags state who can use it, for traffic distortions the access flags state who it applies to
21:09 #navit: <@KaZeR> yep
21:09 #navit: < mvglasow> good, then I'll implement it this way
21:10 #navit: < mvglasow> thanks for your input
21:10 #navit: <@KaZeR> anytime
22:33 #navit: <+ilovekiruna> KaZer: PING
23:24 -!- mvglasow [~mvglasow@dslb-188-104-111-252.188.104.pools.vodafone-ip.de] has quit [Quit: Leaving]
23:43 -!- xenos1984 [~xenos1984@22-164-191-90.dyn.estpak.ee] has quit [Quit: Leaving.]
--- Log closed Sun Mar 04 00:00:18 2018