Re: [omgps] collect feature requests
On Tue, Jun 30, 2009 at 11:32:39PM +0200, Laszlo KREKACS wrote:
I already wrote about it about a month ago:
http://lists.openmoko.org/pipermail/community/2009-June/048997.html
So you've found that vfat, ext2 and ext3 aren't very good (for storing
map tiles)? How about using reiserfs instead?
Remember accessing invidual files on a sd card takes time. A lot.
You can try it for yourself, copy to a pendrive your ~/Maps directory.
Now tar the dir (Maps.tar) and copy that singly file to the pendrive.
The result is something like 40sec compared to 6-7min.
I cannot reproduce that huge time difference, I get more like +50 % than
+900 %:
time (s)space left (MB)
fs/blocksizecp tar cp tar
ext3/1024 242 162 405 404
reiserfs/1024 305 193 426 421
ext3/2048 208 143 397 404
reiserfs/2048 264 161 415 414
ext3/4096 193 131 376 398
reiserfs/4096 242 156 394 398
I used the script below on my Freerunner with a USB card reader and the
512 MB uSD card that came with the Freerunner. I used the default journal size
for both ext3 and reiserfs. I guess you would want to reduce that.
#!/bin/sh
# Compare file system suitability for storing map tiles
# with that of a tar archive in terms of speed and
# space efficiency.
TILESOURCE=/usr/local/share/maptiles/openstreetmap
TESTDEV=/dev/sda2
TESTMOUNT=/mnt/flash
OPTS_ext3='-q -T small -m 0 -b 4096'
OPTS_reiserfs='-q -b 4096'
for fs in ext3 reiserfs; do
eval 'FSOPTS=${OPTS_'${fs}':-}'
for i in 1 2; do
mkfs.${fs} ${FSOPTS} ${TESTDEV}
mount ${TESTDEV} ${TESTMOUNT}
START=$(date +%s)
tar -cf ${TESTMOUNT}/OSM.tar ${TILESOURCE}
df -h ${TESTMOUNT}
umount ${TESTDEV}
FINISH=$(date +%s)
echo Tar test ${i} on ${fs} took $((${FINISH} - ${START})) s.
done
for i in 1 2; do
mkfs.${fs} ${FSOPTS} ${TESTDEV}
mount ${TESTDEV} ${TESTMOUNT}
START=$(date +%s)
cp -a ${TILESOURCE} ${TESTMOUNT}/OSM
df -h ${TESTMOUNT}
umount ${TESTDEV}
FINISH=$(date +%s)
echo Cp test ${i} on ${fs} took $((${FINISH} - ${START})) s.
done
done
--
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: [omgps] collect feature requests
On Mon, Jun 29, 2009 at 05:29:22PM -0700, mqy wrote: First, I must appreciate all omgps users, for your test and feed back. OK, a couple of problems running it on Debian: 1) At startup, a message Unable to something or other directory in very small print pops up. Suggestion: Use the default font size for error message dialogs. 2) Running it from a shell, messages such as this one are printed: 20090711 14:43:52 [WARN] load image failed: Failed to open file '/home/rask/.omgps/maps/OSM/1/0/0.png': Permission denied $ ls -l ~/.omgps/maps/OSM/*/*/*.png -- 1 rask rask 9091 Jul 11 14:43 /home/rask/.omgps/maps/OSM/1/0/0.png -- 1 rask rask 4436 Jul 11 14:44 /home/rask/.omgps/maps/OSM/1/0/1.png -- 1 rask rask 7730 Jul 11 14:43 /home/rask/.omgps/maps/OSM/1/1/0.png -- 1 rask rask 4226 Jul 11 14:43 /home/rask/.omgps/maps/OSM/1/1/1.png Suggestion: Don't mess with the file permissions. 3) Running it again, at startup, a message Unable to create pid file something or other. in very small print pops up. $ ls -l ~/.omgps/omgps.pid --x--- 1 rask rask 5 Jul 11 14:42 /home/rask/.omgps/omgps.pid Suggestion: Don't mess with the file permissions. Delete the pid file on exit. 4) The GPS part only works if I have the GPS activated by some other means such as running TangoGPS or using fsoraw. Otherwise, it just sits there with Initializing GPS displayed at the bottom. -- 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: [omgps] collect feature requests
Hi! On Tue, 2009-06-30 at 08:14 -0700, mqy wrote: First of all I have to say that fso-framework is excellent, because we do need a top level abstraction and manger to control access to system resources (especially the hardwares). As of GPS related APIs in ogpsd, UBX binary protocol is used to issue control commands (such as initialize GPS receiver, upload/download AID messages), and NMEA protocol is used to accept messages passively. On GTA02 ogpsd uses UBX only (no NMEA) so the only overhead compared to omgps would be that the parsing is implemented in python. Do you think that your UBX parser code is ready to replace the python parser? If yes, then there wouldn't be any problems anymore with using ogpsd (currently performace/battery usage). Jan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On GTA02 ogpsd uses UBX only (no NMEA) so the only overhead compared to omgps would be that the parsing is implemented in python. I'm sorry that I said ogpsd uses NMEA :( omgps talks with ogpsd (gypsy service) through dbus APIs, so another overhead is delivering of dbus signals. As of my test, the approximate overhead is over 5% (CPU usage). Do you think that your UBX parser code is ready to replace the python parser? If yes, then there wouldn't be any problems anymore with using ogpsd (currently performace/battery usage). No. The Gypsy service good for most users who want to get just data such as lat/lon. Fso-framework manages GPS device, it is not easy to write another working parser (data provider). UBX binary is preferred by omgps because I want full control. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3231221.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Sun, Jul 05, 2009 at 03:13:44AM -0700, mqy wrote: 2009/7/5 Rask Ingemann Lambertsen (via Nabble) ml-user+167888-1251911...@n2.nabble.com: On Mon, Jun 29, 2009 at 05:29:22PM -0700, mqy wrote: Please feel free to comment or add new feature requests here. Two comments on the package control file: 1) The dependency on python2.6 is missing. 2) The description is still the default one. Let me explain my build environment. HOST env: debian chroot on top of ubuntu 1. build with openmoko unstable toolchian (from openmoko download site) om-conf omgps make clean make om-make-ipkg omgps With this approach, take care to run om-conf again once Makefile.am is modified. 2. build with bitbake (SHR), see omgps_svn.bb I have no idea how any of that works, but I'm guessing that somewhere you have a file called 'control'? This is what it looks like in the package: $ dpkg-deb -f ~/software/omgps_0.1_20090618-3_armv4t.ipk Package: omgps Version: 0.1 Description: package built by openmoko toolchain Section: openmoko/applications Priority: optional Maintainer: meng Architecture: armv4t Homepage: http://www.openmoko.org/ Depends: Source: omgps about comment #1: I have no idea how to test Python version installed in tool chain, so have to hard code the version as 2.6. What about try 2.4 or something else? That's not what I'm asking. Just add the libpython2.6 package name to the Depends: line to resolve this dependency: $ omgps omgps: error while loading shared libraries: libpython2.6.so.1.0: cannot open shared object file: No such file or directory about comment #2: which description? would you please clarify? The one that says package built by openmoko toolchain. -- 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: [omgps] collect feature requests
Let me explain my build environment. HOST env: debian chroot on top of ubuntu 1. build with openmoko unstable toolchian (from openmoko download site) om-conf omgps make clean make om-make-ipkg omgps With this approach, take care to run om-conf again once Makefile.am is modified. 2. build with bitbake (SHR), see omgps_svn.bb about comment #1: I have no idea how to test Python version installed in tool chain, so have to hard code the version as 2.6. What about try 2.4 or something else? about comment #2: which description? would you please clarify? 2009/7/5 Rask Ingemann Lambertsen (via Nabble) ml-user+167888-1251911...@n2.nabble.com: On Mon, Jun 29, 2009 at 05:29:22PM -0700, mqy wrote: Please feel free to comment or add new feature requests here. Two comments on the package control file: 1) The dependency on python2.6 is missing. 2) The description is still the default one. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list commun...@... http://lists.openmoko.org/mailman/listinfo/community View message @ http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3207160.html To unsubscribe from [omgps] collect feature requests, click here. -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3208174.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Hi Laszlo, Thanks for all the hard work you've been putting in. I have two questions: 1) If the filesystem is crashing, doesn't it seem like we should fix the filesystem instead of making a new file format? 2) You mentioned that fsck takes an hour for you. I'm having trouble reproducing that. It always takes less than a minute for me. Here is what I'm doing, let me know if I'm testing it incorrectly: a) tangogps find /media/mmcblk0p5/Maps | wc -l b) Download maps (+4 levels) in tangogps (just to further stress it) c) While that is running, I remove all power sources, causing a crash d) At reboot, the filesystem is automatically recovered (I'm using ext3 journaling) e) I force a fsck and check how long it takes, like so: umount /media/mmcblk0p5 time e2fsck -f /dev/mmcblk0p5 For me, it's always 42 seconds. --Ben P.S. Did you try that clock speed suggestion from BillK? On Tue, Jun 30, 2009 at 5:05 AM, Laszlo KREKACSlaszlo.krekacs.l...@gmail.com wrote: Noone experienced whole filesystem crash because of *that* many open file descriptors? It would be really strange. ITs really simple to test it: While using tangogps/omgps remove the battery. Almost 90% percent and the whole filesystem crashes (the tiles are no more availables) You can test it, with: find /home/root/Maps -name *.png |wc -l I bet it will hang. So I request the following feature: Instead of having 75000 file for 118MB, compress the tiles into reasonable 1MB files. So 118 files in total in place of 75000 files. Anyone agree? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
Hi Bilk: Don't worry :) I've said that I'm afraid of the corruption. So this feature will be configurable if it can be integrated. 2009/7/2 William Kenworthy (via Nabble) ml-user+1677-108203...@n2.nabble.com: I hope not - I have over 2 million tiles stored on SD card - if file corruption or disaster occurs, it may affect only one tile if its being accessed at the time - imagine the effect of file system corruption on one large archive ... you will most likely lose the lot. Then there is the extra overhead needed - Ive gotta ask why? - if you can justify the extra cpu needed for this, why not do vector maps? BillK On Thu, 2009-07-02 at 00:42 -0700, mqy wrote: x and y are tile no in tile coordinate system within range of [0.. 2^zoom). just do it if you have time, since proof of concept is necessary :) keep in mind clear APIs. it's likely that, the final version to be integrated into omgps is rewritten in C. Laszlo KREKACS wrote: If I understand right the OSM tiles, they have the following directory ... -- William Kenworthy bi...@... Home in Perth! ___ Openmoko community mailing list commun...@... http://lists.openmoko.org/mailman/listinfo/community This email is a reply to your post @ http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193977.html You can reply by email or by visting the link above. -- View this message in context: http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3205707.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Mon, Jun 29, 2009 at 05:29:22PM -0700, mqy wrote: Please feel free to comment or add new feature requests here. Two comments on the package control file: 1) The dependency on python2.6 is missing. 2) The description is still the default one. -- 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: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 00:20, Laszlo KREKACSlaszlo.krekacs.l...@gmail.com wrote: I dont want to compress at all. The 118MB for me is perfect. I only want to pack the directory into a file. But not compressing. Im thinking about tar or ar. Tar completely fail at random access, simply it lacks the table of content, so accessing the last file in the archive requires reading the whole content before it. I fail to see how is this true for normal tar files (vs. data read from pipe). Can you elaborate please? Zip support accessing each files in the archive, although it compress the file by default. Pardon my ignorance, but wouldn't zip -0 do the trick for your purpose? :) -- Regards, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 7:22 AM, mqymeng.qing...@gmail.com wrote: XML is used as a database, elements can be easily added, modified, removed. xor tends to be overkilled as of map tile usage -- we don't need iterating, delete, and that much meta information. With my suggested design, we can even add newly downloaded tiles: insert record into meta database, and append tile content into heap file. If I understand right the OSM tiles, they have the following directory structure: XX/YYY/ZZZ.png 10/558/357.png All the information is obtained from this info (position, zoom level), am I right? XX: zoom level YYY: position x? (or I dont know how to call it;) ZZZ: position y? So I think we should only pack the files into the KISS archive file. For more in depth explanation see the end of this mail. So something like this: XX/YY1.kiss XX/YY2.kiss XX/YYY.kiss Im willing to implement a simple kiss/unkiss program (just like tar/untar), for easy archiving. I will use python with no non-standard modules. Best regards, Laszlo ps: Some statistical data: Number of all tiles # cd ~/Maps/OSM; find . -name *.png |wc -l 63818 Subdirs in zoom level dirs (YYY), and total number of files. for i in *; do echo -n $i; echo -n ; cd $i; ls -1|wc -l; cd ..; done for f in *; do cd $f; for i in *; do cd $i; for k in *; do echo $i/$k ~/Maps/OSM/$f.txt; done; cd ..; done; cd ..; done cd ~/Maps/OSM for i in *.txt; do echo -n $i ; cat $i|wc -l ; done 2: 4 dirs, 16 files 3: 8 dirs, 64 files 4: 11 dirs,77 files 5: 17 dirs,83 files 6: 22 dirs, 265 files 7: 22 dirs, 217 files 8: 17 dirs,75 files 9: 26 dirs, 152 files 10: 39 dirs, 426 files 11: 71 dirs, 1484 files 12: 100 dirs, 1046 files 13: 78 dirs, 2902 files 14: 193 dirs, 23400 files 15: 86 dirs, 1941 files 16: 119 dirs, 4033 files 17: 277 dirs, 27637 files Count the files in the subdirs(ZZZ): for i in *; do echo -n $i; echo -n f ; cd $i; for j in *; do cd $j; echo -n $i # $j @; ls -1|wc -l; cd ..; done; cd ..; done The number of files is in general 20-30, and the maximum was 180. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
You can read it here, I also included it (at the end of mail) for reference: http://pastebin.com/m608acaeb From your reference: ## General properties - blocksize: 512 bytes - only store filename (and directory if any) and content It might be convenient for future to store file properties like time of modification. This way you could implement automatic update of tiles that have been modified since last update or archive creation. -- Kind Regards Patryk Benderz IT Specialist Linux Registered User #377521 +48 22 538 6292 ERSTE Securities Polska S.A. ul. Królewska 16 Warszawa 00-103 KRS 065121 NIP 526-10-27-638 REGON 011136053 Kapitał akcyjny: 15.500.000 złotych (w pełni opłacony) This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission. Email secured by Check Point ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 8:42 AM, Alexander Shulginalex.shul...@gmail.com wrote: I fail to see how is this true for normal tar files (vs. data read from pipe). Can you elaborate please? Yepp, of course;) Tar archive does not contain the byte positions of files inside the archive. That means accessing a file inside the archive needs to read the whole content before it, and determine where each file ends. (and you test if you are at the desired file by reading its header). It simply lacks of a TOC (table of content). So accessing the last file in the archive reuires to reading the whole archive. You can read it here: http://en.wikipedia.org/wiki/Tar_(file_format)#Format_details Simplification of tar archive: [1. file header][1. file][2.file header][2. file][3. file header][3. file] So how you read the third file from the archive? You read the file until the [3. file header], your test is successfull (is it the right file?), and you read the file itself. You see? You have read the whole file, just accessing the last item inside. Zip support accessing each files in the archive, although it compress the file by default. Pardon my ignorance, but wouldn't zip -0 do the trick for your purpose? :) It will do more or less, however there are three main problems with it: 1. you can only obtain the whole file from the archive. So you cant read a part of the file. So if you packed lets say a 700MB file to zip, you run out of memory on neo. At least this is the case on standard python zipfile module. 2. There is no random access feature, at least not in standard python modules. 3. There are significant processor time wasted when accessing to a file (many computation required). Btw, it needs to benchmark on the neo, how worse is it. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 9:15 AM, Patryk Benderzpatryk.bend...@esp.pl wrote: - only store filename (and directory if any) and content It might be convenient for future to store file properties like time of modification. This way you could implement automatic update of tiles that have been modified since last update or archive creation. This is a neverending game. You store one properties, others want other property to store. You finally ends something overcomplicated like an xml structure. And for accessing the files inside the archive, you dont need this infos at all. But this fileformat is flexible enough, just attach the metainformation of files as a file into the archive! And your problem is solved, and it is future-proof. So the file structure would be something like this in your case: [header] [filenames] [1. file = metadata file] [2. file] [3. file] [4. file] However this fileformat is not final, Im open for suggestions;) I didnt decided if the filenames section should go at the end, or right after the header. And where to store the metadata, if any? (start vs. end of file) So [header] [filenames] [1. file] [2. file] [3. file] vs. [header] [1. file] [2. file] [3. file] [filenames] The same with metadata: [header] [filenames] [1. file = metadata file] [2. file] [3. file] vs. [header] [1. file] [2. file] [3. file = metadata file] [filenames] Need a bit of thinking here. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
x and y are tile no in tile coordinate system within range of [0.. 2^zoom). just do it if you have time, since proof of concept is necessary :) keep in mind clear APIs. it's likely that, the final version to be integrated into omgps is rewritten in C. Laszlo KREKACS wrote: If I understand right the OSM tiles, they have the following directory ... -- View this message in context: http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193890.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 9:42 AM, mqymeng.qing...@gmail.com wrote: x and y are tile no in tile coordinate system within range of [0.. 2^zoom). just do it if you have time, since proof of concept is necessary :) keep in mind clear APIs. it's likely that, the final version to be integrated into omgps is rewritten in C. Ok. I'll do it. I will put the [filenames] section at the end of file. That way appending to the file is dead simple. The header structure will be the same, so between 10-20 bytes are always the [filenames] position. I was thinking more about the metadata stuff. If we agree on a filename, like .metadata-kiss, and attache it as a simple file, there is no importance where in the archive should be placed (but I think should be placed at the end): [header] [1. file] [2. file] [3. file = metadata file] [filenames] But metadata is really for future consideration (if people find this archive format useful). I will also make some test archive file along with the kiss and unkiss program, to easy implementing. Here is the updated specification (I added two more faq entries, max filesize and max filename length): http://pastebin.com/f51927121 Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
Here is the updated specification (I added two more faq entries, max filesize and max filename length): http://pastebin.com/f51927121 I made a small mistake (header structure), here we go: http://pastebin.com/f5feafd7a Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
I hope not - I have over 2 million tiles stored on SD card - if file corruption or disaster occurs, it may affect only one tile if its being accessed at the time - imagine the effect of file system corruption on one large archive ... you will most likely lose the lot. Then there is the extra overhead needed - Ive gotta ask why? - if you can justify the extra cpu needed for this, why not do vector maps? BillK On Thu, 2009-07-02 at 00:42 -0700, mqy wrote: x and y are tile no in tile coordinate system within range of [0.. 2^zoom). just do it if you have time, since proof of concept is necessary :) keep in mind clear APIs. it's likely that, the final version to be integrated into omgps is rewritten in C. Laszlo KREKACS wrote: If I understand right the OSM tiles, they have the following directory ... -- 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: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 10:08 AM, William Kenworthybi...@iinet.net.au wrote: I hope not - I have over 2 million tiles stored on SD card - if file corruption or disaster occurs, it may affect only one tile if its being accessed at the time My experience differs completely from yours. - imagine the effect of file system corruption on one large archive ... you will most likely lose the lot. I would even prefer to loosing my map files (backups?), than crashing the whole filesystem. However this is not the case. I dont intent to push pack everything into a single file. Instead have about 1MB files. (or pack subdirs only) So if you want to loose something, loose 1MB. But this fileformat should be safe enough, if the header is untouched, you can recover files from the archive (and there are the checksum options too) Then there is the extra overhead needed - Ive gotta ask why? - if you can justify the extra cpu needed for this, why not do vector maps? Need a serious benchmark here, if the extra overhead is true or not. In opposite of your opinion, I expect speed improvements. ;) Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
I do not completely understand the reasons why there is a need for (once again) a new file format. As far as I understand the proposal, it is just a file system running in an image file. Like mounting an ISO or any other file system residing not on a raw disk but within a file. So what problem does it solve better than just using the existing file system hierarchy directly (/tiles/z/y/x.png)? If it does not compress, has no directories, is not faster and is not more reliable as William pointed out. I see only one benefit - you can copy the whole archive as a single object instead of copying a file tree. New file formats usually create more problems than they solve... Am 02.07.2009 um 10:08 schrieb William Kenworthy: I hope not - I have over 2 million tiles stored on SD card - if file corruption or disaster occurs, it may affect only one tile if its being accessed at the time - imagine the effect of file system corruption on one large archive ... you will most likely lose the lot. Then there is the extra overhead needed - Ive gotta ask why? - if you can justify the extra cpu needed for this, why not do vector maps? BillK On Thu, 2009-07-02 at 00:42 -0700, mqy wrote: x and y are tile no in tile coordinate system within range of [0.. 2^zoom). just do it if you have time, since proof of concept is necessary :) keep in mind clear APIs. it's likely that, the final version to be integrated into omgps is rewritten in C. Laszlo KREKACS wrote: If I understand right the OSM tiles, they have the following directory ... -- William Kenworthy bi...@iinet.net.au Home in Perth! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
2009/7/2 Dr. H. Nikolaus Schaller h...@computer.org I do not completely understand the reasons why there is a need for (once again) a new file format. As far as I understand the proposal, it is just a file system running in an image file. Like mounting an ISO or any other file system residing not on a raw disk but within a file. Good point. You can divide the archive into 100kb blocks and use mount -o loop on them. When you run out of space, just create a new block. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 10:15, Laszlo KREKACSlaszlo.krekacs.l...@gmail.com wrote: On Thu, Jul 2, 2009 at 8:42 AM, Alexander Shulginalex.shul...@gmail.com wrote: I fail to see how is this true for normal tar files (vs. data read from pipe). Can you elaborate please? Yepp, of course;) [snip] Simplification of tar archive: [1. file header][1. file][2.file header][2. file][3. file header][3. file] So how you read the third file from the archive? You read the file until the [3. file header], your test is successfull (is it the right file?), and you read the file itself. You see? You have read the whole file, just accessing the last item inside. Yes, but is lseek(2) banned on neo? This is what I was talking about then mentioned normal files (i.e. not pipes). :) Pardon my ignorance, but wouldn't zip -0 do the trick for your purpose? :) It will do more or less, however there are three main problems with it: 1. you can only obtain the whole file from the archive. So you cant read a part of the file. So if you packed lets say a 700MB file to zip, you run out of memory on neo. At least this is the case on standard python zipfile module. 2. There is no random access feature, at least not in standard python modules. 3. There are significant processor time wasted when accessing to a file (many computation required). Btw, it needs to benchmark on the neo, how worse is it. OK, I see now. Thanks for explanation. -- Cheers, Alex ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
El Wednesday, 1 de July de 2009 23:20:40 Laszlo KREKACS va escriure: ## General properties - blocksize: 512 bytes - only store filename (and directory if any) and content - first file contains the filenames - header: start block, end block, position of last block ## Overall file structure [header][filenames][1. file][2. file][3. file] ## [header] [SB][EB][POS] [SB][EB][POS] [SB][EB][POS] etc.. My first reaction to this was: Why do you need this? My points are: 1- With this format the resulting archive is near read only (every few inserts need the whole file should be rewrote. One could use a loop mounted filesystem and use well tested tools. 2- To make it usefull with every app I think we need to mount it with fuse. 3- Not enogh metadata. I think it could be simpler that way Metadata Block [0..511] [0..3] Previus # metadata block (last block for fist metadata block) [4..7] Next#Metadata Block (First on last metadata block [8..] Metadata_items #list of Metadata_item Metadata_item [0..1] Metadata_size #Bytes; [2] Kind # of metadata (Name, Block,Size, Date,CRC, ...) [3..6] file Id [8..Metadata_size-1] Value; Block Value [0..3] Start Block [4..7] End Block The example on QA soud could have the folowing metadata be: 00 00 00 00 # Previous 00 00 00 00 # Next 00 1F 01 00 00 00 01 first filename.extension #31 Bytes Name id 1 00 11 01 00 00 00 02 second try # 17 Bytes Name id 2 00 1D 01 00 00 00 03 I want a sexy name.txt #29 Bytes Name id 4 00 0F 02 00 00 00 01 00 00 00 01 00 00 00 02 # id 1 blocks 1-2 00 0F 02 00 00 00 02 00 00 00 03 00 00 00 04 # id 2 blocks 3-4 00 0F 02 00 00 00 03 00 00 00 05 00 00 00 08 # id 3 blocks 5-8 00 0B 03 00 00 00 01 00 00 03 00 #id 1 768 bytes 00 0B 03 00 00 00 02 00 00 04 00 #id 2 1024 bytes 00 0B 03 00 00 00 03 00 00 07 FF #id 3 2047 bytes 00 00 #end of metadata And a total file size of 9 blocks or 4608 bytes but with the same disk usage of 8kb. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
kimaidou wrote: Hum... speaking as a OpenStreetMap user, it would be great to merge the functionalities of omgsp with those of a tool like http://wiki.openmoko.org/wiki/Mokomapper meaning big buttons (9 per full-screen) allowing to store preset OSM data such as shop=bakery, highway=residential, amenity=pub, etc.. and be able to export directly in osm format. Nice idea. And if I export GPX instead of OSM, include all that pub/bakery/... stuff as comments. (The gpx format support comments) These comments then show up in JOSM - very useful. I usually add detail (housenumbers etc.) to areas that are already well mapped, so making OSM directly won't work for me. The road is already there, for example. GPX comments makes it easy to add only the stuff that is new. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Marcel wrote: Am Dienstag, 30. Juni 2009 13:48:05 schrieb Patryk Benderz: make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. Feature request: add support for vector/binary maps. That would be really nice. Problem might be the low render speed for vector maps though which navit suffers from... Maybe there are ways to speed it up? For the freerunner, make sure you do all tour drawing calculations with integer math only. No floating point coordinates. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
I usually add detail (housenumbers etc.) to areas that are already well mapped, so making OSM directly won't work for me. The road is already there, for example. GPX comments makes it easy to add only the stuff that is new. Good point, so my next idea : have the 2 features ;) * one map from scratch into .osm when you KNOW there is nothing here -- directly in osm format (especially for poi, because roads require some basic post-processing to become a way in osm (simplify, cut, etc.) * one map for josm into .GPX : what you said Kimaidou ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
On Thu, Jul 2, 2009 at 10:24 AM, Laszlo KREKACSlaszlo.krekacs.l...@gmail.com wrote: Need a serious benchmark here, if the extra overhead is true or not. Ok, I have written the python implementation of the file archive maker. I need to finish (ie. write the unpacking part) of it. I compiled few benchmarks... I compressed the whole OSM maps tiles on my laptop (I repeated it 10 times): l...@buldergep:~/Maps/OSM$ echo -e \noutput.kiss; time python ../../Asztal/down/openmoko/paroli/data/kiss/kiss.py ../report.txt;mv output.kiss ..; echo -e \noutput.tar; time tar -cf ../output.tar .; echo -e \noutput.zip; time zip -0 -r output * ../report.txt; mv output.zip ..; echo -e \noutput_comp.zip; time zip -r output_comp * ../report.txt; mv output_comp.zip ..; rm ../output*; rm ../report.txt output.kiss real0m4.447s user0m2.748s sys 0m1.520s output.tar real0m4.039s user0m0.236s sys 0m1.188s output.zip real0m5.556s user0m1.276s sys 0m2.632s output_comp.zip real0m12.438s user0m8.437s sys 0m2.620s So the speed is about the same as in .tar file case. And it beats the zip. File sizes: -rw-r--r-- 1 lol lol 109M 2009-07-02 19:11 output_comp.zip -rw-r--r-- 1 lol lol 125M 2009-07-02 19:11 output.kiss -rw-r--r-- 1 lol lol 156M 2009-07-02 19:11 output.tar -rw-r--r-- 1 lol lol 113M 2009-07-02 19:11 output.zip -rw-r--r-- 1 lol lol 93M 2009-07-02 19:11 output.kiss.bz2 -rw-r--r-- 1 lol lol 94M 2009-07-02 19:11 output.tar.bz2 Total size of invidual files: l...@buldergep:~/Maps/OSM$ du -hs . 290M. Pretty strange, it reserves half the size I think this file format worth the effort. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Wed, Jul 1, 2009 at 7:44 AM, W.Kenworthybi...@iinet.net.au wrote: 1/2 an hour is no problem (often use GPS daily on the way to work - coz I can :) - longest drive was ~5 hours, which needed power at about the 3.5 hour mark - was 6 months ago and it should go longer now. fsck does take an hour or so, but i only do it once a month as programmed maintenance - rarely finds an error UNLESS there has been a nasty crash which is rather rare these days (shr-unstable, built by myself). Yes it sometimes used to happen that I get a call or SMS when using tangogps and have had crashes so need to take the battery out to reset - almost always no errors (using ext3, for at least the past two months). If you are worried about fsck speed, put the SD card in a usb key and use a desktop/laptop to fsck it - much faster. When I use gps, I dont have laptop Try reducing the clock speed as I suggested - thats the most likely cause of your problems. Your symptoms sound very like what happens to me (on any SD card) when running with the standard clock speed. While the speed drop is ~1/3, its unnoticeable in my usage pattern. Also make sure that the card is mounted async - sync is dismally slow and any gain in stability is lost because transfers are exposed as they take much longer to complete. Swap will also add a degree of reliability in normal use, but if using a lot of swap, the phone can slow down dramaticly as thrashing starts - manually flushing swap gets things back on an even keel. Yepp, but the problem only occurs with tangogps There are some tar based compressed file systems out there (when tested, ~3.3gbytes of png's will compress down to ~550Mbytes as tar.bz2, but you need a lot of cpu cycles to extract) and they are not reliable at all. the problem is that OSM maps are either png (lots of small files) or vector based which adds a real and critical processing load as seen by navit. I actually symlink similar files (many are just ocean/desert - South Western Australia) and symlinks less than a certain size get stored in the inodes (fast symlinks) so dont take any disk space - the problem then becomes that ext3 has an upper limit to inodes :( I dont want to compress at all. The 118MB for me is perfect. I only want to pack the directory into a file. But not compressing. Im thinking about tar or ar. In short, you are barking up the wrong tree if you think that large numbers of files are causing your problem. Maybe. But if I wouldnt have any problem with those crash, I would like to see implemented. If nothing else, the inode usage. (for me, the fast copying to sd card). Im extra-paranoid about this kind of file-access. I dont like to stressing the filesystem to the limit. I have this experience in normal computer usage: Compressing a directory into zip and copyying a single file to the pen drive, takes several time less, then copying the directory as-is. If you ever tried a pendrive like 16 or 32GB you know what Im talking about. And it is independent of OS (windows vs. linux), and the filesystem of the pendrive (vfat vs. ext2) I didnt brother to reinstall tangogps since a month, because exactly of the above issue. To bad it seems that Im the only one in this boot. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New archive file format (was: [omgps] collect feature requests)
I dont want to compress at all. The 118MB for me is perfect. I only want to pack the directory into a file. But not compressing. Im thinking about tar or ar. Hi! I have studied all the available archive and compression options. Most notably tar[1][2][4][6] and zip file format [3]. They are the most common archive types. I read also ar (dpkg and ipkg uses it) and cpio format. So I did my homework, and made some researches. Our requirements: - no compression (no wasted cpu time) - random access (no slow waiting time and memory issue) - readily available module/library for easy of integrating (best: no additional package is required to install on the phone) Tar completely fail at random access, simply it lacks the table of content, so accessing the last file in the archive requires reading the whole content before it. Zip support accessing each files in the archive, although it compress the file by default. There are dar[5] and xar[7], which meets our random access criteria. However dar needs to be ported to the device, and xar is still in development (that means limited python support for example). So I wrote down the most dumb archive fileformat ever;) When I wrote the specification, I only had one goal: make it so simple, that everybody can implement it, so no need to wait for ready-made library. It is called KISS fileformat (keep it simple and stupid), the preferred extension would be filename.kiss You can read it here, I also included it (at the end of mail) for reference: http://pastebin.com/m608acaeb I think it is suitable for our map tile usage. What do you think? Best regards, Laszlo [1]: http://en.wikipedia.org/wiki/Tar_(file_format) [2]: http://www.python.org/doc/2.5.2/lib/module-tarfile.html [3]: http://www.python.org/doc/2.5.2/lib/module-zipfile.html [4]: http://en.wikipedia.org/wiki/Comparison_of_file_archivers [5]: http://en.wikipedia.org/wiki/DAR_(Disk_Archiver) [6]: http://en.wikipedia.org/wiki/Archive_formats [7]: http://code.google.com/p/xar/ KISS archive fileformat specification: # KISS archive format (Keep It Simple and Stupid) ## General properties - blocksize: 512 bytes - only store filename (and directory if any) and content - first file contains the filenames - header: start block, end block, position of last block ## Overall file structure [header][filenames][1. file][2. file][3. file] ## [header] [SB][EB][POS] [SB][EB][POS] [SB][EB][POS] etc.. [ 4][ 4][ 2] [ 4][ 4][ 2] [ 4][ 4][ 2] etc.. [ header ] [ filenames ] [1. file] etc.. SB (start block): 4 byte EB (end block): 4 byte POS (position of last block): 2 byte All numbers are stored big-endian. That means most significant bit first. Example: 613 dec = 265 hex = \00 \00 \02 \65 (4 bytes) 130411 dec = 1FD6B hex = \00 \01 \FD \6B (4 bytes) Note: The remaining part of the header block MUST be filled with zero bytes. You will always have remaining part in the block, simply each file takes 10 bytes. (512/10 = 51 and 2 bytes left) ## [filenames] UTF-8 text for each filename, delimited with '\n' byte. The directory structure is preserved too. [name of 1. file]['\n'][name of 2. file]['\n'][name of 3. file] etc.. Some examples: this is a file.txt this2.tar.gz this3.html images/loller.html weird_dir/this\/files contains\/several\\ slashes.txt Special characters: '\n': You cant have '\n' character in the filename. It is preserved. (it is not supported in most filesystems anyway) '/': directory delimiter. To save directory structure. '\/': if the filename itself contains an / character '\\': if the filename itself contains a \ character ## [X. file] The file content as is. ## FAQ: Q: Why another archive format? A: Because it is the most dumb format ever;) Q: Why not tar, ar, zip, [name archive type here]? A: Short answer: widely used archive format are not suited for random access with no compression. Long answer: tar: there is no index, reading the last file of the archive requires reading the whole file before it. zip: individual files are compressed, which means: processortime xar: it would fit the requirements, but it is not widely supported, and not in every language. Q: I use X language does KISS supported there? A: The fileformat is so simple, it is intented, every programmer could implement it in no time. Q: Does compression supported? A: No. But you can compress the whole file, just like in tar case: filename.kiss.bz2. Use it for file sharing. Q: Do advanced features (rights, symlinks, hardlinks, user/group/other) are preserved? A: No. It was not the goal of this archive. Although you can implement it, just write those informations in the first file. It is not recommended. Q: If the original file is not multiple of 512 bytes, how it will look in the archive, how many bytes will it take? A: Lets have an example. We have three files: 768bytes file, 1024 bytes, 2047 bytes
Re: New archive file format (was: [omgps] collect feature requests)
wow On Wed, Jul 1, 2009 at 2:20 PM, Laszlo KREKACSlaszlo.krekacs.l...@gmail.com wrote: I dont want to compress at all. The 118MB for me is perfect. I only want to pack the directory into a file. But not compressing. Im thinking about tar or ar. Hi! I have studied all the available archive and compression options. Most notably tar[1][2][4][6] and zip file format [3]. They are the most common archive types. I read also ar (dpkg and ipkg uses it) and cpio format. So I did my homework, and made some researches. Our requirements: - no compression (no wasted cpu time) - random access (no slow waiting time and memory issue) - readily available module/library for easy of integrating (best: no additional package is required to install on the phone) Tar completely fail at random access, simply it lacks the table of content, so accessing the last file in the archive requires reading the whole content before it. Zip support accessing each files in the archive, although it compress the file by default. There are dar[5] and xar[7], which meets our random access criteria. However dar needs to be ported to the device, and xar is still in development (that means limited python support for example). So I wrote down the most dumb archive fileformat ever;) When I wrote the specification, I only had one goal: make it so simple, that everybody can implement it, so no need to wait for ready-made library. It is called KISS fileformat (keep it simple and stupid), the preferred extension would be filename.kiss You can read it here, I also included it (at the end of mail) for reference: http://pastebin.com/m608acaeb I think it is suitable for our map tile usage. What do you think? Best regards, Laszlo [1]: http://en.wikipedia.org/wiki/Tar_(file_format) [2]: http://www.python.org/doc/2.5.2/lib/module-tarfile.html [3]: http://www.python.org/doc/2.5.2/lib/module-zipfile.html [4]: http://en.wikipedia.org/wiki/Comparison_of_file_archivers [5]: http://en.wikipedia.org/wiki/DAR_(Disk_Archiver) [6]: http://en.wikipedia.org/wiki/Archive_formats [7]: http://code.google.com/p/xar/ KISS archive fileformat specification: # KISS archive format (Keep It Simple and Stupid) ## General properties - blocksize: 512 bytes - only store filename (and directory if any) and content - first file contains the filenames - header: start block, end block, position of last block ## Overall file structure [header][filenames][1. file][2. file][3. file] ## [header] [SB][EB][POS] [SB][EB][POS] [SB][EB][POS] etc.. [ 4][ 4][ 2] [ 4][ 4][ 2] [ 4][ 4][ 2] etc.. [ header ] [ filenames ] [1. file] etc.. SB (start block): 4 byte EB (end block): 4 byte POS (position of last block): 2 byte All numbers are stored big-endian. That means most significant bit first. Example: 613 dec = 265 hex = \00 \00 \02 \65 (4 bytes) 130411 dec = 1FD6B hex = \00 \01 \FD \6B (4 bytes) Note: The remaining part of the header block MUST be filled with zero bytes. You will always have remaining part in the block, simply each file takes 10 bytes. (512/10 = 51 and 2 bytes left) ## [filenames] UTF-8 text for each filename, delimited with '\n' byte. The directory structure is preserved too. [name of 1. file]['\n'][name of 2. file]['\n'][name of 3. file] etc.. Some examples: this is a file.txt this2.tar.gz this3.html images/loller.html weird_dir/this\/files contains\/several\\ slashes.txt Special characters: '\n': You cant have '\n' character in the filename. It is preserved. (it is not supported in most filesystems anyway) '/': directory delimiter. To save directory structure. '\/': if the filename itself contains an / character '\\': if the filename itself contains a \ character ## [X. file] The file content as is. ## FAQ: Q: Why another archive format? A: Because it is the most dumb format ever;) Q: Why not tar, ar, zip, [name archive type here]? A: Short answer: widely used archive format are not suited for random access with no compression. Long answer: tar: there is no index, reading the last file of the archive requires reading the whole file before it. zip: individual files are compressed, which means: processortime xar: it would fit the requirements, but it is not widely supported, and not in every language. Q: I use X language does KISS supported there? A: The fileformat is so simple, it is intented, every programmer could implement it in no time. Q: Does compression supported? A: No. But you can compress the whole file, just like in tar case: filename.kiss.bz2. Use it for file sharing. Q: Do advanced features (rights, symlinks, hardlinks, user/group/other) are preserved? A: No. It was not the goal of this archive. Although you can implement it, just write those informations in the first file. It is not recommended. Q: If the original
Re: New archive file format (was: [omgps] collect feature requests)
add another wow from here :o 2009/7/1 jeremy jozwik jerjoz.for...@gmail.com: wow On Wed, Jul 1, 2009 at 2:20 PM, Laszlo KREKACSlaszlo.krekacs.l...@gmail.com wrote: I dont want to compress at all. The 118MB for me is perfect. I only want to pack the directory into a file. But not compressing. Im thinking about tar or ar. Hi! I have studied all the available archive and compression options. Most notably tar[1][2][4][6] and zip file format [3]. They are the most common archive types. I read also ar (dpkg and ipkg uses it) and cpio format. So I did my homework, and made some researches. Our requirements: - no compression (no wasted cpu time) - random access (no slow waiting time and memory issue) - readily available module/library for easy of integrating (best: no additional package is required to install on the phone) Tar completely fail at random access, simply it lacks the table of content, so accessing the last file in the archive requires reading the whole content before it. Zip support accessing each files in the archive, although it compress the file by default. There are dar[5] and xar[7], which meets our random access criteria. However dar needs to be ported to the device, and xar is still in development (that means limited python support for example). So I wrote down the most dumb archive fileformat ever;) When I wrote the specification, I only had one goal: make it so simple, that everybody can implement it, so no need to wait for ready-made library. It is called KISS fileformat (keep it simple and stupid), the preferred extension would be filename.kiss You can read it here, I also included it (at the end of mail) for reference: http://pastebin.com/m608acaeb I think it is suitable for our map tile usage. What do you think? Best regards, Laszlo [1]: http://en.wikipedia.org/wiki/Tar_(file_format) [2]: http://www.python.org/doc/2.5.2/lib/module-tarfile.html [3]: http://www.python.org/doc/2.5.2/lib/module-zipfile.html [4]: http://en.wikipedia.org/wiki/Comparison_of_file_archivers [5]: http://en.wikipedia.org/wiki/DAR_(Disk_Archiver) [6]: http://en.wikipedia.org/wiki/Archive_formats [7]: http://code.google.com/p/xar/ KISS archive fileformat specification: # KISS archive format (Keep It Simple and Stupid) ## General properties - blocksize: 512 bytes - only store filename (and directory if any) and content - first file contains the filenames - header: start block, end block, position of last block ## Overall file structure [header][filenames][1. file][2. file][3. file] ## [header] [SB][EB][POS] [SB][EB][POS] [SB][EB][POS] etc.. [ 4][ 4][ 2] [ 4][ 4][ 2] [ 4][ 4][ 2] etc.. [ header ] [ filenames ] [1. file ] etc.. SB (start block): 4 byte EB (end block): 4 byte POS (position of last block): 2 byte All numbers are stored big-endian. That means most significant bit first. Example: 613 dec = 265 hex = \00 \00 \02 \65 (4 bytes) 130411 dec = 1FD6B hex = \00 \01 \FD \6B (4 bytes) Note: The remaining part of the header block MUST be filled with zero bytes. You will always have remaining part in the block, simply each file takes 10 bytes. (512/10 = 51 and 2 bytes left) ## [filenames] UTF-8 text for each filename, delimited with '\n' byte. The directory structure is preserved too. [name of 1. file]['\n'][name of 2. file]['\n'][name of 3. file] etc.. Some examples: this is a file.txt this2.tar.gz this3.html images/loller.html weird_dir/this\/files contains\/several\\ slashes.txt Special characters: '\n': You cant have '\n' character in the filename. It is preserved. (it is not supported in most filesystems anyway) '/': directory delimiter. To save directory structure. '\/': if the filename itself contains an / character '\\': if the filename itself contains a \ character ## [X. file] The file content as is. ## FAQ: Q: Why another archive format? A: Because it is the most dumb format ever;) Q: Why not tar, ar, zip, [name archive type here]? A: Short answer: widely used archive format are not suited for random access with no compression. Long answer: tar: there is no index, reading the last file of the archive requires reading the whole file before it. zip: individual files are compressed, which means: processortime xar: it would fit the requirements, but it is not widely supported, and not in every language. Q: I use X language does KISS supported there? A: The fileformat is so simple, it is intented, every programmer could implement it in no time. Q: Does compression supported? A: No. But you can compress the whole file, just like in tar case: filename.kiss.bz2. Use it for file sharing. Q: Do advanced features (rights, symlinks, hardlinks, user/group/other) are preserved? A: No. It was not the goal of this archive. Although you can implement it, just write
Re: New archive file format (was: [omgps] collect feature requests)
Thumb up for your effort:)
A simpler design choice would be:
1. int get_tile_meta(int zoom, int x, int y, TileMeta *tm) -- fill in
offset, size; return -1 if tile not found
-- implemented by collecting per map meta info into a sqlite database
2. int get_tile_bytes(char* buf, TileMeta *tm) -- read tile content into
buf of size
-- implemented by collecting tiles into a big file.
Where TileMeta is defined as:
struct TileMeta
{
int offset;
int size;
U4 crc;
char *name; // optional
};
This kind of data source is abstracted as a tile provider, in addition to
the default standard file system based one.
I'd like to see if xar works well too.
regards,
mqy
Laszlo KREKACS wrote:
Hi!
I have studied all the available archive and compression options.
...
Best regards,
Laszlo
...
--
View this message in context:
http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193471.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
Hi! Thank you for the kind words. I'd like to see if xar works well too. I have only one problem with xar: xml. It complicates things unnecessary. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
XML is used as a database, elements can be easily added, modified, removed. xor tends to be overkilled as of map tile usage -- we don't need iterating, delete, and that much meta information. With my suggested design, we can even add newly downloaded tiles: insert record into meta database, and append tile content into heap file. Laszlo KREKACS wrote: ... I have only one problem with xar: xml. It complicates things unnecessary. ... Laszlo -- View this message in context: http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193580.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Hum... speaking as a OpenStreetMap user, it would be great to merge the functionalities of omgsp with those of a tool like http://wiki.openmoko.org/wiki/Mokomapper meaning big buttons (9 per full-screen) allowing to store preset OSM data such as shop=bakery, highway=residential, amenity=pub, etc.. and be able to export directly in osm format. My idea is to get some inspiration here : http://wiki.openstreetmap.org/wiki/OSMtracker Have a look at the screenshots, this is THE app missing on the freerunner to dynamically add data into OSM. Combining the map navigation of omgps and the easy editing of osm tracker would be awesome ! Ex: I am fooling around in my city, with omgps on. Hey, this bakery is not in the map. 3 clics further, it is ! (1clic on Osm, on click on Shops, one click on Bakery To be able to see if this bakery was or was not already in osm, it would be great to have a layer osm poi above the slippy mapnkik map This is my dream :D 2009/6/30 ivvmm unachieva...@gmail.com mqy wrote: currently, you have to stop track then view path with track replay. Please, make track replay rewindable! For huge tracks you have to wait forever while it gets where you wanted it to. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
I wish it had smoother scrolling, like tangogps has. I think that layer plugins would be a really good thing. One idea is to use the navit engine (for example) for routing using the vector data from OSM, and then display that on top of the png maps in omgps. By the way, omgps uses about 50% more memory than tango from what I saw. About 15mb compared to 10mb. Michal 2009/6/30 mqy meng.qing...@gmail.com First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178247p3178247.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
El Tuesday, 30 de June de 2009 02:51:38 David Ford va escriure: For those of you who post using nabble -- please reconsider. Nabble posts duplicates. The below was posted by nabble four times. The headers clearly indicate nabble at fault with four different originating message IDs. I haven't seen a duplicate coming from Nabble on this list and I'm suscribed with two email accounts. Additionally, many people report problems with nabble's javascript (no, JS isn't evil Doc) in any browser other than firefox. So please don't point people to nabble as a place to follow threads or research a message. I haven't had problems with konqueror but I've never used Nabble for other thing that testing it or as an emergency backup. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
On Tuesday 30 June 2009 09:21:27 Jose Luis Perez Diez wrote: I haven't seen a duplicate coming from Nabble on this list and I'm suscribed with two email accounts. http://lists.openmoko.org/pipermail/community/2009-June/050354.html http://lists.openmoko.org/pipermail/community/2009-June/050355.html http://lists.openmoko.org/pipermail/community/2009-June/050356.html http://lists.openmoko.org/pipermail/community/2009-June/050358.html This look like duplicate, no ? -- Vincent MEURISSE ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
The wha'ts ahead mode , fixed position(in the middle a little displaced at bottom) and moving/rotating map showing on top what's ahead, also a trasparent compass or at least a North mark to know actual map orientation. when there is not speed enough 4km/h the map may rest in the last direction detected. 2009/6/30 Michal Brzozowski ruso...@poczta.fm: I wish it had smoother scrolling, like tangogps has. I think that layer plugins would be a really good thing. One idea is to use the navit engine (for example) for routing using the vector data from OSM, and then display that on top of the png maps in omgps. By the way, omgps uses about 50% more memory than tango from what I saw. About 15mb compared to 10mb. Michal 2009/6/30 mqy meng.qing...@gmail.com First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178247p3178247.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
El Tuesday, 30 de June de 2009 09:36:38 Vincent MEURISSE va escriure: On Tuesday 30 June 2009 09:21:27 Jose Luis Perez Diez wrote: I haven't seen a duplicate coming from Nabble on this list and I'm suscribed with two email accounts. http://lists.openmoko.org/pipermail/community/2009-June/050354.html http://lists.openmoko.org/pipermail/community/2009-June/050355.html http://lists.openmoko.org/pipermail/community/2009-June/050356.html http://lists.openmoko.org/pipermail/community/2009-June/050358.html This look like duplicate, no ? Yes those messages share the same text but have different message id and timestamps. See the cause on 1246324530823-3178414.p...@n2.nabble.com :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Tuesday 30 June 2009 09:02:52 kimaidou wrote: Combining the map navigation of omgps and the easy editing of osm tracker would be awesome ! Ex: I am fooling around in my city, with omgps on. Hey, this bakery is not in the map. 3 clics further, it is ! (1clic on Osm, on click on Shops, one click on Bakery To be able to see if this bakery was or was not already in osm, it would be great to have a layer osm poi above the slippy mapnkik map This is my dream :D Having this kind of app is also a dream for me! :) Only one question. How you upload data to OSM? Can you upload all data at the end of the day, or you need to be allways connected? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Tuesday 30 June 2009 11:19:33 David Garabana Barro wrote: Having this kind of app is also a dream for me! :) Only one question. How you upload data to OSM? Can you upload all data at the end of the day, or you need to be allways connected? I'm asking about OSMtracker, of course. I've already used omgps :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Sorry I have not used Osm tracker, as my only mobile pc is my openmoko. I have just looked at the screen shots. Bu I have used osm2go (which has been ported to openmoko : http://comiles.eu/~natanael/projects/ , see the osm2go dir and the goocanvas dir ), and a deconnected edition is possible. When you reconnect, it just sends the changes made. So it is possible to do 2009/6/30 David Garabana Barro da...@garabana.com On Tuesday 30 June 2009 11:19:33 David Garabana Barro wrote: Having this kind of app is also a dream for me! :) Only one question. How you upload data to OSM? Can you upload all data at the end of the day, or you need to be allways connected? I'm asking about OSMtracker, of course. I've already used omgps :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Tuesday 30 June 2009 11:37:04 kimaidou wrote: Sorry I have not used Osm tracker, as my only mobile pc is my openmoko. I have just looked at the screen shots. Bu I have used osm2go (which has been ported to openmoko : I didn't knew it, thanks for the link ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
I like osm2go, but here are the things wich prevent me to use it : * not easy installation. If you encounter an error, you must create manually the ~/.osm2go folder * needs to set a project (not easy from the openmoko) to download the osm vector format * you must set many projects if you want to map in many places, because the projects must contains very small areas not to be vry slow (best if a rectangle of 5 km * 5km ). It is a shame you cannot start from scratch * optimized for maemo screen, so not very usable with finger But, it remains a great app, and you can try it on you debian or ubuntu : https://garage.maemo.org/frs/?group_id=830 And have a look of the wiki page http://wiki.openstreetmap.org/wiki/OSM2Go As a conclusion, I would say I cannot use it on my openmoko which is very frustrating since it has many great features. This is why I think we must create a dedicated openmoko software for easy editing : * png tiles * big add poi buttons with preconfigured osm tags (as osm2go does well) * deconnected mode : import osm data / upload changes BUT without displaying the vector data, OR only a small bit of data (new layer) chosen by the user. Diplaying vectors make osm2go slow on the freerunner, but we need the data to be able to commit changes I hope I do not monopolize the subject :D 2009/6/30 David Garabana Barro da...@garabana.com On Tuesday 30 June 2009 11:37:04 kimaidou wrote: Sorry I have not used Osm tracker, as my only mobile pc is my openmoko. I have just looked at the screen shots. Bu I have used osm2go (which has been ported to openmoko : I didn't knew it, thanks for the link ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Hi - and thanks for omgps, it rocks! * I want to second what kimaidou said, tools to improve OSM mapping would be awesome.. There were two threads about this a while ago, see http://lists.openmoko.org/pipermail/community/2009-June/thread.html#49036 http://lists.openmoko.org/pipermail/community/2009-June/thread.html#49329 - I'd really much like to be able to save POI's or something to load on JOSM to add it to OSM. Big buttons that'd allow me to mark 'paved road starts', '80km/h speed limit starts', 'crossroads', 'bridge' etc. mokomapper has some of this built in but it doens't work with fbus-based GPS-stuff.. * Supporting layers doesn't sound like a bad idea. * Being able to change the frequency of saving the location would be nice 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: [omgps] collect feature requests
The possibility to enable/disable aided gps start within the settings would be nice since fso still does agps function by itself. So the aided feed of data from omgps would do it the second time after gps start. And disabling agps in omgps speeds up the start and exit time of omgps a little bit. :) Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. Feature request: add support for vector/binary maps. OSM maps take a lot of space. Example, map of Poland downloaded from OSM uses few GB contrary to binary format, which uses less then 20 MB at the moment of this writing. I use maps for navit found here: http://downloads.cloudmade.com/ -- Kind Regards Patryk Benderz IT Specialist Linux Registered User #377521 +48 22 538 6292 ERSTE Securities Polska S.A. ul. Królewska 16 Warszawa 00-103 KRS 065121 NIP 526-10-27-638 REGON 011136053 Kapitał akcyjny: 15.500.000 złotych (w pełni opłacony) This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
It would be really helpful for track logging to be able to split a track from the main screen. This makes it easier for later OSM editing, so you know where a way/road changed. Otherwise I support any previously mentioned ideas to ease later import/edit in JOSM and alike. Cheers, Christian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Noone experienced whole filesystem crash because of *that* many open file descriptors? It would be really strange. ITs really simple to test it: While using tangogps/omgps remove the battery. Almost 90% percent and the whole filesystem crashes (the tiles are no more availables) You can test it, with: find /home/root/Maps -name *.png |wc -l I bet it will hang. So I request the following feature: Instead of having 75000 file for 118MB, compress the tiles into reasonable 1MB files. So 118 files in total in place of 75000 files. Anyone agree? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
I haven't seen a duplicate coming from Nabble on this list and I'm suscribed with two email accounts. I see duplicates _constantly_. It's really annoying... -- Kind Regards Patryk Benderz IT Specialist Linux Registered User #377521 +48 22 538 6292 ERSTE Securities Polska S.A. ul. Królewska 16 Warszawa 00-103 KRS 065121 NIP 526-10-27-638 REGON 011136053 Kapitał akcyjny: 15.500.000 złotych (w pełni opłacony) This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
JS isn't evil Doc) in any browser other than firefox. So please don't point people to nabble as a place to follow threads or research a message. Can you provide alternative, where point them to? Mailing list archive or is there anything else?? -- Kind Regards Patryk Benderz IT Specialist Linux Registered User #377521 +48 22 538 6292 ERSTE Securities Polska S.A. ul. Królewska 16 Warszawa 00-103 KRS 065121 NIP 526-10-27-638 REGON 011136053 Kapitał akcyjny: 15.500.000 złotych (w pełni opłacony) This message and any attached files are confidential and intended solely for the addressee(s). Any publication, transmission or other use of the information by a person or entity other than the intended addressee is prohibited. If you receive this in error please contact the sender and delete the material. The sender does not accept liability for any errors or omissions as a result of the transmission. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Am Dienstag, 30. Juni 2009 13:48:05 schrieb Patryk Benderz: make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. Feature request: add support for vector/binary maps. That would be really nice. Problem might be the low render speed for vector maps though which navit suffers from... Maybe there are ways to speed it up? -- Marcel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
hi Ciao, omgps supports two data providers: (1) UBX binary and (2) fso ogpsd (through dbus). with #1, no way to utilize ogpsd, you know duplicate connection to /dev/ttySAC1 would cause unexpected result. Fox Mulder wrote: The possibility to enable/disable aided gps start within the settings would be nice since fso still does agps function by itself. So the aided feed of data from omgps would do it the second time after gps start. And disabling agps in omgps speeds up the start and exit time of omgps a little bit. :) Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3182489.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
My name is Rainer not Ciao but i forgive you. :) Ok so when i understand it right i can change between nativ UBX Format and ogpsd (NMEA format?) usage. As i know ogpsd was introduced to solve the problem of multiple programs accessing /dev/ttySAC1 and instead use ogpsd which support multiple connections. But what is not clear to me is how you connect to the gps with UBX format. I thought this is only possible over /dev/ttySAC1, which would block possible ogpsd readings, or does ogpsd support NMEA and UBX format? So in the end i only have to switch somehow from UBX to ogpsd input in omgps to disable the aided gps data function? mqy wrote: hi Ciao, omgps supports two data providers: (1) UBX binary and (2) fso ogpsd (through dbus). with #1, no way to utilize ogpsd, you know duplicate connection to /dev/ttySAC1 would cause unexpected result. Fox Mulder wrote: The possibility to enable/disable aided gps start within the settings would be nice since fso still does agps function by itself. So the aided feed of data from omgps would do it the second time after gps start. And disabling agps in omgps speeds up the start and exit time of omgps a little bit. :) Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Hehe, I just googled ciao, Ciao bella:) First of all I have to say that fso-framework is excellent, because we do need a top level abstraction and manger to control access to system resources (especially the hardwares). As of GPS related APIs in ogpsd, UBX binary protocol is used to issue control commands (such as initialize GPS receiver, upload/download AID messages), and NMEA protocol is used to accept messages passively. NMEA is good, because it is standard and easy to understand, easy to implement parser. but standard also means less flexibility comparing to UBX binary protocol which provides richer data and more controls. I've implemented three parsers (UBX binary, UBX NEMA, standard NEMA) and can switch on the fly. Finally I realized that it is unacceptable without supporting fso. I can choose use gpsd (or fso-gpsd) + ogpsd as data provider, but i's not battery-friendly -- fso-gpsd accepts data from ogpsd, converts them to NMEA messages, fso-gpsd users get data from it through sockets. To use ogpsd, it is obvious that omgps talks directly with ogpsd. I want better performance and free controls. UBX binary is efficient enough, so it is kept as default data provider. The common communication model of UBX binary is polling: send request, read response and optional ACK. On omgps start, it checks if ogpsd has users connected to it (for example fso-gpsd). If no existing users, omgps use UBX binary as data provider, then initialize GPS receiver (enable UBX binary protocol, disable NEMA protocol)... NOTE: the three protocols can be enabled at the same time, this means /dev/ttySAC1 can output binary + text. During omgps running, each response message is validated (header + checksum + ack). If another user of GPS receiver (say ogpsd) is started, it would re-initialize GPS, which may cause omgps read timeout, get bad data. Anyway, omgps can detect conflict and during that period other GPS receiver users may lose some data which are consumed by omgps. Upon conflict, omgps checks existing GPS receiver users via ogpsd dbus API, if the count 0, omgps has to switch data provider to ogpsd. To get data from ogpsd you have to register signals (aysnc mode, ogpsd sends data per second) or poll in synchronous mode. So the finnaly conclusion: you can't manually switch to ogpsd. BTW, is the start time unacceptable? Ciao, mqy :) Fox Mulder wrote: My name is Rainer not Ciao but i forgive you. :) Ok so when i understand it right i can change between nativ UBX Format and ogpsd (NMEA format?) usage. As i know ogpsd was introduced to solve the problem of multiple programs accessing /dev/ttySAC1 and instead use ogpsd which support multiple connections. But what is not clear to me is how you connect to the gps with UBX format. I thought this is only possible over /dev/ttySAC1, which would block possible ogpsd readings, or does ogpsd support NMEA and UBX format? So in the end i only have to switch somehow from UBX to ogpsd input in omgps to disable the aided gps data function? mqy wrote: hi Ciao, omgps supports two data providers: (1) UBX binary and (2) fso ogpsd (through dbus). with #1, no way to utilize ogpsd, you know duplicate connection to /dev/ttySAC1 would cause unexpected result. Fox Mulder wrote: The possibility to enable/disable aided gps start within the settings would be nice since fso still does agps function by itself. So the aided feed of data from omgps would do it the second time after gps start. And disabling agps in omgps speeds up the start and exit time of omgps a little bit. :) Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3183105.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
On Tuesday 30 June 2009, Patryk Benderz wrote: JS isn't evil Doc) in any browser other than firefox. So please don't point people to nabble as a place to follow threads or research a message. Can you provide alternative, where point them to? Mailing list archive or is there anything else?? There are the list archives at http://lists.openmoko.org Other sites have archives and interfaces too: http://kerneltrap.org/mailarchive/openmoko-community http://openmoko.markmail.org 10 seconds with a search engine will turn up several more. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
The summary is listed here: http://code.google.com/p/omgps/wiki/FeatureRequests?ts=1246375354updated=FeatureRequests I will go traveling during 07-02 ~ 07-04. If your comment or suggestion may not list there, it is likely due to delay. -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3183248.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
Yes, and he and I discussed it on IRC a few minutes after all 4 postings. He clicked to submit and it didn't respond so he clicked again and tried yet again etc. While it appeared that the web interface wasn't posting to him, it actually did post which made him post it four times. In my original message I pointed out that it was nabble at fault, as indicated by the different message IDs but the exact same message body. On 06/30/09 04:32, Jose Luis Perez Diez wrote: [...] Yes those messages share the same text but have different message id and timestamps. See the cause on1246324530823-3178414.p...@n2.nabble.com :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
mqy wrote: Hehe, I just googled ciao, Ciao bella:) :) ... So the finnaly conclusion: you can't manually switch to ogpsd. BTW, is the start time unacceptable? No it is good but i thought we could even accelerate it a little bit. You know... the faster the better. :) Ciao, Rainer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
hi Laszlo, I've developed concurrent Java programs on sever, ever experienced problem of file descriptor out of per process limit. Haven't seen it crash file system on server or desktop boxes. By default the fd limit is 1024 (see it with ulimit -a), If that's the cause, you would fail even if with battery plugged. I don't think find or wc open that much file descriptors at all. My guess: to read dir entries in a directory, open the direcotory, then read inodes in this directory, then close the directory. Of course at least a pipe is created. My test with omgps running shows no failure, with 26954 image files. You can add a swap file /partition then test again, to see if limited memory causes this problem. I've watched with `vmstat 1`, seen limited memory usage. Here is my clues: #1: max current of usb power supply is 500mA, with heavy CPU load, uSD card may not get enough power then fails to work. #2: Many people experienced the lose partition problem including myself, I can remember somebody asked that why GPS hurt uSD card?. Laszlo KREKACS wrote: Noone experienced whole filesystem crash because of *that* many open file descriptors? It would be really strange. ITs really simple to test it: While using tangogps/omgps remove the battery. Almost 90% percent and the whole filesystem crashes (the tiles are no more availables) You can test it, with: find /home/root/Maps -name *.png |wc -l I bet it will hang. So I request the following feature: Instead of having 75000 file for 118MB, compress the tiles into reasonable 1MB files. So 118 files in total in place of 75000 files. Anyone agree? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3185152.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Tue, Jun 30, 2009 at 10:40 PM, mqymeng.qing...@gmail.com wrote: My test with omgps running shows no failure, with 26954 image files. You can add a swap file /partition then test again, to see if limited memory causes this problem. I've watched with `vmstat 1`, seen limited memory usage. Here is my clues: #1: max current of usb power supply is 500mA, with heavy CPU load, uSD card may not get enough power then fails to work. #2: Many people experienced the lose partition problem including myself, I can remember somebody asked that why GPS hurt uSD card?. Ok, I lied a bit. I only tested with tangogps. But, it was reproducible. If the device freezed or I removed the battery, many tile maps got unreadable. I couldnt even list some directories or cd into them! (it rules out heavy CPU load, and not getting enough power) I already wrote about it about a month ago: http://lists.openmoko.org/pipermail/community/2009-June/048997.html So the problem really comes about the insane 75000 files (118MB). I would really like to tar, ar, zip, etc the dirs containing the invidual tiles. It seems an easy job! Would be much more managable, speed up a lot the file copying (copying many small files is several magnitude slower!). Current directory structure: OSM/11/1102/715.png OSM/11/1102/716.png OSM/11/1102/717.png OSM/11/1102/718.png We could simply create an OSM/11/1102.tar file, containing those invidual files. I bet it would be not slower. I could even imagine some speed boost. Remember accessing invidual files on a sd card takes time. A lot. You can try it for yourself, copy to a pendrive your ~/Maps directory. Now tar the dir (Maps.tar) and copy that singly file to the pendrive. The result is something like 40sec compared to 6-7min. So please consider to implement this on-the-fly untaring capability. Thank you, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Hi, I used gpsplot under WM for a while. What I liked was the possibility to open a GPX track, and to move along it. You could then edit it, by cutting the beginning or the end of it. This was for me interesting to cut parts which I wanted to keep private. Onen mqy wrote: First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Tue, Jun 30, 2009 at 11:32 PM, Laszlo KREKACSlaszlo.krekacs.l...@gmail.com wrote: But, it was reproducible. If the device freezed or I removed the battery, many tile maps got unreadable. I couldnt even list some directories or cd into them! (it rules out heavy CPU load, and not getting enough power) And doing a fsck.ext3 -y /dev/mmcbl0p2 took more than one hour! And another thirty minutes to untar the original OSM.tar file. (from NAND). It was a pretty ugly experience as I was 1000 km away of home, and no internet connection. Thanks i have put the OSM.tar on nand, and uncompressed to an independent partition in the sd card. So I could recover without any computer or internet. But took about 2 hours to recover. Once it crashed, two times it ran out of battery, and once I needed to remove the battery. So I want this more managable archive file format things. ;) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
mqy wrote: First, I must appreciate all omgps users, for your test and feed back. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? +1 to display cells on the map, like it is shown on the OSM map on the openBmap website. This must be done through something standard (KML?), because your app should stick to its purpose, and should not have features specific to obm, or only under a plugin, don't you think? Onen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Onen, obm data can be abstracted as a kind of POI to display. obm can be integrated into omgps with loosely coupled interfaces. to support obm, omgps must: 1. get obm data within an lat/lon rectangle and display them as a layer (just like POIs) 2. show details of each node 3. optionally as a gps data provider for obm. Here are problems to be concerned by obm logger. 1. user may not able to connect to net or can't afford to be online for long time. so must be able to get obm data offline. 2. local data must be able to be updated, do this with open obm logger? 3. while obm logger running, it connects to ogpsd to get GPS data, this triggers omgps switching its data provider from UBX binary to ogpsd, which waste energy. Lets think about how to implement plugin interface. 1. Protocol version: avoid incompatibility. 2. Type is defined as: * type_id (string) * type_name (string) * image (file path string) 3. Type data is defined as * type_id * lat (double) * lon (double) * desc (string) Let's think about C wrapper functions for Python plugins: /* get version */ 1. char * get_version(void); /* returns types definition, format TBD */ 2. char * get_types(void): get type definitions. /* returns data list, empty or NULL type id means all types, format TBD */ 3. char * load_data(type_id, lat1, lon1, lat2, lon2) To avoid too much data returned, omgps can limit minimal zoom level to call load_data(). Upon get data, omgps renders those data into current view. What do you think? Onen wrote: +1 to display cells on the map, like it is shown on the OSM map on the openBmap website. This must be done through something standard (KML?), because your app should stick to its purpose, and should not have features specific to obm, or only under a plugin, don't you think? Onen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3186131.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Laszlo, I understand your trouble, but I have to say that your problem is uncommon, because that is caused by unstable underlying infrastructure. Have you ever tested with other uSD cards, or have you upgraded kernel image and rootfs image to latest? Your request for archived repository was added into into requirement list, it will be implemented once I have evidence that it does not affect performance too much. Other than performance reason, I also worry about safety and memory usage. By safety I mean all eggs in one basket. Laszlo KREKACS wrote: Ok, I lied a bit. I only tested with tangogps. But, it was reproducible. If the device freezed or I removed the battery, many tile maps got unreadable. I couldnt even list some directories or cd into them! (it rules out heavy CPU load, and not getting enough power) I already wrote about it about a month ago: http://lists.openmoko.org/pipermail/community/2009-June/048997.html So the problem really comes about the insane 75000 files (118MB). I would really like to tar, ar, zip, etc the dirs containing the invidual tiles. It seems an easy job! Would be much more managable, speed up a lot the file copying (copying many small files is several magnitude slower!). Current directory structure: OSM/11/1102/715.png OSM/11/1102/716.png OSM/11/1102/717.png OSM/11/1102/718.png We could simply create an OSM/11/1102.tar file, containing those invidual files. I bet it would be not slower. I could even imagine some speed boost. Remember accessing invidual files on a sd card takes time. A lot. You can try it for yourself, copy to a pendrive your ~/Maps directory. Now tar the dir (Maps.tar) and copy that singly file to the pendrive. The result is something like 40sec compared to 6-7min. So please consider to implement this on-the-fly untaring capability. Thank you, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3186272.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Tue, 2009-06-30 at 23:32 +0200, Laszlo KREKACS wrote: ... But, it was reproducible. If the device freezed or I removed the battery, many tile maps got unreadable. I couldnt even list some directories or cd into them! (it rules out heavy CPU load, and not getting enough power) ... So the problem really comes about the insane 75000 files (118MB). ... 75000 tiles is not a lot: r...@om-gta02 ~ $ df -h Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 252544151096101448 60% / none 6040056 60344 0% /dev shmfs60400 0 60400 0% /dev/shm /dev/mmcblk0p1 94559 76295 13382 85% /media/card /dev/mmcblk0p2 5719599 2107720 3383078 38% /media/p2 volatile 60400 580 59820 1% /var/volatile r...@om-gta02 ~ $ find /media/p2/OSM -name *.png|wc 2207969 2207969 74463452 Yes, thats over 2 million files :) TangoGPS works fine ... Not all SD cards are created equal - many (including mine) require a reduced clock speed and then they are completely stable. I keep running out of inodes - ext3 sucks, even when created using maximum inodes - then fsck really takes forever! I believe reiserfs which is a far better file system in my opinion is available in 2.6.29 SHR (I am stuck on 2.6.28 as 2.6.29 gsm doesnt work for me.) - stabler and doesnt have inode limits. Try creating an init.d script to run at boot: r...@om-gta02 ~ $ cat /etc/init.d/sd_clk #!/bin/sh echo 1000 /sys/module/glamo_mci/parameters/sd_max_clk r...@om-gta02 ~ $ and make sure its mounted async BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Wed, Jul 1, 2009 at 6:12 AM, W.Kenworthybi...@iinet.net.au wrote: Yes, thats over 2 million files :) TangoGPS works fine ... Are you brave enough, that when you use tangogps for lets say a half an hour, you remove the battery from your phone? (without any power connection). Please report how much time it takes the fsck to finish (after that). Cant be just me. It happened with the default 512MB card too, which comes with the phone. Im not saying that we should create only one big archive file. Im saying that we should create archive files with 512-1024 kB size. So be reasonable filesizes. It optimize filesystem usage too, reduce fsck. I can see only positive effects here. I dont see the carrying all eggs in one basket. Positive effects: - reduced fsck time - far less inode uses, that means we can even use vfat for it - much less copying time (when you copy to the phone), I hope several order of magnitude less - 512-1024kB filesize shouldnt be a big deal of memory usage Im more than happy to gather a bit attention here. Thank you for your time. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
On Wed, 2009-07-01 at 07:13 +0200, Laszlo KREKACS wrote: On Wed, Jul 1, 2009 at 6:12 AM, W.Kenworthybi...@iinet.net.au wrote: Yes, thats over 2 million files :) TangoGPS works fine ... Are you brave enough, that when you use tangogps for lets say a half an hour, you remove the battery from your phone? (without any power connection). Please report how much time it takes the fsck to finish (after that). Cant be just me. It happened with the default 512MB card too, which comes with the phone. Im not saying that we should create only one big archive file. Im saying that we should create archive files with 512-1024 kB size. So be reasonable filesizes. It optimize filesystem usage too, reduce fsck. I can see only positive effects here. I dont see the carrying all eggs in one basket. Positive effects: - reduced fsck time - far less inode uses, that means we can even use vfat for it - much less copying time (when you copy to the phone), I hope several order of magnitude less - 512-1024kB filesize shouldnt be a big deal of memory usage Im more than happy to gather a bit attention here. Thank you for your time. Laszlo 1/2 an hour is no problem (often use GPS daily on the way to work - coz I can :) - longest drive was ~5 hours, which needed power at about the 3.5 hour mark - was 6 months ago and it should go longer now. fsck does take an hour or so, but i only do it once a month as programmed maintenance - rarely finds an error UNLESS there has been a nasty crash which is rather rare these days (shr-unstable, built by myself). Yes it sometimes used to happen that I get a call or SMS when using tangogps and have had crashes so need to take the battery out to reset - almost always no errors (using ext3, for at least the past two months). If you are worried about fsck speed, put the SD card in a usb key and use a desktop/laptop to fsck it - much faster. Try reducing the clock speed as I suggested - thats the most likely cause of your problems. Your symptoms sound very like what happens to me (on any SD card) when running with the standard clock speed. While the speed drop is ~1/3, its unnoticeable in my usage pattern. Also make sure that the card is mounted async - sync is dismally slow and any gain in stability is lost because transfers are exposed as they take much longer to complete. Swap will also add a degree of reliability in normal use, but if using a lot of swap, the phone can slow down dramaticly as thrashing starts - manually flushing swap gets things back on an even keel. There are some tar based compressed file systems out there (when tested, ~3.3gbytes of png's will compress down to ~550Mbytes as tar.bz2, but you need a lot of cpu cycles to extract) and they are not reliable at all. the problem is that OSM maps are either png (lots of small files) or vector based which adds a real and critical processing load as seen by navit. I actually symlink similar files (many are just ocean/desert - South Western Australia) and symlinks less than a certain size get stored in the inodes (fast symlinks) so dont take any disk space - the problem then becomes that ext3 has an upper limit to inodes :( In short, you are barking up the wrong tree if you think that large numbers of files are causing your problem. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178247p3178247.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178254.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178260p3178260.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
BIGGER BUTTONS!!! On Mon, Jun 29, 2009 at 5:30 PM, mqymeng.qing...@gmail.com wrote: First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178254.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178265p3178265.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
and more sincerely. perhaps a setting for lenght of displayed track. say your carting about with the track on, and you want to look at omgps to see where you have been but the line only draws so many minutes [?] into the past. i might be good to have a setting in the app that could control this for times when you want to see the whole shabang -jeremy On Mon, Jun 29, 2009 at 5:33 PM, jeremy jozwikjerjoz.for...@gmail.com wrote: BIGGER BUTTONS!!! On Mon, Jun 29, 2009 at 5:30 PM, mqymeng.qing...@gmail.com wrote: First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178254.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
hehe, how big? double? jeremy jozwik wrote: BIGGER BUTTONS!!! -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178300.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
make sense, I can remember this request before. but that's not battery-friendly. think how to draw such a path after you get thousands of fixes on each redraw (per second)? what about add another menu item let you review history? what about start track automatically at start? currently, you have to stop track then view path with track replay. jeremy jozwik wrote: and more sincerely. perhaps a setting for lenght of displayed track. say your carting about with the track on, and you want to look at omgps to see where you have been but the line only draws so many minutes [?] into the past. i might be good to have a setting in the app that could control this for times when you want to see the whole shabang -jeremy On Mon, Jun 29, 2009 at 5:33 PM, jeremy jozwikjerjoz.for...@gmail.com wrote: BIGGER BUTTONS!!! On Mon, Jun 29, 2009 at 5:30 PM, mqymeng.qing...@gmail.com wrote: First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178254.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178321.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
vertical, i would say yes. right now its only stylus or finger nail and lots of concentration. also, theres a lot of empty space in the main menu :) the change buttons for color or gps preset need to be bigger for sho On Mon, Jun 29, 2009 at 5:39 PM, mqymeng.qing...@gmail.com wrote: hehe, how big? double? jeremy jozwik wrote: BIGGER BUTTONS!!! -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178300.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
NABBLE [was: Re: [omgps] collect feature requests]
For those of you who post using nabble -- please reconsider. Nabble posts duplicates. The below was posted by nabble four times. The headers clearly indicate nabble at fault with four different originating message IDs. Additionally, many people report problems with nabble's javascript (no, JS isn't evil Doc) in any browser other than firefox. So please don't point people to nabble as a place to follow threads or research a message. TY 4x posted message: On 06/29/09 20:29, mqy wrote: First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
make sense, I can remember this request before. but that's not battery-friendly. think how to draw such a path after you get thousands of fixes on each redraw (per second)? thats why i was thinking a slider that someone could set if they dont want to be battery friendly at that one moment. then set it back when there being battery conscious. what about start track automatically at start? i like the manual method of starting a track. i use this program a lot as a navigation aid just carting about, even without tracking. so if it autotracked all the time id fill up my in device memory! currently, you have to stop track then view path with track replay. jeremy jozwik wrote: and more sincerely. perhaps a setting for lenght of displayed track. say your carting about with the track on, and you want to look at omgps to see where you have been but the line only draws so many minutes [?] into the past. i might be good to have a setting in the app that could control this for times when you want to see the whole shabang -jeremy On Mon, Jun 29, 2009 at 5:33 PM, jeremy jozwikjerjoz.for...@gmail.com wrote: BIGGER BUTTONS!!! On Mon, Jun 29, 2009 at 5:30 PM, mqymeng.qing...@gmail.com wrote: First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178254.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178321.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
it seems firefox plugin cookieculler prevents post displaying response. noscript is another trouble maker. I'm sorry for the duplicates. David Ford wrote: For those of you who post using nabble -- please reconsider. Nabble posts duplicates. The below was posted by nabble four times. The headers clearly indicate nabble at fault with four different originating message IDs. Additionally, many people report problems with nabble's javascript (no, JS isn't evil Doc) in any browser other than firefox. So please don't point people to nabble as a place to follow threads or research a message. TY 4x posted message: On 06/29/09 20:29, mqy wrote: First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/NABBLE--was%3A-Re%3A--omgps--collect-feature-requests--tp3178346p3178414.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
mqy wrote: currently, you have to stop track then view path with track replay. Please, make track replay rewindable! For huge tracks you have to wait forever while it gets where you wanted it to. signature.asc Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
