What functionality is of highest priority for you?

SirfIII compatiblity
13% (48 votes)
AGPS capability in J2ME
8% (30 votes)
Use the EXIFTOOL for tagging
10% (37 votes)
Add a scale to the map
1% (3 votes)
Add google maps to the internal interface
10% (35 votes)
Allow editing tracks in the tables
8% (29 votes)
Allow modifying tracks on the map
10% (36 votes)
Act as a "position" server (phone/PC)
3% (10 votes)
Upload past data to a remote server
1% (2 votes)
Upload data to OpenStreetMap directly
7% (24 votes)
Send SMS to other phones with current position.
2% (6 votes)
Exchange tracks between phones.
0% (0 votes)
Send current position to remote server at regular intervals.
4% (13 votes)
Configuration/Download for Dummies (limited functionality interface)
6% (20 votes)
Keep a database of tracks to use in tagging or in finding past tracks.
7% (24 votes)
Allow configuring track segment colors (in the table, on the map)
3% (11 votes)
Add statistics regarding tracks
5% (17 votes)
Other (add a comment to the poll)
4% (15 votes)
Total votes: 360

Comments

mdeweerd's picture

Closing the poll.

SirfIII compatiblity
13% (48 votes)
-> At the top of the list: wow.  I am currently looking into another protocol that was already partially implemented.  This will help to implement SirfIII easier and grow the user base.

Use the EXIFTOOL for tagging
10% (37 votes)
-> This should not be too difficult, so will be done in the near future.

Allow modifying tracks on the map
10% (36 votes)
-> More difficult.

Add google maps to the internal interface
10% (35 votes)
-> Not so straightforward either due to licensing constraints.  Still, I got the message.

AGPS capability in J2ME
8% (30 votes)
-> DONE already!!!

Allow editing tracks in the tables
8% (29 votes)
-> I guess that this will be done prior to modification of tracks on the map directly.  The underlying functionality needed for this can be a subset of what is needed for map modification.  Incremental change is easier.

Upload data to OpenStreetMap directly
7% (24 votes)
-> DONE already.

Keep a database of tracks to use in tagging or in finding past tracks.
7% (24 votes)
-> I liked this one, but will be lower on the list.

Configuration/Download for Dummies (limited functionality interface)
6% (20 votes)
-> A bit surprised it is not higher on the list. So I'll just focus on making phototagging a bit easier to do - EXIFTOOL is high on the list so geotagging is a topic that users 'need'.

Add statistics regarding tracks
5% (17 votes)
-> Will not be a priority.  May be added according to opportunity.

Send current position to remote server at regular intervals.
4% (13 votes)
-> DONE.

Other (add a comment to the poll)
4% (15 votes)
-> Different requests in the comments.  Interesting suggestions, some 'partially' done.

Allow configuring track segment colors (in the table, on the map)
3% (11 votes)
-> Very low priority.

Act as a "position" server (phone/PC)
3% (10 votes)
-> No server implementation then.

Send SMS to other phones with current position.
2% (6 votes)
-> Very low priority.

Upload past data to a remote server
1% (2 votes)
-> Even lower priority.

Add a scale to the map
1% (3 votes)
-> Very low priority.

Exchange tracks between phones.
0% (0 votes)
-> Something that does not need to be investigated.

distance

I'd like to see the distance of internal (in map and perhaps tracksummary) and exported tracks (html).

Thanks for developing this great piece of software :)

Export

I'd like the capability to export the altitude correction in the CSV file format.
I'd like also the possibility to export the RCR in the NMEA format.

Claudio

Filtering out tight data logs

I just logged for the first time and I set a track point every 5 seconds for a 1 day trip by car. I would like to filter out all data points in a way that only leaves points every (e.g.) 1 km of distance of the track. The feature to filter
by distance doesn't do that for me (correct?).

Please make a feature to "thin" a track by time or distance so it shows up on
a map nicely without too many tack points.

Thanks!

GUI should remember window size

It would be nice if the program could store its position and size, and use the values at next start

Imroy's picture

J2ME user interface

How about a proper UI for the mobile version? It looks like you've cobbled together something yourself (no offence intended). Isn't there a standard UI toolkit in J2ME?

I particularly have trouble with it interpreting a press of the up/down control as two or more events. It means I have to be careful when selecting menu items. When moving up or down by just one item I have to give the button a very quick push. And when selecting a menu item I have to pause momentarily to make sure it doesn't skip past the intended item and I end up selecting the wrong thing.

mdeweerd's picture

J4ME is used

Hi

I used J4ME. I looked around for some frameworks and while J4ME is certainly not the most complete one, it was the one that I succeeded in setting up quickly (including the bluetooth serial link).

Regarding the double 'push', I changed the related delay in the latest dev versions. I have no feedback if that works better or not - I do not have the problem. What version are you using?

Anybody proposing to build another/better GUI is welcome to do so. It would be mostly GUI work (& making sure the bluetooth link works).

Logger as hard drive

Hi Mario,

It would be nice if the logger could be made to emulate a hard drive when connected to the host. One could then see what's in the logger and select the log to download and convert. This could preferably be achieved with a simple drag-and-drop, i.e., download and conversion in one operation.

Karl Masreliez

mdeweerd's picture

Brainstorming

I see the idea which is good in terms of 'convergence'. Of course a log download could still take 10 to 20 minutes which would be too long. Some means of downloading the log in the background could help.
Further, the log is of course only available in a raw contiguous format and to know what is in it, it has to be downloaded. Supposing that the download is (partially) complete, one could of course show filenames with splitted data according to the rules set out elsewhere.
In the current setup, a derivative could be interesting and not extremely difficult to accomplish: drag and drop one of the buttons (CSV, KML, ...) to a destination directory. I am not sure what the application (BT747) gets to know about the destination (e.g., destination path), but it might also automatically scan the destination path for files, and virtually tag them (i.e., only place them on the map but not change the file content), get some of the parameters from the destionation path (e.g., google map key).

OK, I see. What about if the

OK, I see. What about if the raw file was downloaded (smart download), converted to a selectable format, for instance NMEA, and stored in a Log Files directory, all done automatically when one connects the logger to the host?

Karl Masreliez

mdeweerd's picture

Auto download on connect.

This is something that could be done 'fairly easily' upon 'connect' in BT747. BT747 can be made to autoconnect on opening too (already the case for J2ME).

Of course, this would need to be configureable through say a menu option like 'Autodownload' with options 'None, To CSV, To KML, ....' using the current settings for the paths.

To do it automatically when connecting the logger to the host, there is more work. One needs to find out how BT747 can be launched when the Operating System detects that a device is connected. If that is done then the current functionality already allows to implement what you suggest here. It is simply required to launch the command line interface of BT747 to request connection, download and conversion (to multiple formats too).
You could probably come close to it if you figure out the parameters you need to feed in to BT747cmd and put a link on your desktop that you click once you connected your device.

Autodownload

Could you please show me what the command line would look like for a one-click auto download and conversion to NMEA? Even better would of course be if you could add this feature as a menu item as you suggested.

Cheers,
Karl Masreliez

mdeweerd's picture

BT747cmd

Something like: BT747cmd -a -f MyDestinationBasename --outtype KMZ,GPX,NMEA -p COM4: --splittype TRACK => This downloads from the device on port COM4: to which the application will try to connect. The download goes into MyDestinationBasename.bin and the tracks in files like MyDestinationBasename-timespec.nmea. In this example, three output types will be written: KMZ, GPX and NMEA. You can of course select NMEA only if you do not mention the other two. The splittype indicates that multiple files should be created based on track identification which uses the distance in time between two valid positions. You could adjust that parameter through the --timesplit option that is not mentioned here. You can even tag your pictures on the command line if you want to. BT747cmd -h will give you an idea of the options or you can read here: http://www.bt747.org/node/52 . You may need to put BT747cmd.bat or BT747cmd.sh. In principle you can also use run_j2se.bat in stead of BT747cmd.bat as long as you add options to the execution. That works for me but was never validated by others.

BT747cmd

Thank you! Where do I find BT747cmd?

Karl Masreliez

mdeweerd's picture

BT747cmd is in the zip distribution

BT747cmd is in the zip distributions (on sourceforge).
You can find it in the root directory, but as said, the run_j2se start scripts should do the same with options.

P.S.: If you get an account on the site, then I do not need to 'approve' your comments ;-).

Works like a charm!

Thank you!

Karl Masreliez

PS: Tried to sign up for an account, but did not receive a password.

fux's picture

Hi.My 'important' wishes for

Hi.

My 'important' wishes for the next version(s):

  • EXIFTOOL for tagging
    I want to tag my Canon RAW Files (cr2) with the GPS position. EXIFTOOL supports writing CR2, so this is my most wanted feature.
  • Allow editing of tracks (map & tables)
    A quick editing of tracks would be very nice - especially to correct/delete mistaken positions.
  • Track database
    A database with all previous tracks would be very great. Overwriting the bin file with every new tracking is not an "optimal" solution. E.g. an (optional) interface to JDBC driver would be nice. I would then use MySQL as database.

Regards
Michi