[01:30:40] *** Quits: Horwitz (~mich1@p200300ec9f03e800022268fffe64e7c4.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) [01:43:06] *** Joins: Horwitz (~mich1@p200300ec9f02e800022268fffe64e7c4.dip0.t-ipconnect.de) [01:43:06] *** ChanServ sets mode: +o Horwitz [12:23:32] *** Joins: peterm6881 (~peter@91.40.93.209.dyn.plus.net) [12:25:45] why is it when I Navigate and Select in Planet Extractor, the bin file is the same size regardless of whether I select the whole state or a tiny featureless area??? [12:26:41] I dont want the whole 172MB of New South Wales, I only want the tiny bit I zoomed in on [12:31:33] its a pity, because apart from being useless, its pretty good [12:36:08] hi perterm6881 [12:36:19] from what i see the predefined area is 313 mb [12:37:20] but unfortunately I cant explain you why it does not scale down so much, my guess what be that metadata takes a larger share of the whole dataset [12:39:17] if i remember correctly, the bin format is a kind of a zipped file [12:39:25] so we could have a look inside to find out [12:41:33] hi ilovekiruna [12:42:24] pick any area, its all the same. You can zoom right in but after a certain point the map doesn't get any smaller, which defeats the object [13:32:57] *** Quits: peterm6881 (~peter@91.40.93.209.dyn.plus.net) (Quit: Leaving) [13:46:31] @jkoan, do you have some insights? [13:50:00] hi ilovekiruna, hi peterm6881: the reason it that this is the minimal size for all tiles when all files are of size 0. So its just really really much metadata for empty files [13:50:57] this is as far i know because the binfile driver is crippled [13:52:02] i started a new binfile2 driver which uses libzip, but this one i've just started for research on binfile [14:09:19] ilovekiruna: does this help? [14:11:12] @jkoan, at least much better explanation than anything I could have said [14:11:36] good :D [14:12:35] i think more detail is that there is a file within the zip named index which contains pointers or such to submaps, but i am currently researching this [14:16:16] but i couldn't find out why this file is needed, because as far as my understanding goes the filenames of the tiles have bbox's, but probably its for performance [15:11:34] *** Joins: peterm6881 (~peter@91.40.93.209.dyn.plus.net) [15:14:44] *** Quits: peterm6881 (~peter@91.40.93.209.dyn.plus.net) (Client Quit) [16:29:21] *** Quits: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) (Ping timeout: 264 seconds) [16:41:40] *** Joins: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) [18:20:16] Hi all [18:21:31] I am currently considering another traffic plugin, capable of connecting to TraFF servers via HTTP/HTTPS, available on most (ideally all) platforms on which Navit is supported [18:21:53] for this we would need HTTP client functionality in Navit [18:22:43] the only thing we have is the map download code in navit/file.c, most of which seems to have been written in 2010/2011 by Martin Schaller [18:23:56] though it is quite rudimentary and supports only plain HTTP and GET, no SSL and no POST [18:25:00] so I'd either have to implement all of this stuff from scratch, or get some third-party HTTP library [18:25:41] and if we want to be really clean, we could then also migrate from our own HTTP client code to that library [18:26:08] questions: first, does anyone know if we ever considered using an external HTTP library? [18:27:29] second, does anyone have a sufficient grasp of the HTTP client code in file.c and would know what API it needs to provide, and how the map driver would need to use it (so one could port the driver to an external HTTP lib)?