HomeMicrosoft


How to get an address from Streets & Trips given a pushpin setting?
StreetLady
Hello! I've been training myself on Microsoft Streets and Trips and can do with it many of the things I need to. Here is one issue I haven't been able to solve.

For context, I should let you know that I keep my address, etc. data in various Access tables, which I import into Streets & Trips when any data is changed. Each table's data has a different S&T pushpin symbol so I can tell them apart.

Sometimes, I need a pushpin group to include a location on the map for which I do not have an actual street address (call it "Quirk"). In my Access table, for the Quirk address, I can include a somewhat close street. When the set's been imported into S&T, I can find on the map more precisely where Quirk's pushpin should be and move it (thereby keeping the rest of Quirk's data for its balloon). That's fine for the first time.

But consider what happens when that Access table's data changes (some addresses deleted, others added). I do my normal procedure of deleting the associated pushpin set in S&T, then re-import that table/set from Access, and re-set the S&T pushpin symbol for that set. Everything's fine except for Quirk, which is again starting out in the wrong location. I need it to be more correct. And the cycle continues.

If only I had a way to get an approximate address from where I'd set my pushpin. But I don't see any way to get an address from S&T given a pushpin location. Or, if S&T could handle an intersection of 2 streets as an address, I could include that in my Access data. But, alas, S&T does not seem to be able to handle that. And any "close" but fake addresses get changed into really off locations. If I could get an address from something else, like GoogleEarth, that could work. But it also does not well handle these locations on the fringes of civilization.

It seems like there should be some kind of kludge to help this situation. If any of you who are much more expert at S&T have some ideas, please let me know. And, I realize I've probably not explained this well, so please ask questions if I can maybe make it clearer. Thanks!
SpadesFlush
Try the following to see if that might work for you.

As you probably know, S&T can find a location by either street address or map co-ordinates. If you do a search [ctrl-f] and go to the Lat/Long tab, you simply enter those co-ordinates, click the Find box, and then the OK box and S&T will drop a pushpin on that location with the name being the co-ordinates. All you need to do is rename the PP to suit your needs and move it to the appropriate PP set.

So the question then is how to get the co-ordinates. Fortunately, that is easy. When you do your initial find for the location and satisfy your self that you have got it right, double-click on the location to center the map there. Then, when you do the above the map co-ordinates will show in the Lat/Long Find box of above as part of the second sentence that begins "Example: The map is currently centered on latitude ...".

In other words, do the two steps in reverse order for an easy process flow.

I do not know if you can store Lat/Long co-ordinates in Access but, if you can, those should be importable to S&T as two further columns. I think S&T can import data that is a mix of street addresses and Lat/Long co-ordinates so long as you make sure the columns are properly imported.

Another thought might be to have separate PP set called say "Quirks" where you can store copies of your manually-found pushpins. Then when you create new sets from new Access tables, you can simply copy the appropriate PPs to the new set. So, every time you find a location and make a PP, make sure there is a PP copy in the Quirks PP set as well as the 'correct' set.
StreetLady
Thank you so much, SpadesFlush! Using your Latitude/Longitude approach works very well. I now have 2 more columns in the Access table, and S&T does import Quirk fine with that data.

Unfortunately...

Quote:
Originally Posted by SpadesFlush
I think S&T can import data that is a mix of street addresses and Lat/Long co-ordinates so long as you make sure the columns are properly imported.
...what you said there does not seem to work. I thought I read or saw in a video where S&T could handle such a mix of data importing methods, but now that the Lat/Long data is in for the one record, it ignores my other records with street addresses.

It looks like for any particular table, I have to choose between either street addresses or Lat/Long. That somewhat defeats the purpose of my nice one-to-one relationships of Access tables and S&T pushpin sets. Like you said, I might just have to break out a new table for Quirk and his future quirky buddies, and continually treat them as special cases. But at least when I've tracked down a Lat/Long once, I never have to re-do it.

In any case, you've helped me tremendously. I don't do GPS, so I hadn't been thinking in terms of Lat/Long, but now I realize there's a whole new world that I should not ignore. Thanks!
SpadesFlush
Glad to be of some help. And thank you for teaching me something in the process: I (obviously) did not know the inability to mix street-address and Lat/Long data imports as you say
Quote:
It looks like for any particular table, I have to choose between either street addresses or Lat/Long.
But, with some experimentation, I can confirm that your observations seem to be correct. In fact, it is even worse than that. It seems that even if your source data table has the column headings of lattitude and longitude, even without data in those columns, it will not import the address data! I did this in Excel but I see no reason for Access or other data base applications to perform any differently. It seems to be all down to the way S&T imports data.

So, there does not seem to be a way of creating a pushpin set of addresses for those locations where the addresses are not in S&T's native data base. Bummer. This should be fixed by Microsoft.

Of course, I suppose you could redefine all your location specifics in your data base to Lat/Long thereby creating one unified table for all addresses but I suspect this is more work than it is worth. The address information would be preserved in your pushpin balloon.
SpadesFlush
P. S. Even if you went to a data base matched to the Lat/Longs of your locations as suggested in my last paragraph above, you would not have to show that in the pushpin balloons. If you uncheck the appropriate boxes under the Balloon tab of the PP set Properties, that information will not be displayed.
StreetLady
Too bad I was right on the nix of the mixing of address and Lat/Long importing. It’s good you reproduced the procedure so we’re more sure of our findings.

Quote:
Originally Posted by SpadesFlush
In fact, it is even worse than that. It seems that even if your source data table has the column headings of lattitude and longitude, even without data in those columns, it will not import the address data! I did this in Excel but I see no reason for Access or other data base applications to perform any differently. It seems to be all down to the way S&T imports data.

So, there does not seem to be a way of creating a pushpin set of addresses for those locations where the addresses are not in S&T's native data base. Bummer. This should be fixed by Microsoft.
Yes. And with your extra experimentation, it does seem to be a real bug rather than just a design flaw.

If S&T can import with street addresses (which it can) and import with Lat/Long (which it can), then it’s not a difficult algorithm to add conditional importing methods.

What do you think is our best chance of getting Microsoft to recognize this as a legitimate bug to fix? (I don’t trust an email from a StreetLady to have any impact.)
~~~~~~~~~~
Quote:
Originally Posted by SpadesFlush
Of course, I suppose you could redefine all your location specifics in your data base to Lat/Long thereby creating one unified table for all addresses but I suspect this is more work than it is worth.
You suspect right -- at least for my case. I always have many more street addresses than Quirks. Segregating the latter lets them “feel more comfortable” with their own quirky kind without dumbing down the efficiency of the mainstreams.
SpadesFlush
I appreciate your retaining a sense of humor while discussing this problem which I can imagine is a real pain for you in day-to-day use.

With respect to a fix, you first should know that some responsible people at Microsoft monitor this forum and, in the past, have acted very constructively on points raised by forum posters. Posting here is probably better than sending an e-mail. On the other hand, it is apparent that Microsoft cannot deal with all issues raised here.

There is a long wishlist http://www.laptopgpsworld.com/wish-list of unfulfilled and sincere user requests, but it is outside of the scope of this forum to do anything other than point these things out and propose changes.

Similar issues with the workings of pushpins have been identified here in the last couple of years, maybe to the point that they represent a true concentration of design issues that would be appropriate for Microsoft to tackle. Probably the best thing we can do is to keep discussing these things as they come up.
StreetLady
Quote:
Originally Posted by SpadesFlush
I appreciate your retaining a sense of humor while discussing this problem which I can imagine is a real pain for you in day-to-day use.
Thank you. Good humor can keep the lassitude out of the latitude.

Quote:
Originally Posted by SpadesFlush
...some responsible people at Microsoft monitor this forum...
That’s nice to know. I wonder how popularity, urgency, necessity, etc. can play a role. For example (off main topic of this thread), I really, really, really want the ability to designate my choice of pushpin symbols in my Access tables for importing. I was shocked to find out in these forums that couldn’t be done. (I believe I learned that from you teaching others who were asking.) I never entered into any conversation on that topic, so until this moment, only my little lap pup knew of my pre-importing symbol wish. How many other people want that?

In other words, anyone (including Microsoft) could find out that they don’t provide that feature that people want. But does anyone have any clue how much people want it -- as compared to other improvements?

Though the topic of this thread seems to be a bug, while the symbol issue to be a feature, I’d choose the latter if I could only have one.

Quote:
Originally Posted by SpadesFlush
There is a long wishlist of unfulfilled and sincere user requests...
I suppose, despite Microsoft’s possibly noticing this thread that you and I have been winding, I should add a wish to the list over there.
© laptopgpsworld.com About