Step 1
What I'm after is to determine whether or not the original coordinates on gc.com have, for whatever reason, over-written the corrected coordinates in gsak. Or, to put it another way, even though coordinates have been marked as corrected, they are still in fact the original coordinates. Once that has been determined, then take some sort of action.
I've downloaded SQLiteStudio (which is okay) and sqlite-gui (which is quicker) so that I could examine the gsak database structure. If I understand correctly, the table.fields of concern are as follows
Caches Table
Latitude,Longitude,HasCorrected
Corrected Table
kBeforeLat,kBeforeLon,kAfterLat,kAfterLon
Joined on Code,kCode
I do not know the database structure on gc.com. But before going there, it is a safe assumption that querying gc.com for every cache in a list is inefficient and impractical. So it seems to me that selecting a list of candidates to work on is the proper order of business.
So the first task is to short list caches for potential error. Bear with me as I work through this.
A. Assuming we have a list of mysteries with corrected coordinates, then the 'hascorrected' field plays no role. But if the list contains a mix, then the first step might be to filter on has HasCorrected or at least use it as part of the selection criteria.
B. Comparing 'corrected' before.lat/lon with after.lat/lon proves nothing because if they don't match, it only shows a change (which is supposed to happen anyway if there has been an update), and if they do match, the reason could be nothing other than they were imported manually then flagged as corrected without refreshing from gc.com
C. Comparing 'corrected' after.lat/lon with 'caches' lat/lon is an interesting thought, but if the cache has corrected coordinates then these values 'should' be the same.
D. Comparing 'corrected' before.lat/lon with 'caches' lat/lon seems to hold the best promise as these values should 'not' be the same. This is very similar to B above. But for 'this' to hold value, we assume the proviso that the caches have been refreshed and contain current information. Note. This may be the source of most errors such that imported lists were refreshed prior to setting the HasCorrected flag.
To this end, then, a query like the following permits visual inspection and provides a hint about the number of caches that may be in error.
Caveat. My query ignores/rules-out half answers where either the lat's match or the lon's match but not both... which 'may' indicate a problem. But either way, what I have is a beginning.
Q1. Is the logic I've laid out reasonable? How might it be improved?
Q2. Understanding that gsak returns full records, how might my select query be implemented as a filter in gsak? A link to a help page would be sufficient.
Note. If all's well, the next step would seem to be to query the original coordinates from gc.com and compare those to what is in the gpx file. Once that is done, a course of action could be determined. This assumes the original coordinates are accessible even if the cache page has been updated with corrected coords. If that can't be done, then that would add an extra hurdle to overcome.
Thanks if you've made it this far.
What I'm after is to determine whether or not the original coordinates on gc.com have, for whatever reason, over-written the corrected coordinates in gsak. Or, to put it another way, even though coordinates have been marked as corrected, they are still in fact the original coordinates. Once that has been determined, then take some sort of action.
I've downloaded SQLiteStudio (which is okay) and sqlite-gui (which is quicker) so that I could examine the gsak database structure. If I understand correctly, the table.fields of concern are as follows
Caches Table
Latitude,Longitude,HasCorrected
Corrected Table
kBeforeLat,kBeforeLon,kAfterLat,kAfterLon
Joined on Code,kCode
I do not know the database structure on gc.com. But before going there, it is a safe assumption that querying gc.com for every cache in a list is inefficient and impractical. So it seems to me that selecting a list of candidates to work on is the proper order of business.
So the first task is to short list caches for potential error. Bear with me as I work through this.
A. Assuming we have a list of mysteries with corrected coordinates, then the 'hascorrected' field plays no role. But if the list contains a mix, then the first step might be to filter on has HasCorrected or at least use it as part of the selection criteria.
B. Comparing 'corrected' before.lat/lon with after.lat/lon proves nothing because if they don't match, it only shows a change (which is supposed to happen anyway if there has been an update), and if they do match, the reason could be nothing other than they were imported manually then flagged as corrected without refreshing from gc.com
C. Comparing 'corrected' after.lat/lon with 'caches' lat/lon is an interesting thought, but if the cache has corrected coordinates then these values 'should' be the same.
D. Comparing 'corrected' before.lat/lon with 'caches' lat/lon seems to hold the best promise as these values should 'not' be the same. This is very similar to B above. But for 'this' to hold value, we assume the proviso that the caches have been refreshed and contain current information. Note. This may be the source of most errors such that imported lists were refreshed prior to setting the HasCorrected flag.
To this end, then, a query like the following permits visual inspection and provides a hint about the number of caches that may be in error.
| CODE |
SELECT C.Code,C.Name,C.Latitude,K.kBeforeLat,C.Longitude,K.kBeforeLon FROM caches C INNER JOIN Corrected K ON C.Code=K.kCode WHERE C.Latitude=K.kBeforeLat and C.Longitude=K.kBeforeLon; |
Caveat. My query ignores/rules-out half answers where either the lat's match or the lon's match but not both... which 'may' indicate a problem. But either way, what I have is a beginning.
Q1. Is the logic I've laid out reasonable? How might it be improved?
Q2. Understanding that gsak returns full records, how might my select query be implemented as a filter in gsak? A link to a help page would be sufficient.
Note. If all's well, the next step would seem to be to query the original coordinates from gc.com and compare those to what is in the gpx file. Once that is done, a course of action could be determined. This assumes the original coordinates are accessible even if the cache page has been updated with corrected coords. If that can't be done, then that would add an extra hurdle to overcome.
Thanks if you've made it this far.