'Stops' should be at exact addresses, instead of the closest intersections
A user brough this issue to my attention:
Quote:
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!).
|
|
May 16th, 2008, 10:05 AM
Linear Mode
Similar Threads