Imported Track Names

Former Member
Former Member
imported tracks are named:
ACTIVE LOG: dd mmm yyyy hh:mm
ACTIVE LOG: 04 AUG 2010 12:55

how about a simple change....

ACTIVE LOG: yyyy mm dd hh:mm
ACTIVE LOG: 2010 08 04 12:55

This is in keeping with the ASTM date format.
If the GPS wrote the names in that format it would solve a huge problem with sorting tracks that span different months in chronological order.

If they were named in ASTM date format the computer would automatically sort them in chronological order.

I figure this is probably not easily done within the desktop environment.

BUT

It seems the desktop developers could suggest something like this to the GPS software developers and it would sure make working with tracks so much easier for the end user.

Yes, it can be done by using a good text editor to find and replace.
This should just work easily within the Garmin software.

It's the lack of attention to little details like this that make working with Garmin's products soooooo frustrating.
  • Yes... you are right !

    And what about waypoints, tracks and routes listed "by distance" and not "by name" in the recent units?
    (E.g. Oregons)

    I think they want to simplify the user's experience...
    however, searching the object I need in these new units gives me headache !
    (Try to find a specific track among the archived tracks in an oregon... the naming is not so intuitive!)

    Andrew.
  • Former Member
    0 Former Member over 14 years ago
    We currently just take the name of the track in the device's GPX file:

    e.g.:
    <name>ACTIVE LOG: 19 MAR 2010 09:29</name>

    Some devices merely number the active log, and others may have different date formats, so it may be difficult to find a one size fits all solution. We've considered this issue before and will reevaluate to see what the best solution would be; thanks for the suggestion.
  • Former Member
    0 Former Member over 14 years ago
    All of the devices should write the names of the log files in the exact same format (ASTM).

    All throughout the Garmin line. Any other solution is ludicrous.
  • I would not think the Mac development team could do nothing more than request Garmin to change the way their GPSs name tracks. I would also think it would require a firmware update and produce all type of issues for third party apps supporting Garmin GPS. Looks like the simplest solution would be for BaseCamp to have a date time field in addition to symbol and name.

    While we are adding columns, how about a state provence column that is automatically filled from the coordination location. Route or tracks could use the starting states/provence.
  • Former Member
    0 Former Member over 14 years ago
    That's part of their problem, Too many models with too many different ways of doing things.

    Some serious basic communication between the hardware developers and the Desktop software developers, and some standardization of basic things could go a long way toward making their life easier, and would also go a long way toward making end user experience much better. Someone within Garmin needs to be in charge of making some standard methods that should always be adhered to, no exceptions.

    Another Example...(maybe this is partly fixed with the new BaseCamp?)

    Send a route to a Nuvi that does not support routes.
    BaseCamp will tell you route transferred successfully.

    BaseCamp should tell you something like "your unit does not support the transfer of routes". I wonder how many support calls they have received over that one? Support calls end up costing lots of money.

    The fact that the unit does not support routes should be contained in the device.xml file that all units write, and BaseCamp should be able to read that file and act accordingly.

    If BaseCamp had a Date and time field that would mean the software developers would need to write several different routines to parse the date out of the track logs. Since the track logs are not consistent from one unit to the other that would be not as easy as you think.

    The KISS principle can work if used consistently.
  • Former Member
    0 Former Member over 14 years ago
    Instead of putting the responsibility for the track log name format to be of a standard form - get the Basecamp developers to translate the track log name into a computer friendly format - it would be relatively easy - use a table to contain all the log name formats from the various Garmin devices with a translation formula to produce a sensible format.
    If the table is added correctly it could be external to the main code base and so could be updated very easily without a recompile. Or it could be made end user updateable.

    A design requirement to be put to the hardware developers that new formats are not to be encouraged and that the track log name should conform to an existing format unless they have a very good reason - in which the conversion table would have an additional entry made to it.
  • Former Member
    0 Former Member over 14 years ago
    They are already translating it into several different languages.

    ASTM date format was created because it is language independent and universally sorted by all computers. That kind of change could eliminate the maintenance of some existing code.

    Simplicity = lower cost to Garmin, and hopefully lower cost to the consumer.
  • Former Member
    0 Former Member over 14 years ago
    Updating Basecamp with a table lookup feature as described above is a one off coding effort and a table maintenance activity. And then all Basecamp user get the benefit immediately.

    Waiting for all the firmware to be updated to provide a better date format will take years and will only give benefit to Basecamp users with new products.
  • While I hate to put a damper to all this discussion of how easy this problem would be to fix if by making the hardware groups conform to a standard way of putting out track log names, the truth is that just isn't going to happen. If dealing with non-standard names was anywhere close to our biggest challenge in dealing with differences between Garmin GPSs, I would be very happy. If I was king for a day, I would start with making GPSs that don't accept routes tell us so. Problems like that don't have a good solution in desktop software.

    We will solve the track sorting issue by presenting user data in a table that will allow them to sort by any column the user wishes, including track date.
  • Former Member
    0 Former Member over 14 years ago
    Sounds good - so it would handle the date in Day Month Year sequencs and sort it into the correct calendar sequence

    When can you have it ready please