BaseCamp Wishlist

I'd like to see some more GPX choices for Export. I use BaseCamp to manage everything and the Etrex 30 handles the navigation. I augment these tools with a geocaching app on a smartphone because of the live network access to geocaching.com while I'm on the trails. I can post field notes and/or logs and manage trackables immediately while in the field. Plus search for caches near me, etc. The two devices augment each other very well.

So I export my list(s) to the smartphone app. The BaseCamp GPX export file does not import properly into the smartphone app. I have to load the GPX file into GPSBabel and export as GPX again and then the smartphone app is happy with it. If I take this GPSBabel file and import it into a BaseCamp list, BaseCamp and the Etrex do not display it properly. So I have to take the extra step of taking my exported lists through GPSBabel and saving a duplicate file before hitting the trail each time. This makes extra work that I shouldn't have to do.

Would it be possible to add a filetype option at the export stage to output a more generic version of the GPX file? I'm not interested in finger pointing; I just want all my toys to play nice together. ;)

What data doesn't get imported properly?

Could you provide examples of say one geocache exported by BaseCamp and then cleaned up for GPSBabel?

Sample Files

Originally Posted by FALAGAR " />">
What data doesn't get imported properly?

Could you provide examples of say one geocache exported by BaseCamp and then cleaned up for GPSBabel?





Sure. I have attached 2 files. One is the Export from BaseCamp. When imported into CacheSense software on my smartphone, the cache data is missing:
GC Code
No long description
No Logs
No Hint
No attached waypoint

If I just load and export from GSAK, I get the 'fixed' file, and it shows all these things correctly when I load it into CacheSense. It also displays properly if I import it back into BaseCamp.

The answer from the developer was, "The Basecamp GPX is not a valid GPX as far as CS is concerned as it does not use the Groundspeak namespace, you can probably import it into GSAK then export it for CacheSense?" And this is what's working.

Thank you for these files.

Yeah, it looks like we might be missing a namespace declaration. We are also writing version 1.0, GSAK writes version 1.0.1.

I created a case for this, but it might take a while to get this implemented.

If you are really bothered by this, you could write your own plugin to export into the proper format using BaseCamp's plug-ins: https://forums.garmin.com/showthread.php?13452-Data-Converter-Plugin-Development

It turns out either format is valid and should be handled by any client that handles GPX files. Unfortunately many/most don't, especially in embedded enviroments. Our format is customized to make our outdoor devices happy, because they don't like the groundspeak namespace at the top of the document. It sounds like this mobile app wants the opposite. In that conflict, the device will have to take precedence. Unfortunately it seems that you're stuck running it through GPS-Babel for now. Sorry for the inconvenience.

After a little more testing, BaseCamp imports Groundspeak files and it's own, of course. My Etrex 30 reads BaseCamp and Groundspeak GPX files, too. GSAK has an export choice of GPX 1.0 or 1.1 (not labeled as 1.01). Etrex 30 works with the 1.0 GSAK files but does not like the 1.1 output of GSAK. So far, so good. Everybody seems to import either namespace and either 1.0 or 1.01 GPX versions except the one third-party app that I'm using on my smartphone. That one only works properly with the Groudspeak namespace files.

Thanks for the input which pointed me to do more testing with various output version options. It's a little frustrating to have to buy a $30 program just to massage data formats between devices. Oh well, it is what it is.

Support import of KML files

Although BC is supposed to open KML and KMZ files, attempting to import a KML file results in no error but no imported data, either!

If I created a .kml file from Google, it would not load.
For instance, look at the PeninsulaCities.kml file that I attached. (i found instructions but cannot make them work. Help?)
When opened in a text editor it appears to be a well-formed xml file consisting of a bunch of waypoints.
But when I try to open it in BC, it 'appears' to be opening it and loading data, but nothing appears.
Any ideas what is wrong? Are google maps kml files "bad" somehow?
I just verified this with BC 4.0.5

I was told: open the kml file in Google Earth and save it as kmz; BC will read that.
Well, fine, but (1) I have to install Google Earth, (2) that is an extra step/annoyance, and (3) BC is supposed to read KML files anyway!
------------------------------------------
What follows below is my experimenting with KMZ files; there may (or may not) be something useful there as well.
But the simplest thing would be to have import of KML files work.
-ceej



So I was curious about .kml and .kmz
I found what someone said was the relationship: a .KMZ has been compressed ('zipped' up) using an application such as WinZip. The .ZIP file is then renamed as a .KMZ
So I decided to test it out.

I have both 7zip and windows zip.
So I used each to compress a .kml file and renamed the result as .kmz
BC failed to import either of them.

What I did not do then, but have now done, is test those .kmz files in Google Earth.
Interestingly, the .kmz file created by windows opens OK in Google Earth; the .kmz file created by 7zip gets a parse error.
So that is probably the reason that the 7zip .kmz file did not open in BC.
However, neither does the windows compressed file!

If, however, I do as suggested and use Google Earth to save the file as a .kmz, then BC will import it correctly.

SO.....
IF there is a standard for compressed/zip files, then the three programs are doing slightly different things. The compression that Google Earth does to create a .kmz file is 'slightly different' from that produced by Windows or 7zip (I do not have WinZip; I'll see if I can get a trial version to test with). And that slight difference is enough to cause BC to return nothing when it tries to import a .kmz file created by those compression programs.

As to why not use Google Earth? Well, I can right-click, zip, and rename in a flash. Unfortunately that does not work.
It would be nice if BC would just operate on .kml files directly. I'd be interested to know why the BC programmers chose to work on the compressed (.kmz) version.

Some wishes:
1) when selecting a way or via point in a route you have to dubble click on it and basecamp zooms in on the point: nice! But also the arrival and departure time dialog pops-up. For me this is a feature I do not use, I would like to be able to turn it off (e.g. in the route dialog via the more info switch?) and than double clicking on a roue/via point should not open the additional arrival & departure dialog.
2) With the route dialog open and deleting a route/via point, the dialog jumps back to top of the list of route/via points... especially nasty with a longer list. It should jump back to the point before or after the deleted point.
3) With the route dialog open with a selected route point, the dialog jumps back to top of the list... when you move / correct the via point on the map. The point should stay selected (especially with a longer list...)
4) Unfortunately you have to relocate nearly every via route /via points on a road because Basecamp is not very good in positioning the via point on roads.... when making a route with the route tool
5) After editing an activity profile, there are two options: recalculating routes that use the profile or not recalculating the routes and change to custom profile. The main problem is that when choosing the first option you can wait for a long time before all routes are recalculated of course depending on the size of your database. This will become worse in time when the database size increases. Please add an option without automatic recalculation, but saving the changes..
6) Being able to change the projection angle of the map somewhere (in the option dialog ? or ctrl-alt A as in mapsource). At least for us northern Europeans the angle is always wrong when we download a updated version of city navigator Europe. My solution is now to install mapsource + ctrl-alt A, but that should not be necessary...
7) ability to lock a library list / make it read only to avoid removing items (especially useful for collections of geographical fixed waypoints)
8) support of won't alert status of via points in the garmin oregon! (by adjusting the firmware ?? - ok not an basecamp item but a real pain in the ... and the local garmin support team does not want to understand this problem and always suggest to reset the oregon ....)
9) support of the dot symbol in basecamp on the garming oregon and not changing it into a blue pin (work around via registry hack does not work) (by adjusting the firmware ?? - ok not an basecamp item but a real pain in the ... and the local garmin support team does not want to understand this problem and always suggest to reset the oregon .... )
10) Support for the idea of user defined location of the database (even in the cloud..?!)

To end positively: I really like using basecamp and the work you guys are doing to improve it.

So here they are, some of the things I would like to have in BC:

- keyboard shortcuts for play/pause/rewind/forward a route/track, maybe displayed in the tooltips?
- wider option list for playback speed - and maybe some shortcuts for increase/decrease it (and to be really pushy I'd say 2 shortcuts to be able increase/decrease playback speed with 2 different speeds)? really, it would make much more sense to allow me to write in there the playback speed I feel right and be able to easily increase/decrease it by keyboard shortcuts (not being forced to move my focus to the mouse)
- option to NOT move screen when playing. Really, what's to BC if I am looking at something else on the map while it is drawing the nice red arrow along the route/track??? Or maybe I just want to view following (or previous) sections of the route/track while waiting for the play pointer to get there.

And another one, EXTREMELY IMPORTANT I would say:

!!!!!!!!!!!! ALLOW BASECAMP TO MODIFY DATA ON INTERNAL STORAGE ON ZUMO 660 !!!!!!!!!!!
(and YES, I KNOW it can modify data on the inserted microSD, if you have one in the device, but I am now referring to the internal storage of the zumo 660)

THANKS!!!


very important, I forgot to say: Please. :)