HomeMicrosoftWish List

Stops should be at exact addresses, instead of the closest intersections
Marvin Hlavac

A user brough this issue to my attention:

My ongoing problem with ALL earlier versions Microsoft Streets and Trips (and MapPoint) is that when using it as a route planning tool, its default method of locating Stops generates erroneous routes. I'm curious if this behavior has been addressed or if anyone has a way around the situation given the data below:

(Import this simple comma delim. Text file with a header row)

Name, Address, City, State
A, 95 Maple St,Carteret,NJ
B, 29 Thornal St,Carteret,NJ
C, 23 Matthew Ave,Carteret,NJ
D, 37 Matthew Ave,Carteret,NJ
E, 182 Washington Ave,Carteret,NJ
F, 20 Catherine St,Carteret,NJ
G, 287 Washington Ave,Carteret,NJ
H, 6 Mary St,Carteret,NJ
I, 20 Duffy St,Carteret,NJ
J, 12 Duffy St,Carteret,NJ

Once imported, you'll see the pushpins get located as expected. Now 'Add Pushpins as Stops' and you'll notice that the route Stops adjacent to Street intersections get placed at the center of an intersection. This may not be a big deal for a small route like the one above, but imagine a dataset 10 times this size. The problem is Driving Directions (generated from these mis-placed stops) are at best inefficient, or more usually (in a city setting) not possible to execute on the ground. For example, navigating from G to H, Directions joined these into a single stop (stops 3 & 4) not reality. Proceeding on to F (Stop 5), the Directions won't specify the right turn required, they merely assume you're on route at a point in the adjacent intersection; again not reality, and also not possible (legally) if this happed to be a one way street opposing. Proceeding on to C (Stop 7, misplaced in the intersection beyond, and combined with Stop 8), the Directions would have you making a left turn at (Stop 6) which is actually further down the road, past the intersection. A backup / turn around would be required.

The Driving Directions are 'correct' given the placement of route Stop nodes, it's just that Streets and Trips won't [properly] place Route Stop objects like it does for Pushpin objects. I can only assume there is technical reason for this, but the practical result is that in order to get workable driving directions, one is forced to visually pour over the mapped dataset (large in my case) and hopefully locate these misplaced nodes and manually 'back them up' from the intersection, on the proper street (at a point further back from its associated pushpin), until the Route Stop object no longer wishes to snap to the intersection. This is further complicated in cities where block segments between intersections are too short to place the Route node out of the snap aperture of either intersection; forcing one to choose between 2 'wrong' locations and the attendant Driving Directions error. I realize that I'm asking a lot of a toy program like S&T to route hundred(s) stop route datasets, so I sprung the $$ for Map Point, as more business grade application, but it suffers with same defective route placing engine, so I abandoned that.

In short, I need a method of decreasing the Route node snap aperture, so I don't have to deliberately misplace stops to generate valid driving directions. Secondly, I need Streets and Trips Driving Directions to route for arrival in FRONT of a given stop, and not assume I have arrived simply because I am along side the property at a nearby intersection. This is because the next stop may be in a different direction or the street may be a one way.

Thanks to anyone who devoted the time and attention to follow this complex issue. I have always considered it a 'bug' but never have had time (until now) properly make my case (given the length of this post you can see why!).
I wish the S&T team would set their product up on the bug-tracking database at Microsoft Connect. More so than any other type of product, a navigation product can only be tested in the real world, in the field.

As I've said before on this board, S&T's core engine is starting to creak after a decade of service. There are a bunch of 10-year-old bugs that seem to be caused by technical limitations, such as the slow redraw on GPS updates, the crash if you leave the GPS on too long, etc. (I have no inside information -- these are just guesses but they feel like technical limitations, just like this bug.) There was tantalizing code about a complete ground-up rewrite of S&T in managed code two years ago: http://blogs.msdn.com/mappoint_b2b/archive/2006/03/06/544277.aspx. But nothing ever came of it, and the team seems to have been devoting its energies to the website instead of the boxed product.

As far as I am aware, there is no deliberate crippling of S&T vis-a-vis Mappoint. (e.g. this kind of bug is not like, say, Selective Availability on GPS, where it's fixed for the premium users but degraded for the standard users.) Mappoint simply exposes an API, which S&T doesn't.
Marvin Hlavac
This issue is still present in the new Streets & Trips 2010.
I wonder if a simple program could be written to convert a data base like the one in the example to a GPX file that could then be imported, routed, and optimized.
Ken in Regina
It's a simple comma delimited list so something like GPSBabel should be able to do the conversion. You might need to jigger the list a little to get things in the right order but it should work.

I'm not sure how importing a GPX file would help? If I understand the problem correctly the issue only arises if these addresses are designated as stops.

That is, I can import a list like that from, say, an Excel spreadsheet into a pushpin group. S&T will find the locations for the addresses in the list and create the pushpins. I can then ask S&T to create an optimized route for the pushpin group and the points in the route will be in the correct locations.

But if I designate the addresses in the list as stops you get the problem described.

Not sure how importing a GPX file would overcome that.

Of course I might be misunderstanding the problem. ??

I think the problem is that when S&T 2010 creates route stops from pushpins it does not locate the stop exactly at the pushpin location. Rather, it locates the stop to a nearby intersection of two roads on the map.

My suggestion is that perhaps one could export an xml GPX file of the correctly-located pushpins and then augment it so that it includes a corresponding set of route stops with the exact appropriate location parameters of the pushpins.

That file could then be re-imported into S&T and serve as the basis for a new route calculation. It is just an idea; I know very little about GPX files and defer to those wiser than me.
Marvin Hlavac
There may be some long-winded work-around, but the S&T issue remains. And most users will not go to all the trouble of searching or implementing work-arounds for this. There are people out there who use Streets & Trips (or MapPoint) on a daily bases to do their multi-stop routing. A routing in some cases can be much less than optimal if a stop (or several stops) is (are) placed in the middle of an intersection instead at a particular address at the correct street.

This is a serious issue, and I'm surprised this has not been discussed more, and it hasn't yet been corrected. I think, by reading the first post, and by looking at the screen shot, it can easily be understood how this "imperfection" of placing stops can affect the quality of routing.
laptopgpsworld.com About