--- Log opened Tue May 06 00:00:09 2014 01:19 -!- drlizau [~liz@billiau.net] has joined #navit 01:22 #navit: < Navit> The following compiles failed: http://download.navit-project.org/logs/navit/wince_arm/svn/navit-svn-5772.failed 01:22 #navit: < Navit> See compile results history at http://download.navit-project.org/logs/navit/stats.html 03:07 -!- drlizau [~liz@billiau.net] has quit [Ping timeout: 265 seconds] 05:21 -!- drlizau [~liz@billiau.net] has joined #navit 09:29 -!- xenos1984 [~quassel@131.237.196.88.dyn.estpak.ee] has joined #navit 11:50 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection] 14:29 -!- KaZeR [~kazer@64.201.252.132] has joined #navit 14:29 -!- mode/#navit [+o KaZeR] by ChanServ 14:29 #navit: <@KaZeR> hi there 14:33 #navit: <@KaZeR> i need some help with sdb+ldap. we have an old patch that we always had to apply to get bind to work with our dns ( http://bpaste.net/show/dOGmAdsZijCOc80jJBuE/ ) 14:33 #navit: <@KaZeR> i meant with our ldap schema, not our dns 14:34 #navit: <@KaZeR> i am trying to update this patch so that it works with a newer version of bind. i wrote the update, and it works : i can query the entries which are stored in the ldap server 14:37 #navit: <@KaZeR> but if i try to query a host which is not know, named segfaults : here's the gdb output and bt of the call: http://bpaste.net/show/jc54EKwJ2ryamienUv4N/ 14:40 #navit: <@KaZeR> my updated patch : http://bpaste.net/show/60HPcsk5IiTrDTmlWCpr/ ( applied against bind-9.9.4-P2 ) 15:25 #navit: <@KaZeR> fuck i'm not awake 15:25 #navit: <@KaZeR> obviously the wrong chan :) 17:09 -!- woglinde [~henning@24-134-58-61-dynip.superkabel.de] has joined #navit 18:08 -!- woglinde [~henning@24-134-58-61-dynip.superkabel.de] has quit [Quit: zapp] 19:13 #navit: < ColdFyre> hm 19:14 #navit: < ColdFyre> r5772, is that possible for non-android? 19:21 -!- j_f-f [~quassel@orion2589.server4you.de] has quit [Remote host closed the connection] 19:24 -!- j_f-f [~quassel@orion2589.server4you.de] has joined #navit 19:38 -!- tryagain [~tryagain@178.216.76.61] has joined #navit 19:40 #navit: < tryagain> ColdFyre It's already exist in gtk_drawing_area. What graphics do you want to have glow around the text? 19:41 #navit: < ColdFyre> qt 19:41 #navit: < ColdFyre> i'm running KDE and will likely use the full screen modes 19:42 #navit: < tryagain> ah.. I have not expirence with qt at all... But that should be quite simple. Do you able to compile navit for your needs? 19:43 #navit: < ColdFyre> i just compiled it 5 minutes ago :) 19:43 #navit: < ColdFyre> (yes) 19:43 #navit: < tryagain> :) 19:44 #navit: < tryagain> have you tried to find code in qt similar to what was patched in android? 19:45 #navit: < ColdFyre> i'm not really much of a developer, i know how to compile, read docs, and play with navit's xml file 19:46 #navit: < ColdFyre> tryagain, did you add that glowing text patch? 19:46 #navit: < tryagain> yes 19:47 #navit: < tryagain> do you know your qt version? There are lots of #ifdefs inside qt code 19:48 #navit: < ColdFyre> how close of a task was that to http://trac.navit-project.org/ticket/692 ? 19:48 #navit: < ColdFyre> qt-4.8.6 (fedora 20) 19:51 #navit: < tryagain> well it looks for me quite readable on android and gtk_drawing_area, even if two or more texts overlap (only last drawn is visible) 19:52 #navit: < tryagain> can you try to specify gtk_drawing_area as your graphics. I'm not sure it's a requiremnt to have gnome installed to run it. 19:52 #navit: < tryagain> so you'll see results yourself 19:53 #navit: < ColdFyre> i have the ability to use it to test it yes, but i need the internal gui long term 19:53 #navit: < tryagain> can you post your CMakeCache.txt somewhere? It would help to figure out what branch of qt code you actually use. Some of them seem to include shadow effects. 19:54 #navit: < ColdFyre> sure 19:54 #navit: < tryagain> it's compatible with internal gui 19:55 #navit: < ColdFyre> i don't have a CMakeCache 19:55 #navit: < tryagain> did you use autotools to compile? 19:56 #navit: < ColdFyre> i'm not sure, i ran autogen, ./configure, then make 19:56 #navit: < tryagain> yes, that's autotools 19:56 #navit: < tryagain> it has a different file 19:57 #navit: < tryagain> hm... config.h should be sufficient 19:57 #navit: < tryagain> (and even easier to read) 19:58 #navit: < ColdFyre> .log or .h? 19:58 #navit: < tryagain> .h 19:59 #navit: < tryagain> will be away for some time.. but i'll anyway read logs. 19:59 #navit: < ColdFyre> http://pastebin.com/xjb1a3zm 19:59 #navit: < ColdFyre> thanks :) 20:09 -!- drlizau [~liz@billiau.net] has joined #navit 20:47 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection] 21:13 #navit: < tryagain> ColdFyre what if you change QImage img(g->w+2, g->h+2, QImage::Format_ARGB32_Premultiplied); to 21:13 #navit: < tryagain> QImage img(g->w+2, g->h+2, QImage::Format_ARGB32); 21:14 #navit: < tryagain> line 454 21:14 #navit: < tryagain> of graphics_qt_painter.cpp 21:15 #navit: < ColdFyre> what will that change do? 21:15 #navit: < tryagain> it looks llike actually navit attempts to do shadow/glow effect, but it's may be wrongly implemented 21:16 #navit: < tryagain> it looks like freetext code does not use permultiplied format, while qt code attempts to use it 21:18 #navit: < tryagain> btw, are gtk_drawing_area texts more usable to you than qt_painter ones? gtk_drawing_area does glow effect for me. 21:18 #navit: < ColdFyre> i can use the drawing_area 21:19 #navit: < ColdFyre> i just did not want to install the gtk-libs, but i did anyway :p 21:21 #navit: < tryagain> i feel that these are now almost automatically included when you install your linux as they are widely used by different software, even not related to gnome 21:38 #navit: < ColdFyre> bah, i wonder why these maps are so "blocky" with the water borders 21:40 #navit: < tryagain> that's because of the way we store and use map data. Data is split into the tiles, and we mark whole upper level tiles as "water", but actual boundary goes to lower level tiles. 21:41 #navit: < tryagain> these lower level tiles are not used when we draw at low zooms 21:43 #navit: < tryagain> so when you zoom in, you get actual boundary. When you zoom out - only approximation of it 21:44 #navit: < ColdFyre> ah, is there a way to override that - because the maps look terrible when zoomed out 21:46 #navit: < ColdFyre> this is so strange, half of the US is shown as water 21:48 #navit: < ColdFyre> http://gyazo.com/984db8b9240dcf32b012703192a2243a 21:48 #navit: < tryagain> you may try to increase order_delta of your does that effect disappear when you zoom in? 21:49 #navit: < ColdFyre> no, the same regions remain as water 21:50 #navit: < ColdFyre> even at the closest zoom 21:53 #navit: < tryagain> then tap water area, goto map point information, find poly_water_tiled item, find osm_id attribute of it. Then view that object's osm data. It's most probably coastline data error in osm database. 22:00 #navit: < tryagain> for example, http://www.openstreetmap.org/way/224936100 should not have natural=coastline tag 22:00 #navit: < ColdFyre> maybe it's me, but adding order_delta="999999" to the tag is not having any change on the rendering 22:00 #navit: < tryagain> hmm 22:02 #navit: < tryagain> there are different problems. Adding it will not help with leaked water as in my above osm reference. But should help to render correct coastlines on low zoom levels. 22:04 #navit: < ColdFyre> right, it's not changing the "valid" coastlines, though 22:05 #navit: < ColdFyre> i've been using navit's planet extractor, i wonder if that's the issue 22:06 #navit: < ColdFyre> i'd imagine the OSM folks would have noticed such an issue by now 22:09 -!- justinzane [~justinzan@67.21.190.20] has joined #navit 22:09 #navit: < justinzane> hello all 22:10 #navit: < justinzane> I've got a couple questions... 22:10 #navit: < justinzane> - Is there a source tree somewhere specifically for the Android build? 22:10 #navit: < justinzane> and 22:13 #navit: < justinzane> - I've been looking at the navit.xml and navit.dtd files and, considering that I **hate** xml and am therefore somewhat ignorant about it, it seems that the DTD could use some opdating. 22:14 #navit: < justinzane> I've also been trying to breakout the major sections into "xi:include" or "!ENTITY" references so that, expecially on small screens, it is reasonable possible to edit the configuraiton using something like nano. 22:15 #navit: < justinzane> Has this been done before, considered, verified to be a stupic idea? 22:19 #navit: < tryagain> justinzane there's only one source tree for all platforms, which is available through svn 22:20 #navit: < justinzane> Ok. I've just started figuring out how to import that into github. 22:20 #navit: < tryagain> building instructions are here http://wiki.navit-project.org/index.php/Android_development 22:21 #navit: < justinzane> tryagain: Looking at the commit log, there do not seem to be a whole lot of commits, is it still a pretty active project? 22:22 #navit: < tryagain> not less than you see commits. There are a few devs around who did not leave project completely but commits are very rare these days 22:23 #navit: < tryagain> if you'll come with a patch, it's highly appreciated 22:23 #navit: < justinzane> tryagain: that is a shame. The FOSS world needs a good alternative to Nokia/Google/Apple/Garmin/etc. 22:24 #navit: < tryagain> we're welcome to people willing to help 22:24 #navit: < justinzane> Well, I'll give it a spin. I'm thoroughly new to Android development as well, but, then again, that is what IRC and Google are for. :) 22:24 #navit: < tryagain> yeah 22:25 #navit: < justinzane> thanks 22:31 #navit: < ColdFyre> downloading this 38GB world is terrible, even on 100mbit 22:36 #navit: < tryagain> why do you need it? 22:39 #navit: < ColdFyre> i'm going to process it myself to see if that coastline issue is still present 22:40 #navit: < ColdFyre> the missing coastline 22:41 #navit: < tryagain> i've done a few fixes... http://www.openstreetmap.org/user/tryagain/history#map=3/48.15/-36.85 22:42 #navit: < tryagain> But osm inspector seems to not report such cases as questionable anymore. 22:43 #navit: < tryagain> mapnik uses a someway preprocessed coastline data so it's immune to such errors. 22:46 #navit: < ColdFyre> this is all for a car pc, and it's quite the challenge to get something for a touchscreen and easily readable where you don't have to think much 22:49 #navit: < ColdFyre> OSM seems to be able to distinguish between US/Interstate/State routes, does navit as well? 22:52 #navit: < tryagain> navit recognizes highway=* tags, if that's what you're meaning. It uses less important roads only at the begining and at the end of the route. 22:53 #navit: < ColdFyre> i was wondering more for display purposes 22:58 #navit: < tryagain> it maps different highway=* types to different navit items and able to draw them in different ways. Actually, default car layout draws them in different ways. 22:59 #navit: < tryagain> but that's not about https://wiki.openstreetmap.org/wiki/Route 23:01 #navit: < ColdFyre> i guess the question i'm wondering is - is it possible to display in navit the type of highway? 23:02 #navit: < tryagain> what osm tag do you mean by type of highway? 23:03 #navit: < ColdFyre> give me a few for the tag 23:03 #navit: < ColdFyre> by the way, the coastline removals you made did not have any impact 23:05 #navit: < tryagain> better you give me some osm way reference and its type :) 23:06 #navit: < tryagain> for them to have impact, they should be included in your downloaded data. We process our map data every few days now. 23:06 #navit: < ColdFyre> ah 23:07 #navit: < tryagain> Data you've downloaded is probably daily extract which also does not contain my changes 23:08 #navit: < tryagain> have to go now... See you! 23:08 -!- tryagain [~tryagain@178.216.76.61] has quit [Remote host closed the connection] 23:30 -!- xenos1984 [~quassel@131.237.196.88.dyn.estpak.ee] has quit [Remote host closed the connection] --- Log closed Wed May 07 00:00:09 2014