Re: Yaouh! out (update for tangogps maps)
On Fri, January 23, 2009 02:58, William Kenworthy wrote: Reiserfs3 however just rocks! Yes, it's killer! Sorry, that was a troll, my apologies (could not resist it). -- Regards, Jan Henkins ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
ext2/3 is not really suited to storing such a large number of small files. afaik ext3 can be configured to use small files. (I don't understand why ext2/3 is used at all these days, as it has been obsolete for years. that's nonsense. Except for one bug 8 years ago[1], ReiserFS has worked flawlessly for me on my desktop systems.) i use ext2/3 for over ten years now and never had any problems. if you like reiser better, it's ok, but please don't tell such nonsense only to justify your likings. it's purely a matter of personal preferences, nothing more -- and least of all extX is bad, reiser is good. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
arne anka wrote: ext2/3 is not really suited to storing such a large number of small files. afaik ext3 can be configured to use small files. (I don't understand why ext2/3 is used at all these days, as it has been obsolete for years. that's nonsense. Except for one bug 8 years ago[1], ReiserFS has worked flawlessly for me on my desktop systems.) i use ext2/3 for over ten years now and never had any problems. if you like reiser better, it's ok, but please don't tell such nonsense only to justify your likings. it's purely a matter of personal preferences, nothing more -- and least of all extX is bad, reiser is good. There is also a lot of community support for ext[234] with noticeable active development. I'm not so certain what the condition of ReiserFS is these days, but I don't think there have been any enhancements or improvements to match ext4. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
its not nonsense - ext2/3 is vastly overrated - However, I am aware that its very much dependent on your use case. And in my use case, Ive been bitten too many times. Never heard that ext3 is good for small files - the opposite in fact as it doesnt do tail packing (so can waste huge amounts of space), and has limited number of inodes available - which limit I ran into. Ive since reformatted with the maximum, but that is supposed top cause performance problems though I have not measured how much its slowed the FR down. I am worried about the future for Reiserfs, but apparently work was continuing when I last checked. BillK On Fri, 2009-01-23 at 10:36 +0100, arne anka wrote: ext2/3 is not really suited to storing such a large number of small files. afaik ext3 can be configured to use small files. (I don't understand why ext2/3 is used at all these days, as it has been obsolete for years. that's nonsense. Except for one bug 8 years ago[1], ReiserFS has worked flawlessly for me on my desktop systems.) i use ext2/3 for over ten years now and never had any problems. if you like reiser better, it's ok, but please don't tell such nonsense only to justify your likings. it's purely a matter of personal preferences, nothing more -- and least of all extX is bad, reiser is good. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Fri, Jan 16, 2009 at 04:12:19PM +0100, Tilman Baumann wrote: Untested code: import httplib conn = httplib.HTTPConnection(tile.openstreetmap.org) conn.request(HEAD, /file...) r1 = conn.getresponse() print r1.status, r1.reason etag = getheader(ETag) print etag And if stuff was new, make GET instead of HEAD The 'If-None-Match:' header field of the GET request appears to do the right thing. http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26 Example using wget when we don't have the tile: $ wget --server-response http://tile.openstreetmap.org/5/6/7.png --2009-01-22 18:14:19-- http://tile.openstreetmap.org/5/6/7.png Løser tile.openstreetmap.org...128.40.58.204 Connecting to tile.openstreetmap.org|128.40.58.204|:80... forbundet. HTTP forespørgsel sendt, afventer svar... HTTP/1.1 200 OK Date: Thu, 22 Jan 2009 17:14:19 GMT Server: Apache/2.2.4 (Ubuntu) ETag: 865cd3d3cc1cf8ae3cf920234f539d91 Content-Length: 5822 Cache-Control: max-age=518361 Expires: Wed, 28 Jan 2009 17:13:40 GMT Keep-Alive: timeout=3, max=100 Connection: Keep-Alive Content-Type: image/png Længde: 5822 (5,7K) [image/png] Saving to: `7.png' 2009-01-22 18:14:19 (179 KB/s) - `7.png' saved [5822/5822] Example where we have an up-to-date tile already: $ wget --server-response \ --header 'If-None-Match: 865cd3d3cc1cf8ae3cf920234f539d91' \ http://tile.openstreetmap.org/5/6/7.png --2009-01-22 18:15:25-- http://tile.openstreetmap.org/5/6/7.png Løser tile.openstreetmap.org...128.40.58.204 Connecting to tile.openstreetmap.org|128.40.58.204|:80... forbundet. HTTP forespørgsel sendt, afventer svar... HTTP/1.1 304 Not Modified Date: Thu, 22 Jan 2009 17:15:25 GMT Server: Apache/2.2.4 (Ubuntu) Connection: Keep-Alive Keep-Alive: timeout=3, max=100 ETag: 865cd3d3cc1cf8ae3cf920234f539d91 Expires: Wed, 28 Jan 2009 18:17:50 GMT Cache-Control: max-age=522144 2009-01-22 18:15:25 FEJL 304: Not Modified. Example where we have an outdated tile: $ wget --server-response \ --header 'If-None-Match: 865cd3d3cc1cf8ae3cf920234f539d90' \ http://tile.openstreetmap.org/5/6/7.png --2009-01-22 18:23:10-- http://tile.openstreetmap.org/5/6/7.png Løser tile.openstreetmap.org...128.40.58.204 Connecting to tile.openstreetmap.org|128.40.58.204|:80... forbundet. HTTP forespørgsel sendt, afventer svar... HTTP/1.1 200 OK Date: Thu, 22 Jan 2009 17:23:10 GMT Server: Apache/2.2.4 (Ubuntu) ETag: 865cd3d3cc1cf8ae3cf920234f539d91 Content-Length: 5822 Cache-Control: max-age=522491 Expires: Wed, 28 Jan 2009 18:31:22 GMT Keep-Alive: timeout=3, max=100 Connection: Keep-Alive Content-Type: image/png Længde: 5822 (5,7K) [image/png] Saving to: `7.png' 2009-01-22 18:23:10 (129 KB/s) - `7.png' saved [5822/5822] -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Tue, Jan 20, 2009 at 08:20:59AM +0900, William Kenworthy wrote: ext2/3 is not really suited to storing such a large number of small files. The main problem is the fixed number of inodes which I ran out of despite having 2Gb still free on the SD card partition :( To work around, create the file system with -b 1024 -i 1024 for the maximum number of inodes - unfortunately this cant be changed after the FS is created. This is another problem that would be solved by using ReiserFS. It is a pity that it is not compiled into the kernel as shipped by the distributions. (I don't understand why ext2/3 is used at all these days, as it has been obsolete for years. Except for one bug 8 years ago[1], ReiserFS has worked flawlessly for me on my desktop systems.) [1] http://lkml.indiana.edu/hypermail/linux/kernel/0003.1/0714.html -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Agree. Every system Ive put ext2/3 on has had problems, lost data, corruptions, constant need to fsck, even whole filesystems unrecoverable. I think its only useful where you have simple systems, a UPS and light usage. And ext2/3 on a freerunner SD card just emphasises what a crap filesystem they are for modern uses. I will start experimenting with ext4 on a non-critical system soon, but I dont hold much hope its any better. Reiserfs3 however just rocks! BillK On Thu, 2009-01-22 at 20:21 +0100, Rask Ingemann Lambertsen wrote: On Tue, Jan 20, 2009 at 08:20:59AM +0900, William Kenworthy wrote: ext2/3 is not really suited to storing such a large number of small files. The main problem is the fixed number of inodes which I ran out of despite having 2Gb still free on the SD card partition :( To work around, create the file system with -b 1024 -i 1024 for the maximum number of inodes - unfortunately this cant be changed after the FS is created. This is another problem that would be solved by using ReiserFS. It is a pity that it is not compiled into the kernel as shipped by the distributions. (I don't understand why ext2/3 is used at all these days, as it has been obsolete for years. Except for one bug 8 years ago[1], ReiserFS has worked flawlessly for me on my desktop systems.) [1] http://lkml.indiana.edu/hypermail/linux/kernel/0003.1/0714.html -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Rask Ingemann Lambertsen ha scritto: On Fri, Jan 16, 2009 at 04:12:19PM +0100, Tilman Baumann wrote: Untested code: import httplib conn = httplib.HTTPConnection(tile.openstreetmap.org) conn.request(HEAD, /file...) r1 = conn.getresponse() print r1.status, r1.reason etag = getheader(ETag) print etag And if stuff was new, make GET instead of HEAD It sure would be more efficient if OSM supported the If-Modified-Since: header in a GET request. Then you wouldn't need the HEAD request. Also, consider using the same connection for multiple requests. It ought to help a lot with such small files. where can i found httplib package for openmoko? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Helge Hafting ha scritto: Carlo Minucci wrote: http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage A very good idea, but it does not work yet. My maps are in /media/card/kart/, but yaouh thinks they are in /home/root/Maps. so it doesn't check my 5 tiles. i found the bug :) go to line 83 of the yaouh.py and add a new line, after dir = out[2], with j = n and test it now it should work ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
William Kenworthy wrote: On Mon, 2009-01-19 at 14:54 +0100, Helge Hafting wrote: Carlo Minucci wrote: http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage A very good idea, but it does not work yet. My maps are in /media/card/kart/, but yaouh thinks they are in /home/root/Maps. so it doesn't check my 5 tiles. I have tangogps set up that way, because there is more room on the 8GB card, and it isn't blanked when I flash a new SHR image. I do not know where tangogps keeps this information though. Helge Hafting After trying a few different things, now one of my first moves is to delete /home/root/Maps and replace it with a symlink to the SD card Maps directory. Thanks for the tip - the workaround worked. Where I live (Perth, Western Australia) there are large areas of surrounding sea/land/forestry/desert etc that use a single colour tile - each of only 103 bytes. I symlinked all identical files (based on md5sum) such that only one copy of each is kept. This has the advantage that as ext2/3 uses fast-symlinks, the actual symlink (provided the path is 60 characters) is stored in the inode and doesnt take any block space on the FS. This shrinks the size as given by du -sh from 3.3Gb down to ~550Mb. Interesting idea. Half of my tiles are blank too. But what happens when tangogps (or yaouh or whatever) re-downloads some previously blank tile that now has a new road on it? Will the link break for that tile? Or will the sole blank tile be replaced, so that every blank area now has the same road on it? I don't keep a tile repositiory on my desktop, I download directly to the freerunner. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Carlo Minucci wrote: Helge Hafting ha scritto: Carlo Minucci wrote: http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage A very good idea, but it does not work yet. My maps are in /media/card/kart/, but yaouh thinks they are in /home/root/Maps. so it doesn't check my 5 tiles. i found the bug :) go to line 83 of the yaouh.py and add a new line, after dir = out[2], with j = n and test it now it should work I removed the Maps/OSM symlink, and did this change. It seems to work! :-) I noticed another problem yesterday though. I worked around the problem by making a symlink, and the program ran. I have slightly more than 50.000 tiles. After a while, Yaouh had worked through 12000, updating about 4000. It seems 1 in 3 tiles were changed. This took a lot of time, so I left it running overnight. It crashed sometimes during the night, and the disk was not full. The log file merely told that yaouh.py was interrupted by a segmentation fault. Could there be a memory leak? Or will yaouh use memory proportional to the number of tiles (or perhaps the number of out-of-date tiles)? With 128M and 5 tiles, there is no more than 2684 bytes per tile. So linear memory consumption will not work well. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Tue, 2009-01-20 at 11:00 +0100, Helge Hafting wrote: William Kenworthy wrote: ... Where I live (Perth, Western Australia) there are large areas of surrounding sea/land/forestry/desert etc that use a single colour tile - each of only 103 bytes. I symlinked all identical files (based on md5sum) such that only one copy of each is kept. This has the advantage that as ext2/3 uses fast-symlinks, the actual symlink (provided the path is 60 characters) is stored in the inode and doesnt take any block space on the FS. This shrinks the size as given by du -sh from 3.3Gb down to ~550Mb. Interesting idea. Half of my tiles are blank too. But what happens when tangogps (or yaouh or whatever) re-downloads some previously blank tile that now has a new road on it? Will the link break for that tile? Or will the sole blank tile be replaced, so that every blank area now has the same road on it? I don't keep a tile repositiory on my desktop, I download directly to the freerunner. Helge Hafting Check if you have run out of inodes - there are only so many to go around! - this was a problem foe until I realised it as it looks like there is plenty of room, but strange crashes and the like occur as there are no free inodes. and $ echo aa aa $ ln -s aa bb $ echo cc bb $ cat aa $ cc So it will overwrite. Not a problem for me as I dont use gprs (too expensive in Oz for casual use, and coverage is miserable outside the central capitals and large towns.) and the desktop system is always the master. Started out this way as kept losing the partition in the early days and ext2/3 is not a very good filesystem for devices like this anyway, corruption occurs quite readily so I dont trust it :) Alternatively, identify the symlined master and make it read only - wont update, but wont overwrite all similar tiles either. Also, I didnt think tangogps overwrote files already downloaded - it uses them from the cache instead - will have to test the download dialog, but I seem to remember that didnt download existing tiles either. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Tue, 2009-01-20 at 19:44 +0900, William Kenworthy wrote: On Tue, 2009-01-20 at 11:00 +0100, Helge Hafting wrote: William Kenworthy wrote: ... Where I live (Perth, Western Australia) there are large areas of surrounding sea/land/forestry/desert etc that use a single colour tile - each of only 103 bytes. I symlinked all identical files (based on md5sum) such that only one copy of each is kept. This has the advantage that as ext2/3 uses fast-symlinks, the actual symlink (provided the path is 60 characters) is stored in the inode and doesnt take any block space on the FS. This shrinks the size as given by du -sh from 3.3Gb down to ~550Mb. Interesting idea. Half of my tiles are blank too. But what happens when tangogps (or yaouh or whatever) re-downloads some previously blank tile that now has a new road on it? Will the link break for that tile? Or will the sole blank tile be replaced, so that every blank area now has the same road on it? I don't keep a tile repositiory on my desktop, I download directly to the freerunner. Helge Hafting Check if you have run out of inodes - there are only so many to go around! - this was a problem foe until I realised it as it looks like there is plenty of room, but strange crashes and the like occur as there are no free inodes. and $ echo aa aa $ ln -s aa bb $ echo cc bb $ cat aa $ cc So it will overwrite. Not a problem for me as I dont use gprs (too expensive in Oz for casual use, and coverage is miserable outside the central capitals and large towns.) and the desktop system is always the master. Started out this way as kept losing the partition in the early days and ext2/3 is not a very good filesystem for devices like this anyway, corruption occurs quite readily so I dont trust it :) Alternatively, identify the symlined master and make it read only - wont update, but wont overwrite all similar tiles either. Also, I didnt think tangogps overwrote files already downloaded - it uses them from the cache instead - will have to test the download dialog, but I seem to remember that didnt download existing tiles either. BillK A little thought - if a tile is to be replaced, delete it first (and therefore if its a symlink, problem solved. Scripts like yaouh could be easily adapted - tangogps, may not be necessary - need to prove that. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
William Kenworthy wrote: Also, I didnt think tangogps overwrote files already downloaded - it uses them from the cache instead - will have to test the download dialog, but I seem to remember that didnt download existing tiles either. tangogps uses the cache - until you notice that the cache is getting old and ask it to download. (Click the map, select map download from the menu) The visible area is then downloaded, plus a user-specified amount of extra zoom levels for that area. Any existing cache for that area is replaced. I do this (using USB networking) when I have updated a place in openstreetmap. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Tue, Jan 20, 2009 at 2:30 PM, Helge Hafting helge.haft...@hist.no wrote: tangogps uses the cache - until you notice that the cache is getting old and ask it to download. (Click the map, select map download from the menu) The visible area is then downloaded, plus a user-specified amount of extra zoom levels for that area. Any existing cache for that area is replaced. huh - so Tangogps is able to update tiles?? I didn't know it, lack of reading/documentation/UI/something. Does it download overwrite all tiles already downloaded in the selected area or does it use the etag thing to save traffic? r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Helge Hafting wrote: I noticed another problem yesterday though. I worked around the problem by making a symlink, and the program ran. I have slightly more than 50.000 tiles. After a while, Yaouh had worked through 12000, updating about 4000. It seems 1 in 3 tiles were changed. This took a lot of time, so I left it running overnight. It crashed sometimes during the night, and the disk was not full. The log file merely told that yaouh.py was interrupted by a segmentation fault. Could there be a memory leak? Or will yaouh use memory proportional to the number of tiles (or perhaps the number of out-of-date tiles)? With 128M and 5 tiles, there is no more than 2684 bytes per tile. So linear memory consumption will not work well. I think I may have found the problem. yaouh (and tangogps) outputs lots of text while working, and this text ends up in /var/volatile/tmp/x.log (Or /tmp/x.log, /tmp symlinks to /var/tmp which again links to /var/volatile/tmp.) The file is currently 30M, yaouh is not the only offender, but the file keep growing. Now, /var/volatile is tmpfs in main memory, so I am currently wasting 30M of the precious 128M this phone has. (A quarter of all memory, for a log file!) This output is rarely seen by users. I guess it is useful for debugging, but could be removed from a production release, or at least add a debug flag that must be used to get output. If the amount of output is proportional to the amount of tiles being checker or downloaded, then some users will run out of memory just from that. Looks like many programs like to fill this log. People who don't have swap, and see instability after too much uptime, may want to check the size of /var/volatile/tmp/x.log. My 30M accumulated over 4 days, I have swap to help me though. It looks like tmpfs is limited to half of memory, but the remaining 64M could get tight. Also, some programs don't like it when /tmp gets full. A reboot fixes this, but we don't want to reboot to clear out logfiles. :-/ Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Tue, Jan 20, 2009 at 2:59 PM, Helge Hafting helge.haft...@hist.no wrote: Risto H. Kurppa wrote: huh - so Tangogps is able to update tiles?? I didn't know it, lack of reading/documentation/UI/something. Just click anywhere on the map. map download is the last item on the popup menu. There seem to be a bug in that the zoom level you're looking at doesn't get updated. A user-configurable amount of zoom levels below are downloaded though. I therefore tend to zoom one level out before downloading. I don't know if it uses etags, but I guess it blindly downloads all. If it used etags, then it could save space by not having tens of thousands of identical copies of the blank land tile and the blank sea tile. Helge Hafting I think you got me wrong: yes, I know that it can download new tiles, but if you already have downloaded the tiles of some area and then after some months you'd like to get the latest map tiles (=dowload the latest, changed tiles), does the 'download tool' do it or does it see that the tiles are already there and will not download anything. In some update scripts the etag is used to recognize if the tile on the server is different than the local tile and if it is, then the tile file is downloaded. Or maybe I got you wrong :) Anyway, a tool to upgrade the tiles (that uses the etag thing, not downloading all the files) is needed and I think we've seen it now, just need to test.. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Risto H. Kurppa wrote: I think you got me wrong: yes, I know that it can download new tiles, but if you already have downloaded the tiles of some area and then after some months you'd like to get the latest map tiles (=dowload the latest, changed tiles), does the 'download tool' do it or does it see that the tiles are already there and will not download anything. The 'download tool' download the tiles so that you get the newest ones even if you had some old outdated tiles there. I don't know if it downloads _every_ tile blindly, or only those that changed since last time. But all tiles within the visible region, down to the configured zoom limit will be new up-to-date tiles once the download finishes. Assuming there are no network errors/timeouts - that can leave old tiles or even blank areas. Also, if you have old tiles down to a deep zoom level, then the innermost ones aren't updated unless you specify sufficient depth. The yaouh tool is better, in that it updates every outdated tile regardless of zoom level. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Tue, Jan 20, 2009 at 8:00 PM, Helge Hafting helge.haft...@hist.no wrote: Risto H. Kurppa wrote: I think you got me wrong: yes, I know that it can download new tiles, but if you already have downloaded the tiles of some area and then after some months you'd like to get the latest map tiles (=dowload the latest, changed tiles), does the 'download tool' do it or does it see that the tiles are already there and will not download anything. The 'download tool' download the tiles so that you get the newest ones even if you had some old outdated tiles there. I don't know if it downloads _every_ tile blindly, or only those that changed since last time. But all tiles within the visible region, down to the configured zoom limit will be new up-to-date tiles once the download finishes. Assuming there are no network errors/timeouts - that can leave old tiles or even blank areas. Also, if you have old tiles down to a deep zoom level, then the innermost ones aren't updated unless you specify sufficient depth. The yaouh tool is better, in that it updates every outdated tile regardless of zoom level. Ah, okay, thanks for this information , didn't know Tangogps can also update. Put yes, I prefer yaouh (or even better the desktop-perl -script. Will try it soon) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Carlo Minucci wrote: http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage A very good idea, but it does not work yet. My maps are in /media/card/kart/, but yaouh thinks they are in /home/root/Maps. so it doesn't check my 5 tiles. I have tangogps set up that way, because there is more room on the 8GB card, and it isn't blanked when I flash a new SHR image. I do not know where tangogps keeps this information though. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Mon, Jan 19, 2009 at 3:54 PM, Helge Hafting helge.haft...@hist.no wrote: Carlo Minucci wrote: http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage A very good idea, but it does not work yet. My maps are in /media/card/kart/, but yaouh thinks they are in /home/root/Maps. so it doesn't check my 5 tiles. I have tangogps set up that way, because there is more room on the 8GB card, and it isn't blanked when I flash a new SHR image. I do not know where tangogps keeps this information though. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Hi! By default the OSM maps are in /home/root/Maps/OSM So creating a symbolic link from this directory to your µSD card will do it: you don't have to move the files anywhere or even touch tangogps configuration, only point the directory to the card. r-- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Risto H. Kurppa ha scritto: By default the OSM maps are in /home/root/Maps/OSM So creating a symbolic link from this directory to your µSD card will do it: you don't have to move the files anywhere or even touch tangogps configuration, only point the directory to the card. yes it's a solution but check in the tangogps config file if you have right path for map you can found in /home/root/.gconf/app/tangogpd/%gconf.xml ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Carlo Minucci wrote: Risto H. Kurppa ha scritto: By default the OSM maps are in /home/root/Maps/OSM So creating a symbolic link from this directory to your µSD card will do it: you don't have to move the files anywhere or even touch tangogps configuration, only point the directory to the card. yes it's a solution but check in the tangogps config file if you have right path for map you can found in /home/root/.gconf/app/tangogpd/%gconf.xml I see stringvalueOSM|http://tile.openstreetmap.org/%d/%d/%d.png|/media/card/kart|0/stringvalue in this file. The path seems correct, and tangogps has no problems using it. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Mon, 2009-01-19 at 14:54 +0100, Helge Hafting wrote: Carlo Minucci wrote: http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage A very good idea, but it does not work yet. My maps are in /media/card/kart/, but yaouh thinks they are in /home/root/Maps. so it doesn't check my 5 tiles. I have tangogps set up that way, because there is more room on the 8GB card, and it isn't blanked when I flash a new SHR image. I do not know where tangogps keeps this information though. Helge Hafting After trying a few different things, now one of my first moves is to delete /home/root/Maps and replace it with a symlink to the SD card Maps directory. Rather than use the yaouh script, the first version of which didnt like the symlink, I used the idea (thanks for putting me onto E-TAG) in a quick perl lashup - works fine (well, working fine as I have ~84 png files totalling 3.3Gb and its been running since soon after yaouh was announced - will be awhile yet!) I use a master archive on my desktop for this - and syn the freerunner to this using rsync. Some things I ran into with such a large number of maps: ext2/3 is not really suited to storing such a large number of small files. The main problem is the fixed number of inodes which I ran out of despite having 2Gb still free on the SD card partition :( To work around, create the file system with -b 1024 -i 1024 for the maximum number of inodes - unfortunately this cant be changed after the FS is created. Where I live (Perth, Western Australia) there are large areas of surrounding sea/land/forestry/desert etc that use a single colour tile - each of only 103 bytes. I symlinked all identical files (based on md5sum) such that only one copy of each is kept. This has the advantage that as ext2/3 uses fast-symlinks, the actual symlink (provided the path is 60 characters) is stored in the inode and doesnt take any block space on the FS. This shrinks the size as given by du -sh from 3.3Gb down to ~550Mb. Pity ext2/3 doesnt do tail packing, but maybe reiserfs which would be a lot more suitable will come into the FR one day. When I get time, I hope to investigate a loopback like tarfs or squashfs to see if that can improve this wasted space. I'll need to finish my current update and create a new symlinked archive to see how much wastage tail packing would save - should be a fair bit. Lastly, I would get occasional lockups, blank tiles and FS corruption from tango - eventually traced it to the SD card clock - if you see this look up sdclk on the wiki and slow it down a bit. Have fun, BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Tue, Jan 20, 2009 at 1:20 AM, William Kenworthy bi...@iinet.net.au wrote: After trying a few different things, now one of my first moves is to delete /home/root/Maps and replace it with a symlink to the SD card Maps directory. Rather than use the yaouh script, the first version of which didnt like the symlink, I used the idea (thanks for putting me onto E-TAG) in a quick perl lashup - works fine (well, working fine as I have ~84 png files totalling 3.3Gb and its been running since soon after yaouh was announced - will be awhile yet!) I use a master archive on my desktop for this - and syn the freerunner to this using rsync. Could you please share your perl script to update the maps on the desktop, that's exactly what I'd like after I noticed how long it will take. On desktop people usually have more online time, more power and better connection than on Freerunner. Thanks! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
ok, give me a couple of hours to clean it up and make it presentable :) BillK On Tue, 2009-01-20 at 09:16 +0200, Risto H. Kurppa wrote: On Tue, Jan 20, 2009 at 1:20 AM, William Kenworthy bi...@iinet.net.au wrote: After trying a few different things, now one of my first moves is to delete /home/root/Maps and replace it with a symlink to the SD card Maps directory. Rather than use the yaouh script, the first version of which didnt like the symlink, I used the idea (thanks for putting me onto E-TAG) in a quick perl lashup - works fine (well, working fine as I have ~84 png files totalling 3.3Gb and its been running since soon after yaouh was announced - will be awhile yet!) I use a master archive on my desktop for this - and syn the freerunner to this using rsync. Could you please share your perl script to update the maps on the desktop, that's exactly what I'd like after I noticed how long it will take. On desktop people usually have more online time, more power and better connection than on Freerunner. Thanks! r -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Ar, cant be bothered to fix it too much :)
cutpasted below.
Watch the line breaks input by email.
Script 1 does the updates
No error protection/recovery (hasnt thrown any errors anyway!) - I
suspended the system it was running on last night (forgot about it! - it
continued again fine when resumed without a problem :)
I got carried away chomp'ing, could be better done.
Change paths to suit your system
This was proof of concept - now I know it works,
I want to use LWN instead of curl,
thread it for 6 or so concurrent threads
add error protection
script2 generates a symlinked directory based on an original which is
left unchanged. Can take a few hours to run, but it was dealing with 3
plus gbytes of files and could be better optimised. Once generated, sync
to the FR using rsync over wlan
BillK
On Tue, 2009-01-20 at 09:16 +0200, Risto H. Kurppa wrote:
On Tue, Jan 20, 2009 at 1:20 AM, William Kenworthy bi...@iinet.net.au wrote:
...
Could you please share your perl script to update the maps on the
desktop, that's exactly what I'd like after I noticed how long it will
take. On desktop people usually have more online time, more power and
better connection than on Freerunner.
...
___
Script 1
#!/usr/bin/perl -w
use strict;
use File::Basename;
use File::Copy;
my $MD5SUM=/usr/bin/md5sum -b ;
my $tiles=http://tile.openstreetmap.org/;;
my $OSM=/home/wdk/Maps/OSM/;
my $curl='/usr/bin/curl -I ';
my $find='/usr/bin/find /home/wdk/Maps/OSM -name \*.png';
print Finding files\n;
my @ALLfiles=`$find`;
my $tmp = $#ALLfiles; print $tmp\n; # number of files found
foreach my $LOCfile (@ALLfiles) {
chomp($LOCfile);
my $md5sum =`$MD5SUM $LOCfile`; $md5sum=~s/ .*$//; chomp($md5sum); #
clean
print $LOCfile :: $md5sum\n;
my $OSMfile = $LOCfile; $OSMfile=~s!$OSM!$tiles!; # swap paths from
local to http
my $OSMmd5sum = `$curl $OSMfile \| grep ETag \| cut \-d \-f 2`;
chomp($OSMmd5sum);
print $OSMfile :: $OSMmd5sum\n;
if ($md5sum ne $OSMmd5sum) {
print $md5sum != $OSMmd5sum\n;
print `wget $OSMfile` . \n;
my $basename = basename $LOCfile;
print move($basename, $LOCfile);
}
print \n\n;
}
print Files: $tmp\n;
___
Script2
#!/usr/bin/perl -w
# symlinks identical OSM png files in a directory structure
# 1. load all png files into an array
# 2. load all directories into an array
# 3. use 2 to create a parralel tree
# 4. One file in 1. at a time:
# 4.1 create an MD5 hash for the file
# 4.2 check hash store of md5sums for an identical hash
# 4.2.1 if a match, create a symlink in the new tree
# 4.2.2 if *NOT* a match, copy file and add to hash store
use strict;
use File::Path;
use File::Copy;
my $MD5SUM='/usr/bin/md5sum -b';
my @ALLfiles=`find /home/wdk/Maps/OSM/ -name \*.png`;
my @ALLdirs=`find /home/wdk/Maps/OSM/ -type d`;
my %Ufiles;
DirStruc; ## create tree
foreach my $item (@ALLfiles) {
chomp(my $TmpHash = `$MD5SUM $item`);
$TmpHash =~ s/ .*$//; # md5sum returns the md5hash AND the file name
## if file exists in the hash make a symlink in the new tree to its
master
## else add to hash and copy file to new tree
if (exists $Ufiles{$TmpHash}) {
# extract value
my $LinkTo = $Ufiles{$TmpHash};
MakeLink($LinkTo, $item);
} else {
AddHash($TmpHash, $item);
}
}
print \n\nNumber of png files: . ($#ALLfiles + 1) . \n;
my $tmp=keys %Ufiles;print Number of unique files: . $tmp . \n;
sub DirStruc {
foreach my $dir (@ALLdirs) {
$dir =~ s/OSM/OSM-new/;
chomp($dir);
eval { mkpath($dir) }; if ($@) { print Couldn't create $dir:
$@; }
}
}
sub MakeLink {
my @tmp = @_;
chomp(@tmp);
$tmp[1] =~ s/OSM/OSM-new/;
eval { symlink($tmp[0], $tmp[1]) }; if ($@) { print Couldn't create
symlink: $@; }
print x;
}
sub AddHash {
my @tmp = @_;
chomp($tmp[1]);
$tmp[2] = $tmp[1];
$tmp[2] =~ s/OSM/OSM-new/;
eval { copy($tmp[1], $tmp[2]) or die File $tmp[1] cannot be copied to
$tmp[2]. };
$Ufiles{$tmp[0]}=$tmp[2]; ## add to hash as new file
print .;
}
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Same problem here :( How could I solve this? It seems a _great_ app ;) The Digital Pioneer wrote: No go. I tried grepping for just OSM though, here's what I got... r...@om-gta02 [~] # cat .gconf/apps/tangogps/%gconf.xml | grep OSM stringvalueOSM/stringvalue -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Francesco de Virgilio *Ubuntu-it Member and Wiki Editor* mailto:frad...@ubuntu-it.org http://wiki.ubuntu-it.org/FrancescoDeVirgilio *Wikimedia Italia Member* http://en.wikipedia.org/wiki/User:Fradeve11 *OpenStreetMap Mapper* http://www.openstreetmap.org/user/Fradeve11 *Blog* http://fradeve.netsons.org Love - Peace - Freedom - Free Software ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Francesco de Virgilio ha scritto: Same problem here :( How could I solve this? It seems a _great_ app ;) wait for release 0.2 :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Fri, Jan 16, 2009 at 04:12:19PM +0100, Tilman Baumann wrote: Untested code: import httplib conn = httplib.HTTPConnection(tile.openstreetmap.org) conn.request(HEAD, /file...) r1 = conn.getresponse() print r1.status, r1.reason etag = getheader(ETag) print etag And if stuff was new, make GET instead of HEAD It sure would be more efficient if OSM supported the If-Modified-Since: header in a GET request. Then you wouldn't need the HEAD request. Also, consider using the same connection for multiple requests. It ought to help a lot with such small files. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
On Sat, Jan 17, 2009 at 3:33 AM, Francesco de Virgilio fradev...@gmail.comwrote: Same problem here :( How could I solve this? It seems a _great_ app ;) Open TangoGPS, go to config, set the repo to other than OSM, save. Then set it back to OSM, save. That should do it. :) -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Yaouh! out (update for tangogps maps)
http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
http://wiki.openmoko.org/wiki/Yaouh! quite impressing a page ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
arne anka wrote: http://wiki.openmoko.org/wiki/Yaouh! quite impressing a page ... try with ! :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
arne anka wrote: http://wiki.openmoko.org/wiki/Yaouh! quite impressing a page ... If your mail client is like mine then it's not including the ! as part of the URL and so you end up at http://wiki.openmoko.org/wiki/Yaouh (blank page) instead of http://wiki.openmoko.org/wiki/Yaouh! I've put in a redirect on the Yaouh page to avoid this problem in future. Cheers, Mike. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Getting the following output in SHR, with maps stored in ~/Maps 40 Unhandled exception in thread started by Traceback (most recent call last): File /usr/bin/yaouh.py, line 78, in up_progressbar print _ + dir + _ UnboundLocalError: local variable 'dir' referenced before assignment -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
El día Friday, January 16, 2009 a las 02:14:55PM +, Michael Sheldon escribió: arne anka wrote: http://wiki.openmoko.org/wiki/Yaouh! quite impressing a page ... If your mail client is like mine then it's not including the ! as part of the URL and so you end up at http://wiki.openmoko.org/wiki/Yaouh (blank page) instead of http://wiki.openmoko.org/wiki/Yaouh! One should use terminal/xterm based MUA, like Mutt (like I do) and avoid those pretty coloured user interfaces which are trying to 'think' for you and mostly doing that wrong :-) sorry, could not resist matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e matthias.ap...@oclc.org - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ SPAMer of the year: Subject: Alle Software ist Deutsche Sprachen From: -40 % die Neujahrsaktion gabriellekel...@grungecafe.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
The Digital Pioneer ha scritto: Getting the following output in SHR, with maps stored in ~/Maps 40 Unhandled exception in thread started by Traceback (most recent call last): File /usr/bin/yaouh.py, line 78, in up_progressbar print _ + dir + _ UnboundLocalError: local variable 'dir' referenced before assignment oh you can delete this line, it's only for my debug (sorry for my bad english) you have check if in tangogps your repository is call OSM my script (for now) search only OSM in the tangogps config file, and if there is another name can't find the right dir e generate this error ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Carlo Minucci a écrit : http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage Just a question : how can you check the remote file without dowloading it before ? Do you use etag [1] to do that ? Xavier. [1] http://en.wikipedia.org/wiki/HTTP_ETag ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
I use OSM repo, yes. I removed that line, but now it just breaks on another one (line 82). So still no go. -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Xavier Cremaschi ha scritto: Carlo Minucci a écrit : http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage Just a question : how can you check the remote file without dowloading it before ? Do you use etag [1] to do that ? yes etag i check with this: curl -I http://tile.openstreetmap.org/$file | grep ETag | cut -d \ -f 2 do you know a better way? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
do you know a better way? No it seems great, I just wanted to know ;) Xavier. (will try the application) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Carlo Minucci wrote: Xavier Cremaschi ha scritto: Carlo Minucci a écrit : http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage Just a question : how can you check the remote file without dowloading it before ? Do you use etag [1] to do that ? yes etag i check with this: curl -I http://tile.openstreetmap.org/$file | grep ETag | cut -d \ -f 2 do you know a better way? Doen't python have a http lib? Calling external apps is not really the fastest and safest way. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Tilman Baumann wrote: Carlo Minucci wrote: Xavier Cremaschi ha scritto: Carlo Minucci a écrit : http://wiki.openmoko.org/wiki/Yaouh! i a simple interface for update the maps of tangogps it's optimized for low band usage Just a question : how can you check the remote file without dowloading it before ? Do you use etag [1] to do that ? yes etag i check with this: curl -I http://tile.openstreetmap.org/$file | grep ETag | cut -d \ -f 2 do you know a better way? Doen't python have a http lib? Calling external apps is not really the fastest and safest way. Untested code: import httplib conn = httplib.HTTPConnection(tile.openstreetmap.org) conn.request(HEAD, /file...) r1 = conn.getresponse() print r1.status, r1.reason etag = getheader(ETag) print etag And if stuff was new, make GET instead of HEAD -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
The Digital Pioneer ha scritto: I use OSM repo, yes. I removed that line, but now it just breaks on another one (line 82). So still no go. ok open a shell into the phone e launch this cat ~/.gconf/apps/tangogps/%gconf.xml | grep OSM|http and check if you receiver a row like this r...@saponettofono:~# cat ~/.gconf/apps/tangogps/%gconf.xml | grep OSM|http stringvalueOSM|http://tile.openstreetmap.org/%d/%d/%d.png|/home/root/Maps/OSM|0/stringvalue r...@saponettofono:~# ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
No go. I tried grepping for just OSM though, here's what I got... r...@om-gta02 [~] # cat .gconf/apps/tangogps/%gconf.xml | grep OSM stringvalueOSM/stringvalue -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
The Digital Pioneer ha scritto: No go. I tried grepping for just OSM though, here's what I got... r...@om-gta02 [~] # cat .gconf/apps/tangogps/%gconf.xml | grep OSM stringvalueOSM/stringvalue ok this is the problem :) can you send me this %gconf.xml via email? i want to check the difference with mine ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi.. Very nice program.. works like a charm (so far (checking on ~70k tiles)).. it's somewhat slow, though.. maybe you can implement that python httplib to save the curl invocations? :) please? Thank you for that tool. (The OSM updater just didn't cut it for me) Cheers, - -- Thomas - -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ Give a man a fish, and he will eat for a day; Teach a man to fish, and he will eat for a lifetime. The moral? READ THE MANUAL! - Sign on a computer system consultant's desk - -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklw+TgACgkQuGo1cDcCdir7DQCffJWCLJlu9DWuTKcd11Il7YNb 3TkAoJdxGUjrWJ8vhnTgKyGEUzSnvy5P =jqpo -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Thomas Franck ha scritto: Very nice program.. works like a charm (so far (checking on ~70k tiles)).. it's somewhat slow, though.. maybe you can implement that python httplib to save the curl invocations? :) please? maybe in the next release :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Hi! Yes, it looks like a very nice program and I like it that it checks the files without loading them - a lot less traffic for OSM servers me :) I have about 300 000 tiles on the card so speed really matters in this case.. It took some minutes after pressing the start button before I got any stdout/GUI feedback (except the OSM line), I suppose this is when it was indexing the files. I tried to stopwatch how long it takes to update 100 tiles or so but it got stuck in some file, waited for it almost 4 minutes before I restarted it. So some further development would be nice but this already is a usable tool, if it only is able to run through all my files. Also a desktop version would be handy, should just try if you can run the .py on desktop.. r On Fri, Jan 16, 2009 at 11:26 PM, Carlo Minucci ge...@napodano.com wrote: Thomas Franck ha scritto: Very nice program.. works like a charm (so far (checking on ~70k tiles)).. it's somewhat slow, though.. maybe you can implement that python httplib to save the curl invocations? :) please? maybe in the next release :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
I run a little test: Timed how long it takes to scan through 150 tiles (not all updated), it took 3:20. So for my 300 000 tiles it would take about 4.6 days and this would leave me another 2.4 days to use the map before it's re-rendered so all speed available is really appreciated :) (ok, it's a long time since I downloaded the tiles so for example now 350/720 have been updated. Running this more often will not take quite this long..) r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yaouh! out (update for tangogps maps)
Another test: I tried it on my desktop Ubuntu Intrepid. It starts nice and I see the GUI, it finds my map directory and starts downloading well, a lot faster than on moko wireless connection. It checked 17 files (downloaded 16) and crashed: /home/rhk/freerunner/maps/osm_uusi/10/593/293.png % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 126580 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 Unhandled exception in thread started by Traceback (most recent call last): File ./yaouh.py, line 102, in up_progressbar md5=md5sum.read() IOError: [Errno 4] Interrupted system call I don't know about others but it might be faster to update the tiles on the desktop (more power, fast connection and more on-line time available) and then copy/rsync the changed files to the memory card. This is the reason why I'd like to run it (also) on my desktop. Anyway, thanks again for a nice and useful app! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
