Export EHPE as HDOP in gpx

[Michael Hofmann]

For exporting data from igotu to JOSM (Java OpenStreetMap Editor), it would be nice to export EHPE
as HDOP, provided HDOP is not available from igotu. I've noticed others do this as well for some
applications, e.g., EventLogger:
http://web.tiscali.it/macri/Event_Logger/Event_Logger.htm
It's more of correctness question than technical question, as the patch is actually quite simple:

hopet@kloboucek:~/igotu/trunk/igotu2gpx$ bzr diff
=== modified file 'src/gpxexporter/gpxexporter.cpp'
--- src/gpxexporter/gpxexporter.cpp 2009-10-26 19:31:00 +0000
+++ src/gpxexporter/gpxexporter.cpp 2009-11-06 20:39:23 +0000
@@ -115,6 +115,8 @@
                     << "</time>\n"
                 << xmlIndent(2) << "<sat>" << point.satellites().count()
                     << "</sat>\n"
+ << xmlIndent(2) << "<hdop>" << point.ehpe()
+ << "</hdop>\n"
                 << xmlIndent(1) << "</wpt>\n";
         }
     }
@@ -138,6 +140,8 @@
                     << "</sat>\n"
                 << xmlIndent(4) << "<speed>" << point.speed() / 3.6
                     << "</speed>\n"
+ << xmlIndent(4) << "<hdop>" << point.ehpe()
+ << "</hdop>\n"
                 << xmlIndent(3) << "</trkpt>\n";
         out << xmlIndent(2) << "</trkseg>\n";
         if (!tracksAsSegments)

[Michael Hofmann (mh21)]

Thanks for your question. I don't really know. EHPE will give you a different scale than HDOP, so I think at least some conversion between the scales should be done. Otherwise, I would be fine with a patch to implement this.

[hopet (hopet)]

The conversion would be needed of course - some comments are available, e.g., from here:
http://gpsinformation.net/main/epenew.txt
but as far as I know, we don't have have URA information available (except that some sources suggest URA < 10).
Btw, what's the meaning of MSVs_QCN and weight criteria? Couldn't that be used?

Another (and more clean) option would be to create extension like:
<extensions>
<ehpe unit="m">5</ehpe>
</extensions>
in analogy to what TrekBuddy does (GSM and NMEA extensions - but they also prefix it with their own namespace):

<?xml version='1.0' encoding='UTF-8' ?>
<gpx version="1.1" creator="TrekBuddy 0.9.89" xmlns="http://www.topografix.com/GPX/1/1" xmlns:nmea="http://trekbuddy.net/2009/01/gpx/nmea" xmlns:gsm="http://trekbuddy.net/2009/01/gpx/gsm">
  <trk>
    <trkseg>
      <trkpt lat="45.530174693" lon="-122.614001793">
        <ele>56.5</ele>
        <time>2009-11-15T16:48:16.431Z</time>
        <fix>3d</fix>
        <sat>4</sat>
        <extensions>
          <nmea:course>314.1</nmea:course>
          <nmea:speed>22.6</nmea:speed>
          <gsm:cellid>456</gsm:cellid>
        </extensions>
      </trkpt>

[hopet (hopet)]

More authoritative source on EHPE-HDOP conversion:
http://www.nps.gov/gis/gps/WhatisEPE.html

[Michael Hofmann (mh21)]

According to Mobileaction:
MSV: total number of found SV for this record?
QCN: qualified satellite number with C/N value > criteria?

But I did not check whether this is correct. Anyway, it doesn't really apply here. And I have no idea what the weight criteria actually does.

Putting most of the stuff we have in the gpx file in an extension is actually a good idea. Would this be enough for you, because then scaling doesn't matter?

[hopet (hopet)]

The only thing is use of this information by the third-party software - but I can also write a patch for JOSM, but the question is whether it's going to be accepted or not.

I've received information from Mobileaction (http://www.a-trip.com/forum/viewtopic.php?t=1141), that HDOP is not recorded by the device now and I assume they are getting the EHPE information directly from the GPS chip and thus doing no HDOP<->EHPE conversion on their own.

[hopet (hopet)]

I've committed the extended GPX export into a new branch:
bzr push lp:~hopet/igotu2gpx/extended-gpx

HTH. Please check whether it's OK for you.

[Michael Hofmann (mh21)]

This should land in 0.4.0. Thanks hopet! I was not able to find the source code for the change (https://code.edge.launchpad.net/~hopet/igotu2gpx/extended-gpx does not show any commits related to this), are you sure that you pushed your changes to launchpad?

[hopet (hopet)]

Michael,

I've used the bzr push command but probably haven't commited it
(I'm using CVS/SVN and have very little experience with bzr).
I did bzr commit now and the changes should be in revision 183.

HTH,
Petr

> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Michael Hofmann
> Sent: Wednesday, January 13, 2010 2:05 PM
> To: <email address hidden>
> Subject: [Bug 484667] Re: Export EHPE as HDOP in gpx
>
> This should land in 0.4.0. Thanks hopet! I was not able to find the
> source code for the change
> (https://code.edge.launchpad.net/~hopet/igotu2gpx/extended-gpx does not
> show any commits related to this), are you sure that you pushed your
> changes to launchpad?
>
> ** Changed in: igotu2gpx
> Milestone: None => 0.4.0
>
> --
> Export EHPE as HDOP in gpx
> https://bugs.launchpad.net/bugs/484667
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in MobileAction i-gotU USB GPS travel logger Mac/Linux support: New
>
> Bug description:
> For exporting data from igotu to JOSM (Java OpenStreetMap Editor), it would be nice to export
> EHPE
> as HDOP, provided HDOP is not available from igotu. I've noticed others do this as well for
> some
> applications, e.g., EventLogger:
> http://web.tiscali.it/macri/Event_Logger/Event_Logger.htm
> It's more of correctness question than technical question, as the patch is actually quite
> simple:
>
> hopet@kloboucek:~/igotu/trunk/igotu2gpx$ bzr diff
> === modified file &#039;src/gpxexporter/gpxexporter.cpp&#039;
> --- src/gpxexporter/gpxexporter.cpp 2009-10-26 19:31:00 +0000
> +++ src/gpxexporter/gpxexporter.cpp 2009-11-06 20:39:23 +0000
> @@ -115,6 +115,8 @@
> << "</time>\n"
> << xmlIndent(2) << "<sat>" << point.satellites().count()
> << "</sat>\n"
> + << xmlIndent(2) << "<hdop>" << point.ehpe()
> + << "</hdop>\n"
> << xmlIndent(1) << "</wpt>\n";
> }
> }
> @@ -138,6 +140,8 @@
> << "</sat>\n"
> << xmlIndent(4) << "<speed>" << point.speed() / 3.6
> << "</speed>\n"
> + << xmlIndent(4) << "<hdop>" << point.ehpe()
> + << "</hdop>\n"
> << xmlIndent(3) << "</trkpt>\n";
> out << xmlIndent(2) << "</trkseg>\n";
> if (!tracksAsSegments)
>
>
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/igotu2gpx/+bug/484667/+subscribe