--- Log opened Sat Jan 26 00:00:00 2019 05:01 -!- xenos1984 [~xenos1984@62.1.171.210] has joined #navit 05:01 -!- mode/#navit [+v xenos1984] by ChanServ 05:46 -!- xenos1984 [~xenos1984@62.1.171.210] has quit [Ping timeout: 268 seconds] 07:25 -!- xenos1984 [~xenos1984@62.1.171.210] has joined #navit 07:25 -!- mode/#navit [+v xenos1984] by ChanServ 08:30 -!- xenos1984 [~xenos1984@62.1.171.210] has quit [Quit: Leaving.] 14:40 -!- mvglasow [~mvglasow@dslb-088-064-184-231.088.064.pools.vodafone-ip.de] has joined #navit 14:56 #navit: < mvglasow> hi all, CI for Android still seems broken, see here: https://github.com/navit-gps/navit/issues/738 14:56 #navit: < mvglasow> would be great if anyone familiar with CircleCI could take a look 16:13 #navit: <+ilovekiruna> hi mvglasow 16:13 #navit: <+ilovekiruna> I tinkered a bit with it in the past 16:14 #navit: <+ilovekiruna> at first I would check the docker container we use to built android 16:59 #navit: <+ilovekiruna> mvglasow: can it be related to shifting the navit build to a separate build script? 17:12 #navit: < mvglasow> ilonvekiruna not really, the merge of that build script ran successfully 17:13 #navit: < mvglasow> and the script itself simply groups a few commands from the previous yml 17:13 #navit: < mvglasow> and between the last commit that worked and the first that failed, there were no changes to the toolchain 17:13 #navit: <+ilovekiruna> mvglasow 17:13 #navit: <+ilovekiruna> have you seen my last message? 17:13 #navit: <+ilovekiruna> on github? 17:14 #navit: <+ilovekiruna> I think I found the problem 17:14 #navit: <+ilovekiruna> the build step before the script installs the ndk 17:14 #navit: <+ilovekiruna> but there seems to be a manual question if the license terms are accepted 17:14 #navit: <+ilovekiruna> we dont give a proper input there so the installation of the ndk quits 17:15 #navit: < mvglasow> let me check how we install the NDK 17:16 #navit: < mvglasow> yeah, we use sdkmnager, which requires that for some packages 17:16 #navit: < mvglasow> did you find any such messages in the log output? 17:17 #navit: <+ilovekiruna> yes 17:17 #navit: <+ilovekiruna> I found exactly those messages on the log of circleci 17:17 #navit: <+ilovekiruna> what I dont like about this part is that is shows to be successful despite failing 17:17 #navit: < mvglasow> thanks for catching that, I'll take care of it 17:18 #navit: <+ilovekiruna> happy that i could be of a help :-D 17:18 #navit: < mvglasow> accepting the license is a bit hackish but I have done that elsewhere 17:19 #navit: <+ilovekiruna> mvglasow: jkoan seems to work on it 17:23 #navit: <+Navit> Hi @all 17:23 #navit: < mvglasow> hi jkoan, I see you've taken care of the issue 17:24 #navit: <+Navit> Switching the image to something newer with ndk suffix seems to help 17:24 #navit: < mvglasow> quick one: in line 78 of circleci.yml, I think we can then drop ndk-bundle 17:25 #navit: < mvglasow> if the image already comes with it 17:25 #navit: <+Navit> I am offline again now. If you wand you can merge the pull request when all builds are green ;) 17:25 #navit: < mvglasow> ok, I'll look into it. Thanks for your help! 18:21 #navit: <+ilovekiruna> mvglasow: what do you think about my idea for the osd? 18:22 #navit: < mvglasow> ah, the blurry picture :-) 18:22 #navit: < mvglasow> so basically, your proposal is to split the screen roughly in half and display an auxmap next to the main one 18:23 #navit: < mvglasow> but with a different style (showing different POIs) and (as far as I can tell form the picture) a different zoom factor? 18:24 #navit: < mvglasow> did I get that correctly? 18:24 #navit: < mvglasow> and in the picture you posted, which would be the auxmap? 18:39 #navit: <+ilovekiruna> I would say in the left part showing no POIs at all 18:39 #navit: <+ilovekiruna> to give a clear view to the road 18:39 #navit: <+ilovekiruna> potentially also zoom in 18:39 #navit: <+ilovekiruna> the auxmap would be the left one which is unlike here just overlayed over the main map 18:43 -!- youte [~youte@95-210-221-249.ip.skylogicnet.com] has quit [Read error: Connection reset by peer] 19:21 #navit: < mvglasow> hmmm... personally, I have taken a different approach to this 19:22 #navit: < mvglasow> by simply using a map style which shows hardly any POIs 19:22 #navit: < mvglasow> and using a zoom level that is sufficiently detailed even in an inner city 19:23 #navit: < mvglasow> (I think I do zoom in a but farther than Navit does by default) 19:23 #navit: < mvglasow> the screenshot I sent you the other day should illustrate it well 19:24 #navit: < mvglasow> the map style is from 0606.at, scaled for the pixel density of my device 19:25 #navit: < mvglasow> I'd first talk about the defaults for the zoom level and the POIs shown on the map 19:26 #navit: < mvglasow> because I don't think the "fat and dirty" approach of Osmarender, which since its discontinuation has started to creep into the OSM Carto style, lends itself particularly well to car navigation 19:34 #navit: < mvglasow> maybe a very easy approach would be to group all non-essential POIs in a single layer (or handful of layers) 19:34 #navit: < mvglasow> maybe even standardized across map styles 19:34 #navit: < mvglasow> and provide a quick way of toggling them 19:35 #navit: < mvglasow> the benefit would be that we'd get to use the full screen, rather than just half of it 19:49 #navit: < mvglasow> also it would probably be less coding work :-) 20:18 #navit: <+ilovekiruna> I for example had that problem in a complicated street in hannover 20:18 #navit: <+ilovekiruna> with all different parking lots very difficult to spot where one actually has to go to 20:19 #navit: <+ilovekiruna> wait, you mean just in those situations remove all the disturbing POIs? 21:23 #navit: < mvglasow> either on demand in those situations, or generally 21:24 #navit: < mvglasow> that is, either use a map style that shows only POI categories relevant while driving 21:25 #navit: < mvglasow> or, if we go for a more "fat-and-dirty" approach, offer a quick way to hide the "fat-and-dirty" POIs 21:25 #navit: < mvglasow> could be an OSD button or a menu item 21:42 #navit: <+ilovekiruna> i could imagine sth else 21:42 #navit: <+ilovekiruna> more along the lines I planned it 21:43 #navit: <+ilovekiruna> could we hide the POIs once we are approaching a change of route, like a crossing, an exit of an autobahn or similiar? 21:44 #navit: < mvglasow> I am really wondering whether we need the fullset of POIs under normal conditions 21:44 #navit: <+ilovekiruna> a very good question 21:44 #navit: < mvglasow> that is, shops, restaurants, water fountains and whatnot 21:45 #navit: <+ilovekiruna> thinking now, shouldnt we need parking places just in case we are close to the final destination? 21:45 #navit: < mvglasow> I use a map style that shows none of these 21:45 #navit: < mvglasow> when I am looking for one of them, I set it as a destination 21:45 #navit: <+ilovekiruna> mvglasow: I hope u know I dont want to push you back, but am really concerned about improving things for the better 21:45 #navit: < mvglasow> sure, no worries 21:46 #navit: <+ilovekiruna> i think we also need to distinguish urban and rurual areas 21:46 #navit: <+ilovekiruna> in rurual areas, the issue might be a lot less important as there arent many POIs anyway 21:47 #navit: < mvglasow> yep, POI density is a thing to consider 21:47 #navit: <+ilovekiruna> can we in anyway measure that???? 21:48 #navit: < mvglasow> maybe there's an easier approach 21:48 #navit: <+ilovekiruna> sure, am all for it 21:48 #navit: < mvglasow> for example, which POI types really matter to a driver and are not the route destination 21:49 #navit: < mvglasow> I could imagine gas stations and parking lots 21:49 #navit: < mvglasow> these should be on the map 21:50 #navit: < mvglasow> opposite example would be restaurants: for the most part, you either have a restaurant as your destination, or you don't care that there's a restaurant nearby 21:50 #navit: <+ilovekiruna> yes, but as it seems sometimes parking lots are heavily overtragged 21:50 #navit: < mvglasow> and if you're looking for restaurants nearby: menu > position > POIs > restaurants 21:51 #navit: <+ilovekiruna> yes, that sounds reasonable 21:52 #navit: < mvglasow> good point about the parking lots 21:52 #navit: <+ilovekiruna> also bus stops should be rather unrelated 21:53 #navit: <+ilovekiruna> i like the idea of optimizing which POIs to display 21:53 #navit: <+ilovekiruna> would be also good to have opinions by jkoan and KaZeR 21:53 #navit: < mvglasow> when you're in a car, yes; might be different for pedestrians 21:53 #navit: <+ilovekiruna> I would say we focus for now on cars 21:54 #navit: <+ilovekiruna> maybe situation is also different in different countries or places 21:54 #navit: < mvglasow> though the 0606.at layout solves that in a rather elegant way by just displaying dots, which is rather unobtrusive 21:54 #navit: < mvglasow> bus stops, that is 21:55 #navit: < mvglasow> focus on car navigation is fine, I use Navit for car, bike and foot navigation 21:56 #navit: <+ilovekiruna> if you give me this layout I could test it in the coming weeks 21:56 #navit: <+ilovekiruna> i think in the week after fosdem will be in hannover 21:58 #navit: < mvglasow> look here: https://wiki.navit-project.org/index.php/Android#0606.at_Android_Layout 21:58 #navit: < mvglasow> maybe it would make sense to integrate it into the Navit source code and adapt it for different displays 21:59 #navit: <+ilovekiruna> so what do the red dots depict here? 21:59 #navit: < mvglasow> bus stops 22:02 #navit: <+ilovekiruna> if you look at screenshots below this, you can already see my point 22:02 #navit: <+ilovekiruna> right now i only see mostly osd layout for the link you sent, am i wrong? 22:16 #navit: < mvglasow> there's a link to the map layout: https://wiki.navit-project.org/index.php/Layout#Mapnik_for_small_screens 22:17 #navit: <+ilovekiruna> I c 22:26 #navit: <+ilovekiruna> a bit general question 22:27 #navit: <+ilovekiruna> should we consider spliting in general both parts now that we can have xi:include? 22:31 #navit: < mvglasow> you mean, map and POIs? 22:33 #navit: <+ilovekiruna> I mean osd and map layout 22:34 #navit: < mvglasow> sure, I would consider those two entirely separate things 22:34 #navit: < mvglasow> map layouts have already been split into separate xml files 22:35 #navit: < mvglasow> which makes it a lot easier to add new map layputs 22:35 #navit: < mvglasow> OSD is a bit more difficult because there is no single root 22:36 #navit: < mvglasow> there are a bunch of elements, all under , together with some other elements 22:44 #navit: <+ilovekiruna> then we could also separate the layouts also more easily in the navit-layouts repo 22:55 #navit: < mvglasow> haven't looked at it yet, but essentially yes, each layout is a separate xml file, only assets would have to be provided somehow 22:59 -!- xenos1984 [~xenos1984@5f39-1aef-fc09-7587-8780-8398-07d0-2001.dyn.estpak.ee] has joined #navit 22:59 -!- mode/#navit [+v xenos1984] by ChanServ 23:27 -!- xenos1984 [~xenos1984@5f39-1aef-fc09-7587-8780-8398-07d0-2001.dyn.estpak.ee] has quit [Ping timeout: 240 seconds] 23:56 -!- mvglasow [~mvglasow@dslb-088-064-184-231.088.064.pools.vodafone-ip.de] has quit [Quit: Leaving] --- Log closed Sun Jan 27 00:00:02 2019