SiliconFiend
-
Posts
358 -
Joined
-
Last visited
Posts posted by SiliconFiend
-
-
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.
-
Perhaps you would be so kind to include a short trail section coded and a screenshot of the map so I could see how it applies.
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.
-
IMHO: routing at walking speeds is a joke, a beep to tell you to turn right or left, give me a break.
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.
-
Amazon's price seems to change rather dramatically from day to day. I've seen it as low as $275. I think today's price is $340. Who knows what it will be after Christmas. I'd say, however, that if you see it down around $275 again, you might want to consider snagging it.
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...
-
Foreign countries use many of the multitudes of map Datums that all GPS's have but that we all ignore except for WGS84 and NAD27, perhaps Garmin is not a USA company and keyed their China maps to a China Datum? Changing your Datum should remove any offset of any kind, if it's what i'm suspecting.
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.
-
It is turned off. I think it may have something to do with the terrain in south GA and central FL where i use it. i can scroll map to the west NC east TN area and get better colors with that terrain. IDK. Thanks for the info!
I'm sorry, but if you have white water, it is in Marine mode, period....
Or you're on the Colorado river...
-
So far any solution available using not China made GPS ???
G.
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.
-
I've been "searching" the threads on this for the last 2 days, and have only found links to the 2.30 GPSchipset .RGN file. Maybe my search terms are not well enough defined? If you have that link (to 2.40 or 2.50) I would really apreciate a re-post or an E-Mail if that is easier. Thanks!
P.S. I put in a request to Garmin tech support, but we all know how that will turn out !
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.
-
Actually, it would be great to find both the 2.40 AND the 2.50 GPSchipset RGN files. Anybody?
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.
-
http://forum.openstreetmap.org/viewtopic.php?id=1965 is the other conversation over at OSM.
Frankly, SiliconFiend, I'm thankful for the help, but I don't know what you mean (or how to go about 'it') when you state: "refined and derived (usually) from those source GPS traces". Happy to learn of course!
Perhaps other thread is interesting, though, for people following it, especially with regards to my clarification of the problem.
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.
-
Yea thank you!
I am looking, sadly at their forum an 'experienced' used states: ( http://forum.openstreetmap.org/viewtopic.php?id=1965 )
"The search system in OSM for gps tracklogs is very bad and you are going to have a hard time to get anything out of it."
They got THAT right!
Any other methods out there, dear users?
CouchsurferI 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.
-
I guess one thing is that there are so many maps for 'zurich' for example, on openstreetmap, yet none that filter out when I say 'zurich train', etc hmmmm anyway...
I need tracks I can lay on my zurich map so I can get around... any ideas? Also would love such tracks for San Francisco, and I always have this question for new cites - any sources?
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.
-
no really I want to learn about this for personal navigation! Anyone?
Check OpenStreetMap.
-
Vista Ultimate here and it runs GE just fine. Always has - I don't think it has anything to do with Vista. Do you get an error?? what happens when you try to install?
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.
-
The other way I use this option is when I am hiking and I see a peak I want to know more about. The area I am in in the sawtooths has MANY peaks. So by shooting a waypoint to the peak in question I can plug that in to my National Geographic TOPO and find out more about it.
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!
-
Did you backup? If not do this now!!!
Look for gmapsupp.img, all your maps will be in the same folder. Your OR allows several other map file names that older models do not. Older models only allow gmapsupp.img.
When you use Mapsource, it builds gmapsupp.img. It can hold 2025 map segments from Topo, etc.
HTH
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.
-
When you say "facing up" I presume you mean screen facing the sky, correct? What orientation is best for ceramic and how good are those antennae under dense cover? The 60CSx does incredibly well.
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.
-
When you say "facing up" I presume you mean screen facing the sky, correct? What orientation is best for ceramic and how good are those antennae under dense cover? The 60CSx does incredibly well.
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.
-
I've got both units--the 60CSx and the etrex Vista HCx (actually my brother's but in my possesion right now).
There are four major differences between these two units:
1) Screen size and brightness--the 60CSx definitely wins here. When held next to each other in any kind of light, the 60CSx is significantly larger, sharper and brighter (except with backlights on--HCx may have a little edge here). Because the 60CSx screen is larger, it's a lot more readable at the same zoom level.
2)Form factor: HCx wins. It's more compact and lighter--feels better in the hand. It doesn't have an antenna protruding (uses a ceramic internal antenna). 60CSx is more sturdy, however, and I don't have to be as careful with it.
3)Buttons--Big advantage for 60CSx. The toggle lever on the HCx is frustrating to use and I'm constantly tipping it (you either press down or tip it) by accident which starts up the cursor and a location datafield that shrinks the small map even further requiring me to action the "back" button to return to the normal display. This is a big design defect in my opinion. The side buttons on the HCx are poorly marked, all look similar, and difficult to figure out without a lot of practice. The buttons on the 60CSx face frontwards, are clearly marked and simple to use.
4)Chipset: I prefer the 60CSx. It's more accurate and stable with the SiRfStar III GPS chipset. It's too bad that Garmin uses this chip only in the 60CSx because it's the best one out there. The MediaTek chip in the HCx is OK, but has more drift and just doesn't seem as sensitive and predictable. This may have something to do, as well, with the ceramic antenna--not as good under heavy cover as a quad helix (the one that protrudes from the top of the 60CSx). I recently read that SiRf has run into patent problems with their chip and is being sued big-time. I wonder if this is why Garmin dropped them as suppliers to all their newer devices.
You can get the HCx cheaper than the 60CSx. It's a very good unit, but if price and size are not all-important to you, I give the nod to the 60CSx--now considered an "industry standard" for accuracy and ease of use.
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).
-
Just to throw my two cents worth here (and admitting my opinion may be over priced): Look at the iPhone for a minute.
Shirt-pocket-slim, lightweight form factor, general purpose handheld computer, huge bright daylight readable touch-screen, 8 or 16 gig of RAM depending on the model, camera, speakers, microphone, accelerometers, multiple radio devices (wifi, bluetooth, cell phone, and even a GPS in the newest models), etc... Out the door cheaper than a lot of premium consumer grade GPSRs, but then again it's subsidized by the monthly service.
The iPhone shows how much CAN be done in that form factor. Even understanding that DeLorme and Garmin and others don't have Apple's cash reserves or R&D budgets - that constructive proof really makes all the rationalizations about what the GPS makers CAN'T do sound a bit hollow.
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.
-
....
You will get a hollow bar as the data is being downloaded. Wait and get a good set. After it is complete, the bar will turn solid color and you should see the letter D on the signal bars for the birds that are being corrected.
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.
-
1. How is EPE calculated?
2. What is the barometric altimeter auto-calibration algorithm?
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.
Topo & routing
in GPS technology and devices
Posted
Quite. I started a new thread here.