Notices


Reply
Thread Tools
Framstag's Avatar
Posts: 72 | Thanked: 51 times | Joined on Jul 2008 @ Germany
#11
Originally Posted by gsever View Post
Hey,

I updated GPSJinni again and now it works, doesn't complain about other packages. Glad to see that if fixed latitude writing annoyance.
Fine, that it works now.

Originally Posted by gsever View Post
What is the highest precision that you could write to a file or read from the GPS receiver? (I see 47.9246 for example could this be improved like 47.9246XX ? ) Exported KML shows some funny locations --probably due to the positioning uncertainties ehh?
Lat, long are doubles that will be multiplied by 10000000.0 and rounded (and shifted to get a unsigned integer number). I haven't calculated it myself but this is a common trick fromt he OSM world and is saif to have still enough precision for real world position. Note that the position error of the dvice is normally higher.

Originally Posted by gsever View Post
Could we set writing frequency interval to KML output? Say I want to my locations to be written or sampled only for 1/5/10 sec intervals.

I currently use the default, but liblocation allows time precision of 1,2, 5, 10, 20, 30, 60, 120 seconds. I can add this to the TODO list.

Originally Posted by gsever View Post
Can you add time stamp to the space coordinates? Say at what time I was at 47.9246 longitude etc...


Originally Posted by gsever View Post
Creation of time-stamped logging file. Let say when I start recording I want the file automatically be appearing as YEARMONTHDAY_HHMMSS and save as KML in the same fashion.
Yes time is already stored in the internal file format and thus can be added to the KML output. Do you have a link to a concrete example for how time is stored in KML?

Originally Posted by gsever View Post
OK, I admit I want a lot Consider them as feature requests? Do you have an issue tracker so that these will not be forgotten.

Other than that, thanks for making it available to us
No problem with adding valid feature requests to the TODO list ;-) I think the time stuff should be the easiest one to add.
 

The Following User Says Thank You to Framstag For This Useful Post:
Banned | Posts: 388 | Thanked: 57 times | Joined on Mar 2010
#12
Originally Posted by Framstag View Post

I currently use the default, but liblocation allows time precision of 1,2, 5, 10, 20, 30, 60, 120 seconds. I can add this to the TODO list.
What is the default read rate? Less frequent reading would be ideal for some cases.

Yes time is already stored in the internal file format and thus can be added to the KML output. Do you have a link to a concrete example for how time is stored in KML?
See (from a simple timestamp kml search)
Time and Animation KML Documentation

Looking at white_shark.kml example your kml structure needs to be altered a bit (i.e. each time-stamp seemingly needs to be paired with space-coordinates) However this addition would make the tool more professional. Mapper might have time-stamping enable outputting option --looking at this blog. (Can't test mapper due to dependency issues during installation)

No problem with adding valid feature requests to the TODO list ;-) I think the time stuff should be the easiest one to add.
You could have a check-box type of option indicating to save a file with time-stamp (for its actual kml output name) It is always a good idea to save such location information with the beginning of the recording.
 
Banned | Posts: 388 | Thanked: 57 times | Joined on Mar 2010
#13
Hey,

I confirm another lat-long logging bug using the latest GPSJinni. It puts me way of on KML then what is actually be showing on. Do you have an e-mail. Maybe I can contact you privately so we could figure out problem on the actual recorded data.

Thanks.
 
Posts: 67 | Thanked: 36 times | Joined on May 2010 @ Claremont (LA), California
#14
It turns out that when gpsjinni exports a KML file, it swaps the latitude and longitude\ (putting the longitude first, while the convention is to put latitude first). I suspect that this very easily fixed bug is the cause of a lot of the problems people have been having.

Until the bug is fixed, the following script can be used to correct a saved KML file:

Code:
#!/bin/bash
#
# Fix a gpsjinni file that has swapped latitude/longitude information.
#
USAGE='Usage: fixjinni kml-files'

TMP=/tmp/fixjinni.$$
trap "rm -f $TMP; exit 1" 1 2 15
trap "rm -f $TMP; exit 0" 13

for file
do
    awk '{
	if ($1 == "</coordinates>")
	    {
	    incoords = 0
	    print
	    }
	else if ($0 ~ /<coordinates>/)
	    {
	    gt = index($0, ">")
	    prefix = substr($0, 1, gt)
	    suffix = substr($0, gt + 1)
	    if (suffix == "")
		{
		incoords = 1
		print
		next
		}
	    lt = index(suffix, "<")
	    coords = substr(suffix, 1, lt - 1)
	    suffix = substr(suffix, lt)
	    split(coords, data, ",")
	    print prefix data[2] "," data[1] "," data[3] suffix
	    }
	else if (incoords)
	    {
	    split($1, data, ",")
	    print "          " data[2] "," data[1] "," data[3]
	    }
	else
	    print
	}' \
      "$file" \
      > $TMP
    (trap "" 1 2 13 15; cp $TMP "$file")
    rm -f $TMP
done
 
Posts: 67 | Thanked: 36 times | Joined on May 2010 @ Claremont (LA), California
#15
My script above fixes KML files from the buggy gpsjinni, but it's not very helpful if (like me) you tagged a bunch of pictures and then deleted the KML files.

So here's another script. This one requires exiftool and only runs on Linux, but it will correct the tags in pictures that were incorrectly tagged with the buggy version. In the simplest form, you stick it in a directory somewhere, chmod +x geotagfix, and run:

./geotagfix -v *.jpg

(it also works on cr2 files, and can easily be modified to accept crw, Nikon NEF, and such--just expand the case statement).

But what if (like me) you tagged some stuff with tracks from gpsjinni and others correctly with tools like ecoach or mappero? Well, if (like me) you were at a place where the longitude is greater than 90 (or greater than the maximum latitude you reached), you can fix only files with obviously bad coordinates:

./geotagfix -v -m 90 *.jpg

The script could easily be fixed to look for a minimum/maximum legal longitude/latitude range, but it's late and what I did is enough for my needs. So that's left as an exercise for the reader. :-)

if you're paranoid, the -n switch will tell you what files would be fixed, but will do nothing else.

Enjoy!

Code:
#!/bin/bash
#
# Fix geotags that were incorrectly input by gpsjinni.  This code
# depends on the assumption that I'm beyond 90 degrees either east or
# west.
#
USAGE="Usage: geotagfix [-m maxlat] [-v] files

The given files have their GPS data extracted.  The latitudes and
longitudes are interchanged, and the files are rewritten with the new
data.

    -m maxlat	Specify the (integer) maximum latitude found anywhere
		in the files (default 0).  Only images with
		"latitudes" greater than this value will be rewritten.
		For example, if you are shooting in most of the United
		States, specify -l 90 to only swap pictures that have
		a latitude greater than or equal to 90 degrees (which is
		impossible in a correct file).  The default, -m 0,
		will swap the coordinates in all files; in this case
		you must ensure that all input files actually need
		correction.
    -n		Report files that would be fixed, but don't fix them.
    -v		Report changed files."

maxlat=0
action=true
verbose=false
while (( $# > 0 ))
do
    case "$1" in
	-m)
	    maxlat="$2"
	    shift
	    ;;
	-n)
	    action=false
	    ;;
	-v)
	    verbose=true
	    ;;
	--)
	    shift
	    break
	    ;;
	-*)
	    echo "$USAGE" 1>&2
	    exit 2
	    ;;
	*)
	    break
	    ;;
    esac
    shift
done

TMP=/tmp/geotagfix.$$
trap "rm -f $TMP.*; exit 1" 1 2 15
trap "rm -f $TMP.*; exit 0" 13

for pic
do
    case "$pic" in
	*.jpg|*.cr2)
	    ;;
	*)
	    continue
	    ;;
    esac
    exiftool "$pic" \
      | egrep GPS \
      | sed '/^GPS Date/s/:/-/g' \
      > $TMP.a
    lat=$(grep 'GPS Latitude *:' $TMP.a | awk '{print $4}')
    if (( lat >= $maxlat ))
    then
	# Picture needs coordinate swapping.  Since exiftool refuses to
	# let us rewrite GPS tags, we need to create a dummy KML file
	# and use it to geotag the picture.
	#latref=$(sed -n 's/GPS Longitude Ref *: *//p' $TMP.a)
	#longref=$(sed -n 's/GPS Latitude Ref *: *//p' $TMP.a)
	awk '
	    /^GPS Time / \
		{
		tm = $NF
		}
	    /^GPS Date / \
		{
		dt = $NF
		}
	    /^GPS Altitude / \
		{
		alt = $4
		}
	    /^GPS Latitude / \
		{
		# This is actually the longitude.  We take advantage
		# of the fact that if you add zero to a string, awk
		# converts it to a number while ignoring any trailing
		# non-numeric information (in this case, single and
		# double quotes).
		d = $4
		m = $6 + 0
		s = $7 + 0
		dir = $8
		long = d + m / 60.0 + s / 3600.0
		if (dir == "S")
		    long = -long
		}
	    /^GPS Longitude / \
		{
		# This is actually the latitude.  See above about awk
		# numeric conversions.
		d = $4
		m = $6 + 0
		s = $7 + 0
		dir = $8
		lat = d + m / 60.0 + s / 3600.0
		if (dir == "W")
		    lat = -lat
		}
	    END \
		{
		# Make a fake GPX file to feed to exiftool.  I was
		# originally making a KML file, but in the process of
		# working around the exiftool bug I switched to GPX
		# and I was too lazy to switch back (especially
		# because GPX is simpler).
		print "<?xml version=\"1.0\"?>"
		print "<gpx xmlns=\"http://www.topografix.com/GPX/1/1\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:ec=\"eCoachGPXExtensionsV1\" version=\"1.1\" creator=\"ecoach\" xsi:schemaLocation=\"http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd eCoachGPXExtensionsV1 /usr/share/ecoach/ec_gpx_ext_v1.xsd\">"
		print "<trk>"
		print "<name>Dummy</name>"
		print "<number>1</number>"
		print "<trkseg>"
		printf "<trkpt lat=\"%.12f\" lon=\"%.12f\">\n", lat, long
		printf "<ele>%.4f</ele>\n", alt
		printf "<time>%sT%sZ</time>\n", dt, tm
		print "</trkpt>"
		# A bug in exiftool requires at least two track points
		# with different times, else you get a divide by zero.
		# We hack this by faking a time far in the future.
		printf "<trkpt lat=\"%.12f\" lon=\"%.12f\">\n", lat, long
		printf "<ele>%.4f</ele>\n", alt
		print "<time>2038-01-01T00:00:00Z</time>"
		print "</trkpt>"
		print "</trkseg>"
		print "</trk>"
		print "</gpx>"
		}' \
	  $TMP.a \
	  > $TMP.gpx
	if $action
	then
	    exiftool -q -overwrite_original -geotag $TMP.gpx "$pic"
	    $verbose  &&  echo "Fixed $pic"
	else
	    echo "$pic needs fixing."
	fi
    fi
done

rm -f $TMP.*
 
Posts: 67 | Thanked: 36 times | Joined on May 2010 @ Claremont (LA), California
#16
Yet another easily fixed bug: when writing KML files, gpsjinni produces only 4 digits after the decimal point for latitude, and only 3 for longitude. This gives a maximum accuracy of +/- 111 meters in longitude at the equator, and +/- 11 meters in latitude; both less precise than GPS is capable of.

The KML file should offer at least 6 digits after the decimal point for both coordinates. (Ideally, the inaccuracy field, which GPSjinni already calculates, would also be included in the KML.)
 
Posts: 67 | Thanked: 36 times | Joined on May 2010 @ Claremont (LA), California
#17
I found the sources today, and wrote the following simple one-line patch, which both corrects the lat/long interchange and increases the precision of same. The patch is untested because I don't currently have a Maemo build environment. I hope somebody else can test it soon and post an updated build, because GPSjinni is the best tool I've found for geotagging pictures.

Code:
--- GPSJinni.cpp.orig   2010-09-27 16:22:37.000000000 +1300
+++ GPSJinni.cpp        2010-09-27 16:28:26.000000000 +1300
@@ -1594,7 +1594,8 @@
         alt=falt/100;
         time.SetTime(ftim);
 
-        out << "          " << lon << "," << lat << "," << alt << std::endl;
+        out << "          " << setprecision(8) << lat << "," << lon;
+        out << "," << setprecision(3) << alt << std::endl;
       }
     }

Last edited by gkuenning; 2010-09-27 at 03:41. Reason: Fix a typo.
 
Posts: 18 | Thanked: 1 time | Joined on Oct 2010
#18
I like GPSjinni, but I wanted to record my flight (airline) to check it later on, and it simply stopped working with certain speed (?). Is there any speed limitation in tracking?

It would be great to be able to follow directly on the map where the aircraft is just flying, for instance to identify mountains, lakes, or cities.

Anyway, thank you very much for your efforts.
 
Framstag's Avatar
Posts: 72 | Thanked: 51 times | Joined on Jul 2008 @ Germany
#19
Sorry for the late answer.

What does "stop" exactly mean? Note that for tracking there is no limit in speed since only a series of locations is recorded. There are some (to me known) problems with the charts where chart dimension calculation results into a internal busy loop maiing the application hang. Is this possibly what you are seeing. Else speed is handled as a double internally so this should not make any problem.

Drawing a map is difficult as there is no build in solution on the device for map drawing in applications. I'm however also the author of libosmscout (libosmscout.sf.net) withallows for offline map drawing (and routing) so integration of a map in in fact a long term goal. But this may take a while.

Note that I clearified the problem with "gkuenning" about the *.kml file format and it seems that GPSJinni is right and there was a bug in the tool that read the generated *.kml files.

Btw., the version in extras-devel has a (far) better compass and I soon will release a new version that also offers *.gpx export.
 
Reply


 
Forum Jump


All times are GMT. The time now is 09:55.