[01:11:36] *** Quits: Horwitz (~mich1@p200300ec9f3e0800022268fffe64e7c4.dip0.t-ipconnect.de) (Ping timeout: 246 seconds) [01:24:42] *** Joins: Horwitz (~mich1@p200300ec9f016300022268fffe64e7c4.dip0.t-ipconnect.de) [01:24:42] *** ChanServ sets mode: +o Horwitz [07:57:08] *** Quits: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) (Ping timeout: 245 seconds) [08:10:55] *** Joins: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) [13:10:01] *** Quits: ilovekiruna (~ilovekiru@ip1f12afe2.dynamic.kabel-deutschland.de) (Quit: Konversation terminated!) [17:36:34] hi all [18:39:24] @ilovekiruna what's your most wanted feature for navit 0.6.0 or 0.7.0? [18:43:57] jkoan, I would have guessed you would know ;-) [18:44:08] one I wait for ages and planned to work on it [18:44:28] *** Joins: ilovekiruna (~ilovekiru@139.174.228.248) [18:44:28] *** ChanServ sets mode: +v ilovekiruna [18:47:05] my most wanted feature would be a speech interface [18:47:28] it annoys me how we are there behind Google Auto [19:03:40] Ah right I remember [19:04:03] but if you want to make it real am also happy about it :-p [19:19:51] yes, this one is probably quite tough, at least for me. This isn't my topic at all [19:21:01] which would be your most favourite? [19:22:01] to be honest, I wonder if it should be really part of navit [19:22:07] or not on a higher level outside [19:24:07] - own tomtom os with support for rds (tmc -> traffic) - new, better gui - core improvements I thin the first one cuts a lot of time, the second could be possible for me and the last one should be considered general but some things are probably need to be rethought [19:24:47] yep, probably a speech interface should be like an interface (like dbus) and the rest must probably be outside of the navit core [19:34:59] tomtom, tmc... I hear work coming my way :-) [19:35:59] OLFDB has TMC to TraFF conversion working on JRE... does tomtom support Java? [19:36:28] for tmc i probably need you help, yes, but for tomtom i don't think its quite your topic isn't it? [19:37:01] Tomtom has only 32MB of ram, and an old crippled kernel which is my goal to update some day [19:37:31] so I take it that Java isn't an option then...? [19:37:50] so, yes, probably it could run java, slow, but possible, but not effective [19:38:03] better than nothing [19:38:24] getting the traffic data into Navit would then be the next thing to consider [19:38:31] i think navit itself will need every bit from those 32MB it can have [19:39:26] Navit itself currently only supports traffic on Android, but I am planning a TraFF HTTP plugin, which would be cross-platform [19:40:13] then one option would be to ask OLFDB for the JRE port of Qz and add HTTP functionality [19:41:50] yes. But the tomtom tmc is an adapter to connect to the device directly. So i think a direct plugin within navit would be great for performance [19:42:12] i can't connect the tmc adapter to anything else [19:42:53] Qz is designed to work with local TMC adapters, do you know the manufacturer of the TomTOm TMC adapter? [19:43:21] if it'S a GNS FM9, then we at least support the command set [19:43:22] one sec, i will see, but i think its tomtom [19:45:25] don't have it on hand right now [19:45:57] probably at the basement, will see tomorrow [19:47:19] according to this link one of them is a GNS FM6: https://www.dg1sfj.de/elektronik/selbstbau/56-tomtom-one-xl-tmc-empfaenger-steckerbelegung [19:48:16] if the FM6 and FM9 use the same protocol, Qz/RDS Surveyor (essentially the core library) should support it [19:48:35] then it would just be a matter of communicating over the serial interface [19:50:23] my adaptor doesn't look like mine, but probably they are similar in function. [19:51:09] if something on the label says GNS or FM6, then the hardware is probably similar [19:51:43] I think another manufacturer of similar devices is Royaltek, no idea if Tomtom ever sold any of these [19:52:01] and I have no idea if the protocol Royaltek uses [19:53:01] what do you think about having it as a traffic-plugin within navit itself? We would need the tmc files per country, right? [19:53:46] yeah, we'd need those, and port everything from Java to C [19:54:15] there is at least one C library for RDS, though I don't know about RDS support [19:54:37] and I am pretty sure they don't do location parsing, we'd have to implement that [19:55:22] and then, the location tables each come with a different license, most are not really free [19:55:44] for Qz, I process the parts I need into a database and distribute that [19:56:13] quite easy in Java if you include HSQLDB, but might be harder in C, especially when running on constrained memory [19:56:30] maybe bundling SQLite might work, but no idea about memory usage [19:56:33] for c we could use sqllite [19:56:43] 32 MB isn't a lot of memory... how do you even navigate beyond city boundaries with that amount of memory? [19:59:01] last time i tested navigation worked, but searching large areas failed and crashed. [20:01:15] actually, in fact the first device I used Navit on had only 64... iirc it managed to calculate a route from Munich to Milan when using nothing lower than trunk for long distance [20:02:49] anyways, just for copyright purposes regarding TMC location tables, I would suggest keeping the TMC decoding and location parsing stuff separate from Navit [20:03:29] does our architecture support third-party modules? then we could keep it in a separate repo [20:04:02] so at least as a separate lib [20:04:14] yes, this is what pkg-config is used for [20:05:15] that would still require the module sources are available at build time, correct? [20:05:42] I was thinking more down the lines of a separate .so to drop into the system [20:07:17] the headers, right. Exactly like all those *-dev packages do on Linux. This is for compile time. For runtime the liker needs to find the lib (so-file) which need to be present [20:21:36] the interface would need to be stable, to the point that the plugin could have release cycles independent of Navit, everything else will be hard to maintain [20:22:16] yep [20:22:48] i would like to do the same with navit plugins [20:23:34] so that we could release core and plugins independent as well [20:32:24] in any case, I guess the main overhead would be Java, plus some inevitable stuff for RDS/TMC and location parsing [20:33:45] HTTP transport and a web server shouldn't take up that much, I have run that kind of stuff on boxes with even less memory (4 or 8 MB iirc, some twenty years ago) [21:54:26] *** Quits: ilovekiruna (~ilovekiru@139.174.228.248) (Quit: Konversation terminated!)