SiliconFiend
-
Posts
358 -
Joined
-
Last visited
Posts posted by SiliconFiend
-
-
I've had my Vista HCx since August 2007, but I just started having this problem, too. Long pauses when moving the cursor around the map. No recent changes in maps or firmware (I installed 2.60/2.60 shortly after it came out). I might try purging some waypoints/caches.
Just out of curiosity, do you happen to have City Nav NT maps on your Vista HCx?
When I had NT maps, I had the same sorts of delays with the cursor on the map screen. I was able to make the problem go away three different ways:
(1) Make sure that there are no City Nav waypoints in your list of 50 most recent finds. If all 50 in that list were user-generated waypoints or caches I had downloaded, the delays went away. If there were any CN NT waypoints (addresses, stores, restaurants, etc.) the lag came back -- the more CN NT waypoints there were, the longer and more noticeable the lag was. Strange but true... try selecting 50 of your own waypoints just to clear all CN NT waypoints from the Recent Finds list, and see if that makes a difference with the lag. If so, maybe you have the same problem that I had.
(2) Remove the NT maps, either by having only topo maps on the SD card or taking out the SD card altogether. (The delays went away if I only had topo maps on the SD card.) This was not a permanent or practical solution, since I needed auto-routing maps, but it did help identify the problem for me.
(3) Replace the NT maps with non-NT maps. This ended up being my permanent fix for the issue.
Sorry, not NT maps. MGNA v7 with Metrogold. Plus tide points from GPSMAP 168. I have used it successfully to do turn-by-turn navigation for quite a while, with all kinds of address and POI waypoints in my recent finds, but the problem only recently appeared. I load geocaches one-by-one using the "send to GPS" function, and I'm wondering if I recently crossed some threshold.
I did remove a handful of found caches and I haven't seen it show up since then. But, I haven't been using my GPS much lately, either, so I can't say definitively that the problem went away.
-
1.4 seems to have fixed the hole that was Dallas County, TX.
I don't think anything can fix that hole.
-
Alright! Thanks to Siliconfiend for the tip about turning off the “automatic re-routing”. That might just work for me (unless I miss a turn?). The manual is so abbreviated, I’m never quite sure what results to expect from any of those obscurely worded menu commands! Never the less, it is just more of a bother than I thought it should be.
The good news (for me at least) is that I figured out how to get my custom topos and City Navigator loaded (and working) on a single SD Card! It turns out that none of the upload programs recognize my custom topo as a legitimate file (some say it is too big for virtual memory, one says it can not open the file because “0” level can not be empty, and MapSetToolkit requires several other files to be included like “TYP” and ”FID #” etc..).
I can load my topo straight onto the SD Card with windows via USB port (mass storage configuration) and it works just fine. So, what I did was create some folders on my computer hard drive, and after loading the section of City Navigator that I was interested in (the “Country” of California in this case), I then copied it to a folder on my computer. Then I deleted it from the Garmin folder in the Vista HCx and copied my custom topo back into that folder (via USB mass storage link). Then I used Mapwell Mapupload to “add” the City Navigator to the Custom topo already loaded on the Garmin Vista. It took almost 3 hours worth of processing to blend that combination (I suspect that the USB interface in the Garmin was the bottleneck), but it loaded and shows up as independent and individually selectable map sections on my Garmin Vista. Yippee!!! No more “field swapping” of SD Cards for anything I want to do in California anymore! I am still going to try and figure out how to get Mapsource to recognize my custom topo, and I’m sure that MapSetToolkit is the way to do it. It will just take me a while to figure out how to generate all the missing parameters that that program wants to see.
Yeah, you'll want to get MapSetToolkit working (sorry, I've never done it myself) because I'm pretty sure that Mapwel didn't include the routing information from City Navigator, which is a huge loss. As far as I know, only MapSource can combine and upload routable maps. It's possible sendmap could do it (www.cgpsmapper.com), but I don't know.
-
<snip>
I haven’t found a way to easily back out of “routing” and mark a cache as found. Granted I’m a bit spoiled as far as auto-routing, because I’m used to the simplicity and ease of use with my touch screen Tomtom car nav system. Never the less, it seems silly to be forced to “end navigation” in order to “go to” a geocache “off road”, just to have access to the “found” button on the compass, to log a find on the calendar. If I’m missing something, somebody please set me straight (the manual is useless). I can live with that inconvenience if necessary, it just seems that I must be missing something.
Well, you do have to route to a cache off-road in order to be able to mark it as found, but you can save some keystrokes. While your "follow road" route is active and the map page is displayed, Press the Menu button and select Recalculate, then choose Off Road (your routing setup has to be configured for "Prompted").
What I really would like to know is how to have my “custom home made” topos available on the same SD card as the City Navigator.
<snip>
Is there some software that will merge two (or more) IMG files that may not be “Garmin sanctioned”?
<snip>
You have to load them both at the same time. Look at MapSetToolkit to get your custom map into MapSource.
-
I downloaded these maps last week and when I tried to view them in my program GPSTurbo it couldn't recognize them, but it was a simple fix as I was parsing the FAT table incorrectly.
I've totally re-written my IMG map renderer and it now looks more like google street maps with the anti-aliased fat curved edges for the roads and such but when viewing your maps I was noticing a weird rendering glitch on a lot of the cul-de-sac ends. Turns out that a fair number of street poly lines in the map data have duplicate points in them. Typically it is a single road line piece but the end point is duplicated. I'm not sure if this is a "feature" of the IMG format, can a polyline have only one line or is there a minimum of two? Anyway, it was a simple fix to ignore duplicate points. The reason for bringing it up though is that if the duplicate point is not a limitation of the format, then you could save a few bytes here and there by stripping these out of the dataset.
Cheers,
Kevin Pickell
Could it have been data from the different layers?
-
OS = Ordnance Survey: http://www.ordnancesurvey.co.uk/oswebsite/
I think these are the most detailed maps of the UK with markings of walking trails etc.
www.openstreetmap.org It started in the UK because of the Ordnance Survey's restrictive copyright, and there's a big focus on comprehensive coverage. You can get the data onto your Garmin GPS using a program called mkgmap. There are projects in the works (I'm working on one) to create routable GPS maps from OpenStreetMap data.
-
Not sure why you're getting the first warning since the combined segment covers a smaller area than 10 degrees, cgpsmapper can handle segments larger than that anyway so I'm not sure why it gives a warning about it.
The "skipped because of wrong data" is normal. I get it all the time. I don't know what it means but I have a program that will gather statistics for the maps and I ran it on the original map and on the combined map and the results are the same.
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.
-
Okay, I finally got around to trying this and I'm seeing some strange messages in the display. In the first part, I get warnings such as this:
00210107.mp(330268) : Warning W008: Element spans more than 10 degrees!
Then later, I see:
****RGN40**** Elements to process -->153535 100% Processed -->105268 Split -->1283 Skipped because of wrong data -->4400
The "element spans more than 10 degrees" seems like a weird error. How is that possible when the segments themselves are tiny? And the "Skipped because of wrong data" is a bit concerning, too. I realize these are just warnings, but is it going to be missing data in the output? Any idea what might be causing these messages?
-
<snip>
I have all the NPS data (but have not looked at roads to see if they are on the topo map and lots of their data was in e00 which is a pain to convert to shapefile).
<snip>
ogr2ogr is your friend (www.gdal.org). Easy conversion between a wide variety of GIS formats.
I looked at the site and all I found were things for raster conversions. But I could have missed it. The way I deal with .e00 files is I have an old (3.0) version of ArcView. I use the Import Utility to convert the files (which is a pain). The import utility creates files I can import into ArcView as a theme. I then save the theme as a shapefile. Then I add it in GPSmapedit. It works but is time consuming and a pain. Is there a better way out there?
Just download and install the gdal package. ogr2ogr is part of those tools. A lot of the toolkit (the GDAL part) is focused on bitmaps but ogr2ogr is for vector data. It's a command-line tool, but once you get the arguments figured out (it's not too hard), conversion is quick and relatively easy. It can also reproject into whatever coordinate system you need at the same time (that's the -t option). If you have more than a couple files to work with, it's definitely worth your time to learn it.
-
<snip>
I have all the NPS data (but have not looked at roads to see if they are on the topo map and lots of their data was in e00 which is a pain to convert to shapefile).
<snip>
ogr2ogr is your friend (www.gdal.org). Easy conversion between a wide variety of GIS formats.
-
But there has also been a recent problem with the entire 32 satellites. This week, #1, was taken off line completely. There are now only 31 active. I've noticed on the live tracking sites that that has actually been leaving a bit of a hole over North America during the afternoon in North America.
It's about dang time. I've been frequently seeing #1 directly overhead for quite a while but unable to get any signal from it, so it has been occupying one of my channels but not giving any position information. Good to get it out of the way. Bring on the new sats!
-
Also, does anyone know how I can connect my GPS to my laptop and use the big screen for navigating when in the car? I.E. have the passenger working the laptop but with the detail on the big laptop screen?
thanks,
biGjOhn
Look at the free Garmin utility called nRoute--allows you to track your position on a laptop in real-time.
-
The actual height shown by the Garmin was 1236-1237m - basically dead on with the actual.
I feel a little bad about posting about that trip on here, since I did no geocaching whatsoever
heh.
Nice real-world test - I'm guessing that this log represents several hours of data, with over 800 m of elevation change, and in all probability, significant wind speeds and barometric pressure changes. 2 m accuracy should satisfy the needs of most recreational users!
Is it too late to go back and place your own geocache at the top of the mountain?
Oops. Now it's your turn to be wrong.
He has the Legend HCx, which does not have a barometric altimeter. His excellent accuracy was with only GPS elevation available. -
I won't argue one way or another, however I can say that in in places that are prone to large pressure changes say in the mountains where weather and pressure changes quickly that I've found the auto calibrated barometric elevation profiles to be less accurate than GPS elevations in most cases. That said I've seen places where the GPS reported elevation is horribly from surveying benchmarks as well.
As noted above, the instantaneous reading of GPS elevation on a consumer GPSr is only reliable to about 20 metres at best; 50 metres or more is not uncommon in sub-optimal reception conditions. (Long-term averages over several hours at a fixed location will generally be reasonably close to true elevation, but I am talking about the real-time on-the-spot reading that you get from your hand-held GPSr as you move around.)
That said, would not a better test of the auto calibration be to say start a day hike or drive at a survey benchmark and then return to the benchmark or hike to another benchmark and compare the reported elevations? Or set up a route with mapsource topo hike/drive the route and then compare elevation profiles to the topo profile for the route/track? Something that takes more than a hour or two to complete so larger changes in pressure can be encountered. We can easily see a 15-20hpa change in a day here, and that's without heading up into the mountains. It would be interesting to see how well the auto calibration could deal with that type of pressure change while moving and changing elevation as well.
I would gladly do a test with a benchmark - if I could find one in my area (Brisbane, Australia). However, I don't know how to find published benchmarks with elevation in my areas.
My Mt-Coot-Tha test was an attempt to overcome this limitation by doing a circuit repeatedly, logging both GPS and barometric elevation. I have 1:25,000 topo maps of the area, with 5 m contour intervals. My track logs conform well with the topo map data; however, the variation I experienced between the accuracy of the GPS elevation trace and the barometric elevation trace isn't really enough to prove that my barometric elevation trace "fits" the topo maps "better" than the GPS elevation. However, the auto-calibrated barometric elevation is noticeably less variable than GPS elevation when returning to the same point - and I think that really proves the point. I have had enough experience with my Summit HC to know that this behaviour is also typical for longer records / greater elevation changes / greater barometer pressure changes. Yes, a controlled benchmark would be a better test, though.
Is it not probable that part of the Garmin's auto calibration takes into account if the unit is moving......if the unit is stationary it's easy to adjust out pressure changes because the unit is not going anywhere. I would guess that type of correction is much harder when the unit is changing in elevation and position, and pressure changes occur. That would seem to be a more real world test than leaving it on a desk all day recording data.
I don't know the details of Garmin's algorithm - it is trade secret, and Garmin aren't saying. However, my guess is that the auto-calibration algorithm is optimised for auto-calibration of a moving GPSr, because that is what the unit is basically designed for - and my Mt Coot-Tha test, and roybassist's test show that auto-calibration IS effective for a moving GPSr. I don't know whether the algorithm specifically changes when stationary, but my guess is that it does not - because if it did, I would expect the auto-calibrated barometric elevation traces from my static tests to be even less variable than they were.
Hope this helps!
Thanks. I was misunderstanding the barometric pressure as the absolute pressure.
-
I've had my Vista HCx since August 2007, but I just started having this problem, too. Long pauses when moving the cursor around the map. No recent changes in maps or firmware (I installed 2.60/2.60 shortly after it came out). I might try purging some waypoints/caches.
Just out of curiosity, do you happen to have City Nav NT maps on your Vista HCx?
When I had NT maps, I had the same sorts of delays with the cursor on the map screen. I was able to make the problem go away three different ways:
(1) Make sure that there are no City Nav waypoints in your list of 50 most recent finds. If all 50 in that list were user-generated waypoints or caches I had downloaded, the delays went away. If there were any CN NT waypoints (addresses, stores, restaurants, etc.) the lag came back -- the more CN NT waypoints there were, the longer and more noticeable the lag was. Strange but true... try selecting 50 of your own waypoints just to clear all CN NT waypoints from the Recent Finds list, and see if that makes a difference with the lag. If so, maybe you have the same problem that I had.
(2) Remove the NT maps, either by having only topo maps on the SD card or taking out the SD card altogether. (The delays went away if I only had topo maps on the SD card.) This was not a permanent or practical solution, since I needed auto-routing maps, but it did help identify the problem for me.
(3) Replace the NT maps with non-NT maps. This ended up being my permanent fix for the issue.
Sorry, not NT maps. MGNA v7 with Metrogold. Plus tide points from GPSMAP 168. I have used it successfully to do turn-by-turn navigation for quite a while, with all kinds of address and POI waypoints in my recent finds, but the problem only recently appeared. I load geocaches one-by-one using the "send to GPS" function, and I'm wondering if I recently crossed some threshold.
-
Don't forget Mapcenter 2.
-
I just downloaded IbycusUSA1.3. Thanks for all of your efforts.
I loaded it into Mapsource 6.13.7, it appears that all of the map segments are available to view on Mapsource, but there are no topo contour lines viewable on the Ibycus map.
It is not a Topo map. It is a street map.
Ah. Thanks for the info. I was thinking it was a topo
I've decided that eventually I will add topo, I haven't decided quite how yet, but I will add it eventually.
Dale
You should be aware that there is another effort going on for 24k US Topo maps by IndyJpr, Oz and others, using SRTM DEM data, NHD water data and other data sources. You might want to coordinate with them to minimize duplication of effort.
-
I've just returned from a 570-mile round trip (285 miles each way) on which I gathered some data to add to this thread. The trip was made in about 5 and a half hours each way, with one day in between.
Thanks, Roy - more good data.
Not to puncture anyone's balloon, but Roy's test didn't exercise the auto-calibration of anything. If I'm reading correctly, he was simply monitoring the pressure reported by his GPS and comparing it to the pressure broadcast by the weather service. All he proved is that the pressure sensor has good accuracy. That's (very) important and we do appreciate the data collection, but that's not where the auto-calibration comes in. The auto-calibration takes into account the elevation calculated from the GPS signals in order to correct for changes in pressure due to weather which would otherwise show up as elevation changes. Julianh's test is a good exercise of the auto-calibration function.
-
I've had my Vista HCx since August 2007, but I just started having this problem, too. Long pauses when moving the cursor around the map. No recent changes in maps or firmware (I installed 2.60/2.60 shortly after it came out). I might try purging some waypoints/caches.
-
Any update on the progress of the California map?
-
Wow - great effort getting the US maps off the ground. I got pointed to this thread a New Zealand project that does similar (our maps are already auto-routing - you've got that to look forward to at some point).
I wanted to just pop up a couple of ideas for those that are doing the hard work behind the scenes building these maps.
If you can, look at using OpenStreetMap as your repository. As a previous poster mentioned, they have imported TIGER data already (although it may not be 2008 yet, I imagine they'll update it soon). OSM also has excellent processes and tools for people to update the raw map data by uploading GPX tracklogs, and improving the data themselves. This will provide you with a massive infrastructure for sharing the maintenance of the map data. Also, OSM is improving tools for producing Garmin map files, from OSM data.
I think over time that OSM is going to become a natural worldwide repository for mapping data.
Cheers Gav
Have the New Zealand maps been imported into OSM yet? Because just this week I updated a utility to transform routable Polish Format maps into OSM format. (here)
My goal is to be able to go the other way--transform OpenStreetMap data into routable Garmin maps. I have plans, but little time.
-
Rick, download this free program called DNRGarmin. Once you have the program installed, go 'File/Set Projection' and choose your "NAD_1983_StatePlane_Delaware_FIPS_0700" first so it opens correctly. When your shapefile opens DNR will create both the projected coordinate fields and the Lat/Lon fields. You should recognize the Lat/Lon as being correct for the area your data is in. To convert it to a gpx file, go to File/Save To/File/ and Save as type: (*.gpx). It creates the gpx file in WGS84.
If you have any problems contact me directly.
-Pat
Thanks Pat for the quick reply.
I tried that last night and it will only load 32,000 entries before I get an error. My shapefile has 125,000 entries (the entire state). Maybe I need to break it into smaller pieces using QDIS, save smaller files, convert each file using DNR Garmin, and then reload each one individually.
Thanks again,
Rick
Try the free tool ogr2ogr, part of the FWTools kit (www.gdal.org or fwtools.maptools.org). You can reproject to GPX with WGS84 lat/lon using this command:
ogr2ogr -f "GPX" -t_srs WGS84 outfilename.gpx infilename.shp
Note that I haven't actually tried this particular command, but if it doesn't work exactly, some variation of it should. (You may have to use "EPSG:4326" instead of "WGS84").
-
I am tring to make some TOPO Maps of the Kansas City Region 1:24 quality (10 foot contours) for my Garmin Units, but one of the programs I am gonna have to use to get it to work is GPSMapEdit.
The questions that I have for GPSMapEdit are:
1. How long does the Shareware trail period last? It doesn't say how long anywhere on the site.
2. What happens when this period end? Will the software simply nuke itself where it doesn't work anymore or what happens?
I am wondering about this because I am not yet sure if I want to spend $70 (The price now is $65 but its a international purchase and my card company likes to tack on extra fees due to this, also the price might go up because of the dollar becoming weaker and weaker.) on the software yet. It sounds like its intresting software and I would like to play around with it other than making the topo maps.
I've used it occasionally for quite a while, and as far as I can tell, it doesn't disable anything, and there's no annoying messages or anything like that. I think the main thing you don't get with the shareware version is the ability to show Google maps as a background image. But it's a great program so try it out and if you like it and you can, you should support the author.
-
WAAS helps alot when looking for caches once you are close to them, but doesn't do much if you are on an hour long trek first, so I usually turn that feature off to save battery power and then back on as I approach a site.
You're not really saving battery. Other users have tested the battery life with and without WAAS for the Vista HCx and it has a negligible effect. You'd lose more battery by clicking the backlight on a few times. So, if you're in an area that has WAAS coverage (in North America you're generally in good shape), just leave it on.
jeep trail maps
in GPS technology and devices
Posted
You also might want to check out The Northwest Trails Project.