Geofellas

I wish I could claim the credit for the idea but it was actually Ranger Fox who suggested it

Thanks - it looks like your last attempt at averaging was when you didn't have a GPS signal since the accuracy was being reported as 9.9999995620235e+24 m - I'm obviously not handling that situation well Clearly I am going to have to do item number 1 on the "still to do" list (which IS in the description of the cartridge ) - that is to deal with when the accuracy is not acceptable. For now folks, please don't try this when you have no GPS signal It's great to have a group of testers like this - it really helps to eke out the bugs and get a handle on how people use the tool so thanks to all

OK - thanks - that helps Might be a while before I do anything though

OK - I'll try and see if I can replicate that. If you could send your log file to geofellas@gmail.com that would help Thanks

I'm not sure about your question # (1) but if I hide a cache or mark an important landmark I would simply return to the site of the cache or landmark to add more data to the coordinates (more averaging). The accuracy in returning to the point would be mute since there is something on the ground telling me where I am. Just think of the accuracy one could achieve if you checked PDOP and returned over several days for some more averaging. (2) Would a "resume" type function work? You could simply return to the site and addmore data continuing where you left off sort of speak. I don't know, just speculation. PS: I'll get you that log file ASAP (UPDATE-SENT). I experienced aanother crash right after naming my waypoint twice now (seperate condition. I pretty sure it's what Timpat is experiencing). On 1 the program still should check or you could restart a million miles away and get meaningless results. On 2 - yes - that is what we are talking about - but you still need to keep the old data around.

Can you send me your log file so I can see if I can replicate the problem. I assume this was on the Colorado? Hmm - thanks for the suggestion. Raises a few issues: 1) Need to check you are at or close to the saved coordinates or it makes no sense to do it - what should be the allowable margin of error? Current accuracy perhaps? 2) It would require saving some statistics along with the saved waypoint (specifically number of samples taken, and, for the benefit of the user's understanding the likely accuracy of the result, the previous values of min/max accuracy) and neither of these are standard waypoint properties - could probably be done though. Gets even more complicated if a weighted average is used - needs more thought. I'll ponder this one

Since the majority of the world uses metres (sic) I chose to make this the default. At present you can change this to feet by projecting a waypoint and selecting the "feet" option from there - not entirely obvious I grant you. I might enhance the cartridge to provide a setup facility as well to enable you to select your preferences. Obviously metres/feet is one that would be of interest - what other preferences would people find most useful? It would be nice if I could figure out how to get the preferences from the host GPS itself but that is probably device dependent and therefore not practical.

Also note that if you upload a file with a .zip extension to the site it works fine - it seems that the extension does not have to actually be .gwz

No, as it says on the screen when you run the thing, there is no weighting included in this first implementation. It calculates a simple average of the points collected at 2 second intervals over the time you choose to average for - which I have set to a maximum of 10 minutes (randomly!) The displayed accuracy statistics are intended to give you a subjective sense of how effective the averaging has been. Another measure would be to calculate the standard deviation of the sample set - but most people are not likely to really understand what that number would be telling them anyway. I seriously wonder how beneficial including weighting into the algorithm would be. If there is any prior art available on the subject I would be interested to know - my gut feel is that weighting is not going to significantly affect the final result to any practically useful extent. For placing caches I have to think that a simple average is going to be "good enough"

Yes - that is intentional as good Wherigo programming practice. The more locations you have active and visible the more work the processor has to do continually checking on them and that could ultimately cause a crash or reduced performance. So I have set it up so that only one can be active and visible at any one time. When you "Go To" one that is not in the "Locations" list it then appears in the Locations list instead of any one that was there previously.

Hmm - can't replicate it on my CO - no idea how to solve that one at the moment.

Check this out

Since it doesn't look like Garmin are providing Waypoint Averaging on the Colorado any time soon (if ever) I have, at the suggestion of Ranger Fox, written a play anywhere Wherigo cartridge that will allow you to do it. Please feel free to test it and provide any comments, bug reports, issues etc. It is available at the Wherigo website

Version 1.6 with the first cut at Waypoint Averaging is now uploaded to the website

Version 1.5 is now available with Waypoint Projection included

I think you will have to post some source code to get help on this one.

Yes you did - many thanks. It was a regression error in the coordinate display function and should now be fixed in version 1.4 just uploaded

Cool idea - I'll add it to the list Thanks

New version 1.3 now uploaded - fixes crash caused when user fails to select a waypoint from the goto or delete functions. Cartridge made public as a play anywhere cartridge

In the gizmo cartridge (the tutorial) there are 2 calls to Player:RefreshLocation() (lines 1154 and 1162) What is the purpose of these? What do these calls do? Thanks

I too have experienced this. Since I make extensive use of string expressions (rather than simple strings), I suspect that this is a very likely explanation for the cause of the problem. Now I know what to avoid in future. Workarounds that come to mind are: 1) move the function to the author area, or 2) create a string variable called comma with the value of "," and use it instead of typing a comma, or 3) avoid using commas in dialogs

I think you could get the individual lat and long (as numbers) this way too if you needed it. I know it works when I do Player.ObjectLocation.latitude etc. lat = v.ObjectLocation.latitude long = v.ObjectLocation.longitude

You could include some author code that uses the lua function os.date (google "lua os.date" for more info) to determine the current date and insert logic based on that. This is definitely stepping outside the builder Here is some code (incomplete) that I have been playing with in case it helps: dow = {"Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" } month = {"January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" } function ztimerEvery5seconds:OnTick() -- #GroupDescription=Script -- -- #Comment=Script Comment -- local i = os.date("!%c") Wherigo.MessageBox{Text=[[]] .. i .. [[ Processed = ]] .. getdow(i) .. [[ ]] .. getdom(i) .. [[ ]] .. getmonth(i) .. [[(]] .. getmonthnum(i) .. [[)]] .. getyear(i) .. [[ ]] .. get24hour(i) .. [[:]] .. getmin(i) .. [[:]] .. getsec(i),} end function getdow(t) for j = 1 , 7, 1 do if string.sub(dow[j], 1, 3) == string.sub(t,1,3) then return dow[j] end end end function getmonth(t) for j = 1 , 12, 1 do if string.sub(month[j], 1, 3) == string.sub(t,5,7) then return month[j] end end end function getmonthnum(t) for j = 1 , 12, 1 do if string.sub(month[j], 1, 3) == string.sub(t,5,7) then return j end end end function getdom(t) return tonumber(string.sub(t,9,10)) end function getyear(t) return tonumber(string.sub(t,21,24)) end function get24hour(t) return tonumber(string.sub(t,12,13)) end function getmin(t) return tonumber(string.sub(t,15,16)) end function getsec(t) return tonumber(string.sub(t,18,19)) end

So where did you discover about "GetAllOfType" anyway? I don't see it referenced anywhere else in the forums - there must be all sorts of useful stuff like that around that we only find out about by luck unless someone can point to some documentation that I haven't found yet. Thanks

Hey RF - I think you answered a different question here. I've got a good handle on manipulating zones - I am interested in how to prepopulate an input field with a good guess at (some of) the data the user is going to enter so as to reduce roller manipulation (on the CO anyway). Maybe this was intended for a different thread