agentmancuso

That's easy: I'd be finding more trigs and climbing more hills.

GSAK is a fabulous way to organise data for caching and similar (benchmarking, trigging etc). I plan my trips on it completely, and use it to send exactly the information I need to my Vista Cx. Couldn't do without it ( or at least would do a lot less without it) .

I have to agree, what a great package. I have no idea what I would do without it. +1

There's a whole forum!

Maybe it was just attracting the wrong kind of clientele - shifty characters carrying tupperware around and peering under every rock in the carpark.

I think this is the key point. The cache ought to function as a device for attracting people to a worthwhile place they would otherwise overlook.

Hello, best wishes for an impossible task.

Just don't mention which Saint the church is named after ...

In the Uk the difference is currently about 50cm, which is so far within the margin of error of consumer GPSr units as to be meaningless.

The 12 listed for Scotland aren't counties, but regions. And they were abolished in 1996. Here's a list of the historic counties for Scotland and England and Wales.

YoSM POI file updated to YSM421 Regards, Bernie

It's the same over here - a Waymarking category does exist for UK benchmarks, but I don't use it, because, well, Waymarking is pretty dire to be honest. i just use the dedicated UK sites & GSAK.

I'm not sure if trigpointing or benchmarking are sufficiently different to caching to warrant mention, but that's what I mainly do. I also tick hill lists. And buy books.

Terry Marsh is well-known as a writer of hillwalking guide books. My original copy of his Isle of Skye guide eventually disintegrated through overuse and had to be relaced.

Yes, I thought we were headed for that punchline too.

The simple answer is that Groundspeak bought a dataset of US benchmarks; as I understand it, even that is far from complete. They don't do any other country at present, and it's highly unlikely that this will ever change. Waymarking is a very tedious and inefficient method of recording UK trigs - far better to use the dedicate site trigpointinguk.com . If you use GSAK, the FindStatsGen and BadgeGen macros will include trigpoints in totals etc.

Forgot to say, if any GSAK users want the full database, PM me with an email address & I'll send you a copy.

The Trigs POI file has been updated today. There are a few of the usual updates and improvements to data, but the most significant change is the inclusion of all known Irish trigpoints, bringing the total up to 8583 trigs. Regards, Bernie

Congratulations to me on reaching 1500 combined caches/trigs/benchmarks today.

This macro might be of use - I've only just discovered it, and it does the trick for me.

Most of what you've described is storing different types of data in different databases. This is very reasonable, and is quite different to storing, for example, found and not found in separate databases despite the data having the same type. Rgds, Andy Yes, that's true enough. The only other example I can think of is keeping a separate database of caches round a specific holiday destination or suchlike, which I tend to do, then delete the database entirely when we get back.

I'd bet good money that the website mentioned was written in French then translated to English.

I am keeping 6 permanent databases: Caches - everything not found or archived within 200km of home Trigs - all T:UK trigs plus Passive & Active stations etc Benchmarks - all Flush Brackets & 1GL Bolts , plus Rivets/ OSBM Bolts/ CBMs etc within 200km of home Found - All finds of the above, kept together for BadgeGen/FindStatgen purposes YoSM - populated with .gpx from the website Hills - everything from the Database of British hills, plus my own supplementary data Plus a temporary database containing Ordnance Survey info for Northern Ireland, which will disappear in the next few days once I've integrated it properly into the main trigs database. Aside from caches, much of this data is generated from .csv fies, with a variety of different sorts of information in different fields - e.g. in the PlacedBy field, I keep flush bracket numbers in two of the databases, and the User Data fields are all used differently too. Keeping this all together in one database would be highly impractical.