SiliconFiend

So far all the respondents have missed the obvious Send To GPS function. It's not the same thing as WebLinks in that you don't use it from MapSource. You go to the cache page on geocaching.com and click Send To GPS. It will then download the cache coordinates to your Vista HCx. You will need to install the Garmin Communicator plugin.

It may be because the non-x models have 24 MB of internal memory. It's possible that memory causes a significant power draw. Not sure why older models weren't like that, though.

I have an early model Vista HCx (bought it in August 2007). I had never seen the drift until recently (although to be honest I hadn't really been walking in difficult reception conditions very much). When I saw it, I had just turned the unit on (we were approaching a cache) and put the GPS on my belt. There were trees on the path but not dense forest. When I reached the cache area, I looked at the screen and my track was about 30 meters off from my previous tracks, and the EPE circle was big and getting bigger. I looked at the satellite screen and it showed the EPE going from 20 meters slowly climbing up to 25 meters, even though the satellites showed very good reception. I finally rebooted it and it immediately snapped back to the correct location. I think this happened with 2.60. When I upgraded to 2.70 and tried another cache with similar conditions (GPS on my belt, some trees around), it happened again, but with less severity. But even after rebooting the location was wandering (this was on a 4.5 difficulty cache, too, dangit--could have used some help from the GPS!). Anyway, after reading about Blindmantoo's suggestion, I did a hard reset and tried the same cache again (with the GPS on my belt). This time, no drift but the accuracy still wasn't very good (When I held it over the cache spot, it was pointing me 6 meters away when I was at GZ), so it wasn't a "slam dunk", and I'm not convinced that it fixed the drift problem anyway. I haven't tried reverting to GPS software 2.3 yet, but I may if this continues to be a problem.

If you want that functionality, buy a Colorado or Oregon. While I would like it, too, it's highly unlikely that Garmin would cannibalize sales of their new units by adding their key features to older, cheaper units. It's a marketing/sales issue, not an engineering issue.

Since you're in Oregon you may be interested in the Northwest Trails Project for Garmins. Not sure if Smith Rock (my wife--who grew up in Bend--calls it Monkey Rock) is covered yet, but if not, you could contribute your tracks to improve the project. Also, I would be remiss if I didn't mention OpenStreetMap, which I doubt has maps of Smith Rock, but is a great resource for do-it-yourself mappers (there are tools to create Garmin maps from OSM data).

Check out www.openstreetmap.org for accurate (if incomplete) maps of China. Accurate because they were surveyed with non-broken GPS equipment. OpenStreetMap was good enough (better than Google) for Flickr to change over to show their map data instead for China. OSM maps can be put onto a Garmin GPS (non-routing) using a tool called mkgmap.

Take a .gpx file from your pocket query and just run this: gpsbabel -i gpx -f THEFILE.gpx -o garmin -F /dev/ttyUSB0 If your device is connected to your USB port. If it's an older serial device, then use /dev/ttyS0 instead. I think by default that will transfer only waypoints. If you want to transfer tracks, add the -t option. Like this: gpsbabel -t -i gpx -f THEFILE.gpx -o garmin -F /dev/ttyUSB0 For routes, use -r instead.

Actually, the 60CSx has a high-sensitivity chipset (Sirf Star III). It was the first Garmin handheld to have one, and people have been frustrated by Garmin's seeming inability to surpass or (in some cases) even match the performance of that receiver in later handhelds.

Umm, what were you expecting? Why did you even bother ordering it? Sounds like you just wasted shipping charges. I know there are reports of a 2.70 version coming on some new units, but don't you think if Garmin has a magic version that fixes everything, they'll release it to the unwashed masses, too?

On a PC you'd use GPSMapEdit and cgpsmapper (both free) to edit it. The other problem you're running in to is the segment limitation of your GPS. You can load up to 2025 mapsheets on most units. There is a workaround though. Send half, rename the file to gmapbmap.img or gmapprom.img and then load the other half. Dale As far as I know, I don't think that will work on an eTrex, only on a Colorado, Oregon or Nuvi. Maybe the techniques used in this post could work for combining your map segments. I think all you'd have to do is come up with new GDB files and then run the script.

You might check mapcenter2.cgpsmapper.com or www.openstreetmap.org (can be converted to Garmin format using a program called mkgmap).

Hee. Thanks for the laugh. Really, how many times has that happened to you? I think under those circumstances you'd be lucky to have a functioning piece of electronics, not to mention spare batteries...

If it truly is transparent, then it should work. Check your settings. I have a transparent topo map on top of CNNT 2009 which shows contours, trails, water features, etc. A little slower to draw, but it's nice to have all that stuff.

I suspect sendmap (from cGPSMapper) would be capable of sending routable maps to your GPS. Otherwise, you have to modify the registry to get the maps into MapSource, or use a tool such as MapSetToolkit. It's possible the mapset that you will download from MapCenter will have the .reg file that you need in order to make it work with MapSource.

You have to have the routable version of cGPSMapper, which costs ~$2800. Or, you could use MapCenter for free, if you don't mind sharing your maps. (Yeah, I didn't think you'd mind...) I assume you mean geonames.org, or something similar... You'll have to find a way to translate that text file into Polish Map (.mp) format, or find someone who's already done it. If you're handy with programming, it's not difficult to do--the most time-consuming part is mapping all of the types in your source file to Garmin type codes.

I think you may have 'fixed it good'. The link worked earlier, but now I can't seem to read it. Dale The site is down. My edit was only a minute or so after my original post, and it was to fix a missing slash on the closing url tag. I just poked through my browser cache to see if I could resurrect the pdf, but it's gone. Hopefully the site will come back soon... Edit: I found another paper that purports to have a fast algorithm. The paper is longer, but I don't think it's too difficult to understand (I haven't read it fully, mainly the abstract). It even has some pseudocode, which is always helpful. Edit again: I tracked down a paper referenced in the above one, which has an algorithm for clipping against rectangles, which I think is what you want to do. It's much simpler and has a C implementation given (look at the "2D polygon clipping" section). Edit one last (?) time: Found the original paper on the new CiteSeer site here.

Wouldn't an Idaho be a potato? Perhaps they will call their smallest unit a Rhode Island, and their biggest one a Texas. Umm... They'd probably call their biggest one an Alaska. Yes, it's still a state.

You're trying to split a complex polygon (one with nested holes). I'm considering exactly the same problem for a tiling task for OpenStreetMap. I came across this interesting paper about generalized polygon intersection which may be helpful. It's a bit academic, and it's intended for intersecting two arbitrary polygons (instead of one rectangle and one polygon), but it could be helpful in thinking about the issues. Looking at your example: In general, you're going to take one polygon with three holes and transform it into three polygons, some of which have holes and some which don't. The hole in the top right will no longer exist as a hole in the new, split polygons--it will just become part of the outer edge of the two polygons. This means you'll have to join the intersecting points of the outer ring and the "hole" together. Tricky to figure out how to get it right. To talk it out: as you're iterating around the points for the upper right polygon, you'll come to the part where your cutting line is. At that point, you need to follow the cutting line down (or up?) and find the intersections of any inner rings. If there are two intersecting points for the inner ring (your cutting edge could intersect the inner ring only at one point), then you need to connect a line from the intersecting point on the outer polygon to the closest intersecting point on the inner ring, and then add the portion of the ring (which is inside your intersecting area) to the boundary of your outer polygon. Then draw another line along the intersecting line from the inner ring to the next-closest inner ring (if any) and repeat the process, then eventually you'll re-intersect the outer ring and you can close out your polygon. It's an involved process with a lot of steps, but when you break it down, it's manageable. You just have to make sure you account for all the special cases (like does your intersecting rectangle have a corner inside the polygon?). Sorry if this is a bit rambling--writing it out has helped make it more concrete it in my own head. Edit: fixed broken url tag

I've had a really annoying experience with City Navigator 2008 NT (and eventually 2009). I was unable to register City Navigator NT 2008 online under MyGarmin--it didn't even show up on the list as an option. So, I called Garmin and they gave me the unlock code. I asked for the 2009 upgrade and they said wait a day and it should show up as a download, and if not, call back. Well, I had to call back, and they said they'd send a note over to IT and that I'd get an email when it was ready to download. 1 week later, no email so I called back. This time I got to the mobile devices department, and the guy I got on the phone said that I couldn't get it as a download because I had a Vista HCx and it wasn't supported. I tried to tell him that yes, in fact, it was possible and please give me the download, but he was adamant that only the DVD would work. I eventually gave in and said "fine, send me the DVD". They sent it for free, which was nice. Installed it, and then couldn't get it unlocked to my GPS. One more call to Garmin and they said they couldn't do it because of a problem with the website with an undetermined resolution date. They said I might eventually get an email that things were resolved. At this point, I got fed up, found a key generator and took care of it myself. All in all, not a shining example of Garmin's storied customer service.

In GPSMapEdit, you can hit Ctrl+0 to make all levels show up, or Ctrl+1 for level 1 & up, Ctrl+2 for level 2, etc. To return to the default zoom, press . (period). Also, look at the "EndLevel" directive in cGPSMapper. That's how interstates show up at the 20 mile+ zoom.

In case my TYP file becomes unavailable, the magic default color for park polygons in City Navigator 2009 NT is bdff41. That color looks different from the City Navigator park color in MapSource, but it will look the same in your GPS.

Okay, so I spent a lot of time trying to get this right, but I think I have a good solution now. I removed all the place names and roads in the USTopo.cfg. You can get my config file here. Then, with a custom TYP file, I tweaked the park polygons to be partially transparent so that I could see the City Navigator roads underneath. I got a lot of help from this post for the bitmap style. I got some more help from this post for the required registry entry to make the TYP file work with MapSource (basically just add a String value named TYP with the path to the file). BIG FAT WARNING: Make sure your TYP file base name is 8 characters or less. I tried it with 9 characters, and while it displayed correctly in MapSource, it caused a program error when I tried to transfer the maps to my GPS. Some screenshots: Here's a section where the park boundary in City Navigator ends but continues in Topo (the dots are sort of hard to see): I had to experiment a lot with the color to get it to match the park color in City Navigator, because I wanted the dots to disappear when both City Navigator and Topo had the same park. I ended up loading the maps to my unit (Vista HCx), taking a screenshot of a park from CNNT with xImage, then sampling the color of the park in Paint and copying that color into the TYP file. So, now I can see the City Navigator roads underneath the Topo parks, but they end up a bit "freckled" like this: This is acceptable to me, but maybe not for everyone (you can tweak your own if you want). One more thing that needed tweaking was the polygons for urban boundaries (city designations). By default, they were covering city areas, which obscured all the roads for the city. Not very helpful. I didn't want to ditch them completely (also didn't want to recompile the maps...) so I turned them into a very low density dot pattern like this: So, feel free to download my TYP file and use it as-is or you can use this fantastic online editor to tweak it to your liking. Enjoy!

Check http://mapcenter2.cgpsmapper.com or for a little more work but possibly better results, http://www.openstreetmap.org (go to the Wiki and look for a project called mkgmap).

Hmm.... Playing around with this a bit more I think it still needs some tweaking. Place name POIs are duplicated, so those need to go in the DeleteFeature section. Also, polygons like state park areas cover the City Navigator roads (boo!), but unfortunately that's inherent to the transparent map, so that can't be fixed. Too bad the City Navigator maps can't be made transparent... Anyway, I might just delete those polygons (but they're nice to have...). I'm planning to take it out on a caching trip this weekend so hopefully I'll find any more bugs so I can regenerate the Topo combined maps.

I guess I'll see what I get. By the way, do you have any examples of config files where you've removed the background polygon (made a transparent map)? Since I have City Navigator, I'd really like to do as you described and make this map set be transparent and remove the streets and just leave basically the contours and water features. Well, it seemed to work okay. I made the maps transparent and removed all the roads so that it just uses the City Navigator roads. I also took out some other POIs that should be duplicates between the map sets. So now I can see the topo contours and water features on top of City Navigator. Cool! Unfortunately, due to problems in the Topo source, some trails are marked as residential roads (they could have at least made them unpaved roads!). I also saw some incomplete/broken contour lines near where the original segments split, but that problem is also in the source data and not related to the combining process. In case anyone wants to recreate that, here's the contents of the config file I used: [IMGIDChanges] Preprocess=N Transparent=Y TreSize=5000 TreMargin=0.000000 RgnLimit=1024 [DeleteFeature] Point 0x5901;Large airport Point 0x5902;Medium airport Point 0x5903;Small airport Point 0x640e;Park Point 0x6410;School Polyline 0x0;Any road Polyline 0x1;Major highway Polyline 0x2;Principal highway Polyline 0x3;Other highway road Polyline 0x4;Arterial road Polyline 0x5;Collector road Polyline 0x6;Residential Street Polyline 0x8;Highway ramp, low-speed ;Polyline 0xa;Unpaved road Keep for now Polyline 0x27;Airport runway centerline ;Polygon