Radek Bartoň wrote: > Dne Saturday 13 of September 2008 22:47:38 Abdelrazak Younes napsal(a): > >> I was thinking of kml support too so that your track and way points can >> be loaded in Google Earth. KML files are pretty easy to generate. But I >> don't think this kind of format conversion have a place in a GUI app. >> The GUI app could OTOH call some external process to do the conversion. >> >>> There are plans to add more features to this app, either by me or another >>> person who has cloned the tree, he will be working on it in a few weeks I >>> think. > > Concerning tracking format I thought that basic file format shoud be storage > effective binary format. I would prefer standardized one but I don't know > which one yet.
I'd propose to keep ublox binary format. This format is quite clear and already documented. Ideally I'd like a simple daemon (that could be an extension of gypsy) that will write hourly logs of the gps chip in an organized directory structure. The types of ublox messages logged as well as the accumulated size on disk would be configurable. This logger would be started as soon as the GPS is turned on. We could potentially dissociate the AID messages (ephemerises, almanacs, SBAS masks) from the raw and navigation data. Then for example, when started, QtopiaGps would be able to read the track and display the GPS track since the ublox was started. Another program could do something else with the raw data (statistics, conversion to another format, tomography, experimental navigation algorithm, etc). > Then conversion scripts to any other format can be easily > written or gpsbable can be utilized. There could be designed even abstact > inteface for loggers/output devices now but it can be implemented by > different file format handlers lately. Agreed. > >> If you talk about me I will certainly do but I don't have the time right >> now... > > I'm quite sure that that person is me because I post Moris my proposals > recently. Good, that makes the three of us then :-) >>> Adding tracks is definitely something he is planning to do. > > That's true. I've been on a trip with my Neo recently and I reveal many > usefull features which can be implemented and which no available GPS > application for Neo has for now. I'll sumarize them somewhere soon and then > I'll start to implement them sequentially. > >> I stumbled across this: >> http://www.medieninf.de/qmapcontrol/ >> >> It could be a good idea to just use that instead of borowing TangoGPS >> code for openstreetmap support. > > > I'll investigate that possibility closely too but I'm quite sceptic about this > project clearness and design effectivness. I didn't look at the source code yet. > SlippyMap tile download and > display is quite easy to implement so I think it can be done from scratch (or > extracted from TangoGPS). Only difficulties would be dealing with multiple > threads. I've already written Python script for maps pre-download for > TangoGPS similar to gpsfetchmap.pl (it is not publicly available yet) and > there is nothing complicated about that. Very good. Abdel. _______________________________________________ Openmoko community mailing list firstname.lastname@example.org http://lists.openmoko.org/mailman/listinfo/community