DECLINED - [FEATURE] Garmin plugin cache uploads overwrite each other

[+frinklabs]

A number of the Etrex units can only handle six characters in the waypoint name.

 

Now caches contain seven characters, which get truncated when sent to the GPSr

 

For example, uploading GC32P5K to the unit would show as GC32P5 If I tried to subsequently send GC32P5W, it would delete the first sent waypoint and also show as GC32P5

 

This could be fixed with a checkbox programmed into the plugin to optionally remove the first and/or second character.

[knowschad]

A number of the Etrex units can only handle six characters in the waypoint name.

 

Now caches contain seven characters, which get truncated when sent to the GPSr

 

For example, uploading GC32P5K to the unit would show as GC32P5 If I tried to subsequently send GC32P5W, it would delete the first sent waypoint and also show as GC32P5

 

This could be fixed with a checkbox programmed into the plugin to optionally remove the first and/or second character.

 

Are you a GSAK user? If so, you can truncate it yourself. This is hardly a new problem. I would also not call it a bug. Perhaps an enhancement request.

[+frinklabs]

Are you a GSAK user?

 

Sort of... My nag screen is up to 420 seconds. Weird how that is the upper-limit number. Or is it? ;-)

 

This is hardly a new problem. I would also not call it a bug. Perhaps an enhancement request.

 

Wikipedia would define it as a bug

 

(incorrect or unexpected result)

 

The plugin does not indicate that it will only work with a subset of Garmin products. I wouldn't consider a programmatic change to make something work as it should as an "enhancement request" (unless I was Microsoft).

 

If it's so easy to do in GSAK, how hard could it be to do in the plugin?

[+Mos_CH]

 

Wikipedia would define it as a bug

 

(incorrect or unexpected result)

 

The plugin does not indicate that it will only work with a subset of Garmin products. I wouldn't consider a programmatic change to make something work as it should as an "enhancement request" (unless I was Microsoft).

 

If it's so easy to do in GSAK, how hard could it be to do in the plugin?

 

If your car has a fuel-tank with a capacity of 20 gal, do you consider it as a bug of the filling-station, when you are allowed to buy 30 gal of fuel, even when 10 gal are flooding the road?

 

Your old GPSr is the bug, not the plugin (...it's also Garmin, not Groundspeak).

 

If you'll tell me "the filling-station stops after 20 gal", I'll answer "the GPS stops after 6 characters". Full is full!

 

Greetings from Central Switzerland

[+frinklabs]

If your car has a fuel-tank with a capacity of 20 gal, do you consider it as a bug of the filling-station, when you are allowed to buy 30 gal of fuel, even when 10 gal are flooding the road?

 

Definitely a bug. In the pump. They are all supposed to detect when the tank is full and shut off automatically to prevent exactly the scenario you describe.

 

Your old GPSr is the bug, not the plugin (...it's also Garmin, not Groundspeak).

 

Without seeing the actual plugin code, I'd have to say its Groundspeak. Garmin provides the hardware layer interface to their device, while Groundspeak passes parameters to that layer for uploading into the device. The plugin won't send the information unless there is a GPSr present, so there must be two-way communication happening.

 

Again, how difficult could it be, programming-wise?

[jholly]

If your car has a fuel-tank with a capacity of 20 gal, do you consider it as a bug of the filling-station, when you are allowed to buy 30 gal of fuel, even when 10 gal are flooding the road?

 

Definitely a bug. In the pump. They are all supposed to detect when the tank is full and shut off automatically to prevent exactly the scenario you describe.

 

Your old GPSr is the bug, not the plugin (...it's also Garmin, not Groundspeak).

 

Without seeing the actual plugin code, I'd have to say its Groundspeak. Garmin provides the hardware layer interface to their device, while Groundspeak passes parameters to that layer for uploading into the device. The plugin won't send the information unless there is a GPSr present, so there must be two-way communication happening.

 

Again, how difficult could it be, programming-wise?

But Garmin is the supplier of the plugin, not Groundspeak. So why don't you go bug Garmin?

[+dfx]

Without seeing the actual plugin code, I'd have to say its Groundspeak. Garmin provides the hardware layer interface to their device, while Groundspeak passes parameters to that layer for uploading into the device. The plugin won't send the information unless there is a GPSr present, so there must be two-way communication happening.

 

Groundspeak provides the data in form of an XML/GPX document to the Garmin plugin. The Garmin plugin reads that data, communicates with the devices and sends the information over. Groundspeak has no way of knowing whether there's a device connected, what kind of device it is, or whether the transfer was successful.

 

Of course you could still have an option for them to generate the GPX with a shortened waypoint name. But every user would have to know by themselves if they need that or not. Worst case would be that somebody enables this option and owns a modern paperless GPS, which would cause the recording of field notes to fail. Now that would be a bug!

[+frinklabs]

But Garmin is the supplier of the plugin, not Groundspeak. So why don't you go bug Garmin?

 

Garmin supplies the API for the plugin. Groundspeak passes the parameters to that API to be sent to the device.

 

Garmin knows nothing about the format of a GC code.

 

Garmin does not program the "send to gps" button on the Groundspeak website.

 

Groundspeak would have to massage the data before it gets to the API. By including a button that says "Check here to remove GC from your uploaded waypoint"

[Moun10Bike]

As others have indicated, the plugin is coded by Garmin. We have no knowledge of what the target device is. The only thing Groundspeak could do is redesign GC codes to be a maximum of 6 characters long, and that's not going to happen.

[knowschad]

If your car has a fuel-tank with a capacity of 20 gal, do you consider it as a bug of the filling-station, when you are allowed to buy 30 gal of fuel, even when 10 gal are flooding the road?

 

Definitely a bug. In the pump. They are all supposed to detect when the tank is full and shut off automatically to prevent exactly the scenario you describe.

 

Your old GPSr is the bug, not the plugin (...it's also Garmin, not Groundspeak).

 

Without seeing the actual plugin code, I'd have to say its Groundspeak. Garmin provides the hardware layer interface to their device, while Groundspeak passes parameters to that layer for uploading into the device. The plugin won't send the information unless there is a GPSr present, so there must be two-way communication happening.

 

Again, how difficult could it be, programming-wise?

But Garmin is the supplier of the plugin, not Groundspeak. So why don't you go bug Garmin?

Actually, since the same plugin works perfectly fine on newer models, the "bug" would be that the GPSr is truncating what is sent to it.

[knowschad]

Are you a GSAK user?

 

Sort of... My nag screen is up to 420 seconds.

 

There is a fix for that.

[+frinklabs]

As others have indicated, the plugin is coded by Garmin. We have no knowledge of what the target device is. The only thing Groundspeak could do is redesign GC codes to be a maximum of 6 characters long, and that's not going to happen.

 

That's not what was requested. The thread title was changed.

 

If you actually read my original post, I asked for an option to manually truncate the codes myself before downloading them. Having it optional and manual would not affect anyone who didn't put a checkmark in the little box to truncate the GC off the waypoint.

 

Like in GSAK. But for free.

 

EDIT: For the record, this is what the thread title was, before it was changed (i.e. Han shot first):

 

[bUG] Garmin plugin cache uploads overwrite each other

Edited November 9, 2011 by frinklabs

[Moun10Bike]

Okay, I edited your title back. However, with limited resources we are not likely going to take on a project supporting a niche feature needed by out-of-date GPS receivers.

[+frinklabs]

Okay, I edited your title back. However, with limited resources we are not likely going to take on a project supporting a niche feature needed by out-of-date GPS receivers.

 

Send me the source code and I'll see if I can do it for you.