Jump to content

Anyone Know How To Average Coordinates


5¢

Recommended Posts

I am trying to figure out where the center point of all my finds is. Does anyone know how to take all the caches you have found coordinates and then average all the lats and then all the longs? Excel doesn't understand coords. That is the only thing I could think of. Anyone else got any ideas?

Link to comment
I am trying to figure out where the center point of all my finds is. Does anyone know how to take all the caches you have found coordinates and then average all the lats and then all the longs?

If you turn the coords into decimal degrees, Excel will understand them. Unfortunately, the answer you will get by averaging the coords is not actually the center of all your finds. That's because the Earth is not flat.

 

The "center of mass" of your finds would be the point at which the sum of the distances to all your finds is a minimum. I don't think there is any closed-form way to calculate that; you'd have to use some fancy gradient-search method.

 

Hmm... that might be an interesting programming problem.

 

On second thought, maybe it's the sum of the squares of the distances to the caches being a minimum. Now I have to think about it. Too bad my brain is hurting so badly tonight.

Edited by fizzymagic
Link to comment

Once you converted all the finds to decimal degrees and put them in a spreadsheet (I think GPSbabel can do this part for you).

 

Then you can use the GUESS Method.

Plug in a Lat. The SS calculates the distance between that Lat and each Find Lat, and gives you a total. Keep guessing until you find a minimum. Then do the same with Lon.

 

With a little intelligence to your guesses you can quickly find the answer.

 

Doing Lat and Lon separatly makes it simpler. I could be wrong that doing them separatly gives a right answer but I don't think so...

 

Fizzy. Sum of the squares is a regression method, it's the right track and would make finding the minimum distance easier (larger difference in the sums) but I don't think it's needed in this case.

 

Now you have me wondering if you need to do this using sphercial coords instead of assuming flat, or if it even matters.

Edited by Renegade Knight
Link to comment

I assume you want the CENTER and not the Average.

As Fizzy mentioned, because of the elipsoid... the math is not as easy as it would be on a plane.

 

I am just guessing but wouldn't the way to do this be:

 

Find the HIGHEST Lat

Find the LOWEST LAT

FInd the HIGHEST LON

Find the HIGHEST LON

 

Combine these into four points and draw a great circle between the diagnals

Where the two great circles meet should be the center point

Link to comment

I thought he wanted the average. I have some scattered finds in Washington, Florida, Southern California and upstate New York that skew my "limits" so that circle would not be interesting information for me to know. I am guessing that my "average" centerpoint is someplace southwest of my home, 150 miles or so, based on having more than 200 finds in each of Ohio and Tennessee, and more than 50 finds in states like Nebraska, Nevada and Washington. It would be an interesting exercise.

 

Unlike an "averaged" centerpoint, it is easy to determine the mean distance of all your finds from a *known* centerpoint. The "Watcher" software tells me that my average cache find is 270 miles away from my home coordinates. ;)

Link to comment

For two points, the midpoint is skewed by the curve of the Earth. Two points on the equator would have an average (the midpoint) that also lies on the equator. This is not because they are on the same latitude. This is because they are on the same great circle. Two points on the same latitude but further north will have a mid point that is significantly further north. The midpoint longitude will be in the middle (my understanding) where you'd expect to find it, but the latitude starts moving north. The further north the two points are, the greater the degree of northerly shift in the midpoint.

 

Get a globe and run a string between two cities with the same northerly latitude. Now pull the string tight. The middle of the string will shift north.

 

This is why international flights don't appear to fly in straight lines on maps. They DO however appear more straight on globes.

 

The formula for this is beyond me. The distance between points is determined using the haversine function. You'd have to go into spherical geometry to understand it. I never got beyond calculus. Non-Euclidian geometry classes were for the math majors (or masochists).

Link to comment

A better way to describe the point in question is the "center of mass" of your caches. I thought about it, and while I still think it ought to be the point at which the sum of the distances to the caches is minimized, I am still confused because it doesn't work for two points (at any point along the great circle connecting them, the sum is the same). But I think it works for three or more points.

 

In reality, the center of mass of your caches is a spot underneath the surface of the Earth. That point is easy to calculate; you can just get the Cartesian coordinates for every cache and average those. You could then figure out the latitude, longitude, and depth of that point and find the point on the Earth's surface directly above it. It might even turn out that this is the point you are looking for.

 

The people above who said you can average the latitudes and longitudes separately are not correct; it would work if the Earth were flat, but spherical geometry gets complicated.

 

Here's a good way to visualize the problem: imagine a globe with pins at every place you have found a cache. Now attach a rubber band to each of those, and tie the other ends of the rubber bands to a ring that can move. The point you are looking for is the point where that ring would sit.

 

I'm tempted to either write a new program that will calculate this point or else add it to FindStats, because it is an interesting thing.

Link to comment

I was thinking about this last night.

 

If you could caculate the midpoint between two points, the you'd have the center of your two finds.

 

At three points, you have a triangle. The mid point of each line forms a new set of three points. This is a smaller triangle. Find the midpoints between each of these three new points. Now continue the midpoint process until the distance between all three points approaches 0. This process gives you the midpoint of the three points.

 

I say "approaches 0". For our purposes, zero represents the largest distance between midpoints that can no longer be measured on our GPSr; two points have the same decimal degree Lat/Lon on the GPSr.

 

At four points, you don't have four midpoints, you have 6. Think of a square. Draw lines between opposite corners. That's where you get two extra midpoints.

 

Much larger than three or four? Well, for a number of points, N, the number of vertices joining the points in a k-partite graph is calculated using the formula

N(N+1)

-------

2N

 

Where N >= 1

 

It's not quite exponential (1, 3, 6, 10, 15,...) but it does get ugly. For 1000 finds, you'd have to calculate 500500 midpoints over and over and over again until the largest distance between two points is close enough to zero that we can stop. It's nice that you have a linear order of complexity (based on distance) once you get your first set of midpoints. That linear portion of the problem makes me wonder if some math whiz couldn't calculate this out as as single Calculus problem.

 

I have no idea what happens if any two of these points are antipodal.

 

Time to do some more research into areas about which I know nothing.

Link to comment

I found the following link!

 

Whole Buncha Calculations

 

enter two points and it'll tell you the distance, bearing, and midpoint! I'm going to go through the source to figure out how to put this into an Excel spreadsheet. All you'd need then is to enter the points in column A, and run out to the right a thousand columns to where the distance between midpoints approach zero. That column of points will all be pointing to the middle of your plane....

 

(maybe :D )

Link to comment

...The people above who said you can average the latitudes and longitudes separately are not correct; it would work if the Earth were flat, but spherical geometry gets complicated....

 

True. It doesn't work. Now I'm trying to visualize why this doesn't work.

 

The error I was getting was small though. For caches within a few hundred miles it would work well enough for their purposes. Plus you could just convirt them to UTM and then it would be "flat". Same issue with error but a small enough error.

Edited by Renegade Knight
Link to comment

Umm... before the brainiacs get too involved in finding that last foot of accuracy, remember, we're dealing with the beginning of caches. The beginning of multis is not where the cache is. Many puzzles use bogus coords. These two issues alone will skew even the most accurate of calculations.

 

EDIT: kan't speel

Edited by CoyoteRed
Link to comment

Averaging the coordinates directly doesn't work if you're covering a large area of the globe (or if your coordinates happen to be near a transition point between W and E). For example, at high latitudes, a given E-W distance covers many more degrees of longitude than it does at the equator. If your coordinates are over a relatively small area (say, primarily in one state of the US), then the deviation between the sphere and a plane is relatively small, and just averaging the coordinates would give you some kind of approximation. It might not be exactly right, but it'd probably be close enough to be reasonable. As fizzymagic points out, you could calculate Cartesian coordinates and get an average that way, which would almost certainly be below the surface of the earth, and then look at the point above it. I'm not up enough on spherical geometry to know how to do a deterministic calculation of the center of mass, but such a calculation can probably be done. An alternative would be an empirical solution, as long as you can calculate a distance on the surface of the sphere between any two points. I think I prefer fizzymagics earlier suggestion of minimizing the sums of the squares of the distances between the center point and the outer points - if you use the squares, that resolves the problem of finding the center with just two points. You could either calculate gradients empirically and use a Marquardt type algorithm, or use something more simplistic (but with likely higher calculation cost) like a Metropolis type minimization. The Marquardt methods would probably work much more quickly, as I doubt the calculation surface has a significant local minimum issue for most problems. Two antipodal points would likely be problematic.

Link to comment

Actually you just need to use the average lat and longitude. Keep in mind that lat and long are spherical coordinates - degrees north of the equator and degrees west of the prime meridian. You don't need to do anything special. It's confusing because we normally see (and think) about this on a mercator projected map. Straight lines are straight on the "globe" of the earth. They are curved on a mercator projection. If you look at a great circle route on the globe it is a straight line (sight down it to see) even though on a flat map it is curved.

Link to comment
You could either calculate gradients empirically and use a Marquardt type algorithm, or use something more simplistic (but with likely higher calculation cost) like a Metropolis type minimization. The Marquardt methods would probably work much more quickly, as I doubt the calculation surface has a significant local minimum issue for most problems.

The Marquardt algorithm is exactly what I am considering. Actually, I am considering the Levenberg-Marquardt algorithm, which performs very well for functions that are approximately quadratic near the minimum, which is the case here. I am also considering using a simplex method, which is slower to converge but doesn't require calculation of derivatives.

 

I have an old C implementation of the Leveberg-Marquardt algorithm around somewhere. I ought to go dig it up and freshen it for C++.

 

It also occurs to me that once we have that working, it can be used to solve other problems nicely. For example, it can be used to find the point equidistant from three other points by minimizing the sum of the squares of the differences between the distances to the points; it can also be used to solve the more traditional triangulation problem of three points and three distances. It would have a couple of advantages: first, it would solve the problem using the highly accurate ellipsoidal distances, second, it would work for points far apart, and third, it would generate a "good" solution even in the case where there is no exact solution.

Edited by fizzymagic
Link to comment

While a fully technical analysis of my coords would be a great thing and 99% accurate :D , I would like to bring back to light that I was just looking for a general answer to my finds. I have one cache I found in Mexico that could even be taken out of the analysis. All of my caches except for the one in Mexico are within 200 miles of my house.

 

Now back onto theories, algorythms, and other highly intelligent things that I will continue to read and not fully comprehend. :D

Link to comment
I would like to bring back to light that I was just looking for a general answer to my finds. I have one cache I found in Mexico that could even be taken out of the analysis. All of my caches except for the one in Mexico are within 200 miles of my house.

 

Now back onto theories, algorythms, and other highly intelligent things that I will continue to read and not fully comprehend.

You have to remember that we like this stuff. And I had been thinking about it for a while before you asked the question, for a variety of reasons.

 

I have an implementation working in FindStats right now; I am still torn between using the minimum distance point or the point with minimum squared distances. The former will not count finds far away from home as much, and seems to converge a little better, but the latter has its strong points, too. For you, I expect that the difference will not be great, but for me, the difference turns out to be almost 300 miles! The point of minimum distance is very close to my home coords, but the point of minimum squared distance is pretty close to the coords you get from averaging the Cartesian coords.

 

These are actually pretty interesting questions. At any rate, I promise to have something you can use shortly.

Link to comment
I would like to bring back to light that I was just looking for a general answer to my finds. I have one cache I found in Mexico that could even be taken out of the analysis. All of my caches except for the one in Mexico are within 200 miles of my house.

 

Now back onto theories, algorythms, and other highly intelligent things that I will continue to read and not fully comprehend.

You have to remember that we like this stuff. And I had been thinking about it for a while before you asked the question, for a variety of reasons.

 

I have an implementation working in FindStats right now; I am still torn between using the minimum distance point or the point with minimum squared distances. The former will not count finds far away from home as much, and seems to converge a little better, but the latter has its strong points, too. For you, I expect that the difference will not be great, but for me, the difference turns out to be almost 300 miles! The point of minimum distance is very close to my home coords, but the point of minimum squared distance is pretty close to the coords you get from averaging the Cartesian coords.

 

These are actually pretty interesting questions. At any rate, I promise to have something you can use shortly.

 

I wasn't trying to halt the technical stuff. :D I was just putting that statement out there for anyone who had a close enough solution.

Link to comment
I was just putting that statement out there for anyone who had a close enough solution.

 

OK, go and download the newest version of

FindStats and see how the centroid it calculates looks to you.

 

You'll need your All Finds PQ for this, of course.

 

Fizzy,

 

I think this may be off. The red dot is where you show my center point being. It is showing me east of where I think it should be. I could be wrong though. I have more caches in Illinois than Indiana about 63 to be exact. I would have thought it would have been more towards Illinois, but once again, I could be wrong.

 

Here is a map of my finds. I have cut off the one in Mexico, but that would be west anyway.

 

793a5e0d-aa1b-469b-b00c-1c9b934ca5f5.jpg

 

Edit, Taking into account the caches in the top right corner, which is past Indianapolis, I guess your system could be correct, but Mexico should way over ride those 10 caches up there I would think

Edited by 5¢
Link to comment
I think this may be off.

 

Well, it was calculating what I said it was calculating, but I did some more work and discovered that using the sum of the squared distances gives you the same answer that you would get by averaging the UTM coords (for caches close enough together); as a result, I think that is a better definition of "average" than what I was using.

 

So I uploaded a new version that behaves that way. The new answer will be the "correct" one. You can tell it's the new version because it now has a version number: 0.1.1

 

I have checked the output and it does indeed give the correct average position. I expect that with the new version, your point in Mexico will pull the average further south.

Edited by fizzymagic
Link to comment
I think this may be off.

 

Well, it was calculating what I said it was calculating, but I did some more work and discovered that using the sum of the squared distances gives you the same answer that you would get by averaging the UTM coords (for caches close enough together); as a result, I think that is a better definition of "average" than what I was using.

 

So I uploaded a new version that behaves that way. The new answer will be the "correct" one. You can tell it's the new version because it now has a version number: 0.1.1

 

I have checked the output and it does indeed give the correct average position. I expect that with the new version, your point in Mexico will pull the average further south.

 

It actually now shows me even farther east and a tad bit norther.

Link to comment

Cool. I mean, WAY cool. Thank you, Fizzy.

 

My centerpoint was calculated at N 40 06.472, W 84 38.673 N 40 06.898, W 84 29.776 ... a spot northwest of Dayton Ohio, near the Indiana border -- several hundred miles west of my home in Pittsburgh.

 

In other words, pretty close to where I predicted it by rough eyeballing, earlier in the thread!

 

EDIT: I was using the 1.1 version.

EDIT AGAIN: If you're a purist, don't forget to edit out your locationless cache finds, as they use the posted coordinates for the cache page rather than the spot you found. I adjusted the result above after excluding my 13 locationless finds from my All Finds pocket query.

Edited by The Leprechauns
Link to comment

By the way, for those following along at home, I updated both my old Levenberg-Marquardt minimizer and my simplex minimizer to play nicely in C++. While the L-M did a fine job for the calculation of the average we've been describing, I wanted to use a minimization technique to solve a couple of other problems: the "center of a circle" problem in which you are given 3 points and you have to find the point equidistant from those three, and the "triangulation" problem in which you are given three points and three distances.

 

I set up those problems in exactly the way you would expect: minimizing the differences between the distances to each point in the "center" problem, and minimizing the differences between the given distances and the observed distances for the "triangulation" problem.

 

You can't use the L-M approach to those problems because the residuals are not linearly independent, so the curvature matrix is singular. So I used the simplex minimizer for those problems, and it worked great. Remember, these solutions are the exact solutions for the ellipsoid, not spherical or UTM approximations.

 

I would add a solver for those problems to GeoCalc, but if I did that I think it would ruin many, many puzzles!

 

In addition, I think the same approach would work fine for finding the intersection between two geodesics or for finding the distance from a point to a geodesic.

Link to comment
If you're a purist, don't forget to edit out your locationless cache finds, as they use the posted coordinates for the cache page rather than the spot you found. I adjusted the result above after excluding my 13 locationless finds from my All Finds pocket query.

 

Oh -- I forgot to do that in FindStats. I will fix that problem. Locationless don't count in calculating countries or states or position!

 

My centroid BTW, is N 38 58.133, W 116 46.247, about 300 miles NE of my home. All those caches I've done in Europe and on the East Coast.

 

Edit: Done. Version 0.1.2 does not include locationless in the calculation.

Edited by fizzymagic
Link to comment
I think this may be off.

 

Well, it was calculating what I said it was calculating, but I did some more work and discovered that using the sum of the squared distances gives you the same answer that you would get by averaging the UTM coords (for caches close enough together); as a result, I think that is a better definition of "average" than what I was using.

 

So I uploaded a new version that behaves that way. The new answer will be the "correct" one. You can tell it's the new version because it now has a version number: 0.1.1

 

I have checked the output and it does indeed give the correct average position. I expect that with the new version, your point in Mexico will pull the average further south.

 

It actually now shows me even farther east and a tad bit norther.

 

I figured out why my centroid is skewed. I found this cache which is actually a travel bug which is a cache. :) Anyways, it is from Belgium and is what is throwing my centroid out of whack.

Link to comment
Yeah. I also had to manually exclude a half dozen traveling caches.

 

There are a couple possible solutions for this. It's something I thought about when considering how to do "total caching distance" in FindStats.

 

One possible way to deal with it is to make it so that if you added a waypoint to your log, it will use the waypoint you entered for the cache location, not the posted coords.

 

The alternative is to do something like is used in Spinner or GPX2HTML, where you can have a list of "corrected caches," in which you store the actual coordinates where you found each cache. The advantage of the latter solution is that you can enter the final coordinates for mystery and multicaches as well as for traveling caches.

 

I personally have kept a database with the actual coordinates for all the caches I have found, but I realize that not everybody has done that. Feedback would be good.

Link to comment

Another cool tool from FizzyMagic!

 

Do I see another sub-game in this? "Visit Your Centroid" Kind of like Geodashing or the Confluence project, but you visit your centroid and take pictures of what you see there. The beauty is over time it changes so you can revisit it by visiting new places.

 

... or "My Home is My Centroid." Find only those caches that will place your centroid within 1 mile of your home.

 

With all of the icon covetting like going after APE caches, or finding a cache in each state or county, etc. I'm surprised one goal that is never mentioned is finding one cache of every rating. There are 81 unique rating of caches. Who has found them all? The Findstats program could facilitate that if the ratings were displayed in a grid. Interested?

Link to comment

Another cool tool from FizzyMagic!

 

Do I see another sub-game in this? "Visit Your Centroid" Kind of like Geodashing or the Confluence project, but you visit your centroid and take pictures of what you see there. The beauty is over time it changes so you can revisit it by visiting new places.

 

... or "My Home is My Centroid." Find only those caches that will place your centroid within 1 mile of your home.

 

With all of the icon covetting like going after APE caches, or finding a cache in each state or county, etc. I'm surprised one goal that is never mentioned is finding one cache of every rating. There are 81 unique rating of caches. Who has found them all? The Findstats program could facilitate that if the ratings were displayed in a grid. Interested?

All interesting ideas. Since I am stuck at home today with a sick child, I can't play "Visit the Centroid" and drive the entire width of Ohio. And to "move" my Centroid close to my home, I'd have to find an awful lot of caches in New Jersey, and I cannot do that today either. So instead I checked out the grid of 81 rating combinations. This is pretty easy to do using third party software like Watcher or GSAK. Sort your "All Finds" PQ by difficulty with a secondary sort criterion by terrain. Then, scroll down the list and put X's on your grid.

 

I've found 61 of the 81 rating combinations. Not surprisingly, most of the missing ones are in the highest end (4.5 or 5 stars) for terrain and/or difficulty. But I am missing a 1/4 cache and a 4/2.5 cache.

Link to comment
You're doing better than I am. I'm missing 24 of the combinations.

Would you guys seriously like the difficulty/terrain combinations as a table? Like I have said before, I've done all the hard work in FindStats, in terms of parsing the GPX file. Adding new statistics is just fun at this point.

 

I have also been considering making the output an HTML file instead of a text file, so there could be some fancy formatting, too.

Link to comment

I am trying to figure out where the center point of all my finds is. Does anyone know how to take all the caches you have found coordinates and then average all the lats and then all the longs? Excel doesn't understand coords. That is the only thing I could think of. Anyone else got any ideas?

 

After exhaustive playing around with the Haversine function I cannot detect any significant difference between my approach and Fizzy's "Centroid" value. Discrepancies between the two can be attributed to rounding error.

 

The answer is actually quite simple: It's the average your coordinates in radians.

 

To convert to radians: Degree * Pi / 180

To convert to degrees: Radian * 180 / Pi

 

Excel should be able to do this for you.

Link to comment
You're doing better than I am. I'm missing 24 of the combinations.

Would you guys seriously like the difficulty/terrain combinations as a table? Like I have said before, I've done all the hard work in FindStats, in terms of parsing the GPX file. Adding new statistics is just fun at this point.

 

I have also been considering making the output an HTML file instead of a text file, so there could be some fancy formatting, too.

 

Thanks for yet another enhancement from your Software Toys Department. :ph34r:

 

My centroid is about 100 miles off the Northern California Coast, in the Pacific Ocean, almost directly west from Lassen Volcanic National Park. Doubtful I'll visit there anytime soon, although there's a good chance I'll fly near there on my way to Asia.

 

I'd want to keep the option of output in text, if you are going to implement the HTML output, in case I don't want to fire up a browser to view the file.

Link to comment
The answer is actually quite simple: It's the average your coordinates in radians.

 

No, it's not. Not even close. And averaging radians is mathematically equivalent to averaging degrees, you know, since they are, you know, like, related by a constant.

 

Just for fun, I tried averaging the positions of my finds in the way that you describe. The answer was different by more than 100 miles. And it was clearly wrong.

 

Maybe if you have only cached in a very limited area the two might be close to each other, but even then the differences are larger than rounding errors.

 

Sorry to be snippy about this, but this isn't a matter of opinion, and incorrect information needs to be addressed.

Edited by fizzymagic
Link to comment

Well excuse me for getting you into a snit. I'm having trouble getting your findstats.exe to run on more than 30 geocaches without blowing up. I cannot seem to get GSAK to produce a file that your program can digest.

 

So here's where I went wrong:

 

My input:

29.811416666, -90.41588333

29.8234, -90.0065

29.903967, -90.115567

29.9228, -90.127667

29.95125, -90.07868333

29.9591, -90.07121666

29.965583, -90.148233

29.983566666, -90.09208333

30.0075, -90.21145

30.025483, -90.193067

30.02955, -90.208617

30.362667, -90.066983

30.527517, -89.682

35.168517, -83.377417

35.4277, -83.446517

35.586333, -83.838333

35.960417, -83.922933

35.9668, -83.1841

35.969317, -83.18685

35.979333, -83.187617

36.008533, -83.0943

36.011233, -83.836217

36.034833, -83.322917

36.036583, -83.433933

36.040383, -83.349517

36.06185, -83.472583

36.096733, -83.547733

36.098967, -83.5523

36.11675, -83.490533

 

My output:

Average of radians (back to degree,min format): N 33 18.861, W 86 32.836

 

Your output:

Centroid: N 33 18.911, W 86 32.811

 

I used some caches from my GSAK since FindStats.exe requires a gpx file. It was the quickest way for me to generate one. I have caches filed away for the New Orleans, LA area and the Gatlinburg, TN area.

 

The two values are different by 450 feet just outside of Birmingham. I was happy with the result and posted what I felt to be the correct answer. Perhaps I need some wilder numbers to get the 100 miles difference which you mention.

 

I've done enough damage here. :ph34r:

 

(*editted to correct word usage)

Edited by BillsBayou
Link to comment

Well excuse me for getting you into a snit. I'm having trouble getting your findstats.exe to run on more than 30 geocaches without blowing up. I cannot seem to get GSAK to produce a file that your program can digest.

 

Yeah, for some reason GPX files generated by GSAK cause my program to barf. I need to fix that someday. Seems to have something to do with the date and time format. I don't use GSAK, but I do have a license, so I ought to test it.

 

If you turned your coordinates into UTM, you could average them and you'd get the same answer my program does. I know; I checked. The problem comes when you have points that are not in the same UTM zone.

Edited by fizzymagic
Link to comment

1. The program works marvelously on my file of approx. 1580 "real" caches. So, just run your virginal All Finds PQ GPX file through Find Stats before GSAK chews on it, and let Find Stats strip out the locationless finds. EDIT: Modifying the All Finds file using Watcher does not have any noticeable effect on Find Stats.

 

2. I've thought about it, and I'd like to see that grid of difficulty vs. terrain filled in with however many I've done in each box. It would perhaps motivate me to bump my average up over 2/2.

Edited by The Leprechauns
Link to comment
OK, go and download the newest version of FindStats and see how the centroid it calculates looks to you.

 

You'll need your All Finds PQ for this, of course.

The current version info on that page still says 12/7/2005 and v0.1. The FindStats.exe and zip file are up-to-date though. Guess fizzymagic just hasn't gotten around to updating the webpage.
Link to comment
The current version info on that page still says 12/7/2005 and v0.1. The FindStats.exe and zip file are up-to-date though. Guess fizzymagic just hasn't gotten around to updating the webpage.

Yeah, well, fizzymagic doesn't do this for a living, and nobody has offered me a hiking staff yet, either. :huh:

 

v. 0.1.3 is up; has matrix of Diff/Terr and maximum distance in one day. The latter is kinda ill-defined, and I am not totally comfortable with it, though.

Link to comment

Another cool tool from FizzyMagic!

 

Do I see another sub-game in this? "Visit Your Centroid" Kind of like Geodashing or the Confluence project, but you visit your centroid and take pictures of what you see there. The beauty is over time it changes so you can revisit it by visiting new places.

 

It seems to me, that once you have a largish number of caches, your centroid would not move that much. (Unless your routinely cached in areas distant from each other.)

Link to comment
Hey fizzy, what does this mean "Avg. Challenge = 1.58"?

"Challenge" is the greater of Difficulty and Terrain. It is meant as an indicator of how challenging the caches you have done were. I know that a 4/4 and a 4/1 both have the same challenge rating, but experience shows that such caches are often misrated, so I think it is a pretty good indicator.

 

Here is a thread where we discussed some of these things and people compared their statistics.

Link to comment

The distance thing on mine was skewed by one of Markwell's photography caches - also messed up my centroid. Any way to auto filter for that - or best to just delete?

Over the weekend I also tried the new version, and noticed that my maximum one-day caching distance was screwed up, because of logging a moving cache that had temporarily "visited" GeoWoodstock III. I came here to thank Fizzy (who even wrote to me to make sure I saw the new version), and saw your post.

 

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.

 

I wound up taking my All Finds query and excluding the moving caches from the list manually. Most of them were easy to spot by opening the GPX in Google Earth and looking for pushpins in places I've never visited. I missed a couple that are currently "residing" in areas where I have a lot of finds.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...