SiliconFiend

It would be helpful if I could see some MP code AND the resultant trail/road object. I'm not a fluent MP coder, but I've seen enough to recognize patterns. I need an Ah Ha moment. Thanks BTW, we sure have hijacked the OP's thread. Quite. I started a new thread here.

Groundspeak's servers suck. Server timeout left the thread but nuked my post. Here it is again: A new thread instead of further hijacking an existing one... This is a quick overview/explanation of the routing data for cGPSMapper, which uses a file format known as the "Polish Format" (*.mp) The thing with routing data is that it really isn't a visual thing. At its core, it is a simplification of the roads and trails, etc. into a network of nodes which indicate what roads connect to each other and where. This is necessary in order to optimize the data for a routing program (i.e., your GPS) to be able to make route calculations with limited resources (memory and processor time). Here's just two trail snippets from the excellent Calgary Area Trail Maps to give a quick example: [POLYLINE] Type=0x16 RoadID=492 RouteParam=1,0,0,0,1,1,1,1,1,0,0,1 Data0=(51.31465,-115.08197),(51.31169,-115.07952),(51.31010,-115.07901),(51.30873,-115.07724),(51.30842,-115.07698),(51.30722,-115.07690),(51.30521,-115.07762),(51.30430,-115.07820),(51.30315,-115.07956),(51.30096,-115.08754) Nod1=0,2904,0 Nod2=8,2908,0 Nod3=9,3715,0 [END] [POLYLINE] Type=0x16 Label=INDIAN SPRINGS TR RoadID=419 RouteParam=1,0,0,0,1,1,1,1,1,0,0,1 Data0=(51.28890,-115.13917),(51.29160,-115.13805),(51.29328,-115.13665),(51.29452,-115.13483),(51.29525,-115.13440),(51.29607,-115.13449),(51.29650,-115.13440),(51.29710,-115.13359),(51.29817,-115.13277),(51.29903,-115.13175),(51.29993,-115.13166),(51.30259,-115.12779),(51.30418,-115.12625),(51.30452,-115.12578),(51.30546,-115.12191),(51.30564,-115.12084),(51.30564,-115.11940),(51.30636,-115.11428),(51.30611,-115.11309),(51.30551,-115.11180),(51.30538,-115.11116),(51.30551,-115.10977),(51.30564,-115.10917),(51.30615,-115.10814),(51.30701,-115.10746),(51.30808,-115.10728),(51.30903,-115.10668),(51.31027,-115.10530),(51.31053,-115.10475),(51.31079,-115.10316),(51.31225,-115.10050),(51.31241,-115.09943),(51.31233,-115.09848),(51.31298,-115.09764),(51.31332,-115.09698),(51.31375,-115.09545),(51.31435,-115.09192),(51.31452,-115.09020),(51.31499,-115.08815),(51.31504,-115.08673),(51.31495,-115.08612),(51.31435,-115.08351),(51.31465,-115.08197) Nod1=0,2818,0 Nod2=42,2904,0 [END] A polyline is just a string of points that are connected together to form a continuous path. Those points are defined in the Data0 line as pairs of coordinates. This is the base for all linear features on GPS maps (roads, trails, streams, etc.). (As an interesting aside, I think you can make any type of line routable, including rivers, streams, railroads, etc.--the GPS doesn't care). There are a few attributes that are added to a normal polyline definition to make it routable, including the RoadID, RouteParam and then Nod1, Nod2, etc. The RoadID is only used for turn restrictions, so I won't talk about that. The RouteParam defines various things such as how "important" the road is, how fast you can go, and what vehicle types are allowed. This information is all important because the road speed combined with the distance is used to calculate the "Fastest" route on your GPS. The Nod1, Nod2, Nod3 define the routing nodes. As mentioned before, routing nodes define the interconnections between roads or trails. If you look at the first polyline in the sample, you see Nod1=0,2904,0 The number after Nod (1,2,3) doesn't really matter, it's just used to distinguish between the routing node definitions for a particular polyline. The first number after the equals sign indicates which coordinate pair is a routing node, starting at 0 for the first point. For example, if the indicated coordinate pair is 8 and you stood on the first point of the Data0 line and jumped to each coordinate pair in sequence, when you jumped 8 times, you would be at the routing node (intersection). The next number after the comma is the Routing Node ID, which is just a unique number for that Routing Node. When there are other roads that intersect at that point, they'll use the same Routing Node ID in their routing node definitions. That's how the GPS knows that those two roads share the same point and you can move from one road to the other. The last number after the comma is just a flag indicating that the routing node is at the edge of your map segment and can link to a corresponding node in another map segment. So, looking at our map code sample again, you can see that the first polyline has Nod1=0,2904,0 and the second polyline (Indian Springs Tr) has Nod2=42,2904,0 Because they share a Node ID (2904), those trails are linked at that point and you can route between them. Repeat thousands of times for thousands of polylines and you build up an entire road network that way. Because of this, it's best not to do it manually (that would be quite error-prone) but it's well-suited for automated tools such as GPSMapEdit to create and manage the routing nodes. Hope this helps improve your understanding.

Here is a screenshot of a simulated route. This is my maps (Calgary Area Trail Maps) overlaid onto Ibycus' Topo Maps. Thanks for all the nice work you've done on that, by the way. I assisted in the import of your trail maps into OpenStreetMap (meaning: I expanded and partially rewrote the Python translator program, someone else handled the actual upload). MtnHermit, I could give you a routable code sample, but if you're really interested in learning about the routing format for MP files, I'd suggest reading about it from the author, here.

The beep is probably not all that useful, but if you have routable trails, you can find out "how much farther on the trail until we reach the lake". To answer the OP, Garmin is rolling out maps on MicroSD cards with 24k topo contours + DEM shading as well as routable roads and trails. See here. So far, they exist for OR+WA (Northwest), CA+NV (West), CO+UT (Mountain Central) and AZ+NM (Mountain South), with the rest of the US coming eventually.

Usually when Amazon's price changes like this, it's because the product is not "sold and shipped by Amazon". It's sold by third parties through Amazon. I have to disagree. I follow prices there closely for my deals site, and items sold directly from Amazon vary quite a bit. I've seen units where the price changes every other day like clockwork -- up, down, up, down. You follow 'em more closely than I do. I usually only watch an item or two that I'm interested in. In the cases where I've seen it myself, it's been multiple vendors. But I wouldn't doubt that Amazon tinkers with their own prices to up their margins or their volume on any given day... A few years ago, slashdot noted that Amazon sometimes had different prices based on the browser used--higher for IE, lower for Mozilla. Draw your own conclusions...

No, it's because the Chinese government is paranoid. They coerced Garmin (and other manufacturers) to put in certain offsets (which are not constant) into the map data, which are then corrected by a special firmware installed in Chinese market GPS receivers.

I'm sorry, but if you have white water, it is in Marine mode, period.... Or you're on the Colorado river...

www.openstreetmap.org Coverage is not great, but you can help improve it! I have an upcoming trip to China and I just created a map for my Vista HCx. It wasn't trivial and the results are not spectacular, but it seems to work. You might have better luck downloading the pre-compiled version from Cloudmade here. Grab the china.img.zip file, then just drop that gmapsupp.img file on your memory card under the Garmin folder and you'll be all set. Note that with that solution, you won't be able to have any other maps on your GPS at the same time (unless you have a Colorado or Oregon and you do tricks with the internal files). That was the reason I created my own. I've heard there may be a way to combine maps using GMapTool, but I haven't tried it myself.

You need to work on your search skills. I linked to the file earlier in this very thread! But for future reference, the built-in search is horrible. The way to do it is go to Google and type in "site:forums.Groundspeak.com vista hcx 2.50" Here's my earlier post about it. Here's the zip file.

I've got 2.50, which I think was the last "good" version (until 2.8). I got it from a link in another thread, but if needed, I can post it again. I had good luck with the 2.7/2.5 combination, but I've been using 2.8/2.8 lately with no issues (but I haven't tried it under really difficult conditions).

I believe the open-source command-line tool ogr2ogr (part of FWTools package, www.gdal.org) will translate SHP into GPX (among many other formats) and can optionally reproject the data in the process.

My point is that the data in OpenStreetMap is not just GPS traces (that's just a small part of it). People have taken those traces as source data and drawn in the streets and given them attributes (tags). For what you're looking for, download the raw OSM data for the city and then look for things that are tagged like railway=tram, railway=light_rail, railway=subway or download the relations of type route=bus and plot out the listed streets. It would be nice if someone did this automatically for big cities and made that data available in various formats.

I wasn't talking about GPS traces, I was talking about the OpenStreetMap data, refined and derived (usually) from those source GPS traces. Still going to take some work, but not nearly as much as sorting through 157,000 traces.

You need to download the raw data and search for tags such as railway=tram. Or search for bus routes, etc. It's not super easy, but it should be all there if you want to dig for it a bit.

Check OpenStreetMap.

I had some significant problems with Google Earth on Vista Ultimate here. One major problem was with Firefox--the download page would crash Firefox hard, just by viewing the page. That problem seems to have since been fixed--either the web page changed or a Firefox update fixed it (let's hope the latter). The other problem I had was even after downloading and installing, Google Earth wouldn't connect to the server. The black stars background would appear, but no earth. Had to kill the process to exit. Fixed that by uninstalling and reinstalling, but I still have one lingering issue where it says it can't save "My Places". Don't know the cause of that one, but I don't care enough to try uninstalling and reinstalling again.

Me too! This is the only way I use the feature. Over time, you'll get much better at estimating distance too. Rich, I'm sure you know about this site, but maybe some other readers haven't seen it. Quick summary: it can create a dynamic horizon view with peak identification for any spot on Earth (I think)

I'm surprised noone has mentioned OpenStreetMap yet. See a problem, fix it yourself. Presto!

Hi Firstly i want to thank you for your backing up advice that saved my bacon,i deleted gmapbmap which must be the base map but that was fine because i backed up.Then i deleted 1x gmapsup and 1x gmaptz not sure what these are but it stopped that annoying can`t unlock map nonsense.So from this i assume i have to buy another City Navigator for this unit.Garmin dont ya love em lol. Anyway i want to thank you for your great advice.John.... The gmaptz is the timezone file. You'll want to put that one back so your unit can automatically give you local time.

Yes, screen facing the sky. I don't have an Oregon but others who do have reported that the orientation (horizontal or vertical) doesn't seem to matter as much, but holding it with the screen facing the ground impairs reception (why would you do that anyway?). Also users report poorer reception for the Oregon when carried in a pocket, etc (relative to other models), but I haven't read any specific reports of problems in dense cover. On the contrary, Oregon owners seems to think the reception in difficult conditions is as good as any other high-sensitivity GPS receiver. The short answer is that the specific style of antenna (of any that are in current use by GPS manufacturers) really doesn't make much difference in the end--the chipset is far and away the most important factor in reception. Thank you for your kind explanation. Having had such good luck with the 60CSx, I'm wondering if the beefy looking, extenally protruding quad helix antenna is part of what makes this Garmin so good. I know the SiRF chip is excellent, but think that isn't the whole deal. If only the Oregon had this antenna and chipset, and a much brighter screen--that would be the killer! But the eTrex HCx series, with its patch antenna, has at least as good (some early reviews said better) reception than the 60CSx. It had some subsequent drift issues, but those were caused by chipset firmware, which seems to have been fixed now. I would guess that the Oregon's reception "issues" (if you can call them that) are caused by chipset firmware as well. (I'm talking about the reported slight position lagging possibly caused by averaging of readings.) So, that just goes back to my point that the antenna really doesn't matter that much. Other factors can completely dwarf any minor advantage or disadvantage given by a particular antenna style.

Yes, screen facing the sky. I don't have an Oregon but others who do have reported that the orientation (horizontal or vertical) doesn't seem to matter as much, but holding it with the screen facing the ground impairs reception (why would you do that anyway?). Also users report poorer reception for the Oregon when carried in a pocket, etc (relative to other models), but I haven't read any specific reports of problems in dense cover. On the contrary, Oregon owners seems to think the reception in difficult conditions is as good as any other high-sensitivity GPS receiver. The short answer is that the specific style of antenna (of any that are in current use by GPS manufacturers) really doesn't make much difference in the end--the chipset is far and away the most important factor in reception.

Small correction: The HCx has a patch antenna, not a ceramic antenna. Of the Garmin handhelds, only the Oregon has the ceramic antenna. The patch antennas work best when held facing up, which is more conducive for getting the best reception while you're trying to read the screen (quad helix work best vertically).

In defense of GPS manufacturers, the production volume on phones is much larger than GPS receivers, so Apple, et al can get a better deal (strongarm vendors) on components. Plus, there is the ongoing revenue to consider in terms of a subsidy. In the case of the iPhone, the service is a cash stream, as well as sales from their Apps store. For GPS manufacturers, they have maps for future revenue, but other than that, after your initial cash outlay, you as a consumer represent more of a liability (support or warranty issues) than a potential future revenue stream for that particular device sale. Also, GPS receivers are more durable than phones. I doubt you would find any iPhone owner willing to drop it onto concrete from 3 feet, but you might find some GPS owners that would (reluctantly) do it because of its higher robustness. And you wouldn't find any (sane) iPhone owner that would dunk their phone in a foot of water while it was operating, but many GPS owners would gladly perform that demonstration. So yes, GPS manufacturers could (and should) do more, but I don't think it's as easy or clear-cut as some posters have suggested.

Are you sure about the hollow bar significance? I thought the unit displayed hollow bars for units that it had almanac data for (rough information about all satellites available from any satellite) whilst it was downloading enough ephemeris data (specific to that satellite and available only from that satellite) to get a more accurate fix on its orbit - after that the bar turns solid. Then, if the unit can see the EGNOS satellites the unit applies correction data received from them and D appears on all satellites that it is receiving EGNOS data for - this information having been calculated from information received through the ground network grid and sent up to the 3 EGNOS satellites. So, strictly you only need to receive data from one of those satellites to provide corrected data for all GPS or GLONASS satellites in that area. This is as far as I can determine anyway. -Andy What you've described is true for the normal GPS satellites. What coggins was referring to is the bar for the WAAS/EGNOS satellite. That bar will be hollow while it's downloading correction data for the normal GPS satellites. Once it's completed its initial download, the bar will turn solid and you will see "D" on the bars for the normal GPS satellites for which it has correction data.

Oh-oh, I learned earlier this year not to argue with Julian, so I'm passing on #2. Now, for #1, assuming that the algorithm estimating EPE takes into account the map accuracy, exactly how does it know the map's accuracy attribute? From metadata attached to the map? For example the bit rate of an MP3 file where a value such as 128kbps is one of the "tags", or the pixel dimensions, such as 1200 x 1600, are attached as metadata to a jpg file? So the bit rate of a song or the number of pixels of a photo are somewhat indicative of quality, are they not? Is that a reasonable analogy? Garmin maps have different numbers of bits assigned to the different zoom levels. The maximum is 24 bits. Assuming that means 24 bits for latitude and 24 bits for longitude, and taking a wild naive guess about Garmin's coordinate system, I think the minimum resolution would be the circumference of the earth divided by 2^24, or 40,075,160 meters / 16777216 = 2.38 meters. So that would be a grid with 2.38 meter spacing. Maybe.