--- Log opened Wed Mar 06 00:00:14 2013
00:13 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
00:42 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
00:51 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
00:58 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
01:03 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
01:14 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
01:21 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
01:34 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
01:44 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
01:53 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
02:00 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
03:30 -!- cp15` [hzbqoq@p57B1CCF3.dip0.t-ipconnect.de] has joined #navit
03:30 -!- cp15 [tavono@p57B1D26C.dip0.t-ipconnect.de] has quit [Disconnected by services]
03:30 -!- cp15` is now known as cp15
03:31 -!- mode/#navit [+o cp15] by ChanServ
04:02 -!- noradtux [~noradtux@2002:4e36:7a7d::1] has quit [Ping timeout: 264 seconds]
04:07 -!- noradtux [~noradtux@2002:5ce0:39a3::1] has joined #navit
04:09 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
04:20 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
04:31 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
04:52 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
04:57 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
05:22 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
05:50 -!- ColdFyre [~lenny@c-98-248-56-123.hsd1.ca.comcast.net] has quit [Ping timeout: 248 seconds]
05:54 -!- fOB [~fob@ip-178-202-247-64.unitymediagroup.de] has joined #navit
05:55 -!- ColdFyre [~lenny@98.248.56.123] has joined #navit
06:07 -!- woglinde [~henning@f052065032.adsl.alicedsl.de] has joined #navit
06:12 -!- woglinde [~henning@f052065032.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds]
07:26 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
07:45 -!- fOB [~fob@ip-178-202-247-64.unitymediagroup.de] has quit [Quit: Leaving]
08:12 -!- drlizau [~liz@billiau.net] has joined #navit
08:24 -!- Robotaxi [3ef5dbf5@gateway/web/freenode/ip.62.245.219.245] has joined #navit
09:17 -!- Usul1 [~matthias@stw-103-110.ras.uni-rostock.de] has joined #navit
09:17 -!- Usul1 is now known as Usul_AFK
09:35 -!- chollya [~chollya@2a02:7200:0:7:92fb:a6ff:fe36:2aa4] has quit [Ping timeout: 256 seconds]
09:44 -!- chollya [~chollya@2a02:7200:0:7:92fb:a6ff:fe36:2aa4] has joined #navit
09:56 #navit: < Usul_AFK> Is there anybody beside cp15 who likes to work on organizing an new iconset? http://wiki.navit-project.org/index.php/User:Usul/OwnMapIcons
11:51 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection]
12:37 -!- cp15 [hzbqoq@p57B1CCF3.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
12:38 #navit: < Usul_AFK> *yawn*
12:48 -!- cp15 [fwcrri@p57B1CCF3.dip0.t-ipconnect.de] has joined #navit
12:48 -!- mode/#navit [+o cp15] by ChanServ
13:00 #navit: < Usul_AFK> Should we establish some kind of deciding process, which POI icons we like to keep in the new style and which not?
13:01 #navit: < Usul_AFK> Or is it ok, if I try to take a first suggestion?
13:01 #navit: < Usul_AFK> BTW do we have artists within our own community or do we need to attract new ones?
13:09 -!- gringo [~gringo@unaffiliated/gringo] has quit [Read error: Operation timed out]
13:09 -!- gringo [~gringo@unaffiliated/gringo] has joined #navit
14:23 #navit: < Usul_AFK> hmm strange
14:23 #navit: < Usul_AFK> my Pandora gives ENG dirving commands via TTS, even if I have an DE locale :/
15:24 #navit: <@cp15> Is the menu in german?
15:45 #navit: < Usul_AFK> hi
15:45 #navit: < Usul_AFK> yes menu and everything is DE
16:34 -!- xenos1984 [~quassel@185-80-131-46-dyn.internet.emt.ee] has joined #navit
16:34 #navit: < xenos1984> hi everybody
16:36 #navit: < xenos1984> is there a problem with svn version numbers and refreshing the file "version.h"? recently someone pointed out to me that my current tomtom navit build contains an old binary version, but it only shows an old version number in the "About" section, and indeed "version.h" is not refreshed (using cmake)
16:39 -!- tryagain [~tryagain@178.216.76.16] has joined #navit
16:44 #navit: < tryagain> xenos1984 you're most probably doing out-of source build and have version.h defined in source tree by earlier in-tree build attempt. Try to delete version.h in your source tree.
16:45 #navit: < xenos1984> ah, i see
16:47 #navit: < xenos1984> hm... no, it's not in the source tree...
16:48 #navit: < tryagain> strange... And what do you have in version.h of your build tree?
16:49 #navit: < xenos1984> strange, now there is the correct one
16:49 #navit: < xenos1984> seems i set up some path incorrectly, let me see...
16:51 #navit: < tryagain> look twice to source tree, version.h should be there. build process prefers that file over the file in build tree.
16:52 #navit: < xenos1984> actually i messed up the cmake build process - it's not updating anything
16:52 #navit: < xenos1984> i guess that means i have to learn more about cmake ;)
16:53 #navit: < xenos1984> running the old autotools script once, just to get a new binary for download - and then i have to figure out how this really works
16:56 -!- Robotaxi [3ef5dbf5@gateway/web/freenode/ip.62.245.219.245] has quit [Ping timeout: 245 seconds]
17:00 #navit: < Usul_AFK> hi xenos1984
17:00 #navit: < xenos1984> hi Usul_AFK
17:00 #navit: < Usul_AFK> brb -> taking shower
17:03 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has quit [Ping timeout: 264 seconds]
17:09 #navit: < tryagain> Usul_AFK just curious, why do not use some of existing icon collections for map features?
17:09 #navit: < Usul_AFK> hi
17:09 #navit: < tryagain> hi
17:10 #navit: < Usul_AFK> I that might be a choice, I didn't excluded thi solution
17:10 #navit: < Usul_AFK> in a first step I tried to summarize our needs
17:10 #navit: < Usul_AFK> let's see if there is a icon pack, that matches
17:10 #navit: < Usul_AFK> and that is easy to read on small screens (IMHO thats the problem with default OSM icons)
17:13 #navit: < xenos1984> interesting new error...
17:14 #navit: < xenos1984> ./.libs/libnavit.a(xmlconfig.o)(.text+0x678): In function `object_func_lookup': undefined reference to `profile_option_func'
17:14 #navit: < Usul_AFK> And is it missing in the source?
17:15 #navit: < xenos1984> ah, i guess i found it
17:16 #navit: < Usul_AFK> sounds like the callback for inner XML attributes?
17:17 #navit: < tryagain> looks like a part of recent cp15 commit. Might be you have not updated the whole tree?
17:20 #navit: < xenos1984> actually i did, but seemingly forgot to build something...
17:21 #navit: < Usul_AFK> So what do you say, should we just update to the usual Mapnik Icon set? http://www.sjjb.co.uk/mapicons/contactsheet
17:29 #navit:  * Usul_AFK likes feedback ;)
17:29 #navit: < tryagain> I think i would be happy with it. But we'll have to do something to display black icons on the black background of poi search list. Also we'll have to think of a workaround for wince cab distribution, as it supports only up to 999 files inside distribution file.
17:31 #navit: < Usul_AFK> I agree. If we see in practice, that the set is to detailed or something, we can change it either.
17:31 #navit: < Usul_AFK> How about an glyph support?
17:37 #navit: < Usul_AFK> sry sprites was the term
17:37 #navit: < Usul_AFK> So bundling all graphics into one PNG and extracting them from the single one?
17:37 #navit: < tryagain> hm please explain
17:37 #navit: < tryagain> ah got it
17:38 #navit: < tryagain> unsure if it is a good idea for low memory devices
17:38 #navit: < Usul_AFK> +1 but the file no constraint seem to be harder?
17:39 #navit: < Usul_AFK> at least currently we don't increase the number of images, as we just replace them (and maybe kick some out)
17:41 #navit: < tryagain> it was suggested by somebody to store all icons for wince in one zip file inside cab and extract them during first run or on the fly. Zip may be done with zero-level compression.
17:42 #navit: < Usul_AFK> but doens't that one run into the same performance strugles? (getting n things out of 1 unit)
17:44 #navit: < Usul_AFK> personnally I suggest the negative style, as it has a good contrast and avoids problems with black ground/night mode?
17:45 #navit: < tryagain> I'm not very sure about png internals, but reading its parts might require too much file seeks to read one image
17:46 #navit: < Usul_AFK> ah, might be so. In the end, which approach is not that important
17:47 #navit: < Usul_AFK> another question is, how we might realize country specific icon styles
17:48 #navit: < Usul_AFK> For example pharmacy etc. looks quit different in various countries :/
17:53 #navit: < tryagain> I don't think it's of primary concern. Anybody can fine tune that by his preference. Anyway, it wouldn't be very comfortable to have icons changed on the fly.
17:54 #navit: < Usul_AFK> Sure, but maybe we should already reflect this, e.g. defining useful filenames that can be extendet by _DE or something?
17:55 #navit: < Usul_AFK> So how do we do with the names? Recycling the old ones, might bring problems, as they are very mixed. Some describe content, some just an abstract aspect.
17:56 #navit: < Usul_AFK> But if we introduce new ones, we need to change all the map layouts, right?
18:04 #navit: < Usul_AFK> tryagain: I heared you are working on improving the search functionality?
18:16 #navit: < tryagain> sry - other running tasks preempt chatting :) I agree - we have to work out some straightforward schema for naming icon types and variants. And changing icon name means we have to change layouts referencing it.
18:17 #navit: < tryagain> and yes, i'm working on search now
18:19 #navit: < Usul_AFK> oh cool, can you give us some details?
18:22 #navit: < xenos1984> since for example pharmacies look quite the same in germany and austria (i suppose), having something like pharmacy_DE.svg and pharmacy_AT.svg with the same content is probably not very efficient... maybe it is more efficient to have something like pharmacy_cross.svg and pharmacy_halfmoon.svg (these are bad names, just an example), and then have german / austrian styles including the first and arabic / turkish styles including the
18:22 #navit: < xenos1984> second
18:23 #navit: < Usul_AFK> so we define some kind of mixer, who can switch depending on your local country?
18:23 #navit: < xenos1984> one might also think about separating the shape from the coloring scheme, so one can have icons with the same shape, but different colors for day and night layout
18:23 #navit: < Usul_AFK> which can be easily done with SVG magic. But that needs more powerfull embedded systems ;)
18:23 #navit: < xenos1984> yes, this "mixer" is what i was thinking about, or just icon layouts using a "pool" of icons
18:24 #navit: < xenos1984> yes, indeed, that's not difficult with svg ;)
18:25 #navit: < Usul_AFK> so the pool needs a ruleset with which lang setting it displays which icon
18:25 #navit: < Usul_AFK> somekind of partially overwriting the basic style ... hmmm
18:25 #navit: < xenos1984> hm... i wouldn't couple it directly to the display language
18:26 #navit: < Usul_AFK> but we might define it a bit more complex, so we can trigger on "brands" for example and apply later on specific logo icons
18:26 #navit: < Usul_AFK> so an "Aldi" supermarket becomes the brand logo :)
18:26 #navit: < xenos1984> i might prefer estonian language here, because then it reads both estonian street names and turn orders correctly, but still have german symbols
18:27 #navit: < xenos1984> well, yes, one could ;) but basic things first
18:27 #navit: < Usul_AFK> sure, but not putting borders for further steps :P
18:28 #navit: < xenos1984> of course, but sometimes thinking of further steps is a border for making the basic ones reality
18:28 #navit: < Usul_AFK> but hey, till now, we talking about very simple things :D
18:31 #navit: < tryagain> we can use all svg magic during build process and use put multiple png variations of the same svg. Also, some settings might be compile-time options so anyone can get his own icon pack with standard names (so compatible with layouts) but with his preferred look.
18:32 #navit: < Usul_AFK> +1
18:32 #navit: < Usul_AFK> plus an compressor step for WinCE ;)
18:32 #navit: < Usul_AFK> So what would you suggest how I should proceed with the iconset?
18:35 #navit: < xenos1984> i guess figuring out a naming scheme would be a good idea, and making a list which icons are needed and are maybe missing in the mapnik set
18:36 #navit: < Usul_AFK> in a first review nothing seems to be missing
18:36 #navit: < xenos1984> very good
18:36 #navit: < Usul_AFK> but I would like to kick out some of them (temorally)
18:36 #navit: < tryagain> as for using negative icons instead of default ones... it still doesnt solve black-on-black problem. We'll probably have to use "whiteglow" variant for some cases.
18:37 #navit: < Usul_AFK> tryagain: I thought about changing the black one icons?
18:37 #navit: < Usul_AFK> but glow looks nice, yes
18:37 #navit: < xenos1984> ...and here comes the separation of color and shape into the game
18:38 #navit: < Usul_AFK> hmm
18:38 #navit: < Usul_AFK> I see :)
18:38 #navit: < xenos1984> but in this case it would even mean different colors on the map and in the POI search
18:38 #navit: < xenos1984> so not just choosing a single color
18:38 #navit: < Usul_AFK> which might destroy the context :/
18:41 #navit: < Usul_AFK> but maybe we can thing about it later
18:42 #navit: < Usul_AFK> so #1 I will thing about naming convention and #2 grab the corresponding icons
18:42 #navit: < Usul_AFK> ?
18:42 #navit: < xenos1984> sounds fine to me
18:42 #navit: < tryagain> agree
18:44 #navit: < Usul_AFK> okidoki
18:44 #navit: < Usul_AFK> as next step I will play around with the poi info dialog
18:44 #navit: < Usul_AFK> nothing big,reaordering and some cleanup
18:55 #navit: < Usul_AFK> oh and was what the search thing about tryagain ?
18:55 #navit: < Usul_AFK> You spot adress search or even POI search?
18:59 #navit: < tryagain> address search currently. POI search at its current state has much of my work too.
19:00 #navit: < Usul_AFK> sure, NP
19:00 #navit: < Usul_AFK> and so internal refactoring or UI polishing?
19:01 #navit: < tryagain> internals. We currently do not work well below town level.
19:02 #navit: < tryagain> actually, i would use POI search to find a street or house rather than going to street level after i found a town.
19:02 #navit: < tryagain> that has to be changed.
19:03 #navit: < Usul_AFK> yes
19:03 #navit: < Usul_AFK> thats always very annoying that most navis force you to enter the place first, even if just want to find a street in the town :/
19:05 #navit: < tryagain> thats UI, so not what i'm working now on, and not the primary cause why i do not use street search. But i agree, it should be changed too.
19:07 #navit: < Usul_AFK> really? I expected that binfile has an multilevel hashmap that takes the city name into account?
19:09 #navit: < tryagain> streets are not linked with towns. Currently we use town size approximation by population-dependent radius to select streets from the town. If town has polygon around it, we use its bounding box as approximation.
19:10 #navit: < Usul_AFK> ok thats the maptool magic. sadly boundaries are a class of its own at OSM :/
19:10 #navit: < tryagain> multipolygon relations for towns are handled in experimental maptool runs, so not available to endusers yet
19:11 -!- drlizau [~liz@billiau.net] has joined #navit
19:12 #navit: < tryagain> what i plan to do in nearest future, use actual town borders instead of bounding boxes
19:12 #navit: < Usul_AFK> would be great. But I expect a lot of corrupted borders?
19:13 #navit: < tryagain> then i think we could attach city district polygons there to be able to search at sub-city levels when needed
19:13 #navit: < Usul_AFK> so in OSM model allready
19:13 #navit: < tryagain> well, we can report them in the maptool logs
19:13 #navit: < Usul_AFK> yes something like this would be helpful
19:13 #navit: < Usul_AFK> in a crowdfunding project, doing work is not the problem :)
19:14 #navit: < tryagain> but it requires a separate task to visualize it
19:14 #navit: < Usul_AFK> maybe we can ask this guy, who does border checks already form Germany: http://ags.misterboo.de/
19:14 #navit: < Usul_AFK> (but here for the county level)
19:15 #navit: < Usul_AFK> and it would need an fallback to the last version of a polygon which wasn't corrupted, to avoid run problems
19:17 #navit: < tryagain> yes, i was also thinking of some fallback at least for country polygons.
19:18 #navit: < Usul_AFK> the future of navit sounds great :)
19:19 #navit: < tryagain> i know nominatim uses fallback. AFAIK It even do not accept country border changes without manual review.
19:19 #navit: < Usul_AFK> really? To poor that the don't provide an broken relation report :/
19:20 #navit: < tryagain> hm. it might be we just don't know it?
19:21 #navit: < Usul_AFK> I would say as an OSM member I should heard about it ;) xenos1984 how about you?
19:21 #navit: < Usul_AFK> BTW what do you think about this POI info dialog remix? http://www.pichoster.net/?v=VPsM.jpg
19:21 #navit: < xenos1984> well, i never really dealt with nominatim or these things, so i don't know
19:22 #navit: < xenos1984> i only know about the report from maptool ;)
19:22 #navit: < Usul_AFK> garry68 had a relation checker, but tools weren't that popular (as osmbugs or osm inspector for example)
19:23 #navit: < tryagain> I would also like to see POIs around the poi
19:23 #navit: < tryagain> but, yes, it looks cool
19:23 #navit: < Usul_AFK> Really? Can you plz. describe your usecase?
19:25 #navit: < Usul_AFK> I thought the "find similar POIs" item would fit?
19:25 #navit: < xenos1984> yes, the POI dialog looks nice - just make sure the font for the address does not get too small on devices with a small screen ;) they can display only very limited information
19:25 #navit: < tryagain> I would like to see nearby parking zones or bus stops
19:26 #navit: < xenos1984> but in general i like the idea
19:26 #navit: < tryagain> they are not similar, they are nearby
19:27 #navit: < Usul_AFK> @tryagain and you don't use just the map for that? Or invoking a POI search? (this is just the info dialog that appears, if you click on a item on the map
19:29 #navit: < xenos1984> nearby POIs is a good idea - i would like to see the parking lot that belongs to the restaurant i just found, even if it is on the opposite side of the street or around the corner ;)
19:29 #navit: < tryagain> almost any map area is item in the big city, town, suburb polygone, street, house. So you always click an item. And i'd like to start POI search from that item.
19:29 #navit: < Usul_AFK> xenos1984: yes this can be indeed an problem. But to bring a visual hierachy, we should pick a different size between caption, informations and menu
19:29 #navit: < tryagain> s/city,/city:/
19:30 #navit: < Usul_AFK> well as a shortcut you can use the "Find similar POIs" and alter the preselected item
19:31 #navit: < Usul_AFK> or we change it to "Find POIs here" (which is ok for me)
19:31 #navit: < xenos1984> yes, i agree, different sizes improve the layout a lot (if there is enough space)
19:31 #navit: < tryagain> find pois here sounds better
19:31 #navit: < Usul_AFK> and with preselected same POI type?
19:32 #navit: < xenos1984> "find pois here" and "find similar pois" should both be there, but do different things ;) the first gets me the parking zone, the second gets me other restaurants (which may be a bit further away)
19:33 #navit: < tryagain> agree
19:33 #navit: < Usul_AFK> I recommend to keep the menus really (!) short and would care for redundancy
19:33 #navit: < tryagain> agree too :)
19:33 #navit: < xenos1984> maybe a "find nearby...", which then allows you to select parking zone, public transport etc.
19:33 #navit: < Usul_AFK> my workflow would be a bit different than the current one:
19:34 #navit: < Usul_AFK> you fire up navit and get immeadidly to the main menu
19:34 #navit: < Usul_AFK> (people use navit to get to somewhere)
19:34 #navit: < Usul_AFK> there you can use a button for street and POI search
19:35 #navit: < Usul_AFK> for POI search there are categories e.g. tourism, containing multiple subtypes (e.g. museums)
19:36 #navit: < tryagain> POI search is meaningfult only with defined position. If you do not see the map, you don't know where you're searching from.
19:36 #navit: < Usul_AFK> and you can enter a search word for filtering the categories (similar to JOSM F3 xenos1984)
19:36 #navit: < Usul_AFK> So if you want to find something, you use the menu and not a click at a map, as this click implys you want to do an action related to this context (here: map position)
19:37 #navit: < Usul_AFK> am I wrong?
19:37 #navit: < xenos1984> poi search could use the current gps position by default, and be greyed out if there is none
19:37 #navit: < xenos1984> and use the position on the map if invoked from there
19:38 #navit: < Usul_AFK> +1 if invoked with a fix from main menu, yes
19:39 #navit: < xenos1984> because this is how my garmin is doing it, and i like it that way ;) i want a poi close to me, not anywhere else
19:39 #navit: < Usul_AFK> and it stores your last position and if have no gps, it will start searching from there, limited by a area (district, city, surrounding, ...)
19:39 #navit: < Usul_AFK> sure, nobody wants to take a train just to get a bear xenos1984 ;)
19:40 #navit: < xenos1984> limiting by distance might be better - if you're close to a town border, you rather cross that border that driving to the other side of the town to get some food
19:41 #navit: < xenos1984> Usul_AFK: if you want a bear, i know a restaurant which has bear meat pelmenis ;)
19:41 #navit: < Usul_AFK> ;)
19:41 #navit: < tryagain> hm if i take the phone out of the pocket and start navit, it doesnt mean that i'm standing at the same point where I was an hour ago when i've shut navit down and lost gps fix
19:41 #navit: < Usul_AFK> +1 but this is not mean to math the border polygon, it is just an simplification to the consumer
19:42 #navit: < Usul_AFK> nobody wants to enter how much km it should search. So simple languages with example make it easier?
19:42 -!- Usul_AFK is now known as Usul
19:42 -!- ScriptFanix [vincent@Hanaman.riquer.fr] has joined #navit
19:44 #navit: < xenos1984> tryagain: right, the position may be different - but most of the time will probably the same (left the car, had some food, come back, fire up navit again...) - well, and displaying an old position (maybe with a warning that this is not current?) is better than none?
19:45 #navit: < tryagain> and if you stand 10 meters of suburb border, you're most probably more interested in bus stop 30 meters of you around the corner in the sibling district rather than 500m away one in the same district :)
19:45 #navit: < Usul> so we use "city" just as an approxisation for a radius say 15km
19:46 #navit: < Usul> nice talk, but it's time for me to leave :(
19:46 #navit: < Usul> cya
19:46 #navit: < Usul> !
19:46 -!- Usul [~matthias@stw-103-110.ras.uni-rostock.de] has quit [Quit: Leaving.]
19:46 #navit: < xenos1984> i would just run the poi search until the first page on the display is filled, and do another search with increased radius if the user goes to the next page etc. - increasing the distance from one page to the next
19:48 #navit: < tryagain> increasing distance currently means reread all map data from scratch, so its pretty time consuming operation.
19:48 #navit: < xenos1984> ah, i see
19:49 #navit: < tryagain> i would like to be prepeared for that
19:52 #navit: < xenos1984> i also need to go (still in hospital), gn8
19:52 #navit: < tryagain> gn8
19:52 -!- xenos1984 [~quassel@185-80-131-46-dyn.internet.emt.ee] has quit [Remote host closed the connection]
20:03 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection]
20:04 -!- drlizau [~liz@billiau.net] has joined #navit
20:11 -!- drlizau [~liz@billiau.net] has quit [Read error: Connection reset by peer]
20:45 -!- _rd [~rd@p57B49089.dip0.t-ipconnect.de] has joined #navit
20:53 -!- woglinde [~henning@f052067162.adsl.alicedsl.de] has joined #navit
20:55 -!- tryagain [~tryagain@178.216.76.16] has quit [Remote host closed the connection]
21:05 -!- _rd [~rd@p57B49089.dip0.t-ipconnect.de] has quit []
21:05 -!- _rd [~rd@p57B49089.dip0.t-ipconnect.de] has joined #navit
21:25 -!- _rd [~rd@p57B49089.dip0.t-ipconnect.de] has quit []
21:58 -!- fOB [~fob@ip-178-202-247-64.unitymediagroup.de] has joined #navit
22:18 -!- sleske [~chatzilla@p4FD4608F.dip.t-dialin.net] has joined #navit
22:20 -!- sleske [~chatzilla@p4FD4608F.dip.t-dialin.net] has quit [Client Quit]
22:45 -!- woglinde [~henning@f052067162.adsl.alicedsl.de] has quit [Ping timeout: 264 seconds]
23:10 -!- fOB [~fob@ip-178-202-247-64.unitymediagroup.de] has quit [Quit: Leaving]
23:33 -!- KaZeR_W [~Z30@77.242.201.49] has quit [Read error: Connection reset by peer]
--- Log closed Thu Mar 07 00:00:14 2013