I am a novice user and am looking for an application that would help me to create routes.
I downloaded the trial version of Streets and Trips 2010 and have started playing with it. I can import multiple locations but then have to select the Start, End and Stops. Is there some way for me to add this information to the import file so that I just have to click 'get directions'
Can I do this with the Microsoft product or is there another app that would be easier for me to work with?
I downloaded the trial version of Streets and Trips 2010 and have started playing with it. I can import multiple locations but then have to select the Start, End and Stops. Is there some way for me to add this information to the import file so that I just have to click 'get directions'
Can I do this with the Microsoft product or is there another app that would be easier for me to work with?
Hello Cannuck,
Welcome to the forum!
Great question. If you are importing from a csv or xls file then the answer is no. You will need to manually choose the order of stops. After importing the pusphin set you can right-click on the pushpin set name in the legends and overview pane and choose "add pushpins as stops". then move your starting and ending points into position manually using the arrow buttons. Next hit "optimize stops" and it will re-order all the waypoints inbetween to give you the most efficient route.
In S&T 2010, because of the GPX support, you can import the file and if it constains route info it will populate the route planner pane. I have attached a simple route in GPX form that you can import to see how this works.
Welcome to the forum!
Great question. If you are importing from a csv or xls file then the answer is no. You will need to manually choose the order of stops. After importing the pusphin set you can right-click on the pushpin set name in the legends and overview pane and choose "add pushpins as stops". then move your starting and ending points into position manually using the arrow buttons. Next hit "optimize stops" and it will re-order all the waypoints inbetween to give you the most efficient route.
In S&T 2010, because of the GPX support, you can import the file and if it constains route info it will populate the route planner pane. I have attached a simple route in GPX form that you can import to see how this works.
[Oops, I must have posted this at almost the same time as Larry.]
Make sure you have the "Legend and Overview" pane showing. If it's not, click the icon on the toolbar that looks like a shopping list.
After the data import wizard is done, you will see a Pushpin set with the name of the file you just imported.
Right-click on the Pushpin set name and select "Add pushpins as stops".
Open the Route Planner (click the car icon on the toolbar) and you will see all of the items from the pushpin set have been added to the route planner.
You can just click the "Get directions" button and Streets&Trips will calculate the shortest route that includes all of the pushpins.
It's not really easy to figure out ... took me fifteen minutes. But if you use Streets & Trips quite a bit, you will find that for doing routes like this it is the most powerful of all the PC nav programs.
The biggest shortcoming I find is the way it handles matching. If it finds the addresses properly it's really a great tool. If it has a problem it will cause you to tear your hair out!!
It will always match on something. If it can't find a match on the actual street address, it will match on the City (not terribly useful in any location with a population larger than 50). If it can't match on the address or City, it will match on the province (even less useful). So it won't give you any errors to warn you that it really did not find any useful match.
To determine how the matching went, you have to right-click the pushpin set, get the Data set properties and click on the "Matching" tab to see what match was used for each item in the list.
It gets worse. If you don't like the way it matched -- say it matched on City instead of address because the street name is spelled differently in the map database than in reality -- there is no simple way to force a change that I can find. At this point it becomes very much a trial and error exercise, usually requiring making changes in the original data file, reimporting and checking the matches again to see if the change got you the right match this time.
I would be interested in any tips if there are better ways to fix Streets & Trips matching errors. If it was easy to fix them it would really improve the usability of the bulk matching function immensely.
What would be better is to allow an override to the automatic mapping routine. That is, if it can't find a match on Address, stop and let me decide if I want to either change the address or let it match to City.
Streets&Trips default matching heirarchy is not terribly useful most times and it's especially annoying because it never warns you that it's doing it.
...ken...
Make sure you have the "Legend and Overview" pane showing. If it's not, click the icon on the toolbar that looks like a shopping list.
After the data import wizard is done, you will see a Pushpin set with the name of the file you just imported.
Right-click on the Pushpin set name and select "Add pushpins as stops".
Open the Route Planner (click the car icon on the toolbar) and you will see all of the items from the pushpin set have been added to the route planner.
You can just click the "Get directions" button and Streets&Trips will calculate the shortest route that includes all of the pushpins.
It's not really easy to figure out ... took me fifteen minutes. But if you use Streets & Trips quite a bit, you will find that for doing routes like this it is the most powerful of all the PC nav programs.
The biggest shortcoming I find is the way it handles matching. If it finds the addresses properly it's really a great tool. If it has a problem it will cause you to tear your hair out!!
It will always match on something. If it can't find a match on the actual street address, it will match on the City (not terribly useful in any location with a population larger than 50). If it can't match on the address or City, it will match on the province (even less useful). So it won't give you any errors to warn you that it really did not find any useful match.
To determine how the matching went, you have to right-click the pushpin set, get the Data set properties and click on the "Matching" tab to see what match was used for each item in the list.
It gets worse. If you don't like the way it matched -- say it matched on City instead of address because the street name is spelled differently in the map database than in reality -- there is no simple way to force a change that I can find. At this point it becomes very much a trial and error exercise, usually requiring making changes in the original data file, reimporting and checking the matches again to see if the change got you the right match this time.
I would be interested in any tips if there are better ways to fix Streets & Trips matching errors. If it was easy to fix them it would really improve the usability of the bulk matching function immensely.
What would be better is to allow an override to the automatic mapping routine. That is, if it can't find a match on Address, stop and let me decide if I want to either change the address or let it match to City.
Streets&Trips default matching heirarchy is not terribly useful most times and it's especially annoying because it never warns you that it's doing it.
...ken...
Quote:
Originally Posted by Larry
... If you are importing from a csv or xls file then the answer is no. You will need to manually choose the order of stops.
Worked perfectly for me. Did I do something wrong??
...ken...
Sorry for the confusion. What I was trying to say was:
IDW (import data wizard) - you need to do the extra steps such as add the pps as stops and re-order as the order in which these stop appear in the route planner pane is not tied to the order in the xls.
GPX - the waypoints are automatically placed in the route planner in the proper order and you just need to click "get directions" and that is all.
For Ken::
I have attached the testing csv files that show that:
1) the import order is not maintained (import the "OrderedRoute" sheet)
2) the matching dialog appears if there is a choice for the user to make. (MatchingDialog). S&T correctly geocodes the typo's and places the pushpins correctly (More Lake Dr goes to Moore Lake Dr.) and it finds 2 addresses that it cannot find a correct dialog so it shows the matching dialog and gives you a couple choices or an option to skip it the address.
I am guessing that for your test the order just happened to match what you expected but this usually not the case using IDW. (unfortunately)
note: the addresses in these files are totally random using hit detect.
the ".txt" will need to be removed before importing.
IDW (import data wizard) - you need to do the extra steps such as add the pps as stops and re-order as the order in which these stop appear in the route planner pane is not tied to the order in the xls.
GPX - the waypoints are automatically placed in the route planner in the proper order and you just need to click "get directions" and that is all.
For Ken::
I have attached the testing csv files that show that:
1) the import order is not maintained (import the "OrderedRoute" sheet)
2) the matching dialog appears if there is a choice for the user to make. (MatchingDialog). S&T correctly geocodes the typo's and places the pushpins correctly (More Lake Dr goes to Moore Lake Dr.) and it finds 2 addresses that it cannot find a correct dialog so it shows the matching dialog and gives you a couple choices or an option to skip it the address.
I am guessing that for your test the order just happened to match what you expected but this usually not the case using IDW. (unfortunately)
note: the addresses in these files are totally random using hit detect.
the ".txt" will need to be removed before importing.
Getting the hang of this, thank you very much for the posts and the very quick 'How to'!!
Quote:
Originally Posted by Larry
I am guessing that for your test the order just happened to match what you expected but this usually not the case using IDW. (unfortunately)
When I created the test file I did enter them in roughly the right order for a decent route.
However, after I read your reply about having to make Streets optimize the route I intentionally shuffled the order in the import file, as I mentioned in my last post.
After importing, I checked the dataset properties Matching tab and it looks like they came in in the same order as in the import file.
I did not look at the order in the route planner after I clicked to send the dataset to the route planner as stops. I just poked the "Get directions" button and had a good route without any other action.
I did some more testing after reading your comments. Again, I made sure my test file was ... well, not random but intentionally in a really stupid order.
For the record, the stops are not in one city. They are spread across western Canada, from Regina to Vancouver. So it's easy to force them into an order that will result in a really stupid route if Streets tries to use them in anything but one specific order.
This time I paid more attention as I went through the steps. And here's where it gets really interesting....
You can't fool the Route Planner!
That puppy is doing some routing even as you add stuff to it.
A) I checked the Matching tab in the Dataset properties to verify that the list came in in the same order as the import file, eg. will produce a totally wacked route if used in this order. Then, after I clicked to add the pushpin set as stops I opened the route planner pane and ... ??? ... what the heck?? They're already arranged in the right order!!
I did this three times, first mixing the import file into a different order each time, verifying in the Pushpin properties Matching tab that they came in in the order expected and then clicking to add the pushpin set as stops. Every time, when I clicked up the route planner pane, there they sat in the correct order for a good route. !!!
B) I figured you might be tempted to suspect the Import Data Wizard again, as you did in your last post so best I do some more testing to completely rule that possibility out.
With an empty route planner and the pushpins displayed on the map, I clicked them one at a time and added each as a stop. ... Note that I did NOT add any of them as a Start or End. I added every one of them as a Stop and I did it in an intentionally wacko order so that using them in the order I added them would have me crisscrossing western Canada for thousands of extra miles.
I watched the route planner pane as I added each one. As the second, third and Nth pushpins were added, the route planner instantly slotted them into the correct order for a good route.
Note, it did NOT ever add them into the next empty slot in the route planner if that was not the right place in the routing order.
So, the route planner is doing the routing live, as the pushpins are added, whether you add them individually or as a batch. All the "Get directions" button seems to do is just draw the squiggly line on the map and make up the directions text. The routing was already done as the stops were added.
Interesting.
RE: Matching annoyances ... I'll take a look at your files to see what's different from my test file. I've never been able to throw anything at Streets that would make it pop a matching dialog for me. It ALWAYS matches to something. If it doesn't like the address, it just defaults to matching on the City. If it doesn't like that, it defaults to matching on the province.
One of my problem items is a misspelled street name -- "Wedden" on the map, "Weeden" in reality.
- If I use "Wedden" it finds the address.
- If I use "Weeden" it just defaults to matching on the City.
No dialog, no warning, no opportunity to tell it anything.
I haven't ever been able to find any combination of stuff that will cause it to give me an error or pop a matching dialog ... not in 2008, 2009 or 2010.
Is there a setting somewhere that controls this behaviour that I have not been able to find?
...ken...
After doing some tests and playing with wrong spelling and with or without postal codes, I see that if the software cannot make a match from the import file the location does not get 'pinned'. You would have to add it manually for it to appear.
Okay, I tested with the matching test files. I found a couple of things.
A) I guess I did not pay close enough attention to the dataset that results after the import data wizard is done. My names were random enough that I didn't notice what's actually happening.
It was quite obvious with yours that the list on the dataset properties Matching tab are ordered in alphabetical order by name, no matter what order you put them in the import file.
What I don't know is whether they are being ordered that way in the dataset as it is built or whether it's simply ordered that way for display in the Matching tab.
So, either the import data wizard is consistently ordering the imported items in default sort order as the new pushpin set is created or the Matching tab orders it that way for display purposes.
B) I'm not sure what order your "RouteOrder" test file is in. No matter what I did I wasn't able to get a route in the order according to your names in the file (eg. Start1, WP2, WP3, WP4, WP5, End 6). Perhaps that's because I did not make the same selections you did from the offerings in the matching routine popup (more on that below)?
I see what you mean by having to force the start and end points, depending on whether they will be obvious to the route planner or not. In my test file, the end points are so obvious (one stop is in Vancouver, BC, and another stop is in Regina, SK, over a thousand miles away) that route planner gets it right no matter what.
In your test set, the addresses are all in a relatively small cluster so the start point could be any arbitrary point and the end point will be determined by whatever start point is chosen, unless it's forced.
C) The matching routine is just plain wacko, no matter what you feed it.
I ran your matching test file through it. For the first time ever, I saw the matching dialog you described. Here's what happened with your matching test file:
- It doesn't like Oak Dr so it pops a matching dialog that allows me to select Oak Ave. That's nice. However, it places the resulting pushpin on Oak Ave but doesn't update the address, so the pushpin address still displays as Oak Dr, even though it's sitting on Oak Ave.
- It doesn't like 8555th Ave N so it pops a matching dialog that allows me to select 855th Ave in some other City. If I select that offering, it places the pushpin at the origin (beginning) of the line that is designated as 855th Ave. That's a big problem. It does not find the house number on 855th Ave in that other city but it doesn't tell you that. It simply goes to the source point on the line that is 855th Ave and places the pushpin. It does not update the address, so the pushpin address still displays as "833 8555th Ave N, Minneapolis, MN", even though it's actually sitting at 22715 855th Ave, Albert Lea, MN. That's the origin of 855th Ave in Albert Lea.
- "More Lake Dr" ... this is another example of what I hate most about the matching routine. I got no error and no matching dialog. It just selected a different address (Moore Lake Dr) and placed the pushpin there. It didn't tell me it did that. It didn't update the address in the pushpin. And on the Matching tab in the dataset properties it says it matched on Street Address. That's nonsense. It did not match on street address. It substituted a different street address without asking or warning. I really hate when it does that.
I have had similar types of address mismatches as the above three and I've never seen the matching dialog that I saw this time (re: my example of "Weeden/Wedden").
Is it possible that it only works that way when the country selected is "United States"??
...ken...
A) I guess I did not pay close enough attention to the dataset that results after the import data wizard is done. My names were random enough that I didn't notice what's actually happening.
It was quite obvious with yours that the list on the dataset properties Matching tab are ordered in alphabetical order by name, no matter what order you put them in the import file.
What I don't know is whether they are being ordered that way in the dataset as it is built or whether it's simply ordered that way for display in the Matching tab.
So, either the import data wizard is consistently ordering the imported items in default sort order as the new pushpin set is created or the Matching tab orders it that way for display purposes.
B) I'm not sure what order your "RouteOrder" test file is in. No matter what I did I wasn't able to get a route in the order according to your names in the file (eg. Start1, WP2, WP3, WP4, WP5, End 6). Perhaps that's because I did not make the same selections you did from the offerings in the matching routine popup (more on that below)?
I see what you mean by having to force the start and end points, depending on whether they will be obvious to the route planner or not. In my test file, the end points are so obvious (one stop is in Vancouver, BC, and another stop is in Regina, SK, over a thousand miles away) that route planner gets it right no matter what.
In your test set, the addresses are all in a relatively small cluster so the start point could be any arbitrary point and the end point will be determined by whatever start point is chosen, unless it's forced.
C) The matching routine is just plain wacko, no matter what you feed it.
I ran your matching test file through it. For the first time ever, I saw the matching dialog you described. Here's what happened with your matching test file:
- It doesn't like Oak Dr so it pops a matching dialog that allows me to select Oak Ave. That's nice. However, it places the resulting pushpin on Oak Ave but doesn't update the address, so the pushpin address still displays as Oak Dr, even though it's sitting on Oak Ave.
- It doesn't like 8555th Ave N so it pops a matching dialog that allows me to select 855th Ave in some other City. If I select that offering, it places the pushpin at the origin (beginning) of the line that is designated as 855th Ave. That's a big problem. It does not find the house number on 855th Ave in that other city but it doesn't tell you that. It simply goes to the source point on the line that is 855th Ave and places the pushpin. It does not update the address, so the pushpin address still displays as "833 8555th Ave N, Minneapolis, MN", even though it's actually sitting at 22715 855th Ave, Albert Lea, MN. That's the origin of 855th Ave in Albert Lea.
- "More Lake Dr" ... this is another example of what I hate most about the matching routine. I got no error and no matching dialog. It just selected a different address (Moore Lake Dr) and placed the pushpin there. It didn't tell me it did that. It didn't update the address in the pushpin. And on the Matching tab in the dataset properties it says it matched on Street Address. That's nonsense. It did not match on street address. It substituted a different street address without asking or warning. I really hate when it does that.
I have had similar types of address mismatches as the above three and I've never seen the matching dialog that I saw this time (re: my example of "Weeden/Wedden").
Is it possible that it only works that way when the country selected is "United States"??
...ken...
Quote:
Originally Posted by cannuck
After doing some tests and playing with wrong spelling and with or without postal codes, I see that if the software cannot make a match from the import file the location does not get 'pinned'. You would have to add it manually for it to appear.
You do need to right-click the pushpin set and check the Matching tab in the Properties window to see which ones it did not match. Sometimes it will make a match on something that's not obvious, it will place the pushpin somewhere you don't notice and it won't tell you.
Just because you don't immediately see a pushpin for an entry from the import file does not mean that Streets&Trips hasn't tried to put it somewhere on the map. It just might be somewhere you would never expect.
For instance, I had an entry with a misspelled street name and a misspelled city name. I included the province name (BC). So, instead of failing, it matched on Province. The coordinates for the arbitrary location of the province of BC is somewhere near the geographic centre of the province. Since the entry was for an address in a town on the #3 highway in southern BC, I didn't notice. If I had not checked the Matching tab I would have been completely baffled at why it was trying to make a route with a "detour" way up to the middle of the province.
I had a file of addresses in the City of Regina last winter to set up a snow removal route for a friend. Out of 36 addresses in the file, I noticed that a bunch of them were clustered smack in the middle of downtown Regina. I thought most of his clients were in residential areas so I took a closer look. There are eight addresses that it couldn't match the address so it matched just on the City instead. Then it placed all those pushpins right on the dot that is designated as the location for the city.
When I looked at the Matching tab, instead of saying "Not matched", it said it matched on City. Like that's really helpful!!! If I hadn't noticed that cluster of pushpins I would have done an optimized route for my buddy and then looked really stupid when he saw what I had done.
...ken...