Menu

Main Menu
Talk Get Daily Search

Member's Online

    User Name
    Password

    Problem with GPSJinni kml output

    Reply
    Page 2 of 2 | Prev |   1   2 |
    Framstag | # 11 | 2010-04-21, 06:08 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks
    The Following User Says Thank You to Framstag For This Useful Post:
    gold_dragon

     
    gsever | # 12 | 2010-04-21, 07:42 | Report

    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.

    Originally Posted by
    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)

    Originally Posted by
    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    gsever | # 13 | 2010-04-28, 18:39 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    gkuenning | # 14 | 2010-09-24, 11:40 | Report

    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

    Edit | Forward | Quote | Quick Reply | Thanks

     
    gkuenning | # 15 | 2010-09-24, 13:35 | Report

    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.*

    Edit | Forward | Quote | Quick Reply | Thanks

     
    gkuenning | # 16 | 2010-09-25, 04:21 | Report

    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.)

    Edit | Forward | Quote | Quick Reply | Thanks

     
    gkuenning | # 17 | 2010-09-27, 03:34 | Report

    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;
           }
         }

    Edit | Forward | Quote | Quick Reply | Thanks

    Last edited by gkuenning; 2010-09-27 at 03:41. Reason: Fix a typo.

     
    gold_dragon | # 18 | 2010-10-13, 22:03 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Framstag | # 19 | 2010-10-19, 06:32 | Report

    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.

    Edit | Forward | Quote | Quick Reply | Thanks

     
    Page 2 of 2 | Prev |   1   2 |
vBulletin® Version 3.8.8
Normal Logout