Shaping Points Advice

Wapping said:
Given that there appears to be a problem of some sort with some devices (only when making a recalution for the rider going off route) then taking into account shaping points ....
Click to expand...

No. there's more to it. See my post #56 above (last paragraph)
I asked the device to take me from a Start Point to an End Point - no shaping points involved on the planned route. On that occasion it tried to route me round a housing estate with only one way in, and one way out; then, routed past the Start Point. Go figure !!!

Wapping said:
When creating a route, I ask my BaseCamp running Mac to generate A to B. I then drag the magenta line to travel along the roads I want to take, nailing it with shaping points or - to be more exact - software generated waypoints that I then manually convert to unannounced shaping points. If the shaping point I put in fixes the route where I want it to go, I don't add another two or three just for the sake of it. Sometimes I do have to go back and do a little re-fixing as a change lower down the route might alter something I'd already done but that I can live with. John tells us he uses more shaping points, deliberately adding them to fix junctions; maybe it might be an idea to have a go using less, perhaps? It can't hurt and nothing will break.
Click to expand...
That's how I do it, too; and I'm sure how Garmin want us all to do it. Nothing wrong with it at all, it works, but of course you're planning the route using the software... :beerjug:
 
Richard I think the point of the matter is for me at least, when you have seen something that works and you have something that doesn't, (and i say this with reservation because i dont know whats right or wrong, but looking at the way The grey Ones Route Worked, i would guess that its the right way,) I am the type of person who wants to know why.
 
Oh, I agree it's an interesting enough investigation, handicapped to some degree or another by assorted variables.

For what it's worth. When I encountered the bizarre recalculation result in the German town, I could see that the device was splitting the single route into two, though maintaining one magenta line and giving bizarre instructions to turn left back towards and into a tangled magenta mess, when the very obvious thing was to turn right and get back to where I should be going.

By zooming right out I could see my correct route ahead of me to the right, with all its little blue shaping points stretching away towards my final destination, and all the device generated nonsense away to the left. I navigated myself back onto the route. It took the device about a minute to realise I was back on route (it does this sometimes when I go off route and then back on again) during what I call 'the lost minute' it gave no routing instructions beyond 'Drive to xyz strasse'. The lost minute lack of instructions stops just as soon as the device realises I am back on route again.

This suggests to me that there are at least three distinct operations being carried out within the device:

1. The detecting of satellite signals and their use to triangulate a vehicle's position, speed, height and direction along with the local time

2. The rendering onto a screen of a map, a magenta route line (along with any owner created way and shaping points) and a cursor to represent the vehicle's position

3. The separate integration of points 1 and 2 into a route sufficient to give instructions like, turn left in two hundred yards

I think that in the lost minute and maybe in parts of recalculation (when I assume the device might struggle) some aspects of the three somehow get lost or forgotten about. The device then sometimes catches up with itself and corrects (or not) its mistakes. I agree though, the how and the why are interesting.

It might make sense for the device to route a bod back through a missed shaping point and down the road that came after it; after all that is the way the owner had told the device he wanted to go. But that will only happen if the device is instructed to recalculate or is set to do it automatically. That the device then struggles - due to an off route recalculation, demanded of it by the same owner - to make the obvious leap of logic that it would be silly to go backwards and maybe impossible if the road itself is closed, is another matter entirely.

I am now wondering if the 'deviation' button works differently, paricularly in reasonably small roadworks, as opposed to full recalculation and / or to going miles off route by error or because a bod just fancied it..... time and if I ever push it, will tell.
 
"Quote Originally Posted by The Grey One View Post
Could the devices simply be using these limits to calculate a theoretical "fastest" time?
That depends on the speed parameters you've set in Basecamp/Mapsource software."

The speed settings in Mapsource/Basecamp only really effect routes during the planning process. I was referring to what happens within the device when it calculates. In that case I suspect it uses its own data for each road and therefore "sees" narrow lanes as 60 mph and certain other roads as having lower limits. This was just a suggestion as to a possible cause of dubious routing that has been reported by several on here. Were it possible to transfer riding speeds to the device then we might have a possible solution to this problem.

I also suspect that the devices build a picture of the users riding speeds which it uses to predict arrival times.

John
 
The Grey One said:
The speed settings in Mapsource/Basecamp only really effect routes during the planning process. I was referring to what happens within the device when it calculates. In that case I suspect it uses its own data for each road and therefore "sees" narrow lanes as 60 mph and certain other roads as having lower limits. This was just a suggestion as to a possible cause of dubious routing that has been reported by several on here. Were it possible to transfer riding speeds to the device then we might have a possible solution to this problem.
Click to expand...
We've come full circle on this one.
The specific data needed to perform that function can (realistically) only be incorporated into each new mapset, as they are produced and released.


The Grey One said:
I also suspect that the devices build a picture of the users riding speeds which it uses to predict arrival times.
Click to expand...
Personally, I doubt very much the device software is that sophisticated.
If you think about it, it would require enormous processing power - which the 660 & Nav IV certainly don't have - hence the time-delays when it is calculating a route; it would need historic data of road conditions - which they don't possess and, nor can they access; and it would spend most of its time on a data collection exercise, and then transferring said data back to Garmin's HQ.

ETA predictive modelling is probably based around given speeds for particular roads - and while a great many satnav units do calculate-out ETAs based on traffic conditions - I believe this is well beyond the capabilities of the software in these devices; so, back to squaring that circle again, it is most probably attached as a value to a given road.
 
JoeBiff said:
We've come full circle on this one.
The specific data needed to perform that function can (realistically) only be incorporated into each new mapset, as they are produced and released.



Personally, I doubt very much the device software is that sophisticated.
If you think about it, it would require enormous processing power - which the 660 & Nav IV certainly don't have - hence the time-delays when it is calculating a route; it would need historic data of road conditions - which they don't possess and, nor can they access; and it would spend most of its time on a data collection exercise, and then transferring said data back to Garmin's HQ.

ETA predictive modelling is probably based around given speeds for particular roads - and while a great many satnav units do calculate-out ETAs based on traffic conditions - I believe this is well beyond the capabilities of the software in these devices; so, back to squaring that circle again, it is most probably attached as a value to a given road.
Click to expand...

I have had numerous instances of routes transferred to different devices all showing different journey times. I used to run a biker hotel in Austria were I had a big selection of routes for our guests to use. As most of these routes were over mountain passes there was very little scope for a device taking other roads, mostly there was only one road! Each day during the season I would load routes for our guests, anything up to 10 units each day. I would always take each device and set them to the same preferences and avoidance. Obviously I had little control over the maps installed or the software version but on several occasions I was able to confirm identical maps and software. Even when everything was identical the journey time varied. There must be a reason for this and I still think the devices learn how the user rides. Information on average riding speeds can be viewed on all Garmin devices so it is not a huge leap to think it might use these average speeds to work out how long a route might take. Obviously to work out such times it must use information as to average times on different types of roads.

John
 
The Grey One said:
...
Information on average riding speeds can be viewed on all Garmin devices so it is not a huge leap to think it might use these average speeds to work out how long a route might take. Obviously to work out such times it must use information as to average times on different types of roads.
Click to expand...

Certainly not difficult.
But if any of the devices actually did that, don't you think the manufacturers would be shouting long and loud as a USP to raise their unit above the competition? In the same way that TomTom shout and laud their "wavy, wiggley roads" feature.
Nah, I don't buy it. These particular units aren't that sophisticated.
I remain convinced the speeds are incorporated into the mapping (along with other data).
 
JoeBiff said:
Certainly not difficult.
But if any of the devices actually did that, don't you think the manufacturers would be shouting long and loud as a USP to raise their unit above the competition? In the same way that TomTom shout and laud their "wavy, wiggley roads" feature.
Nah, I don't buy it. These particular units aren't that sophisticated.
I remain convinced the speeds are incorporated into the mapping (along with other data).
Click to expand...

If that were the case you would not expect variations in arrival times where everything else is identical. Something is causing different times for identical routes.

I too think that speeds are incorporated in the mapping information, they must be for there to be a calculation possible as to travelling time. I also think these times are modified according to what the device knows about actual riding speeds of the user. This, I think is a possible reason for variations in arrival times.

Garmin, by the way has its own version of the TomTom winding road feature they call it curvy roads

John
 
My three Nav V's, which are set up identically but sometimes not all used on a bike for several months, all give different estimated times for the same journey.

The speed data of each road (where available) is held on the map, along with whether it is described as a motorway or a broken road or for that matter where a restaurant or fuel station is situated.

By default, the Nav V shows the speed limit for the road being ridden, alongside the bike's current speed. For some roads, where I assume no data is available in the map, no speed limit is displayed. These are comparatively rare. For obvious reasons, 'unlimited' German motorways display no speed limit on the devices.

For roads where no speed limit is known, I can only assume the software makes an assumption as to the speed a vehicle will make.
 
I've pulled the following response, written in 2009, which may answer some of the issues being discussed here:

"Thank you for contacting Garmin Europe.

There are speed limits programmed into the mapping data which tells the units what the ETA should be in theory. Sometimes the speed limit maybe too high which means the ETA initially will be too soon but if the speed limit on the road is too low then the ETA will be longer then it needs to be.

The units do recalculate every few minutes to take into account the previous few minutes of driving, once the unit has updated the ETA this should be a better indication of your ETA however there could be more road speed limits that are slightly out along the route causing the ETA to be out. When we release mapping updates there will also be updated speed limits included in these updates.

Mapping isn't owned by Garmin which is why there is a charge to update mapping, the data we use is provided by a company called NAVTEQ who are seen as one of the best digital mapping providers in the world.

It's not something that we control as the data that the ETA uses to predict the arrival time is embedded within the mapping software which Garmin do not own. As you are experiencing issues with the ETA that would suggest to me that you are using an older mapping version; purchasing the latest version and installing this onto your device will allow it to use the updated road speeds that NAVTEQ have provided.

During testing that we have been performing we haven't found an issue with the ETA and found it to be accurate considering it's an estimated time of arrival."

NAVTEQ have now morphed into HERE, as part of the Nokia Group.

So, while the device clearly doesn't have an inbuilt memory of road speed history from which to calculate an ETA, there is the likelihood that any data captured and sent back to Garmin (you can tick the box to allow this data collection, or not) may well include average road speeds over the different roads travelled, and at the different times of day. Such data may be disseminated to the map providers to increase the accuracy of their products.
 
One thing I have noticed since the last update. More UK roads with no speed limit indicated!
30 MPH usually.

Wapping said:
My three Nav V's, which are set up identically but sometimes not all used on a bike for several months, all give different estimated times for the same journey.

The speed data of each road (where available) is held on the map, along with whether it is described as a motorway or a broken road or for that matter where a restaurant or fuel station is situated.

By default, the Nav V shows the speed limit for the road being ridden, alongside the bike's current speed. For some roads, where I assume no data is available in the map, no speed limit is displayed. These are comparatively rare. For obvious reasons, 'unlimited' German motorways display no speed limit on the devices.

For roads where no speed limit is known, I can only assume the software makes an assumption as to the speed a vehicle will make.
Click to expand...
 
"Response written in 2009", didn't someone complain about talking about obsolete software?

I think things have moved on since 2009, Garmin were still producing mapping for my old 2610 in those days. Wapping tells us he has three identical Nav Vs which produce different journey times. I have seen this same phenomenon, devices using the same software version, the same mapping, with all settings identical and yet arrival times vary.

I don't think there is any argument about the software using road speed information to calculate journey times the issue is what causes these variations. Clearly if we have variations there must be something other than the software version, map version or device settings involved.

John
 
The Grey One said:
"Response written in 2009"
Click to expand...
The Nav IV and 660 devices were around in 2009.

The Grey One said:
Wapping tells us he has three identical Nav Vs which produce different journey times. I have seen this same phenomenon, devices using the same software version, the same mapping, with all settings identical and yet arrival times vary.
Click to expand...
While Wapping doesn't say by how much he has noticed them vary - the reason may be in the explanation given in the italic text at post #91. :thumb2

The Grey One said:
.......... the issue is what causes these variations.
Click to expand...
The italic text body gives an clear explanation, in my mind. :thumb2

The Grey One said:
Clearly if we have variations there must be something other than the software version, map version or device settings involved.
Click to expand...
Back to the italic text...
 
Take a newish sat nav that has been used regularly, load a known route that you have used before a few times go outside so that it locks on to satelite reception and note time to destination, reset the sat nav do a hard reset. and then load the same route, and note the time to destination, this may answer your question with reference to learning and remembering time, as by doing a hard reset you are setting the unit back to factory and wiping any stored data, so you may be getting rid of any apparently stored memmory of speed and routes. I am not saying this will prove anything just an idea.
and remember to set your settings as before the reset.
 
JoeBiff said:
The Nav IV and 660 devices were around in 2009. So they were but the software and mapping has been updated many times since then so I still think a 2009 explanation is of little use[/I]


While Wapping doesn't say by how much he has noticed them vary - the reason may be in the explanation given in the italic text at post #91. :thumb2 I can't see any explanation of difference in this. It explains how it works so one would assume it would work exactly the same on every device. The fact that it does not suggests that it is not a complete explanation


The italic text body gives an clear explanation, in my mind. :thumb2 It only tells us what we know, that the software uses the speed information in the mapping. What else is happening?


Back to the italic text...
Click to expand...
Simplistic answer to the question, as I said we know that, it does not take our understanding any further and it's referring to mapping and software that I doubt any of us are using now. Of course the newer version do this but do they do something more?

This whole subject is of little more than of accademic interest as the variations in arrival time are usually of little concequence. That said I would like answers and I have yet to see an alternative to the theory (and that is all it is until proved) that the device adapts to the riding speeds of the user. So if we accept that differences exist, and I think that is allready proved, then should we not look for an answer? It can't by definition be something that is fixed, either in the mapping or the device software. We are looking for another variable so it is not helpful to keep refering to known fixed parameters.


John
 
The Grey One said:
..........
We are looking for another variable so it is not helpful to keep referring to known fixed parameters.
Click to expand...

Re-read my post #91..
"The units do recalculate every few minutes to take into account the previous few minutes of driving..."
That is an indicator of your elusive and indeterminate "variable"......

As you say, the whole subject is of little more than academic interest. I can accept Garmin's explanation and I fully understand the inherent differences between devices.

Ride safe.
 
JoeBiff said:
Re-read my post #91..
"The units do recalculate every few minutes to take into account the previous few minutes of driving..."
That is an indicator of your elusive and indeterminate "variable"......

As you say, the whole subject is of little more than academic interest. I can accept Garmin's explanation and I fully understand the inherent differences between devices.

Ride safe.
Click to expand...

I'm sorry but nothing in that explains why journey times are shown as different before a route is ridden. This is the difference I am talking about and therefore cannot be explained by the recalculation you mention because that can only happen once underway.

John
 
Nippy Normans supply Touratech, Wunderlich, Desert Fox and many other makes of accessories.
You must log in or register to reply here.

Similar threads

Garmin - Starting a route at a via point, plus shaping point behaviour
Replies
8
Views
563
Wapping
Wapping
Mzokk
  • Sticky
Going Direct - aka Navigating past a wonky bit on a Garmin/Here/Basecamp/map.
Replies
4
Views
354
Mzokk
Mzokk
Wapping
Amending a route to match a track on an iPad
Replies
0
Views
326
Wapping
Wapping
Mzokk
Review of Tourstart
Replies
4
Views
483
Mzokk
Mzokk
Wapping
  • Sticky
Using MRARouteplanner created routes on the BMW ConnectedRide Navigator
Replies
2
Views
907
Wapping
Wapping


Back
Top Bottom