GPX time FLOAT_FMT*

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

GPX time FLOAT_FMT*

rnlnero
In gpx.c, is there a reason why the lat/long formats
are different for waypoints, routes, and tracks?
Waypoints use 9 decimal precision (%.9lf), whereas
routes and tracks default to 6 decimals (%lf).

The Lowrance USR format has route waypoints in two
lists -- the master waypoint list and the route list.
When loading, the Lowrance unit would cull the
aggregate waypoint list to remove duplicates based on
the lat/long coordinates.  Because of the different
precision used in gpx.c, when I convert lowranceusr ->
gpx -> lowranceusr, the routes waypoints end up being
duplicated because the lat/longs are different.

So, can I change gpx.c to standardize the lat/long
formats?

Ling
--


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: GPX time FLOAT_FMT*

Robert Lipe
Ling Nero wrote:

> In gpx.c, is there a reason why the lat/long formats
> are different for waypoints, routes, and tracks?

I'll plead incompetence and/or laziness.  I agree that inconsitency is
bad.

> Waypoints use 9 decimal precision (%.9lf), whereas
> routes and tracks default to 6 decimals (%lf).

Since there isn't a GPX-mandated standard here - and the difference is
way below the precision of any consumer grade coordinates anyway - part
of me says it just doesn't matter.  I added the FLOAT_FMT stuff becuase
I was working with someon else's GPX output and needed a way to exactly
mock their output.

> The Lowrance USR format has route waypoints in two
> lists -- the master waypoint list and the route list.
> When loading, the Lowrance unit would cull the
> aggregate waypoint list to remove duplicates based on
> the lat/long coordinates.  Because of the different
> precision used in gpx.c, when I convert lowranceusr ->
> gpx -> lowranceusr, the routes waypoints end up being
> duplicated because the lat/longs are different.

This is only the tip of that iceberg.  There are LOTS of different
formats that have slightly varying precision.  Converting from A->B->A
isn't guaranteed to be a lossless conversion.  For many formats,
converting from A->A won't return an identical file.

No matter how many digits you have, you're always going to have some
problems here.  Instead of comparing for FP equality in the duplicate
suppressor, can you make it a standard floating point "close enough"
test. i.e. instead of:

        if (a == b) ...
make it
        if (fabs(a-b) < .000001) ...

This assumes that ".000001" is your accepted definition of "close
enough", of course.

> So, can I change gpx.c to standardize the lat/long
> formats?

Is this a test suite need or a "real" need?  (Note that changing it
requires churn in many existing entries in our own test suite...)

If we left the default as it is and added an option to the GPX writer to
tweak that, would that work OK for you?

RJL


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: GPX time FLOAT_FMT*

rnlnero
Robert Lipe wrote:
>
> This is only the tip of that iceberg.  There are LOTS of different
> formats that have slightly varying precision.  Converting from A->B->A
> isn't guaranteed to be a lossless conversion.  For many formats,
> converting from A->A won't return an identical file.

Actually, Lowrance USR is one of them.

>
> No matter how many digits you have, you're always going to have some
> problems here.  Instead of comparing for FP equality in the duplicate
> suppressor, can you make it a standard floating point "close enough"
> test. i.e. instead of:
>
I don't have a duplicate suppressor.  The problem isn't specifically having
floating precisions "close enough;" the code doesn't really care what's the FP
precision.  The problem is the gpx code would convert an identical input
lat/long to different output lat/longs, depending on whether the lat/long are
associated with a waypoint or a route/track.  So while I agree A->B->A won't
get you the same A, I think in the case of A->B, the same A should always give
you the same B, not "close enough" B.  That is, identical coordinates should
experience the same lossiness.  As now, the same lat/long would convert to
(e.g.) <wpt lat="38.742112306" lon="-77.379782249"> but <rtept lat="38.742112"
lon="-77.379782">.  I think it should be one or the other, but not both.

>
> > So, can I change gpx.c to standardize the lat/long
> > formats?
>
> Is this a test suite need or a "real" need?  (Note that changing it
> requires churn in many existing entries in our own test suite...)

I'd like to think it's a real need.  If the GPX writer treats all lat/longs the
same way, it would cause no duplicates.  I'm actually surprised no one has seen
this as a problem before.  Maybe Lowrance is the only format with the same
waypoint info duplicated in its routes data.

>
> If we left the default as it is and added an option to the GPX writer to
> tweak that, would that work OK for you?

You mean like "-o gpx,sameprecision"?  That would work but oh so ugly :-)

Ling





-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: GPX time FLOAT_FMT*

Robert Lipe
> As now, the same lat/long would convert to (e.g.) <wpt
> lat="38.742112306" lon="-77.379782249"> but <rtept lat="38.742112"
> lon="-77.379782">.  I think it should be one or the other, but not both.

Thanx for the improved explanation.  Sigh.  You're right.

> Maybe Lowrance is the only format with the same waypoint info
> duplicated in its routes data.

There are a copule of formats that do it.  I guess we've never had
anybody "pitstop" data quite the way you're describing it.

> > If we left the default as it is and added an option to the GPX
> > writer to tweak that, would that work OK for you?
>
> You mean like "-o gpx,sameprecision"?  That would work but oh so ugly
> :-)

Oh, ok.  I'll take a patch that changes this if you fix the reference
files at the same time.  (Yes, this is me delegating. :-)

--
Support GPSBabel by helping to improve it or fund those that that have
done so.  Visit:

        http://sourceforge.net/donate/index.php?group_id=58972


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: GPX time FLOAT_FMT*

rnlnero
Robert Lipe wrote:

> Oh, ok.  I'll take a patch that changes this if you fix the reference
> files at the same time.  (Yes, this is me delegating. :-)

No problem, I'll do it.  What reference files are you talking about?  All the
.gpx files for testo?

I actually changed gpx.c to standardize on %.9lf and ran testo and not a peep
from it.

I should be able to send you a patch soon, along with new files for testo.

Ling
--



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: GPX time FLOAT_FMT*

Robert Lipe
Russ & Ling wrote:

> No problem, I'll do it.  What reference files are you talking about?  All the
> .gpx files for testo?

Yes.

> I actually changed gpx.c to standardize on %.9lf and ran testo and not a peep
> from it.

That's really odd.  If I set:


#define FLT_FMT_T "%.9lf"
#define FLT_FMT_R "%.9lf"

I get about a dozen different filures.

> I should be able to send you a patch soon, along with new files for testo.

Groovy.   Thanx.

--
Support GPSBabel by helping to improve it or fund those that that have
done so.  Visit:

        http://sourceforge.net/donate/index.php?group_id=58972


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
Reply | Threaded
Open this post in threaded view
|

Re: GPX time FLOAT_FMT*

rnlnero
Robert Lipe wrote:

> > I actually changed gpx.c to standardize on %.9lf and ran testo and not a
peep

> > from it.
>
> That's really odd.  If I set:
>
>
> #define FLT_FMT_T "%.9lf"
> #define FLT_FMT_R "%.9lf"
>
> I get about a dozen different filures.
>

That *is* odd.  The only difference is I compiled w/o the USB stuff (don't have
it on my system).  Would that make that much of a difference?

Ling
--



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Gpsbabel-code mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gpsbabel-code