Jump to content
Sign in to follow this  
Followers 2
Orosman

How do I change found log order

Recommended Posts

Hi there

 

I did 43 caches yesterday but forgot to log two of them in order

Is there a way to bulk delete logs so That I can start again or just a way I can move the cache logs around

 

Regards

Orosman

Share this post


Link to post

Hi there

 

I did 43 caches yesterday but forgot to log two of them in order

Is there a way to bulk delete logs so That I can start again or just a way I can move the cache logs around

 

Regards

Orosman

 

You would have to delete them one by one, there is no bulk delete. There is also no way to reorder the logs on the website. How important is it that they be in order? Is it just a personal preference or will it mess up a statistic? Milestones can be adjusted on the website stats as well as in many third party stats programs. Adjusting "Greatest Distance in Day" can be more problematic. If it doesn't affect any of that, I would just forget it.

Share this post


Link to post

If I recall correctly, the answer is an unfortunate "no", at least on the GC site. The good news is that you don't have to delete them all and start over, just delete in reverse order back to the error(s) then relog. For instance, your cache logs are: 1, 2, 3, 5, 6. Delete 6 and 5 and re-enter as 4, 5, 6.

Share this post


Link to post

Thanks Guys

 

Yes it is to do with Stats and I have forgotten how to do that as well

Plus now all the logs say 41 caches done and not 43 (which sucks for the logs)

 

Thanks for the help

Share this post


Link to post

Actually, on a small scale, I've had luck reordering by using the ability to edit dates on the logs.

 

As I recall, the logs will move slightly, but then I never tried a mass batch. At any rate the logs maintain a bit of their new position when the dates are switched back to the correct one. You can decide whether to date forward or backward as well to help nudge them into 'order'.

 

But definitely no bulk sorting. Perhaps a work around would be to start by putting sequence numbers into the log text for reference.

As in log 1 is #1 log 2 is #2 Log 3 is #4 Log 4 is #3 and so forth. At least you would know which is which regardless.

Then take your time 'correcting' using those as a guide.

 

Hope that might help. No need to change anything but the dates as well.

 

Doug 7rxc

Share this post


Link to post

Actually, on a small scale, I've had luck reordering by using the ability to edit dates on the logs.

 

As I recall, the logs will move slightly, but then I never tried a mass batch. At any rate the logs maintain a bit of their new position when the dates are switched back to the correct one. You can decide whether to date forward or backward as well to help nudge them into 'order'.

 

But definitely no bulk sorting. Perhaps a work around would be to start by putting sequence numbers into the log text for reference.

As in log 1 is #1 log 2 is #2 Log 3 is #4 Log 4 is #3 and so forth. At least you would know which is which regardless.

Then take your time 'correcting' using those as a guide.

 

Hope that might help. No need to change anything but the dates as well.

 

Doug 7rxc

 

The caches were all done on the same day. :rolleyes:

 

To the OP: See post #3.

Share this post


Link to post

Actually, on a small scale, I've had luck reordering by using the ability to edit dates on the logs.

 

As I recall, the logs will move slightly, but then I never tried a mass batch. At any rate the logs maintain a bit of their new position when the dates are switched back to the correct one. You can decide whether to date forward or backward as well to help nudge them into 'order'.

 

But definitely no bulk sorting. Perhaps a work around would be to start by putting sequence numbers into the log text for reference.

As in log 1 is #1 log 2 is #2 Log 3 is #4 Log 4 is #3 and so forth. At least you would know which is which regardless.

Then take your time 'correcting' using those as a guide.

 

Hope that might help. No need to change anything but the dates as well.

 

Doug 7rxc

This may actually work as It would shift them around to the right order

 

Thanks

still seems a bit of an issue

so I will see if i need to actually do it or if it is worth the bother

Share this post


Link to post

Actually, on a small scale, I've had luck reordering by using the ability to edit dates on the logs.

 

As I recall, the logs will move slightly, but then I never tried a mass batch. At any rate the logs maintain a bit of their new position when the dates are switched back to the correct one. You can decide whether to date forward or backward as well to help nudge them into 'order'.

 

But definitely no bulk sorting. Perhaps a work around would be to start by putting sequence numbers into the log text for reference.

As in log 1 is #1 log 2 is #2 Log 3 is #4 Log 4 is #3 and so forth. At least you would know which is which regardless.

Then take your time 'correcting' using those as a guide.

 

Hope that might help. No need to change anything but the dates as well.

 

Doug 7rxc

 

The caches were all done on the same day. :rolleyes:

 

To the OP: See post #3.

 

Granted, but that is why the edit to the dates to make some order fixes and then change them back to the right date.

I find it works well, the numbering was due to the quantity he has. Using your example, the ones that are in correct order can be backdated to one date, any that are correct at the end sequence can be to another, leaving a few to be corrected in the middle somewhere, blocks or not. Then you simply redate back to correct date in the right sequence. But like I said, I've never done it in a large block like that. GC logs follow an easily discernible pattern of sequence of entry or even correction.

Give it the data in the right order and the list will correct properly.

 

My pet peeve is with photo posting in logs... often I create a series of shots with captions and the system lists them by some method or other... I get one place in sequence required only to find the other spot reverses or scrambles the list... Sigh!

 

Doug 7rxc

Share this post


Link to post

This may actually work as It would shift them around to the right order

 

Thanks

still seems a bit of an issue

so I will see if i need to actually do it or if it is worth the bother

 

Nice thing is that once you sort out the method, you can work it a bit at a time.

AZcm was correct about one part as I explained my method in my reply to them.

 

It assumes you know what the desired order should be. One also assumes that many of them are in the correct order already.

From experience I mostly get the right sequence for small bunches of caches, then my notes tell me I goofed.

Usually not more than one or two out of sequence. Even then I move the dates before and after the flaws to dates behind and ahead of the desired one. Then use dates in between to establish the correction. Then put the whole thing back in the order that ends up being the correct sequence and date. I don't envy having to do a lot, but I bet you can preserve larger blocks between 'flaws'.

Easier to wait a few days as well, since you have some room then to date back and forward. I'm not sure how the system allows dating ahead of the current date, but it seems to allow that from the choices list.

 

As you said, perhaps you just need to nudge the list closer to the sequence, not exact.

 

Good luck,

 

Doug 7rxc

Share this post


Link to post

Actually, on a small scale, I've had luck reordering by using the ability to edit dates on the logs.

 

As I recall, the logs will move slightly, but then I never tried a mass batch. At any rate the logs maintain a bit of their new position when the dates are switched back to the correct one. You can decide whether to date forward or backward as well to help nudge them into 'order'.

 

But definitely no bulk sorting. Perhaps a work around would be to start by putting sequence numbers into the log text for reference.

As in log 1 is #1 log 2 is #2 Log 3 is #4 Log 4 is #3 and so forth. At least you would know which is which regardless.

Then take your time 'correcting' using those as a guide.

 

Hope that might help. No need to change anything but the dates as well.

 

Doug 7rxc

 

The caches were all done on the same day. :rolleyes:

 

To the OP: See post #3.

 

Granted, but that is why the edit to the dates to make some order fixes and then change them back to the right date.

I find it works well, the numbering was due to the quantity he has. Using your example, the ones that are in correct order can be backdated to one date, any that are correct at the end sequence can be to another, leaving a few to be corrected in the middle somewhere, blocks or not. Then you simply redate back to correct date in the right sequence. But like I said, I've never done it in a large block like that. GC logs follow an easily discernible pattern of sequence of entry or even correction.

Give it the data in the right order and the list will correct properly.

 

My pet peeve is with photo posting in logs... often I create a series of shots with captions and the system lists them by some method or other... I get one place in sequence required only to find the other spot reverses or scrambles the list... Sigh!

 

Doug 7rxc

 

This makes no sense. Each log has a unique sequential log id#. When sorting, it is done by date, then by log ID. If you change the date and then change it back, you have the exact same criteria to sort and the results should be the same.

Share this post


Link to post

I said that it appeared to work for small batches. I have no idea what would happen in large ones or what his primary goal is re accuracy. Probably better to keep his 'official' records in something like GSAK anyway.

 

Since you seem to know all about the GC data field structure, care to share where you got that from? I'd like to see what it is like.

Playing with databases and sorting is what I used to do for a living. I agree that the basic structure of that would prevent a resort in a case like this. But I've never seen anything I've recognized so far, but I'm likely out of date, which is why I'm interested.

 

Doug 7rxc

Share this post


Link to post

I am guessing each log has an ascribed ID# 'attribute' and a date of posting 'attribute'. The date of posting is user-defined, but the ID# is fixed.

 

I always thought the site ordered logs by:

1. The date you ascribed to the log.

then

2. The order in which you posted the log.

 

So that, if you posted your log for cache (1) before your log for cache (2), but ascribed the same date then the site would display your log for cache (1) as before cache (2). All good so far.

 

If you suddenly realized you had actually found cache (2) the day before you found cache (1), and you change the date for the log of (2), it would then appear before (1) in your list of found caches (since the date of the log supersedes the overall 'posted log ID #'). If you then change the date back, (1) should once again be listed before (2).

 

I'm not sure how all this works in actual practice, since I have never attempted to re-order a particular day's finds within that day.

 

Naturally the proof is in the pudding, and if it works...then it works!

 

I will say that I have 'injected' logs for caches I forgot to log properly, and although the log may be posted three or four days after the date I log it for (and may be sequentially out of order on that date), it does appear before the logs on the caches logged on the next day.

 

EDITED: To fix the site's propensity to make an emoticon out of everything.

Edited by AZcachemeister

Share this post


Link to post

I said that it appeared to work for small batches. I have no idea what would happen in large ones or what his primary goal is re accuracy. Probably better to keep his 'official' records in something like GSAK anyway.

 

Since you seem to know all about the GC data field structure, care to share where you got that from? I'd like to see what it is like.

Playing with databases and sorting is what I used to do for a living. I agree that the basic structure of that would prevent a resort in a case like this. But I've never seen anything I've recognized so far, but I'm likely out of date, which is why I'm interested.

 

Doug 7rxc

 

You can see it in the gpx file:

 

<Groundspeak:log id="250467017">

 

It is a common topic on the GSAK Support Forums, usually in regard to someone wanting to reorder their logs to get a certain cache to be a milestone, or the out of order logs causing the most distance traveled in a day to be wrong. According to the log IDs, I crossed the Mojave Desert four times in a single day. Of course, I only crossed it once but I logged the caches in the wrong order.

Share this post


Link to post

 

You can see it in the gpx file:

 

<Groundspeak:log id="250467017">

 

It is a common topic on the GSAK Support Forums, usually in regard to someone wanting to reorder their logs to get a certain cache to be a milestone, or the out of order logs causing the most distance traveled in a day to be wrong. According to the log IDs, I crossed the Mojave Desert four times in a single day. Of course, I only crossed it once but I logged the caches in the wrong order.

 

.gpx would explain not seeing it... not a PM. Now that I know what it looks like I can look elsewhere to see if I can find it.

Thanks for the information.

As I said I based my advice on experience, but not much of it. Perhaps I simply blundered into a specific case that APPEARED to work properly due to the small sample.

 

TO AZ: Up to the larger numbers point that fits my experience, originally was thinking that editing somehow would affect the sequencing, but a fixed ID# would mess that idea. Perhaps a editable sequence number portion of the ID tag would be the answer.

One can slice the data in a field many ways, but I guess that would be easily outstripped by power cachers. I guess I'll go with use GSAK or just add sequence numbers (or use artificial dates since many don't care about the date anyway based on logs that state 'found a year ago' while using the current date).

 

Thanks to both of you again.

Doug 7rxc

Share this post


Link to post

There are probably a lot of good reasons for there to be a fixed log ID#.

I'm not devious enough to say what they all might be, but I can imagine one or two pretty easily. ;)

Share this post


Link to post

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...
Sign in to follow this  
Followers 2

×
×
  • Create New...