routing and exits

[jfheath]

Not a great deal to add to the wisdom already expressed. Except that some maps take short cuts when producing them on the screen - literally. The roads are plotted as longer straight lines so that for some of their length they are not actually plotted where the road lies - they take a straight line short-cut across the bend.

If points are plotted in a map such as this and then loaded into the Zumo, the points will lie to one side of the road, rather than on it, and this can result in the behaviour that you describe.
An example of a simple test that I did with a Google route plotted onto a garmin map - way back in March 2015.

 

[CYYJ]

I NEVER use the "shorter distance" option when selecting a route - never - for exactly the reason mentioned in @ReSTored 's post, part of which was quoted directly above.

I might occasionally "take a look" at what the navigator proposes as a shorter distance option if I need to make a long trip (300 miles or more). Sometimes, the navigator will propose a route off of the major highways, in other words on secondary roads, that is more attractive to me from a "quality of ride" perspective. But, if I elect to use that shorter route, I'll set up a series of waypoints that keep me on that shorter route but set the calculation method to "fastest route" to avoid nuisance detours up back lanes and across corner gas station parking lots.

Michael

 

[ST1100Y]

Not a great deal to add to the wisdom already expressed. Except that some maps take short cuts when producing them on the screen - literally. The roads are plotted as longer straight lines so that for some of their length they are not actually plotted where the road lies - they take a straight line short-cut across the bend.

If points are plotted in a map such as this and then loaded into the Zumo, the points will lie to one side of the road, rather than on it, and this can result in the behaviour that you describe.
An example of a simple test that I did with a Google route plotted onto a garmin map - way back in March 2015.

Sorry, but this is misleading...
LHS shows a route plotted within a mapping software, whilst the RHS shows a recorded track while on the move (including drift, reflections and other issues like overcast, rain or a forest canopy impacting reception), re-imported into a plotting software, overlaying "some" map (added discrepancy toward the real world, as map-projections are varying with each map vendor...)

When I plot a route on a specific map product in Garmin MapSource, shaping points and bearing line sit exactly on the road shown, ditto on the satnav as long as it has the same map loaded...
If I however switch the map product in my MapSource (i.e. from City Navigator to OSM), I'll have the effect as shown above, because the map projections vary...
(if you zoom out into "globe view" and switch back and forth between maps, you'll see how how continents are tilted and even shaped differently...)

 

[jfheath]

LHS shows a route plotted within a mapping software, whilst the RHS shows a recorded track while on the move (including drift, reflections and other issues like overcast, rain or a forest canopy impacting reception), re-imported into a plotting software, overlaying "some" map (added discrepancy toward the real world, as map-projections are varying with each map vendor...)

I obviously didn't explain it clearly enough. There is no recorded track shown on either map.

The left hand side shows a route plotted on Google maps.
I then converted the Google Maps route to a gpx file, and then plotted that gpx file on the Basecamp map - which is what is shown on the right hand side.
So the right hand side shows the Basecamp map with the gpx of the Google route superimposed. The gpx file plots each lat/long coordinate as a track point eg<trkpt lat="53.7192640000" lon="-1.6331260000"></trkpt> It is those individual points that you can see on the right hand map. There is no recorded track involved.

I suppose that there may be some case that the method of conversion by Visualiser is incorrect and it was that conversion that produced the error. If I was doing it now, I would export from Google using a KML file and import that directly into Basecamp. At the time, this option was not available.

I haven't tried it but the different projections of maps on a flat screen should not make any difference. Every point on a track or a route is plotted using latitude and longitude coordinates, which should be converted to the flat screen using the same projection.
I'm aware that Mapsource and Basecamp can sometimes get out of alignment, and that this is easily cured by rotating the map view a tad and then putting it back to north up.

 

[ST1100Y]

I then converted the Google Maps route to a gpx file, and then plotted that gpx file on the Basecamp map - which is shown on the right hand side.

Just proves my point: Google Maps and Garmin Maps are based on different projections...
If you could layer them you'll find that they're differently shaped, so no road will be on top of each other...
This is the root cause of most of the issues when compiling routes between different systems and manufacturers...
A TomTom *.INT will never match a Garmin *.GPX and vice versa, neither will fit with a Google route file, one from Kurviger.de, etc...

Folks always wonder why their satnav acts up on "unknown routes downloaded from the internet"... just won't work...
Store them files on your HD, open them with your plotting program, edit or better rebuild them there on your map, then transfer this to the GPS loaded with the same map... that'll work flawlessly...

https://en.wikipedia.org/wiki/Map_projection

 

[CYYJ]

Just proves my point: Google Maps and Garmin Maps are based on different projections...

Martin has raised a very important and very significant point: There are literally DOZENS of map projections used in the GIS (Geographic Information System) industry, and they all have differences that will be both apparent and very significant at high resolution, which is the resolution that needs to be used when we are trying to overlay tracks or routes onto highways. The differences are generally insignificant when precision of less than 300 feet (100 meters) is necessary.

Google Maps uses WGS 84 overlaid on a Mercator projection for the entire world. This is an appropriate choice if you consider how Google Maps is generally used, and also if you consider that Google either collects their own data for Google Maps (by driving the routes) or uses satellite photography. Garmin, TomTom, and other navigation system providers use cartographic data provided by governmental organizations, and these governmental organizations (usually national governments) are free to choose whatever position format and reference systems they wish. Frequently, they use very old standards because this ensures commonality with maps produced tens or hundreds of years earlier by the same organization. There's nothing wrong with this, but you can't mix and match reference standards when transferring GIS data.

By way of illustration, here's a list of all the different (national) standards that Garmin uses: Position Formats Supported by Outdoor Products.

Way, way back when portable GPS navigators first came out (around 2000), advanced users could manually select the position format used by the device. In an effort to simplify operation, that option has long since been deleted from Garmin (and other) automotive navigators.

Michael

 

[jfheath]

So, let me be clear about this. You seem to be saying that a single point on the globe, specified by latitude and longitude coordinates, will be plotted in a different position on a map depicting a part of the earth's surface, depending on the projection used ? That cannot be right.

I appreciate that the a different projection means that the point will be plotted in a different place on a flat piece of paper, but it will be in the same position relative to the geographical and topological features. As long as the coordinates are subject to the same projection / transformation.

Eg There is a bend in a river at 55 deg N, 2 deg W. I have a point that needs to be plotted at the same coordinates. In one projection that bend is depicted in the centre of a piece of A4 paper. In another projection, than bend is depicted one third from the top of the paper. In both projections I would still expect my point at 55N , 2W. to be plotted on the bend of the river.

 

[dduelin]

If two GPS units choose different exits, turns, etc. I would make sure the same choices are made in both in regards to Preferences such as faster route, shorter route and Avoidances such as avoid tolls, avoid U turns, avoid highways, etc.

 

[CYYJ]

So, let me be clear about this. You seem to be saying that a single point on the globe, specified by latitude and longitude coordinates, will be plotted in a different position on a map depicting a part of the earth's surface, depending on the projection used ? That cannot be right.

Hi John:

There are three different concepts involved in GIS (Geographic Information Systems): Datum, Projection, and Co-ordinate.

It's beyond my knowledge and skill to accurately and confidently explain these three concepts, although I have a fundamental understanding of them because of my past work as an aircraft pilot flying internationally (with a lot of stops along the way).

The best I can do is refer you to some selected discussion & post on the internet that (to me) appar to do a good job of explaining things:

This article: World Geodetic System does a good job of explaining the concept behind datums.

This article: Difference between projection and datum sheds light on different projections (ways of depicting maps), co-ordinate systems (ways of defining a position), and also provides additional explanation about datums.

Pretty much all of the cartography that any of us will encounter in electronic format (internet depictions such as Google Maps, cartography downloaded into GPS navigators) now uses the WGS 84 datum, so for our practical purposes (use by motorcycle riders) we can set datum aside as a variable. But we still need to be aware of what co-ordinate system and what projection is being used on cartography we refer to.

I didn't have this luxury (of ignoring datums) when flying in lesser developed countries, because a great deal of the mapping in those countries has not been updated since the WGS 84 datum was established. Hence the position displayed to me on my aircraft GPS would not always be the same as the position depicted when I used published co-ordinates to determine a position on a projected (paper) map.

Michael

 

[jfheath]

I didn't have this luxury (of ignoring datums) when flying in lesser developed countries, because a great deal of the mapping in those countries has not been updated since the WGS 84 datum was established. Hence the position displayed to me on my aircraft GPS would not always be the same as the position depicted when I used published co-ordinates to determine a position on a projected (paper) map.

I understand about the different projections and how that affects how a position on the globe will be plotted in a different location on one piece of paper showing a 'map' using one projection from the position that it would be shown if the same piece of paper shows a map drawn with a different projection.

If I had superimposed the google map on top of the basecamp map, then the different projections would show up clearly, but I didn't do that. I took the track with all of its lat/long coordinates that Google had plotted on its own map using its projection, and loaded it into Basecamp. It uses the same lat/long coordinates on its map and draws them using whatever projection it uses. The track is a constant. The maps must be slightly different or be plotted to different degrees of accuracy.

 

[CYYJ]

The maps must be slightly different or be plotted to different degrees of accuracy.

A bit of both, I think. The Google map and the Garmin map use different projections, and there are also practical limitations on the accuracy of curved lines (such as roadways) depicted on "vector" - rather than "raster" maps. A vector map is one that is drawn using mathematical descriptions of the objects on the map. A raster map is a scanned image of a paper map.

When the map features presented are straight lines, as is the case for airways on aeronautical maps or ship channels on maritime maps, there will typically be no noticable difference between what is depicted on a vector map and a raster map. When the map feature presented is a wiggly line, such as a roadway or shoreline, the cartographer preparing the vector map has to make a decision about how much accuracy is needed. High levels of accuracy require more points along the feature being drawn, which greatly increases the size of the data file. Systems such as ECDIS used for maritime navigation are designed to cope huge data files. Portable GPS navigators used for automotive navigation have limited memory available for map storage - hence longer gaps between the points that define the roadway.

It is interesting to note that on the higher-end aircraft navigation systems that depict terrain on the ground* as well as routes and airways, the resolution of the terrain on the ground is ridiculously poor - with accuracy of perhaps plus or minus one mile for physical features such as islands, coastlines, rivers, and so forth, even though the accuracy of the navigational data (airways, navigation aids, airports) is accurate to 2 or 3 feet. This is because these systems store a terrain map of the whole world (aircraft are pretty mobile devices), and to store an accurate terrain map for the world would require terabytes of data. Because the terrain presentation is only made available as a convenience to the pilots (it is not used for navigation purposes, just for situational overview), low resolution is quite acceptable.

Michael

* I am not referring to TAWS (Terrain Avoidance Warning Systems) here, or to Synthetic Vision (which derives its data from the TAWS database).

 

[ST Gui]

Why do gps sometime on certain exit tell you to stay left (avoid) stay on route while others it says nothing.

My first thought was some GPS units have a "lane assist" feature which is supposed to guide you to the appropriate lane for every leg of your trip. Not long ago some brands/models had it and others didn't. Now it's a very common feature.

But it looks like you're talking about just your GPS and that it has that feature. It just doesn't always give the information you need where you'd expect it.

The cartography used for automotive GPS navigation has far more detail associated with it than you ever see on the screen. This detail is called "road attributes", and includes things such as the presence of a center divider (physical or painted), lane width, speed limits, turning or parking restrictions, the presence of on and off ramps, markings painted onto the road, signage at intersections, and so forth. There can be as many as 60 different attributes associated with any one stretch of road.

I had no idea.

 

[jfheath]

On the Zumo all routes and tracks are stored in the gpx file as an ordered list of individual points, each pair of which is joined with a straight line. The points are not a fixed distance apart - the software creating the route or track increases the number of points on curves in order to closely match the route with what it has in its map files.
The route and the track use exactly the same plotted points - in fact all you have to do to create a track from a route is to pull out each of the individual <rtept > entries in the gpx file and change them to <trkpt >. Basecamp shows each of these points on a track, but you cannot see them on the route.

Some route points contain additional information which seem to relate to the road for the next section of the route. It comes in this format:

<gpxx:RoutePointExtension>
<gpxx:Subclass>1401C475CC01078010010500000000000000</gpxx:Subclass>
</gpxx:RoutePointExtension>

The coded data is a 36 character hexadecimal number - each character represents4 binary digits. There there is limited information as to what the coding represents, but we can assume road speed, road type, lanes etc. I am pretty sure that one flag allows/inhibits the renaming of the route point - because if you delete this subclass command or if you replace it with a default

<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>

Then the route point is never renamed. This is what MyRouteApp does with its route points.
I have a feeling that one flag also allows/inhibits the altering of a route, as certain routes on the XT never get altered - eg a Trip which has been created from a track.

Because there seems to be so many oddities around the XT's routing and route points, that I wonder how this can be. I begin to imagine that it may be a silly mistake by someone picking out the value for a particular attribute, and forgetting that the convention is to start counting from 0, not from 1.

But I digress !

There is (there has to be) quite a bit of tolerance in the routing on the GPS. For a start, the satnav fixes are not accurate. A single satnav 'fix' can never be relied upon. The adjusted 'fixes' also have a tolerance of a few metres - which is pretty impressive really. We have probably all noticed that if your route is along a motorway, but you decide to leave the motorway on the slip road which runs separate from, but closely parallel to the main route, the satnav doesn't notice. Also if you get close to a plotted route point (a shaping or a via point on a Garmin), the satnav will recognise it as having been visited. Certainly if a Via point is inaccurately placed - if the satnav announces that you are approaching said Via Point, it treats it as having been visited.

It is likely that when creating route files, the software uses this wide tolerance to its advantage. Why waste precious space in the files ensuring that every point is plotted with pin-point accuracy, when it has to be designed to give you the freedom of being in any lane of a multi-lane highway.

I haven't noticed that the Lane Assist feature recognises if you are not following its instructions. I think that it just recognises that you are approaching, and plots the lane(s) that you need to be in. I was using this a few weeks ago in the car, on my way to the airport - a route which I only occasionally take. I had my Zumo mounted on the dash, and also the inbuilt car Satnav. I'm glad that I had the Zumo - it was much more informative about the junctions approaching - eg there were two junctions in rapid succession. The XT showed an early image depicting both junctions and that I needed the second one. For me, the Ford was not as helpful - in fact, it displayed the junction that I needed, but it displayed it as I approached the first I saw no indication that there was another junction to contend with. Had I not had the XT, I would have taken this wrong first junction. When I get irritated by the XT's behaviour, I make sure that I remind myself of what things could be really like and use the satnav in the car. The Garmin is a breath of fresh air in comparison. If we need to go anywhere where I need a satnav, I use the Zumo on the dash.

 

[CYYJ]

We have probably all noticed that if your route is along a motorway, but you decide to leave the motorway on the slip road which runs separate from, but closely parallel to the main route, the satnav doesn't notice.

More likely, the navigator notices that the position fix suggests that you are now on a slip road, but because you have a route active and there is a reasonable expectation that you will ride along the route you have selected, the device delays switching over to show you on the slip road until it is absolutely clear - beyond any doubt - that you are on the slip road. This is likely done to avoid numerous instances of inadvertent, unwanted rerouting being displayed if you are in the curb lane (near the exit to the slip road) when you ride by it.

One way to determine if the device has been programmed to behave this way (which I suspect it has been) would be to ride the same stretch of road, exiting onto the slip road, twice - once with a route active that takes you past the slip road along the main highway, and once with no route active at all (in other words, device is just displaying where it thinks you are).

My guess is that in the latter situation, you would see your position displayed as being on the slip road much earlier than you would when you have the route active.

Michael

 

[Gerhard]

One way to determine if the device has been programmed to behave this way (which I suspect it has been) would be to ride the same stretch of road, exiting onto the slip road, twice - once with

My GPS (NAV5) once reported my maximum speed at over 300 km/h, this happened after a road I took had been straightened but the GPS map still showed the old road so the calculations must have been interpolated using time and the map.

 

[CYYJ]

...the calculations must have been interpolated using time and the map.

No. Speed calculations on any GPS device are performed without reference to the map. They are simple calculations that use distance between two consecutive position fixes divided by time. Position fixes are determined at least once per second, in more recent GPS navigators as frequently as 5 times per second, hence there is no need to refer to map data to take into consideration curves in roads, etc.

The speed error you reported was most likely caused by one of the position fixes being inaccurate. There could be many reasons for this, but incorrect triangulation when determining one or more of the position fixes arising from poor satellite reception is the most probable reason.

Michael

 

[dduelin]

No. Speed calculations on any GPS device are performed without reference to the map. They are simple calculations that use distance between two consecutive position fixes divided by time. Position fixes are determined at least once per second, in more recent GPS navigators as frequently as 5 times per second, hence there is no need to refer to map data to take into consideration curves in roads, etc.

The speed error you reported was most likely caused by one of the position fixes being inaccurate. There could be many reasons for this, but incorrect triangulation when determining one or more of the position fixes arising from poor satellite reception is the most probable reason.

Michael

These speed errors used to be more common back in the ‘90s when GPS signals were purposefully degraded and units were single channel multiplexing devices. Two consecutive fixes might be separated several hundred feet 1 second apart and the unit calculated D/T to mph. Once I left my Garmin 38 on a picnic table for an afternoon. It created fixes all over the place and tracked all over the neighborhood. We still thought it was amazing to know where you were on the planet within 10 meters 90% of the time. The other 10% might be a quarter mile away.

 

[jfheath]

The US military who controlled the GPS satellites made low quality signals available for public use (I have read that they deliberately introduced random errors) - so that they could get an accurate fix, but no-one else could. So errors on early GPS devices were in the tens of metres, not the few metres that we have now. The US Dpeartment of Defence gave in to increasing pressure to make the high qaulity signals available to the public.

Regarding Speed - the satnavs seem to make assumptions in order to improve the accuracy of the calculated position / speed. Speed is 'averaged' in order to get a more reliable value - eg (I don't know the precise method), but a typical statistical average in such circumstances might be to throw away the extreme values and calculate a normal mean average from what is left. You can observe the effect of averaging when you accelerate or brake hard. It takes a few seconds for the satnav to catch up with your actual speed. But now, with a clear view of the sky and maintaining a constant speed the satnav readout is pretty accurate.

Going through a long tunnel is an interesting exercise. Fool the satnav by going slow as you enter the tunnel and then speed up for the speed limit when you are out of view of the satellites. The satnav continues to plot your position based on where it thinks you should be - continually falling behind from your actual position. As soon as you emerge into the satellite view, it gets an accurate fix and suddenly you have covered a large distance in a short amount of time. Your steady 40mph, suddenly becomes well over 100mph.

I have noticed a new behaviour in the XT. When stationary, the 590 used to show the present position on the screen, and it was always moving around as the position was calculated slightly differently each time, leaving a starburst pattern of the where the bike had travelled while it was stationary. This no longer happens - after a couple of seconds of being restless, the XT shows the bike as being completely stationary. It seems to stop processing the signals if there is very little movement between fixes. I have observed that this can sometimes cause problems when setting off on a route selecting closest entry point. The satnav doesn't know which way you are facing. It works it out from successive fixes, and of course this can be wrong. If you do not allow U-turns, and the satnav thinks you are facing the wrong way - it can come up with some weird results when selecting Closest Entry Point !!

Becasue of this, if I ever wish to use CEP, I select the option on the screen, but I don't press Go until I have been moving for a short distance.

 

[Al st1100]

somehow even ardykay54 gets to the right spot with a gps and no drama ...eventually