Proximity Alerts

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proximity Alerts

Manuel Kaufmann
Hi people,

I've been trying to make Proximity Alerts work on my Garmin nüvi 265w
device with no luck for some time and today I posted my problem in the
OpenStreetMap forum [1]

Thanks to that, I received some links coming from Twitter and other
places that help me to find a half solution, but I think there is a
problem in GPSBabel or there are something that it's not clear. At least
for me.

Before writing a post in my blog about "How I did it" I want to ask you
some things to clarify my situation.

The only way I make Proximity Alerts work was by adding the Garmin GPX
extension <gpxx:Proximity>, this means the GPSBabel option
"proximity=70" doesn't work for me. So, for each <wpt> in the GPX file I
added this:

     <extensions>
       <gpxx:WaypointExtension
xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3">
         <gpxx:Proximity>70</gpxx:Proximity>
         <gpxx:DisplayMode>SymbolAndName</gpxx:DisplayMode>
       </gpxx:WaypointExtension>
     </extensions>

After doing that, this command works properly and I get Proximity Alarm
when I'm about 70 meters from those points:

gpsbabel -i gpx -f traffic_calming.gpx -o
garmin_gpi,category="traffic_calming",alerts=1 -F
traffic_calming_gpsbabel.gpi

Now, if I want Proximity Alert + Speed Alert I use "@XX" as suffix in
the name of the <wpt> as the official's Garmin documentation says. Like
this:

     <name>Traffic Calming 01@20</name>

Using this, I get the sonar alarm + visual alarm (saying that I'm going
faster than allowed)

So, why I can't make "proximity=70" nor "speed=20" work from GPSBabel
command line?

-----

Another issue I'm having is with the "bitmap" option. I'm using a 24x24
px and 24-bit BMP image with Magenta as transparent color but I'm not
getting the alpha in my Garmin device. On the other hand, if I use (0,
255, 0) that color is displayed as yellow for some reason.

I also tried with 32-bit with no luck :(

What else I can try to make it work?

I will appreciate a lot your help. Please let me know if you need more
information from my side.

[1] http://forum.openstreetmap.org/viewtopic.php?pid=574906


--

Kaufmann Manuel
-- http://elblogdehumitos.com.ar/

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Robert Lipe-4


On Tue, Feb 2, 2016 at 9:31 PM, Manuel Kaufmann <[hidden email]> wrote:
Hi people,

I've been trying to make Proximity Alerts work on my Garmin nüvi 265w
device with no luck for some time and today I posted my problem in the
OpenStreetMap forum [1]

Thanks to that, I received some links coming from Twitter and other
places that help me to find a half solution, but I think there is a
problem in GPSBabel or there are something that it's not clear. At least
for me.

Garmin GPI is a bit of a mess and it looks like you've found a bug that's been there at least ten years. Looking at the code, I can't say I can explain it, but at least I can show my work.

 
The only way I make Proximity Alerts work was by adding the Garmin GPX
extension <gpxx:Proximity>, this means the GPSBabel option
"proximity=70" doesn't work for me. So, for each <wpt> in the GPX file I
added this:

     <extensions>
       <gpxx:WaypointExtension
xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3">
         <gpxx:Proximity>70</gpxx:Proximity>
         <gpxx:DisplayMode>SymbolAndName</gpxx:DisplayMode>
       </gpxx:WaypointExtension>
     </extensions>

After doing that, this command works properly and I get Proximity Alarm
when I'm about 70 meters from those points:

gpsbabel -i gpx -f traffic_calming.gpx -o
garmin_gpi,category="traffic_calming",alerts=1 -F
traffic_calming_gpsbabel.gpi

Exercising our reader with our writer can be a bit dangerous, but testing gpi is, as I'm sure you've learned, a pain.  The good news is that you're not losing your mind. The bad news is that we screwed up.

Let's start with a test file with values that are easy to recognize.

$ cat mk
lat, lon, prox, speed
36, -87, 70, 40

Let's prove we can read and write this, meaning that everything lands in our internal data structures sensibly.

./gpsbabel -i  unicsv -f mk -o unicsv -F -
No,Latitude,Longitude,Name,Proximity,Speed
1,36.000000,-87.000000,"WPT001",70,40.00

Jolly good.

Now let's write that to a GPI and read it back.

./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts -F one ; ./gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

Not entirely lossless which isn't surprising given the dumb way that data is stuff in the waypoint name, but at least the key values made it. Let's try command line overrides.

./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43 -F one ; ./gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@43","WPT001","Waypoint",7464

no combination of meters to feet that I can think of explains 73 becoming 7464, so we probably misparsed it.

 
Now, if I want Proximity Alert + Speed Alert I use "@XX" as suffix in
the name of the <wpt> as the official's Garmin documentation says. Like
this:

     <name>Traffic Calming 01@20</name>

Using this, I get the sonar alarm + visual alarm (saying that I'm going
faster than allowed)

So, why I can't make "proximity=70" nor "speed=20" work from GPSBabel
command line?

I'm on my way to bed, but I think we're mishandling at least 'speed' command line argument.  Reading and writing the files as above, does that match your observation? If we're blowing it up that badly, it's likely that you can get a speed of 20mph on your bike but not 7464. (I'm not even certain what the default units are; I'm just saying that being off a factor of 30 is unlikely to be good.)



Another issue I'm having is with the "bitmap" option. I'm using a 24x24
px and 24-bit BMP image with Magenta as transparent color but I'm not
getting the alpha in my Garmin device. On the other hand, if I use (0,
255, 0) that color is displayed as yellow for some reason.

I also tried with 32-bit with no luck :(

What else I can try to make it work?

This has always been problematic with Garmin bitmaps. Different devices do transparency differently. Their own code presumably knows which devices do which and how to handle them, but it's a nuance we've not reverse engineered.

Try letting the Garmin code generate the GPI for your device with a single point, as above. Then read the GPI and find the color values and format it used.


Yes, this is all a terrible mess. Garmin built these devices that read GPX, built GPX extensions for all this, but then use this goofy binary file format that they've not documented. Sorry.

So I'll look at our parsing of the speed line, but please confirm the exact commands and provide repro cases so I'm not looking int he GPI writer when the problem is in the GPX reader, for example.  Please use simple data sets and not every traffic sign in your country, too, please. 

RJL

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Manuel Kaufmann
Thank a lot for your answer.

Reading your email made me feel happy and not so stupid. It was driving
me crazy and now I hate GPI and Garmin as anything else in the world :P

El 02/02/16 a las 23:30, Robert Lipe escribió:
> On Tue, Feb 2, 2016 at 9:31 PM, Manuel Kaufmann <[hidden email]
> Garmin GPI is a bit of a mess and it looks like you've found a bug
> that's been there at least ten years. Looking at the code, I can't say I
> can explain it, but at least I can show my work.

Just in case, can you point me to the part of code that work on this?
I'm not sure if I will understand it but I will try.

> ./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts -F one ; ./gpsbabel -i
> garmin_gpi -f one -o unicsv -F -
> No,Latitude,Longitude,Name,Description,Symbol,Proximity
> 1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

I see something weird here. It says WPT001@144, and if I'm not wrong, it
should say WPT001@40 instead. It supposed that @XX means the speed, and
in the "mk" file you have 40 not 144.

> ./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43 -F
> one ; ./gpsbabel -i garmin_gpi -f one -o unicsv -F -
> No,Latitude,Longitude,Name,Description,Symbol,Proximity
> 1,36.000000,-87.000000,"WPT001@43","WPT001","Waypoint",7464

I've got something different here. Take a look:

$ gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43 -F
one ; gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70
$

In [1] there is a formula that I'm not sure to understand properly,
maybe we have the answer regarding the strange number there:

    Prompt Distance = 36 seconds * Speed.

> I'm on my way to bed, but I think we're mishandling at least 'speed'
> command line argument.  Reading and writing the files as above, does
> that match your observation? If we're blowing it up that badly, it's
> likely that you can get a speed of 20mph on your bike but not 7464. (I'm
> not even certain what the default units are; I'm just saying that being
> off a factor of 30 is unlikely to be good.)

I'm going bed also, I'm on GMT-5, but I wanted to leave you a gift for
your tomorrow's morning ;)

> This has always been problematic with Garmin bitmaps. Different devices
> do transparency differently. Their own code presumably knows which
> devices do which and how to handle them, but it's a nuance we've not
> reverse engineered.

This is not so important right now. Let's focus on the other thing first.

I didn't try as many things as I could. So, I have some things more to
try before go deeper on this.

Anyway, Garmin Official docs[1] says: "Transparency color is magenta
RGB: R=255, G=0, B=255" but "8 or 16 bit RGB color palette" and GPSBabel
only allows 24 and 32 bits which is suspect...

[1] http://www8.garmin.com/products/poiloader/creating_custom_poi_files.jsp

> So I'll look at our parsing of the speed line, but please confirm the
> exact commands and provide repro cases so I'm not looking int he GPI
> writer when the problem is in the GPX reader, for example.  Please use
> simple data sets and not every traffic sign in your country, too, please.

I'm using simple data created by hand (only 5 points). These are my
files used in my tests:

  * OSM file generated with JOSM with 5 <wpt>:
linkode.org/kMT6kwYIclFMm1014HjWe7

gpsbabel -i osm -f traffic_calming.osm -o gpx -F traffic_calming.gpx

  * GPX generated with GPSBabel and modified by me to add the Garmin
extensions: http://linkode.org/sAJYKBbpJhHzEpeTCTGOG7

Thanks a lot for your time,

PS: I'm pasting here the same steps you run in this email to see my output:

$ gpsbabel | head -n 1

GPSBabel Version 1.4.3.  http://www.gpsbabel.org

$ cat mk
lat, lon, prox, speed
36, -87, 70, 40

$ gpsbabel -i  unicsv -f mk -o unicsv -F -
No,Latitude,Longitude,Name,Proximity,Speed
1,36.000000,-87.000000,"WPT001",70,40.00

$ gpsbabel -i unicsv -f mk -o garmin_gpi,alerts -F one ; gpsbabel -i
garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

$ gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43 -F
one ; gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

$


--

Kaufmann Manuel
-- http://elblogdehumitos.com.ar/

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Manuel Kaufmann
El 03/02/16 a las 02:00, Francois Visagie escribió:
> Your workflow and input/output formats aren't quite clear to me,

What is not clear for you?

> but you may want to investigate using MapSource in the toolchain. I
> was able to make proximity alerts work on my 276C by correspondingly
> setting the Waypoint Proximity property in MapSource, and then
> uploading the results to the GPSr.

I have some GPX files generated with MapSource by other people and I can
see that MapSource adds the <extensions> with the proximity tag to the
GPX. That why I added it by hand to my own GPX files.

> You can still do further
> pre/post-processing or conversion with GPSBabel, of course.

Yes, that is what I did after added the extensions by hand. I created
the GPI file using GPSBabel finally and that is the one I'm using in the
Garmin device.

Thanks,

PD: I added the GPSBabel mailinglist to To: again because we loose it in
your reply

--

Kaufmann Manuel
-- http://elblogdehumitos.com.ar/

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Robert Lipe-4
In reply to this post by Manuel Kaufmann


On Tue, Feb 2, 2016 at 11:37 PM, Manuel Kaufmann <[hidden email]> wrote:
Thank a lot for your answer.

Reading your email made me feel happy and not so stupid. It was driving me crazy and now I hate GPI and Garmin as anything else in the world :P

Oh, that's totally the place to calibrate your rage. :-)

 

El 02/02/16 a las 23:30, Robert Lipe escribió:
On Tue, Feb 2, 2016 at 9:31 PM, Manuel Kaufmann <[hidden email]
Garmin GPI is a bit of a mess and it looks like you've found a bug
that's been there at least ten years. Looking at the code, I can't say I
can explain it, but at least I can show my work.

Just in case, can you point me to the part of code that work on this? I'm not sure if I will understand it but I will try.

Even if you can't -write- code, reading it is kind of like reading Romance languages. The punctuation and squigglies may throw you, but a little bit of latin will get you far...

gpx.cc is the gpx reader and writer.
garmin_gpi.cc is the garmin_gpi reader and writer.
unicsv.cc is the unicsv reader and writer.

Are you seeing the pattern yet? :-)  OK, not EVERY format follows that scheme, but these do.




./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts -F one ; ./gpsbabel -i
garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

I see something weird here. It says WPT001@144, and if I'm not wrong, it should say WPT001@40 instead. It supposed that @XX means the speed, and in the "mk" file you have 40 not 144.

Actually, that IS a units breakdown.
40 meters per second is 144km/h

Our internal thing that holds this (search for 'float speed' in defs.h) is "meters per second". So we're reading 40 meters per second in unicsv and that's what we're passing to the garmin gpi writer, but the code in garmin_gpi.cc::read_tag()  that makes up the name (search for "QString base")  is formatting the thing after the @ as KPH.

This is kind of like our stuff with character encodings. It's just a very meticulous process of checking every step because each piece in isolation is "right", but it's very easy to lose the units markup along the way.

If you make the "40" in the file named after your intials into "40kmh", it shows as 40 here.  So I think that's WAI.

 


./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43 -F
one ; ./gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@43","WPT001","Waypoint",7464

I've got something different here. Take a look:

$ gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43 -F one ; gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70
$

In [1] there is a formula that I'm not sure to understand properly, maybe we have the answer regarding the strange number there:

   Prompt Distance = 36 seconds * Speed.

I'm on my way to bed, but I think we're mishandling at least 'speed'
command line argument.  Reading and writing the files as above, does
that match your observation? If we're blowing it up that badly, it's
likely that you can get a speed of 20mph on your bike but not 7464. (I'm
not even certain what the default units are; I'm just saying that being
off a factor of 30 is unlikely to be good.)

I'm going bed also, I'm on GMT-5, but I wanted to leave you a gift for your tomorrow's morning ;)

I'm UTC-6  (Nashville, TN area...) but am a night owl where GPSBabel is concerned.

PS: I'm pasting here the same steps you run in this email to see my output:

$ gpsbabel | head -n 1

GPSBabel Version 1.4.3.  http://www.gpsbabel.org

Actually, in the name of our collective sanity, could you please use a current version? 1.4.3 is from 2011.  I'd hate to think we're debugging something we fixed four years ago.  Did the GUI really not prompt you to upgrade or are you just not a GUI user?





 
$ cat mk
lat, lon, prox, speed
36, -87, 70, 40

$ gpsbabel -i  unicsv -f mk -o unicsv -F -
No,Latitude,Longitude,Name,Proximity,Speed
1,36.000000,-87.000000,"WPT001",70,40.00

$ gpsbabel -i unicsv -f mk -o garmin_gpi,alerts -F one ; gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

$ gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43 -F one ; gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70


Actually, now that we have the units knocked out and we get past the ambiguities of "what happens if you have both a speed in your xcsv (like we do) and on the command line (like we do)  that doesn't seem flagrantly wrong.

Please get on a current version (keep your old one if it's convenient) and let's resync.

RJL

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Manuel Kaufmann
El 03/02/16 a las 12:29, Robert Lipe escribió:
> Even if you can't -write- code, reading it is kind of like reading
> Romance languages. The punctuation and squigglies may throw you, but a
> little bit of latin will get you far...
> our source is at https://github.com/gpsbabel/gpsbabel

Well, I'm a Python software developer but it's too much easier than C or
C++. Last time I saw C++ was like 10 years ago...

Anyway, I wanted to be sure that I was taking a look at the right
section of the code, even the respository :)

I will do my best to try to understand it.

> Our internal thing that holds this (search for 'float speed' in defs.h)
> is "meters per second". So we're reading 40 meters per second in unicsv
> and that's what we're passing to the garmin gpi writer, but the code in
> garmin_gpi.cc::read_tag()  that makes up the name (search for "QString
> base")  is formatting the thing after the @ as KPH.

Ok, we should change this behaviour here and also update the
documentation of unicsv to specify the default unit:

    http://www.gpsbabel.org/htmldoc-development/fmt_unicsv.html

> If you make the "40" in the file named after your intials into "40kmh",
> it shows as 40 here.  So I think that's WAI.

Just to be sure, I tried this (with the old gpsbabel version) and it
works as you said:

$ cat mk
lat, lon, prox, speed
36, -87, 70, 40kmh

$ gpsbabel | head -n 1

GPSBabel Version 1.4.3.  http://www.gpsbabel.org
$

$ gpsbabel -i  unicsv -f mk -o unicsv -F -
No,Latitude,Longitude,Name,Proximity,Speed
1,36.000000,-87.000000,"WPT001",70,11.11

$ gpsbabel -i unicsv -f mk -o garmin_gpi,alerts -F one ; gpsbabel -i
garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@40","WPT001","Waypoint",70

> Actually, in the name of our collective sanity, could you please use a
> current version? 1.4.3 is from 2011.  I'd hate to think we're debugging
> something we fixed four years ago.Did the GUI really not prompt you to
> upgrade or are you just not a GUI user?

I'm not a GUI user. In fact, I didn't know it has one :)

I just compiled the 1.5.3 (downloaded the tar.gz from the official
website) and I will repeat the steps here:

$ ./gpsbabel | head -n 1

GPSBabel Version 1.5.3.  http://www.gpsbabel.org
$

$ cat mk
lat, lon, prox, speed
36, -87, 70, 40

$ ./gpsbabel -i  unicsv -f mk -o unicsv -F -
No,Latitude,Longitude,Name,Proximity,Speed
1,36.000000,-87.000000,"WPT001",70,40.00

$ ./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts -F one ; gpsbabel -i
garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

$ ./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=73,speed=43
-F one ; gpsbabel -i garmin_gpi -f one -o unicsv -F -
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@144","WPT001","Waypoint",70

Also, with this version of gpsbabel I don't see your "7464" number
anywhere...

> Please get on a current version (keep your old one if it's convenient)
> and let's resync.

Should I compile the git version?

So, what's the next step? I'm a little confused now. The specific
problem here is that command-line options are being ignored when they
should override the other ones, right?

Thanks a lot for your time.


--

Kaufmann Manuel
-- http://elblogdehumitos.com.ar/

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Robert Lipe-4
Our internal thing that holds this (search for 'float speed' in defs.h)
is "meters per second". So we're reading 40 meters per second in unicsv
and that's what we're passing to the garmin gpi writer, but the code in
garmin_gpi.cc::read_tag()  that makes up the name (search for "QString
base")  is formatting the thing after the @ as KPH.

Ok, we should change this behaviour here and also update the documentation of unicsv to specify the default unit:

Agreed. 


Should I compile the git version?

1.5.3 isn't that old and I've been trying to make a 1.5.4.

 
So, what's the next step? I'm a little confused now. The specific problem here is that command-line options are being ignored when they should override the other ones, right?
 
It looks like that's intended behaviour in the gpi writer.

      if ((opt_proximity) && (! WAYPT_HAS(wpt, proximity))) {

It's a little more tangly above that, and it's seriously weird that 'compute size' modifies the waypoint, but it looks like if you have a speed on individual points (as we do in our unicsv file - easily experimented with by mangling the spelling of the headers) that's used in preference to the command line value that's in opt_proximity.

That makes some sense.  If you have no data, that's an easy way to provide it.  If only some have the data, that's an easy way to fill it in, but not clobber what you have.

I have little confidence that our doc actually SAYS this.  The (German-native) author of this module was more valuable as a coder than a writer.   I'll try to fill in the learnings of this discussion so the next person won't have to stare at source and play "guess the unit" when putting numbers in places.

I'll add that to the 1.5.4 list.

RJL

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Manuel Kaufmann
El 03/02/16 a las 14:46, Robert Lipe escribió:
> That makes some sense.  If you have no data, that's an easy way to
> provide it.  If only some have the data, that's an easy way to fill
> it in, but not clobber what you have.

Yes, I agree with you on this.

BUT there is also another case that is not working: when you have no
data at all in your GPX file and you want to add it by command-line,
remember? That was my first example.

After no luck with that, I tried by adding the <extension> by hand, but
I'm sure that is not the way we want to go. I expect gpsbabel does that
for me if I'm using "-o speed=90,proximity=200m"

> I'll add that to the 1.5.4 list.

Cool.

Thanks,

--

Kaufmann Manuel
-- http://elblogdehumitos.com.ar/

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proximity Alerts

Robert Lipe-4
OK, we start with no data and then we add it via the command line.

rjlimac7:gpsbabel robertlipe$ cat mk
lat, lon, xrox, xpeed
36, -87, 70, 40kmh
rjlimac7:gpsbabel robertlipe$ make &&  ./gpsbabel -i unicsv -f mk -o garmin_gpi,alerts,proximity=200m,speed=90 -F one ; ./gpsbabel -i garmin_gpi -f one -o unicsv -F -
make: Nothing to be done for `all'.

No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@90","WPT001","Waypoint",200

Perhaps something unique to the GPX reader? Let's make a GPX
./gpsbabel -i unicsv -f mk -o gpx -F mk.gpx
rjlimac7:gpsbabel robertlipe$ ./gpsbabel -i gpx -f mk.gpx -o garmin_gpi,alerts,proximity=200m,speed=90 -F one ; ./gpsbabel -i garmin_gpi -f one -o unicsv -F -garmin_gpi defproximity 0
Parse speed
Returned 25
scale 1000
set defproximity 200
defproximity 200
setting defproximity 200
garmin_gpi 25 200
Before 25
After 90
90
No,Latitude,Longitude,Name,Description,Symbol,Proximity
1,36.000000,-87.000000,"WPT001@90","WPT001","Waypoint",200

Somehow we're still talking past each other or they're acting differently on our systems.

RJL

On Wed, Feb 3, 2016 at 1:57 PM, Manuel Kaufmann <[hidden email]> wrote:
El 03/02/16 a las 14:46, Robert Lipe escribió:
That makes some sense.  If you have no data, that's an easy way to
provide it.  If only some have the data, that's an easy way to fill
it in, but not clobber what you have.

Yes, I agree with you on this.

BUT there is also another case that is not working: when you have no
data at all in your GPX file and you want to add it by command-line,
remember? That was my first example.

After no luck with that, I tried by adding the <extension> by hand, but
I'm sure that is not the way we want to go. I expect gpsbabel does that
for me if I'm using "-o speed=90,proximity=200m"

I'll add that to the 1.5.4 list.

Cool.

Thanks,


--

Kaufmann Manuel
-- http://elblogdehumitos.com.ar/


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gpsbabel-misc mailing list http://www.gpsbabel.org
[hidden email]
To unsubscribe, change list options, or see archives, visit:
https://lists.sourceforge.net/lists/listinfo/gpsbabel-misc
Loading...