[00:51:06] *** Quits: Horwitz (~mich1@p200300EC9BC27800022268FFFE64E7C4.dip0.t-ipconnect.de) (Ping timeout: 252 seconds) [01:04:02] *** Joins: Horwitz (~mich1@p200300EC9BC57000022268FFFE64E7C4.dip0.t-ipconnect.de) [01:04:03] *** ChanServ sets mode: +o Horwitz [04:01:57] *** Joins: xenos1984 (~xenos1984@188.187.111.7) [04:01:57] *** ChanServ sets mode: +v xenos1984 [04:28:08] *** Quits: xenos1984 (~xenos1984@188.187.111.7) (Quit: Leaving.) [06:53:37] *** Joins: naggety (~naggety@235.red-2-142-56.dynamicip.rima-tde.net) [09:58:49] Hi. I've been investigating about the big areas painted in blue. As I said, I'm using a map of Spain and Portugal. I've followed this: http://wiki.navit-project.org/index.php/Troubleshooting#Incomplete_Coastlines_within_OSM_Data [10:01:16] I've found 2 poly_water_tyled elements that seems to be creating this mess: https://www.openstreetmap.org/way/286172520 and https://www.openstreetmap.org/way/587342136 [10:02:11] There may be more, but those 2 are which I've found. Both are from Portugal map, and in fact, if I disable Portugal and let only Spain map, the problem disappear. [10:02:22] How can I check what's wrong with that elements? [10:04:48] What can be done to limit the impact of this kind of errors in OSM data? Can I help with that? [13:39:17] *** Joins: xenos1984 (~xenos1984@188.187.111.7) [13:39:17] *** ChanServ sets mode: +v xenos1984 [14:06:32] *** Joins: FranseFrikandel (~FranseFri@2001:1c00:2502:8100:bc5f:1ae:31b:3725) [14:07:55] Hey guys, I have a question. Is there any feature in Navit that allows me to only load the required maps when I have multiple? [14:08:39] Was trying out navit on my laptop, looking to run it on an RPi but it seems a bit slow, however I do have the entire EU map on it. So I was thinking maybe only having needed countries loaded in could help, while still being able to navigate everywhere? [14:24:42] *** Quits: naggety (~naggety@235.red-2-142-56.dynamicip.rima-tde.net) (Quit: Konversation terminated!) [15:14:41] damn looks like the discord gateway broke again [15:25:23] *** Quits: Navit (~Navit@ec2-34-214-224-248.us-west-2.compute.amazonaws.com) (Remote host closed the connection) [15:26:08] *** Joins: Navit (~Navit@ec2-34-214-224-248.us-west-2.compute.amazonaws.com) [15:26:08] *** ChanServ sets mode: +v Navit [15:26:25] discord <-> irc check 1,2 1,2! [15:30:15] <07KaZeR> @viktorgino here's your invite for the qt5 UI mockups repo : https://github.com/navit-gps/navit-gui-qt5/invitations [15:31:10] <07viktorgino> thanks, will push the design files i have so far later [15:31:28] *** Quits: xenos1984 (~xenos1984@188.187.111.7) (Ping timeout: 252 seconds) [15:31:45] Hi guys. I think you might've missed my question earlier due to the discord - IRC link not working? [15:32:15] I was wondering if there was some possibility to have all countries as seperate maps and only load in needed ones, as opposed to always having entire EU map loaded? [15:33:11] Because navit felt a bit on the slow side on my laptop, and was planning on using it on a RPi later. Was wondering if it could be related to a large map? [15:33:38] hi FranseFrikandel [15:34:45] using one large map or multiple small ones shouldn't have a big impact as navit only loads the blocks of data it needs [15:35:05] what felt slow? the routing, or using navit in general? [15:35:34] *** ChanServ sets mode: +v genesis [15:35:54] *** ChanServ sets mode: +v Mineque [15:36:00] Haven't tried a lot. Just the loading speed scrolling around the map. However I guess when actually navigating it would be a lot less noticable than when actually driving as you're covering less distance. [15:36:25] it could be related to the zoom level you are using and the number of items displayed in that zoom level [15:36:30] I still don't have the hardware for all the other stuff, so no GPS etc. yet. [15:36:56] i've been using navit on raspberry pis (2 and 3) extensively and it works quite well [15:37:09] if you are using the default map layout and zoom level that could explain it [15:37:22] Yea I definetly still have to do some editing of the config, there's waaayyy too much stuff on there [15:37:25] if you zoom in closer to the road, is it getting better? [15:37:46] haha yeah. it's hard to find the balance between showing what it can display and displaying what's actually useful [15:37:56] i mean, for the default config [15:39:20] Okay yea can't really say what zoom level might be better or worse, but it's a lot quicker if you're not overtop a big city actually [15:40:26] I'll try out and see if changing config around fixes it. I was mostly wondering if seperated maps could be faster or not. It's not unbearably slow but was just wondering if I could make it more responsive [15:40:57] tweaking the map layout will definitely help. the numbers of maps should have almost no impact because of the way navit uses them [15:44:01] Oh and I also noticed, being zoomed out really far basically turns the entire coast line into big blocks. Now tbh you'd never zoom out this far for actual navigation but was wondering if it's a bug or not? [15:45:39] it's a trade-off. details and workarounds are explained here : https://trac.navit-project.org/ticket/854 [15:46:25] haha quite awesome naggety posted an update in that ticket 90 mins ago [15:49:23] Right I see, thanks a lot! [15:49:36] np, anytime [16:06:19] *** Quits: jasom (~aidenn@ip70-185-146-64.sb.sd.cox.net) (Ping timeout: 246 seconds) [16:53:46] *** Joins: jandegr (6dec8e9f@109.236.142.159) [17:03:49] *** Quits: FranseFrikandel (~FranseFri@2001:1c00:2502:8100:bc5f:1ae:31b:3725) (Remote host closed the connection) [18:00:01] hi kazer [18:05:28] hey ilovekiruna [18:05:59] *** ChanServ sets mode: +v jandegr [18:06:48] kazer, can you explain me a little the fix you asked me to review? [18:06:59] I wonder how the second change relates to build issues [18:12:49] well without this check will make the compilation fail if the struct zip_cd doesn't match what we need [18:13:03] so if you are building with an incompatible libzip version for example [18:13:13] instead of making navit unable to load the map at runtime [18:14:34] it is not related to zipfile kazer [18:15:12] but a misconfiguration of a cross compilation environment, [18:15:34] hence moving from mingw32 to mingw64 brought this up [18:16:23] unless were talking about another issue.......... [18:16:48] we're talking about https://github.com/navit-gps/navit/pull/806/files jandegr [18:17:40] ok, so my remark still stands :) [18:18:02] jandegr, thanks for the explanation [18:19:06] the cryptical check in zipfile.h breaks compilation if it is not ok and prevents distribution of not working binaries [18:19:26] cp15's way :) [18:20:01] but if it fails then reconfigure instead of removing the check !!!!! as was done last year [18:28:00] jandegr: but it would fail if the size of the struct doesn't match what we use, no? [18:30:06] yes and basically the underlying issue is https://stackoverflow.com/questions/3318410/pragma-pack-effect [18:31:06] after removing the check in zipfile last year it then gave errors in binfile at runtime instead of aborting compilation [19:02:21] kazer: I am making progress on the device farm :-) [19:02:32] building a gentoo VM with stf installed [19:37:22] such a mess. [19:37:48] why a vm when you can have a native package. [19:38:09] btw gentoo is dead. [19:42:04] genesis, vm because I have a server with on which I can run it [19:42:14] gentoo still seems pretty alive for me :-) [19:42:38] but i know you prefer nix based OS [19:47:47] *** Joins: xenos1984 (~xenos1984@188.187.111.7) [19:47:47] *** ChanServ sets mode: +v xenos1984 [19:51:03] yes, know you'll remember in few years. [19:51:39] but I am happy with my system, no need to change [19:51:41] my 15 years gentoo experience and friends means nothing, but reality would kick off, portage is abandonware. [19:53:11] when did you an update ?? [19:54:15] a world update. [19:54:31] regularly [20:04:23] *** Quits: jandegr (6dec8e9f@109.236.142.159) (Remote host closed the connection) [20:11:59] *** Joins: jandegr (6dec8e9f@109.236.142.159) [20:11:59] *** ChanServ sets mode: +v jandegr [20:19:32] *** Quits: jandegr (6dec8e9f@109.236.142.159) (Remote host closed the connection) [20:36:08] jkoan: seems like the VM starts stf now :-) [22:03:26] *** Quits: xenos1984 (~xenos1984@188.187.111.7) (Ping timeout: 252 seconds)