Streets And Trips Pushpins/gsak

[+Team MnMizzou]

Hello,

I'm hoping someone can tell me if I'm doing something wrong. I have basically the entire Twin Cities metro in 2 or 3 pocket querries. They are all in one giant database on Gsak. I then use that program to export all of those to Streets and Trips. My job takes me all over the metro and I can look on S&T and see if there are any pushpins close to me if I have some down time. I have gone a step further by color coding my pushpins, so when I find a cache I change it to green. Looked but didn't find, red, etc. Then at a glance I can tell what I've found without having to have internet access.

 

My problem is this... if I update the Gsak database, presumably with new caches that are added to the existing database if I them try to import a second pushpin is created in the exact same spot. So if I've colo-coded a pushpin it is "buried" by the new one. Does anyone know how to prevent Streets and Trips from doing that? Kind of like if you try to copy a folder on a computer and there is a same file name it asks you if you want to replace it... does Streets and Trips have anything like that? Or would there be a better solution using the Gsak end of the process?

 

Thanks in advance!

[+Stunod]

You can use GSAK to filter all the waypoint and export multiple files to S&T. One for unfound, one for found...you could use the "user flag" to filter out caches you DNF'd. Each pushpin set can have it's icon changed by using the data set properties.

[+PDOP's]

Or would there be a better solution using the Gsak end of the process?

I think that this may be the only way. If you filter for each type and do a separate export from GSAK and import into S&T you can assign a different pushpin for each data set (found/not found) in S&T.

 

BTW you don't have to limit yourself to the pushpin icons that come with S&T. Different icons can be imported into S&T.

 

Edit to add this. GSAK will filter by date placed so you could just update your S&T files with new caches each time you run your pocket queries. The down side of this would be that the cache data in S&T would get stale and you'd miss if a cache was archived.

Edited February 9, 2005 by PDOP's

[robertlipe]

Right cluck (sorry, stunod) on the pushpin properties will let you set the icon type for an entire set, but I don't know of a programmatic way to set the pin type individually.

 

For some special cases, I've used customized GPSBabel builds to bust an input file into different types then manually set them (founds are color X, multis are color Y, different terrains, etc.) but as much as I like S&T for general roaming around a map, I find when I need different icon sets that are set by a program that it's just plain easier to use just about ANY other program when I really, really want different icons individually set for different things.

 

Anyone that can figure out how to get S&T to read icon information from an imported file would be a hero to many. (Attempts to reverse engineer the .est format have driven a couple of programmers into the woods screaming something about making the pain stop....)

[+PDOP's]

Anyone that can figure out how to get S&T to read icon information from an imported file would be a hero to many.  (Attempts to reverse engineer the .est format have driven a couple of programmers into the woods screaming something about making the pain stop....)

I've wondered about ST2GPX (the program also converts GPX files to EST files) ability to do this.

 

The screen shot below is from a Pocket Query GPX file run through ST2GPX. I have not altered the icons from what ST2GPX produced. Note the different icons for traditional caches (triangle) , multis and webcam (pushpins) while unknown cache types are "?". Obviously it's not assigning all the icons correctly but it does seem to have an ability to assign different icons based on information from the GPX file.

 

 

[robertlipe]

Now that you mention it, I do recall it. (Carefully notice the URLs that host it.)

 

That project is in kind of an odd state. Last time I looked, it didn't really read and write the files itself, it kind of hooked into the S&T libraries to do the work, IIRC. This made it useful only to those that had S&T and were running on Windows. (I realize that's not a terribly onerous requirement for many, but it was a deal-breaker for general purpose use in GPSBabel proper.)

 

Has anyone heard from James on this?

[+PDOP's]

Has anyone heard from James on this?

I don't think he's a geocacher and he hasn't been on the Babel lists recently.

[+GixxerUT]

Ron Jeremy is a geocacher, too?????

[+BruceS]

The problem listed by the the OP is one good reason to use MapPoint. With MapPoint you do not have to import your point but instead you can link to the csv file. You can also link to multiple csv files. When you do a new export from from GSAK you just refresh the links. No duplicate pins are created (unless they are duplicated in your datasets), can have different pins for different datasets, and pins that the user has manually changed the pin type are not changed on the refresh. Disadvantage of MapPoint is cost.

[+aerospacecase]

With MapPoint you do not have to import your point but instead you can link to the csv file. You can also link to multiple csv files. When you do a new export from from GSAK you just refresh the links. No duplicate pins are created (unless they are duplicated in your datasets), can have different pins for different datasets, and pins that the user has manually changed the pin type are not changed on the refresh.

As Johnny Carson used to say, "I did not know that!"

 

This solves a maintenance problem that I have had using MapPoint and the waypoint importer. I have been changing my finds to a green dot manually and sometimes after a powercaching day, it is a lot of work.

 

Thanks for the tip.