Home › Microsoft Streets and Trips › A bug related to converting files w/pushpins to a new Streets & Trips version
Kathlene really first brought this issue to attention on the Forum in her thread Reading old version files in new version of Microsoft Streets and Trips. It took me a while to figure out what was going on but this is what I think it is.
When you upgrade a file from an older version (say 2010 over 2007) the pushpins show data in the balloons that you did not intend them to. And it is the same data for all the pushpins. In her example, you can see one address in all the flags/balloons when she first converted. That really shouldn't happen.
Fortunately, the work-around is not too horrendous. If you cut the pushpin and immediately paste it back into the same map, that spurious data will be wiped. That is, select the pushpin, right-click, Cut, and then Alt-E-P to restore the pushpin.
Maybe this can be fixed in 2011.
When you upgrade a file from an older version (say 2010 over 2007) the pushpins show data in the balloons that you did not intend them to. And it is the same data for all the pushpins. In her example, you can see one address in all the flags/balloons when she first converted. That really shouldn't happen.
Fortunately, the work-around is not too horrendous. If you cut the pushpin and immediately paste it back into the same map, that spurious data will be wiped. That is, select the pushpin, right-click, Cut, and then Alt-E-P to restore the pushpin.
Maybe this can be fixed in 2011.
I tested it in 2009 and 2010 and it produces the same result. It has that same spurious address in the address fields of all the pushpins after it runs through the matching.
Two things:
1. If you look at the Data Set properies you see that all of the imported pushpins show as "Matched by hand". That suggests to me that all of the pushpins in the original file were, in fact, placed manually and have actual location coordinates associated with them.
So matching is really unnecessary but the conversion routine insists that it has to be done.
2. If you look at each pushpin's individual properties you'll see that the "Matching data" is shown as that spurious address.
It looks like the matching routine thinks it has to use something to match on, even though matching is unnecessary. And when it does that it places that bogus address into the address fields of each pushpin.
What isn't clear is where it's pulling that bogus address from.
But it's clearly a bug in the conversion routine and it looks like it was introduced earlier than 2010. It's also in 2009.
Yo, Larry! Are you reading this? Can you report it to someone?
...ken...
Two things:
1. If you look at the Data Set properies you see that all of the imported pushpins show as "Matched by hand". That suggests to me that all of the pushpins in the original file were, in fact, placed manually and have actual location coordinates associated with them.
So matching is really unnecessary but the conversion routine insists that it has to be done.
2. If you look at each pushpin's individual properties you'll see that the "Matching data" is shown as that spurious address.
It looks like the matching routine thinks it has to use something to match on, even though matching is unnecessary. And when it does that it places that bogus address into the address fields of each pushpin.
What isn't clear is where it's pulling that bogus address from.
But it's clearly a bug in the conversion routine and it looks like it was introduced earlier than 2010. It's also in 2009.
Yo, Larry! Are you reading this? Can you report it to someone?
...ken...
I have seen that happen well before S&T 2009 if the address could not be found. It would place some spurious information from the pushpin set and you couldn't get rid of it short of deleting the pushpin.
Terry
Terry
I need to make one correction to my post above. I said that it's obviously a bug in the conversion routine but that's not technically supportable by the evidence.
Upon reflection, it's more likely it's in the matching routine.
The conversion routine probably has no way of knowing whether matching is necessary or not so it just forces the matching routine to run through the input file, just in case.
It's more likely that the matching routine -- which in my experience does a variety of wacko things in order to try to force a match and never warns you of the silly things it's done -- is the culprit here.
...ken...
Upon reflection, it's more likely it's in the matching routine.
The conversion routine probably has no way of knowing whether matching is necessary or not so it just forces the matching routine to run through the input file, just in case.
It's more likely that the matching routine -- which in my experience does a variety of wacko things in order to try to force a match and never warns you of the silly things it's done -- is the culprit here.
...ken...
Similar Topics