--- Log opened Thu Aug 21 00:00:41 2014 00:07 -!- drlizau [~liz@billiau.net] has joined #navit 00:20 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection] 01:03 -!- KaZeR_ [~KaZeR@64.201.252.132] has quit [Remote host closed the connection] 01:07 #navit: < Navit> The following compiles failed: http://download.navit-project.org/logs/navit/src/svn/navit-svn-5878.failed http://download.navit-project.org/logs/navit/wince_arm/svn/navit-svn-5878.failed 01:07 #navit: < Navit> See compile results history at http://download.navit-project.org/logs/navit/stats.html 06:54 -!- woglinde [~henning@fb-n15-11.unbelievable-machine.net] has joined #navit 07:00 -!- Robotaxi [3ef5dbf5@gateway/web/freenode/ip.62.245.219.245] has joined #navit 07:42 -!- jandegr [574158de@gateway/web/freenode/ip.87.65.88.222] has joined #navit 08:07 -!- bafplus [~bafplus@go.allip.nl] has joined #navit 08:07 #navit: < bafplus> jandegr , Good morning, i'm roadtesting the new change and this far it works great! 08:08 #navit: < jandegr> bafplus, we did not expect anything less :) 08:09 #navit: < jandegr> when you are off the road look at : 08:09 #navit: < jandegr> http://trac.navit-project.org/ticket/1244 08:12 #navit: < bafplus> Good one! You found it, the screenshot seems broken, but when clicked on it does open... 08:13 #navit: < bafplus> But why change it to "," ? Woedent that produce a double one ",,"? 08:14 #navit: < bafplus> Since there already is one between town and co. 08:17 #navit: < jandegr> i keep the ", " from ", Co." 08:25 -!- tauso [~TAugustin@195.81.221.4] has joined #navit 08:26 #navit: < tauso> hi, has somebody looked at the error messages at startup of the latest svn builds? 08:26 #navit: < tauso> "navit:convert_to_attrs:failed to create attribute 'distance_metric' with value ..." 08:26 #navit: < woglinde> tauso do not think so 08:27 #navit: < bafplus> Tauso, thats not from latest build only, i have that error since about 10 builds ago 08:30 #navit: < tauso> yes I know, i was just curious why it's also in the latest build, because I slightly remember a discussion here and I thought somebody fixed it right away 08:32 #navit: < woglinde> if some one could bisect it would be nice 08:35 #navit: < tauso> I tstill think its svn 5822 what broke it. it marks attribute distance_metric as unused, but its still in the navit.xml file 08:36 #navit: < woglinde> ah okay 08:36 #navit: < woglinde> tauso try to remove it from the navit.xml 08:36 #navit: < woglinde> does that works? 08:37 #navit: < tauso> so now the only problem is: is this attribute really unused or not 09:20 #navit: < tauso> when i remove the distance_metric form navit.xlm, the errors are gone. But as i said, I don'nt know if this attribute is really unused 09:34 -!- bafplus [~bafplus@go.allip.nl] has quit [Ping timeout: 264 seconds] 09:41 -!- bafplus [~bafplus@go.allip.nl] has joined #navit 09:49 -!- bafplus [~bafplus@go.allip.nl] has quit [Ping timeout: 250 seconds] 09:59 -!- bafplus [~bafplus@go.allip.nl] has joined #navit 10:20 -!- bafplus [~bafplus@go.allip.nl] has quit [Ping timeout: 260 seconds] 10:23 -!- bafplus [~bafplus@go.allip.nl] has joined #navit 11:44 #navit: < bafplus> distance_metric is for the anounce_level for speech, i guess in combination with the speed, can somebody confirm that speech still works after removing all the lines? 13:01 -!- jandegr [574158de@gateway/web/freenode/ip.87.65.88.222] has quit [Quit: Page closed] 13:04 -!- bafplus [~bafplus@go.allip.nl] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Po-ta-to, boil em, mash em, stick em in a stew.] 14:52 -!- KaZeR [~KaZeR@64.201.252.132] has joined #navit 14:53 -!- mode/#navit [+o KaZeR] by ChanServ 15:15 -!- bafplus [~bafplus@go.allip.nl] has joined #navit 15:30 -!- jandegr [574158de@gateway/web/freenode/ip.87.65.88.222] has joined #navit 15:32 -!- woglinde [~henning@fb-n15-11.unbelievable-machine.net] has quit [Ping timeout: 260 seconds] 15:53 -!- tauso [~TAugustin@195.81.221.4] has left #navit [] 16:06 -!- Robotaxi [3ef5dbf5@gateway/web/freenode/ip.62.245.219.245] has quit [Ping timeout: 246 seconds] 16:09 #navit: <@KaZeR> hi there 16:15 #navit: < bafplus> Hy KaZeR 16:24 #navit: <@KaZeR> 'sup guys? 16:29 #navit: < bafplus> Nithing much realy.... 16:41 -!- KaZeR [~KaZeR@64.201.252.132] has quit [Remote host closed the connection] 16:43 -!- KaZeR_ [~KaZeR@64.201.252.132] has joined #navit 16:44 #navit: < bafplus> I saw you committed the change for the belgium and netherlands map 16:46 #navit: < bafplus> If you have the time, would you be so great to also change the ",co" ticket that jandegr opened? 16:47 #navit: < bafplus> Small change, big respect ;-) 17:02 -!- tryagain [~quassel@178.216.76.113] has joined #navit 17:02 #navit: < jandegr> Hi tryagain, 17:02 #navit: < tryagain> hi jandegr 17:02 #navit: < jandegr> can you tell me something more about extended housenumber search ? 17:03 #navit: < jandegr> I think you committed that 17:03 -!- KaZeR_ [~KaZeR@64.201.252.132] has quit [Remote host closed the connection] 17:03 #navit: < tryagain> hm, what do you mean by "extended housenumber search"? 17:04 #navit: < jandegr> one moment, I'll look it up in the code 17:04 #navit: < tryagain> and what do you want to hear? Just ask... 17:04 #navit: < bafplus> Was that about "hiding" the housenumbers when searching for point off interest? 17:04 #navit: < bafplus> afk 17:05 #navit: < jandegr> it's revision 5436 17:05 #navit: < jandegr> Extended house number search region to ....... 17:07 #navit: < jandegr> I think it is the cause to my issue :http://trac.navit-project.org/ticket/1243 17:07 #navit: < jandegr> but then I might be completely wrong 17:07 #navit: < tryagain> that's my commit 17:08 #navit: < tryagain> is street still found in nearby city? 17:08 #navit: < tryagain> after KaZeR' commit? 17:09 #navit: < jandegr> no, we changed maptool yesterday to work with admin_level 8 17:09 #navit: < jandegr> that commit from kazer is in fact mine, he just did it for me, I have no write access 17:10 #navit: < tryagain> i saw logs. Is housenumber search still an issue with map made with patched maptool? 17:10 #navit: < jandegr> finding streets works perfect now, only when searching housenumbers it sometimes goes wild 17:11 #navit: < jandegr> and on the console I get messages about extending the search range, so I started looking in the code and the commits 17:12 #navit: < tryagain> let's see where it goes wild.. It shouldnt cross town boundary iirc... 17:12 #navit: < jandegr> it crosses town boundary twice !! 17:13 #navit: < tryagain> ah... then that was probably an unfinished idea... 17:13 #navit: < jandegr> I specified an adress in the trac ticket, you can issue a search for it if you have a map for Belgium 17:15 #navit: < tryagain> i would need the map built with patched maptool, i don't have one yet... 17:16 #navit: < jandegr> kazer gave a link to a new map yesterday, one moment... 17:16 #navit: < jandegr> http://www.kazer.org/belgium.bin 17:16 #navit: < jandegr> if kazer still left it there.... 17:17 #navit: < tryagain> i will try it.. 17:18 #navit: < jandegr> thx 17:18 #navit: < jandegr> town = Deinze, street is Kortijksesteenweg 17:21 #navit: < tryagain> korti gives no results 17:22 #navit: < jandegr> typo, kortrijksesteenweg 17:22 #navit: < jandegr> sorry 17:23 #navit: < tryagain> which house number should i try? 17:24 #navit: < tryagain> ah, i have entered 2 and got two clusters 17:24 #navit: < jandegr> tap 1 and partial matches > 1000 show up 17:24 #navit: < jandegr> > 1000 is 2 cities waw 17:25 #navit: < jandegr> > 1000 is two cityies further and some 15 km away 17:26 #navit: < jandegr> or select the suggestion 1023 and the "show results on map" 17:26 #navit: < jandegr> you'll se they are not in Deinze, but in other cities 17:28 -!- tryagain [~quassel@178.216.76.113] has quit [Ping timeout: 255 seconds] 17:30 -!- KaZeR_ [~KaZeR@64.201.252.132] has joined #navit 17:32 #navit: < jandegr> Hi KaZeR 17:33 -!- tryagain [~quassel@178.216.76.52] has joined #navit 17:34 #navit: < tryagain> jandegr sorry, my internet connection has gone. Ok, i can reproduce it. Any idea how to fix? ;) 17:38 #navit: < jandegr> I don't fully understand that part of the code yet, but seems to me it should stay within the town borders ? 17:39 #navit: < tryagain> yes, that was my idea to do it like it's done for streets in http://sourceforge.net/p/navit/code/5415/ 17:39 #navit: < jandegr> I saw something in the code about indexed search too, but it seems to relate to chunk of experimental code in maptool ??? 17:39 #navit: < tryagain> indexed search is related to town search and it's already moved to mainstream 17:40 #navit: < jandegr> oops 17:40 #navit: < jandegr> and to be honest, at this point this part of the code is still above my limits 17:41 #navit: < KaZeR_> hey tryagain 17:41 #navit: < KaZeR_> saw your mail. i don't have a server with >=12 GB RAM now, but i'm considering renting one 17:41 #navit: < jandegr> but I am already happy that you could reproduce the issue 17:42 #navit: < KaZeR_> actually i have a spare server with a lot of ram and horsepower too that we could use temporarily ( i have it for a couple of weeks only but that could buy us some time ) 17:42 #navit: < tryagain> with house number search its not that simple, as navit internal interfaces pass only one parent level for search (i.e. street for housenumber search). But we need another level 17:42 #navit: < jandegr> and you just happened to come in here :) 17:43 -!- hoschi [~marcus@2a02:908:eb51:ad80:9479:ba3a:dbec:8493] has joined #navit 17:43 #navit: < jandegr> I will add some more info to the ticket, and I suppose it wil remain open for now. 17:44 #navit: < jandegr> have to go for 30 mins. 17:44 #navit: < tryagain> KaZeR hey. I'm unsure if we should try to do it on a temporary server... But that could give us some hint if this is th way to go or we need SSD too. 17:44 #navit: < tryagain> jandegr ok, please update the ticket 17:44 #navit: < tryagain> hoschi hi 17:45 #navit: < tryagain> do you have any perfomance benefit from your bidirectional routing improvement? 17:45 #navit: < KaZeR_> tryagain: i'll setup the box asap. anything special needed for the automated process? or do we just have a crontab that will give me all we need ? 17:46 #navit: < KaZeR_> hey hoschi. make sure to share your code, that sounds really interesting :) 17:47 #navit: < tryagain> cp15 done his own scheduler which checks if a process is already running... We could do it our way. 17:48 #navit: < KaZeR_> ok. and maybe commit it somewhere.. and document it :D 17:48 -!- [1]bafplus [~bafplus@5ED0A3EE.cm-7-1c.dynamic.ziggo.nl] has joined #navit 17:48 #navit: < tryagain> At first, we could just try manually running maptool on the planet to check performance. 17:49 #navit: < KaZeR_> yep 17:50 #navit: < tryagain> Simplest way would be to start with pbf. Though production uses o5m which is faster, but it's not available on official mirrors. 17:50 #navit: < tryagain> we could download it from our server 17:51 #navit: < KaZeR_> brb 17:51 -!- KaZeR_ [~KaZeR@64.201.252.132] has quit [] 17:52 -!- bafplus [~bafplus@go.allip.nl] has quit [Ping timeout: 272 seconds] 17:52 -!- [1]bafplus is now known as bafplus 17:52 -!- KaZeR [~KaZeR@64.201.252.132] has joined #navit 17:52 -!- mode/#navit [+o KaZeR] by ChanServ 17:52 #navit: <@KaZeR> re 17:52 #navit: < tryagain> re 17:55 #navit: < tryagain> hoschi Regarding item. You should get all attributes and coordinates before you query for the next item. Otherwise you'll have to requery the map file with map_rect_get_item_byid, which is resuorce hungry and not reenterant. 17:59 #navit: < hoschi> good evening KaZeR, yeah for sure! i want to share :) should i upload onto git or on your svn/git? 17:59 #navit: <@KaZeR> whatever suits you best. long term solution is probably rather svn if you are willing to maintain it 18:00 #navit: < tryagain> hoschi you also may create a trac ticket 18:00 #navit: < tryagain> and attach your diff 18:06 #navit: < tryagain> afk 18:07 #navit: < hoschi> thank you tryagain, i assumed somethink like this 18:08 #navit: < hoschi> and yes ok, i will create a diff at the weekend and post it within a trac ticket. 18:11 #navit: < hoschi> tryagain i need all items of the selections and maps because i want to try to read them into memory for building up the graph with parallel worker. not really a worker-consumer principle. so i need a item with its data needed for buildup the graph and i think the data is within the ->priv data. 18:14 #navit: < hoschi> performance benefit is a speedup of 1.4 up to 3.4, depending on the route that is calculated. 18:16 #navit: < hoschi> but my measurements say that the route_graoh_flood() dijkstra only take 1/10 of the whole time that is needed for a routing request. the biggest part is the buildup of the graph. It takes a lot of time. 18:17 #navit: < hoschi> the most devices these days got more than one core so why should we not use the power ;) 18:18 -!- woglinde [~henning@g225080042.adsl.alicedsl.de] has joined #navit 18:19 -!- hoschi__ [~marcus@2a02:908:eb51:ad80:45ca:a040:923c:85f1] has joined #navit 18:22 -!- hoschi [~marcus@2a02:908:eb51:ad80:9479:ba3a:dbec:8493] has quit [Ping timeout: 240 seconds] 18:32 #navit: < tryagain> hoschi__ are you sure it's not io and unzip being the bottleneck rather than graph buildup? 18:33 #navit: < bafplus> Hy guys, back again...just read the duscusion about the ectended housenumber search. 18:34 #navit: < bafplus> Why not take the zipcode in account in the search? 18:34 #navit: < tryagain> hoschi__ we also have problems with memory consumption on low end devices (like WinCE based ones with 64Mb of RAM) 18:36 #navit: < bafplus> You already specify a town, when taking the town+street you already have (part off) the zipcode. Each town use different zipcodes for that same street, thus would only return the housenumbers that resides in that zipcode/street 18:36 #navit: < tryagain> bafplus actually, it's not natural for me. In my region, not all people know their own zip code, not to say about zip codes in places they visit 18:37 #navit: < tryagain> Here we have some streets having different zipcodes on different ends. 18:37 #navit: < bafplus> You don't have to know it...if you type the town and street, than navit can get the corrsponding zipcode 18:38 #navit: < bafplus> but that still gives a "range" of zipcodes, the zipcodes between the towns are significant different 18:39 #navit: < tryagain> what is "significant" difference? I gess a big city has more zipcode space than a small town. 18:40 #navit: < tryagain> *пгуыы 18:40 #navit: < tryagain> *guess 18:41 #navit: < bafplus> i big citty do have more zipcodes, but tey are simular, like 2011xx, 2012xx while the next town us 3412xx etc, 18:41 #navit: < tryagain> 123??? codes could belong to same city while 345678 and 345680 are different towns. 18:42 #navit: < tryagain> i mean 123000-123999 18:43 #navit: < bafplus> ok...lets take this step by step.... 18:43 #navit: < bafplus> A users gives a town and street, like "town-A" and "street-A" 18:44 #navit: < bafplus> Straat-A runs from town-a thru town-b and end in town-c 18:45 #navit: < bafplus> At this point navit only "looks" at the streetname and so results in housenumbers of all 3 towns...right? 18:46 #navit: < tryagain> something like that. But navit does not require the street to run without gaps. It could find a street few kilometers away... 18:46 #navit: < bafplus> yes...thats where the zipcode comes in... 18:48 #navit: < bafplus> town-a + street-a would result in zipcode aaaa , while town-b + street-a results in zipcode bbbb 18:49 #navit: < tryagain> what if town-a street-a has more than one zipcode? 18:49 #navit: < hoschi__> tryagain its not aboud low end devices, i want to get advantage of ram built in into modern tablets and smartphones which have 1gb or more installed. I dont know if the unzip is the bottleneck. i want to strip up the data read and graph buildup to get informations about time conumption of each step. 18:50 #navit: < bafplus> If navit takes that in account, it can also filter te results by that same zipcode because that zipcodes ONLY is part of town-a 18:51 #navit: < bafplus> ans since town-a is specified by the user as searchcriteria, howcome that navit STILL displays the street form another town? 18:51 #navit: < hoschi__> and to be compatible with low equipped devices there may be an configuration option to choose low mem usage or high mem usage. 18:52 #navit: < tryagain> hoschi__ you'll have to fetch all necessary data (attributes, coordinates) into the list. 18:53 #navit: < hoschi__> but these are in the "item->priv_data" right? 18:53 #navit: < tryagain> hoschi__ or maybe better disable route graph build up alltogether, and compute the time needed to fetch the map data? 18:54 #navit: < tryagain> they are in priv_data until you fetch another item 18:55 #navit: < hoschi__> i can not find any function to make a copy of the priv_data, is it the right way? 18:55 #navit: < tryagain> you should use functions to query attributes and coordinates to fetch them. 18:55 #navit: < hoschi__> simply deactivating the graph buildup may not be sufficient because fetching an item and processing it is chained together 19:01 #navit: < tryagain> Anyway, measuring dry map read time could worth it. You won't be able to do the whole buildup process faster than that time (unless you split unzip to multicore). 19:02 #navit: < hoschi__> maybe ;) 19:05 #navit: < hoschi__> yes but "dry" buildup is how done? if i only fetch all items, copy them and prepend them into a gsList results in very low times. 19:05 #navit: < tryagain> bafplus difficulty is that map driver do not have town info (i.e. its bounding polygon) when it processes the house number search 19:09 #navit: < tryagain> it's current navit internal api limitation. I had worked to fix it, but never finished it, maybe because there were no reports of such neighbouring streets :) 19:11 #navit: < bafplus> so why is there a zipcode displayed when you seach for a street? cant we use them? 19:11 #navit: < hoschi__> api limitation is for my problem?^^ 19:11 #navit: < bafplus> as extra filter? 19:12 #navit: < bafplus> but then still... i try to reproduce jandegr problem using deinze and kortrijksesteenweg, but i got "normal" results.... 19:12 #navit: < tryagain> hoschi__ api limitation is for housenumber search. Your results are interesting. I think it should be enough to compute dry time. So we probably really can improve graph buildup time. 19:12 #navit: < bafplus> jandegr , care to give some screenshots or explain me in Dutch (pm) youre problem? 19:13 #navit: < tryagain> bafplus what map file do yo use? http://www.kazer.org/belgium.bin ? 19:14 #navit: < bafplus> yep 19:15 #navit: < tryagain> i select town, street, then enter a number 1, then select any found housenumber , and do "show results on the map" 19:15 #navit: < bafplus> using the latest build and win32 (could there be a differance between say windows and android maybe?) 19:16 #navit: < bafplus> ehm,..why do that? 19:16 #navit: < tryagain> well, i'm under linux and it's not a current svn (like a week ago). 19:16 #navit: < bafplus> no i ment why show it on map? 19:17 #navit: < tryagain> when you do "show results", you see placement of all found items on the map 19:17 #navit: < jandegr> was gone for a while 19:17 #navit: < tryagain> and it's clear that these results are in different towns 19:17 #navit: < bafplus> the problem was that navit returns multiple sets of housenumbers but from different towns right? or am i missing the point here.... 19:17 #navit: < jandegr> screenshot is already attached to the ticket 19:18 #navit: < jandegr> was just looking in the code and the following : 19:18 #navit: < bafplus> what ticket becuase there are mentioned more than one :-) 19:18 #navit: < jandegr> For unindexed house number search, check if street segments extending possible housenumber locations were found 19:19 #navit: < jandegr> gives the impression there is also an indexed kind of search for housenrs. 19:19 #navit: < jandegr> line 2356 19:20 #navit: < jandegr> ticket is 1243 19:20 #navit: < hoschi__> tryagain, ok thank you. have you any experience with core or binfile plugin? 19:20 #navit: < tryagain> jandegr, it's possible, if you place housenumber index into the map file. Current maptool is unable to do it. 19:21 #navit: < tryagain> hoschi_ yes 19:22 #navit: < jandegr> bafplus, most of the work for your zipcode issue is in the gui 19:22 #navit: < jandegr> the searchengine can be extended for your issue 19:25 #navit: < bafplus> yes but the gui code for that is in the source, i'm no coder so i have noow clue to where to look for it let alone "change" it... 19:25 #navit: < jandegr> tryagain, a last question if possible 19:25 #navit: < bafplus> only thing i can work with is the navit.xml 19:26 #navit: < tryagain> jandegr don't ask to ask, just ask ;) 19:26 #navit: < bafplus> no...just do it ;-) 19:27 #navit: < jandegr> why is the part with the extended search handled outside the while, swith, case construction ? 19:27 #navit: < jandegr> is that done after the search as a kind of postprocessing ? 19:27 #navit: < hoschi__> tryagain you are right i have to load the item data with item_attr_get and item_coord_get but then i have to construct the same structure to remain compatibillity, right? Or i have to change the type of the item to an own implementation. 19:27 #navit: < bafplus> jandegr , if i do the show on map i see the complete street crossing the towns just as youre screenshot but WITHOUT the actual "pins" for the found results 19:27 #navit: < bafplus> must be a map/gui thing i guess 19:30 #navit: < jandegr> bafplus, you can select them to set as destination, so even if they don't show up on your box, it's not good. 19:31 #navit: < tryagain> bafplus strange, i was pretty sure "show all results" feature to be multiplatform.. 19:32 #navit: < tryagain> hoschi__ looks like you'll have to build the list of all found items in your own format and then change the code to process it in parallel... 19:32 #navit: < bafplus> is works, but the labels for the found results are not shown when using the OSM map, if i use the "Car" map the labels are there... 19:34 #navit: < tryagain> bafplus ah... Where you've got that "osm" layout from? 19:34 #navit: < jandegr> bafplus, showing them on the map is only to clarify the issue, but is not relevant on it's own. 19:34 #navit: < tryagain> but very usable :) 19:34 #navit: * tryagain has implemented "show results on the map" 19:36 #navit: < hoschi__> tryagain: "looks like" or "for sure"? :) maybe i get around this when i define a struct holding the data and copy the three functions route_process_traffic_distortion(), route_process_turn_restriction() and route_process_street_graph() to replace the according function calls with structure reads 19:36 #navit: < bafplus> layout is from the wiki 19:36 #navit: < bafplus> it has some more small isues 19:37 #navit: < hoschi__> why is an item not simply an item :D 19:37 #navit: < tryagain> hoschi__ :) 19:38 #navit: < bafplus> jandegr, isnt it the big problem that when searching for housenumbers it shows all results "containing" the given caracter? 19:38 #navit: < bafplus> So searching for "1" wil display 1, 11, 111, 1023, etc, etc 19:39 #navit: < tryagain> bafplus why is it a problem? 19:39 #navit: < jandegr> 1023 is two cities and more than 10km away from the targeted city. 19:40 #navit: < bafplus> because thats why jandegr is getting so much in his housenumber search 19:40 #navit: < bafplus> i agree, but for Navit it IS the same street.... 19:40 #navit: < tryagain> he could had three house numbers "1", and it would not help. Problem is in town boundaries crossing. 19:42 #navit: < bafplus> jandegr, can we go PM and talk this thru in dutch, because i don't think i understand you completely 19:42 #navit: < tryagain> If there were all these 1,11,111,1023 coming from the same city, it would not be a problem 19:42 #navit: < jandegr> I'll build a more verbose version of binfile.c in the next few days, but it might help if you could tell me why there is a codeblock outside the main loop to 19:42 #navit: < jandegr> search for housenr's again 19:47 #navit: < tryagain> jandegr do you mean these restarts? dbg(0,"Extended house number search region to %d x %d, restarting...\n", 19:47 #navit: < tryagain> or something else? 19:49 #navit: < tryagain> KaZeR http://maps6.navit-project.org/planet-140821.o5m 19:51 #navit: < bafplus> Couldnt you warned me that that link was almost 50gn download...i just clicked it :-) 19:51 #navit: < tryagain> ;) 19:52 #navit: < tryagain> that's not your link 19:52 #navit: < bafplus> i know...but when i see a link i just can't help myself... 19:52 #navit: < jandegr> yes, that's the section I mean, it's not in the main loop, probably for a good reason but it would help me to know why it's done outside the main loop 19:54 #navit: < jandegr> and if there is no easy solution to limit the search to the target city, maybe there is a possibility to filter them after the search ? 19:54 #navit: < tryagain> we select the map region by guess. It's not guaranteed to contain the whole street. If there are some hints that street is bigger than our guess, we retry with extended area. 19:55 #navit: < jandegr> thx, clear 19:57 #navit: < tryagain> that's not very easy too, as some map drivers (garmin?) do not require such filtering, and it could be impossible for them to fetch a town polygon. We should fix binfile driver. 19:58 #navit: < tryagain> KaZeR something like maptool -M -k -S 8000000000 -u http://maps.navit-project.org/planet-$to.bin -5 /work/tmp/planet-$to.bin.md5 -6 /work/tmp/planet-$to.bin 19:59 #navit: < tryagain> I think 8G would be ok for 12G RAM 20:00 #navit: < jandegr> ok, no postfiltering, so I'll have to look for a way to improve the decision to restart the search, btw does an increase twice for this search. 20:02 #navit: < bafplus> i may be saying something stupid here....but why guess something if the user already specifies i criteria to search for? 20:04 #navit: < tryagain> bafplus we currently have no way to pass town info into the houenumber search. Only one street segment could be passed for now. It's how navit works. 20:05 #navit: < tryagain> We have to find a way to pass town info without breaking navit's internal api. 20:06 #navit: < jandegr> a aprtial solution might be to stop extending when the name of the street changes, name is probably accessible from the road object ? 20:07 #navit: < jandegr> would already solve the search starting in Deinze 20:08 #navit: < tryagain> we extend only when we find a matching street segment or house number. But we do not count gaps. Stopping on the gaps would probably solve some cases. 20:09 #navit: < jandegr> gap as in 'has another name' ? 20:09 #navit: < tryagain> but if we have a road which has same street names in different adjanced towns, we'll have the problem again 20:10 #navit: < tryagain> yes, has another name or unnamed 20:10 #navit: < tryagain> but what if there's a small unnamed segment? Like a roundabout? 20:11 #navit: < jandegr> yes, but on that specific road where it makes the second crossing of town boundary, but continues after the crossing with the same name, the numbering order reverses 20:12 #navit: < jandegr> the first crossing would be solved (for Deinze) 20:12 #navit: < jandegr> I also noticed it does not extend backwards if you start searching in the town in the middle 20:13 #navit: < jandegr> I'll provide some more info on that in the ticket, but won't be tonight 20:14 #navit: < jandegr> see you later folks 20:15 -!- jandegr [574158de@gateway/web/freenode/ip.87.65.88.222] has quit [Quit: Page closed] 20:15 #navit: < bafplus> seing this discusion and tested it with the longest street in NL...now i know why we navigate on zipcode+housenumber ;-) 20:15 #navit: * tryagain would like to see an example how "it does not extend backwards if you start searching in the town in the middle" 20:17 -!- Mineque [~Mineque@89-68-233-84.dynamic.chello.pl] has joined #navit 20:23 #navit: < bafplus> tryagain , do you want a another "housenumber" case? try netherlands->krommenie->dorpsstraat 20:25 #navit: < bafplus> You are totaly f&%$%ed if you want to go there , just try housenumber 1 and see how navit is strugling with multiple results :-) 20:28 #navit: < bafplus> good luck finding the number 1 you raly have to drive to....without a zipcode you are totaly screwed...btw...thats the longest street in the NL 20:30 #navit: < bafplus> lol...just housenumber "1" gives 14!!!! results 20:30 #navit: < tryagain> bafplus i think navit should show housenumber 1 at the top, isnt it? 20:31 #navit: < bafplus> it does, but it takes a while before navit is finished filtering all the data... 20:31 #navit: < bafplus> at the end you have 14 results with just housenumber "1", after that yiu get 14 housenumber "10" and so on 20:32 #navit: < tryagain> so there are 14 towns having the same street? 20:32 #navit: < tryagain> *same street name 20:33 #navit: < bafplus> same street and al with a housenumber 1... 20:33 #navit: < tryagain> an issue... 20:34 #navit: < bafplus> http://nl.tinypic.com/r/15w0ld/8 20:35 -!- j_f-f [~quassel@orion2589.server4you.de] has quit [Remote host closed the connection] 20:35 #navit: < bafplus> funny thing is that all townnames are "krommenie" while that should be all different names...hmm...now i think of it....small guess...admin_level????? 20:37 #navit: < tryagain> nope, it's again our search engine limitation. It thinks it found an item inside the town it was searching in... 20:38 -!- j_f-f [~quassel@orion2589.server4you.de] has joined #navit 20:38 #navit: < bafplus> i cant say it enough....you asked me a few days ago why i would want a search zipcode+housenumber remember? 20:38 #navit: < bafplus> Now you see why ;-) 20:39 #navit: < tryagain> why do you ask for zipcode search, not for fixing housenumber search to keep insinde town boundary? 20:40 #navit: < bafplus> how about both! Because not everyone KNOWS the zipcode they are traveling too... 20:41 #navit: < bafplus> Don't get me wrong, i 100% support jandegr to fix this 20:41 #navit: < bafplus> But if you KNOW the zipcode, you can get you're destination with less typing and judging the above, more accurate 20:42 #navit: < tryagain> what if there's simply no zipcode tagged on the house? 20:43 #navit: < bafplus> or a housenumber.... 20:43 #navit: < bafplus> it may be abvious that it all relies on the data provided in the maps metadata 20:44 #navit: < bafplus> i can give you an example of some streets that don't have housenumbers (yet) in OSM 20:45 -!- jandegr [574158de@gateway/web/freenode/ip.87.65.88.222] has joined #navit 20:45 #navit: < tryagain> hoschi__ yes i have 20:45 #navit: < tryagain> brrr 20:46 #navit: < tryagain> sorry 20:46 #navit: < jandegr> tryagain : ticket 1243 is updated for the backward situation 20:46 #navit: < bafplus> In those cases the only option is to navigate to the "center" of the street 20:46 #navit: < bafplus> hy jandegr...help me out here... ;-) 20:46 #navit: < jandegr> I was away 20:48 #navit: < bafplus> tryagain , searching for ANY town/street/zipcode/housenumber relies in the data that is inside the map... so if one of them is "missing" you have no option than to navigate to "next best thing" 20:49 #navit: < bafplus> but i guess you already know that ;-) 20:50 #navit: < tryagain> :) 20:50 #navit: < tryagain> jandegr I guess that is not an issue. We do not attempt to find all far away street segments. Most probably, street segments in Dienze are not that big so they are put into low level tiles and not fetched by navit. 20:51 -!- woglinde_ [~henning@f053040053.adsl.alicedsl.de] has joined #navit 20:51 #navit: < tryagain> So it does not extend in that direction. 20:52 #navit: < hoschi__> tryagain thank you for your help :) good fight, good night 20:52 #navit: < tryagain> gn 20:53 #navit: < bafplus> but to get to the bigger picture, ALL features should be working, but why not implement more "ways" to find you're destination depanding on what kind of criteria you are searching? 20:53 #navit: <@KaZeR> tryagain: will have a look at setting up a temp server. i have a few beasts sitting idle 20:53 #navit: <@KaZeR> bafplus: http://goo.gl/SsAhv 20:53 #navit: < jandegr> tryagiain: just wanted to inform you as good as possible, good night. 20:53 -!- hoschi__ [~marcus@2a02:908:eb51:ad80:45ca:a040:923c:85f1] has quit [Remote host closed the connection] 20:54 -!- woglinde [~henning@g225080042.adsl.alicedsl.de] has quit [Ping timeout: 255 seconds] 20:54 -!- jandegr [574158de@gateway/web/freenode/ip.87.65.88.222] has quit [Quit: Page closed] 20:54 #navit: < bafplus> :-) 21:03 #navit: < bafplus> KaZeR , may i shoot an idea for the zipcode search? 21:04 #navit: <@KaZeR> ideas are always welcome :) 21:04 #navit: <@KaZeR> (patches are better, but ideas are also good ;) ) 21:04 #navit: < bafplus> ok... 21:05 #navit: < Mineque> KaZeR, i'm full of ideas 21:05 #navit: < Mineque> but nobody wants them ;( 21:05 #navit: < bafplus> Why not make the "town search" capable of handling "town-names" aswell as "zipcodes"? So the user can enter the town name OR the zipcocde 21:06 #navit: <@KaZeR> Mineque: that's not true. where are your tickets? :) 21:06 #navit: <@KaZeR> bafplus: could be an option indeed. 21:07 #navit: < Mineque> KaZeR, you might find few 21:07 #navit: < Mineque> others in irclog 21:07 #navit: < bafplus> after a zipcode is entered navit should be capable of "displaying" the correct street (or a selection list if more results are found) 21:08 #navit: < bafplus> After that it can precess the same as the current housenumber search 21:09 #navit: < bafplus> it just "skips" 2 steps because the zipcode returns the town+street in one go... 21:09 #navit: < bafplus> and gives a more precise "searcharea" 21:10 #navit: < bafplus> would that be hard to do? If not...is somebody willing to code it" 21:11 #navit: < bafplus> I don't want to be pushy...but its the obe thing i realy miss... 21:14 #navit: < bafplus> not that i want it coded today.. (could it? ;-) ) , but i realy would like this feature to be on the roadmap in the near future... 21:15 #navit: < bafplus> These are the moments i wished i had more coding knowledge/skills.... 21:15 #navit: < Mineque> bafplus, we should add to wiki poll 21:15 #navit: < Mineque> vote for feature to be coded firt 21:15 #navit: < Mineque> first 21:15 #navit: < Mineque> bafplus, i know you pain 21:16 #navit: < bafplus> but only AFTER someone commits to coding it.... 21:17 #navit: < bafplus> like...i could wish it brings me a beer....i would guess that will get a lot of votes but still isen't gonna happen... 21:17 #navit: < Mineque> i tried some time ago with c++ 21:17 #navit: < Mineque> not really succesfully 21:17 #navit: < Mineque> yep i was thinking about tht also 21:17 #navit: < Mineque> how much votes that many beer poll creator send to coder 21:17 #navit: < Mineque> ;p 21:17 #navit: < bafplus> it could give me direction to my fridge tho... 21:18 #navit: < Mineque> i hope we'll meet times that so many beer wont fit in typical fridge ;) 21:18 #navit: < Mineque> means many active users 21:18 #navit: < bafplus> hehe...i second that! 21:20 #navit: < Mineque> yeah yeah, but who will pay for that beers 21:20 #navit: < Mineque> ;p 21:20 #navit: < bafplus> KaZeR...btw....whats the deal with the windows GUI not working? (only internal) 21:21 #navit: < bafplus> I heard that the GUI does have a zipcode search but no actual searchcoding behind it... 21:21 #navit: <@KaZeR> bafplus: i guess that there aren't so many people interested in fixing it :) 21:21 #navit: < bafplus> I guess so...i was also suprised there was a windows version in the first place 21:22 #navit: < bafplus> But just for my referance...is the source the same for all types of OS? 21:24 #navit: <@KaZeR> yes. couple of #ifdef in the code, but otherwise we try to maintain a single code base 21:25 #navit: < bafplus> cool....so in theory...if i "design" a osd etc in my windows version, i can port that easaly to android? 21:26 #navit: < bafplus> btw...thanks foor taking the time to answer noob questions ;-) 21:26 #navit: < bafplus> and not complain about my spelling/grammer....tho i'm still doing quite well after 5 beers... 21:27 #navit: < Mineque> bafplus, celebrating sth or just relaxing? 21:28 #navit: < bafplus> sth? 21:29 #navit: <@KaZeR> mmm beers 21:29 #navit: <@KaZeR> sth = something 21:29 #navit: <@KaZeR> bafplus: you're talking about an osd layout or an osd item ? 21:29 #navit: <@KaZeR> (but in both case, the answer is yes) 21:29 #navit: <@KaZeR> tho, with layouts, the screen resolution has to be taken into account 21:29 #navit: < bafplus> whell...not realy celebrating...if it was it would be that my kids AND wife are off to bed so i have some time to myself ;-) 21:30 -!- woglinde_ [~henning@f053040053.adsl.alicedsl.de] has quit [Ping timeout: 250 seconds] 21:30 #navit: < bafplus> i understand KaZeR 21:32 #navit: < bafplus> Ans because i'm a little bit "stressed" because i have to give a demo of Navit to my company's CO.... 21:32 #navit: < bafplus> tomorow.... 21:34 #navit: < bafplus> KaZeR...what are the specs for the server you need??? Maybe i can arange some deal with my CO tomorow in excange for some codingneeds ;-) 21:34 #navit: <@KaZeR> bafplus: that would be nice. 21:34 #navit: <@KaZeR> we need at least 12GB of ram right now. and i believe that our current map processing server has 8 cores let me check 21:35 #navit: <@KaZeR> yep our current server is 8x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 21:36 #navit: <@KaZeR> but we're getting short in RAM, since OSM datas are growing everyday 21:36 #navit: < bafplus> I cant promiss anything but when we are going to use Navit i guess we need some help to set things up and to do some coding, maybe the company can give something back like the server in exchange for you're help "starting up" everything 21:36 #navit: < bafplus> We are a big IT company....so the resources are already available ;-) 21:37 #navit: <@KaZeR> i personally like the idea 21:39 #navit: < bafplus> i will surtanly try my best to make this some kind of "B2B" thing...but i can only try...no promises yet ;-) 21:41 #navit: <@KaZeR> no worries bafplus. if it works it's nice, if it doesn't we'll find another way :) 21:41 #navit: <@KaZeR> but i appreciate 21:42 #navit: < Mineque> .:@KaZeR:. yep our current server is 8x Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 21:42 #navit: < Mineque> only for processing OSM? 21:43 #navit: < bafplus> just thinking ahead...maybe even the wiki since it lags big-time lately 21:43 #navit: < tryagain> actually maptool uses only one core. But it is very memory hungry. 21:43 #navit: < bafplus> diskspace? 21:43 #navit: < Mineque> ram i guess 21:43 #navit: < Mineque> tryagain, i see, thx 21:43 #navit: < bafplus> whats the diskspace that is needed.... 21:43 #navit: < tryagain> 250 GB of disk, and lots of ram 21:44 #navit: <@KaZeR> Mineque: wiki also is hosted there. trac is on another server 21:44 #navit: < tryagain> disk we use now is SSD. Unsure if that's so critical 21:45 #navit: < bafplus> so in short...if we can provide hosting and server, can we rely on dedicated coding from the core designers? 21:45 #navit: < Mineque> KaZeR, prv? 21:45 #navit: < bafplus> again...its just an idea at this point.... 21:45 #navit: <@KaZeR> bafplus: no, because for that you probably want some form of contract 21:45 #navit: < tryagain> have to go now... gn... 21:45 -!- tryagain [~quassel@178.216.76.52] has quit [Remote host closed the connection] 21:46 #navit: < bafplus> We have enough coders, thats not the point, but i figure that they want some kind of support "learning" the source etc... 21:47 #navit: < bafplus> and give all patches etc back to the project off course 21:48 #navit: < bafplus> if they have a question or need help they cant wait for "weeks" 21:48 #navit: <@KaZeR> bafplus: i can't speak for the others, but i'm pretty sure that you will get best-effort support either on irc, or the mailing list. can't give any SLA tho 21:49 #navit: < bafplus> i understand and i think that my company will also 21:50 #navit: < bafplus> its still a comunity thing 21:51 #navit: < bafplus> but if we can bundle our "powers" i think that would benefit the project big-time 21:52 #navit: <@KaZeR> i'd love to see that happen 21:52 #navit: < bafplus> maybe i'm shooting way to far at this point but i can surely try 21:53 #navit: < bafplus> First, lets see what they will say when they see navit in action tomorow 21:54 #navit: <@KaZeR> i hope your demo will go well, they don't always do :D 21:55 #navit: < bafplus> Well...i'm using it full-time for about a week now and i must say...almost flawless! 21:55 #navit: < bafplus> Some missfix now and then but that could be caused by the internal gps reciever 21:56 #navit: < bafplus> i'm expecting a bluetoot reciever somewhere in teh next days so i will test to see if that improves anything 21:57 #navit: < bafplus> now sometimes navit thinks i'm on a paralell road...very anoying ;-) 21:58 #navit: < bafplus> but i'm off for today..its midnight here and the beer is taking its toll ;-) 21:59 #navit: <@KaZeR> yeah that's definitely an issue with the signal quality and urban jungle. this one is hard to fix. on one hand, we could add some filtering depending of the road you were on previously. on the other, it could lead to even more errors 21:59 #navit: <@KaZeR> good night and best of luck for tomorrow! 21:59 #navit: < bafplus> thanks...that reminds me of a ticket i recently saw about using the demo car for gps-gaps etc 22:00 #navit: < bafplus> maybe thats a sollution? 22:00 #navit: < bafplus> or make the magnetic road a bit more or less "magnetic"? 22:00 #navit: < nate`> AAWell have navit running nicely on my beagle. 22:01 #navit: < nate`> still having issues with my touch screen though. 22:01 #navit: < bafplus> you run navit on a dog??? ;-) 22:01 #navit: < nate`> suppose I should read up more on that. 22:01 #navit: < nate`> bafplus: yeah a black one :p 22:02 #navit: < bafplus> i run it on a panasonic toughbook, it has touchscreen but i don't use it that offten... 22:02 #navit: < nate`> I have a 7" koolertron touch screen I'm going to use. 22:02 #navit: < nate`> things beagle is running: audio, SDR and GPS. 22:02 #navit: < bafplus> i have no clue what that is, besides a 7" touchscreen... 22:03 #navit: < nate`> That's basically what it is heh 22:03 #navit: < nate`> it's a good size to mount on my dash 22:03 #navit: < nate`> and comes off the stand pretty easily 22:03 #navit: < bafplus> i run win32, audio speech using wav, internal gps(a) 22:04 #navit: < bafplus> whats SDR? 22:04 #navit: <@KaZeR> nate`: how are the performances on your beagle? i'm considering getting one for my bike 22:04 #navit: < bafplus> lol...i just saw a dog on the stearingwheel of a bike...thats it...enaugh beer for today ;-) 22:05 #navit: < bafplus> it barks once for left, twice for right... 22:05 #navit: < bafplus> sorry...i'm off... 22:05 #navit: < nate`> KaZeR: well I haven't put it through anything difficult but it's working alright 22:06 #navit: <@KaZeR> nice. any chance you could shoot a video to show the responsiveness of it ? 22:07 #navit: < nate`> if I remember once I get it in the truck 22:07 #navit: < nate`> should be getting that truck back tomorrow. I've had a shitty month with vehicles. 22:08 #navit: < nate`> alternator in my dodge was only generating 5 volts. The auto parts store ordered the wrong one twice, the third one was the right one but part of it was too long to fit in the mounting bracket so had to bust out a hack saw last night to get it in. 22:09 #navit: < nate`> the stupid window issue with my 4runner, did get the driver side door fixed with a new switch and panel, and my left window as well as power locks working only for my tail gate to stop working and had to hunt down a motor for it. Then my key snapped off in the ignition and had to get a new ignition cylinder/lock. 22:09 #navit: < nate`> Meaning once I get the 4runner back tomorrow I have to go to a lock smith and get my doo cylinders rekeyed for the new keys 22:11 #navit: < nate`> It's also been a hell of a couple of weeks for new toys. Went night hunting for hogs earlier this week. Found out that's easier wit hnight vision so bought me a nice monocular for that with a head mount. Picked up a 300 lumen red LED flash light to mount onto my AK. A new dust cover for the AK so I can put my red/green dot and magnifier on it as well as a laser on it. 22:11 #navit: < nate`> Pawn shop had a nice 720p 32" tv for 70 bucks so snagged that and gonna get my rasp pi on there with a flirc receiver. 22:15 -!- bafplus [~bafplus@5ED0A3EE.cm-7-1c.dynamic.ziggo.nl] has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC] 22:16 #navit: < nate`> Hoping this weekend I can get a bunch of projects finished so I can clean my damn work table 22:17 #navit: < nate`> One of those projects is an ultimate swamp cooler so I can turn the damn AC off in this house. 22:21 #navit: < magruder> XD nate 22:21 #navit: < nate`> go from what ever the house unit is down to 10 volts of power to cool the areas that need to be cooled. Should shave about 150 dollars a month at least 22:21 #navit: < nate`> oh the other new toy this month, Springfield xDS in 9mm luger :D 22:45 -!- j_f-f [~quassel@orion2589.server4you.de] has quit [Ping timeout: 250 seconds] 22:50 -!- j_f-f [~quassel@orion2589.server4you.de] has joined #navit --- Log closed Fri Aug 22 00:00:41 2014