Anyone Know How To Average Coordinates

[+fizzymagic]

While the program filters out locationless caches, there's not much that can be done about moving caches. They don't have their own cache type or any other distinguishing feature other than being hidden prior to April 2003.

Actually, I am working on this, and I should have the working result shortly. Since there are several moving caches that people logged more than once in different places, I will change the program from averaging cache positions to averaging find positions. For most caches there is no difference, but if you use the "add a waypoint" feature to your find logs for moving caches it will use those coordinates instead of the nominal cache coordinates. And it will now average in all the find logs you made for each cache. So if you went to an event and logged it 20 times, it will count 20 times as much toward the average.

 

I'm considering adding the locationless back in using this scheme. What do you think?

[+StarBrand]

While the program filters out locationless caches, there's not much that can be done about moving caches. They don't have their own cache type or any other distinguishing feature other than being hidden prior to April 2003.

Actually, I am working on this, and I should have the working result shortly. Since there are several moving caches that people logged more than once in different places, I will change the program from averaging cache positions to averaging find positions. For most caches there is no difference, but if you use the "add a waypoint" feature to your find logs for moving caches it will use those coordinates instead of the nominal cache coordinates. And it will now average in all the find logs you made for each cache. So if you went to an event and logged it 20 times, it will count 20 times as much toward the average.

 

I'm considering adding the locationless back in using this scheme. What do you think?

 

Good thinking - nice workaround - i don't have any locationless but on the surface the idea makes sense for those too.

[+The Leprechauns]

Fizzy, that would work great. I would have no issue with my 13 locationless finds showing up in the spots where I actually found them. And I could go back into my log entries for the half dozen moving caches and enter the "found coordinates" into the supplied field via edits to my logs. Thanks.

 

EDIT: Just thought of something... don't some moving caches employ a convention where the finder uses the "log coordinates" field to record the *new* position where they re-hid the cache? If so, then FindStats would capture where the cache was hidden, not where it was found. That's still better than using the spot where it's currently located... at least the person visited the spot being captured.

Edited February 21, 2006 by The Leprechauns

[+fizzymagic]

EDIT: Just thought of something... don't some moving caches employ a convention where the finder uses the "log coordinates" field to record the *new* position where they re-hid the cache? If so, then FindStats would capture where the cache was hidden, not where it was found.

Yeah, I thought of that. Two ways to deal with it: either go back and change the coords of your log to reflect where you found it (won't really matter now if the next person has already moved it on) or just leave it, as you describe.

 

It's probably never going to be perfect unless you (like me) have actually kept a record of where you found each cache. But at least it is a numerically stable number with a clearly-defined meaning.

[+Allen_L]

I just got a "All my finds" PQ and fed it into findstats.exe and it has been running for 30 minutes using 90%+ of my system (an AMD Athlon 1.99 GHz with 512MB) running XP professional Service Pack 2. Windows explorer show that it did create a _Stats.txt file but it is zero bytes long.

[+Allen_L]

It has now been an hour, I assume there is something in the PQ that FindStats doesn't like.

 

The DOS box looks like

Input file: C:\tempajl\353188.gpx

Output file: C:\tempajl\353188_Stats.tx

File parsed successfully

Getting geocaches.

 

Getting logs.

Analyzing waypoints.

[+fizzymagic]

New version is up. Now finds the centroid of all the logs, including locationless. It uses the posted geocache coordinates unless you have entered coordinates with the log, in which case it uses those. I strongly recommend entering waypoints to accompany your logs for moving caches, locationless caches, and armchair caches.

 

Also, Allen's problem, which sounds like a convergence issue on the iterative solution, should be fixed. If the program ever takes more than a minute, it's gone off into numerical never-never land. Kill it.

Edited February 22, 2006 by fizzymagic

[+Allen_L]

Just downloaded the latest version of FindStats, same result except I only let it run for 5 minutes.

[+fizzymagic]

...I only let it run for 5 minutes.

Well, you get what you pay for, don't you? Had you PMed me about it instead of posting, I might have looked at it.

[+5¢]

Hey fizzy, any way you can hack my ftf's on your stat program?

[+trainlove]

The virtual ME lives under the Quabbin Reservoir and is moving towards where I currently live at about 100 yards a year. But that was simply based on the un-orthogonal Latitudes and Longitudes.

 

I have wanted to find the center of mass of all my cache finds, and of all existing caches in Massachusetts but darn it, Mass has 2 UTM zones. So I thought that figuring out the center of mass of things in 1 zone and the center of mass of the other zone and taking a weighted mean of both answers would work, but darn it, one zone is not orthogonal to another zone so I'm back to the naive weighted average of Lats and Longs.

 

I think it would also be great to calculate the real ground zero of a state. But that would require averaging millions of waypoints. One can't simply average thousands of waypoints along the border of a state, not a geometrically valid thought.