Movables - better logging

Discussion about the Geocaching Australia web site
MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Movables - better logging

Post by MavEtJu » 23 May 17 10:08 am

There is a serious issue with logging and the status of moveables:

There is no difference between logging (as in "I've found it and signed the logbook") and picking up (as in "I've picked it up, it's not there anymore"). So there is no way to tell if a movable is still there unless you read and interpret the logs. (See http://geocaching.com.au/cache/ga5232 and http://geocaching.com.au/cache/ga4880 and see if you can find out which one I went searching for and which one I didn't try....)

How about this approach:

- To indicate that you signed the log, use a "found it" log.
- To indicate that you picked it up, use a "picked up" log. If you haven't logged a "found it" on this movable, it will generate a "found it" log for it too.
- GPX files and API data will show as "not available" once it has been "picked up" but not yet "moved" so that people know it's not there.
- GPX files will convert "picked up" logs to a "write note" log to not confuse third party software, but the API data will have the "picked up" logs.
- The website can now show the cache as not being there but still as "it's in the system".

This way it will be clearer what the status of a movable is.

Edwin

User avatar
caughtatwork
Posts: 17013
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Movables - better logging

Post by caughtatwork » 23 May 17 10:17 am


MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Movables - better logging

Post by MavEtJu » 23 May 17 10:51 am

While the text on the wiki can easily be argued with and countered, what we are talking about here is a way to make it easier to determine the availability of a movable by introducing a new logging type which the backend system can use to generate the right data for the website and provided data by it: There is currently no way to get rid of the ambiguity of the availability.

When you add an "in transit" log type the backend knows the availability of the movable. If no "found it" has been logged by this user for this cache, it can add it.

When a "moved" log is logged, the backend knows the availability of the movable. If no "found it" has been logged by this user for this cache, it can add it.

The GPX file provided changes the "In transit" to a "Note" which overcomes the problem with the third party software. The "available" field in the GPX data will show that the movable isn't there right now. The API data provided keeps the "In transit" log.

The website now can tell is a movable is available.
Apps now can tell if a movable is available.
GPSr can now tell if a movable is available.

Please do tell me where if goes wrong.

Edwin

User avatar
caughtatwork
Posts: 17013
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Movables - better logging

Post by caughtatwork » 23 May 17 11:20 am

I will not argue.

This has been discussed over a long, long period of time with the suggestions you have made. Check the forum for some of these discussions which were distilled in to the wiki entry. You will see that there has been no suitable suggestion which covers the gamut of where a geocache may be at any given point in time.

Your suggestions assume that the person playing is going to followup the actions (which history shows they will not), they have an app which they can use to log actions in the field (which they may not), they log their actions at the end of the day (which they will not) or they use logs in the wrong order (which they will).

A geocacher logs the geocache as found. If the geocache there or not? You cannot force a geocacher to log an "in-transit". So we are back at point 1. Is the geocache there or not? You don't know until you either read the log or wait for the geocacher to log the next action which they may never do as they did not move the geocache. Where is the geocache?

A geocacher logs a found with a new set of co-ordinates. If there is no "in-transit" then where is the geocache? This is not a transactional system.

A geocacher finds the geocache and takes it to rehide. Thay have not yet logged a find, or a note, or an in-transit or a hide. Where is the geocache?

You cannot force a geoacher to make certain logs in certain order at certain times. Read the logs of the geocache you are searching for and identify whether the geocache is there or not and take the risk of searching for something that may not be there.

Here's the list of scenarios you need to over to get accuracy.
1. Log a find on a cache. Where is the cache?
2a. Move a cache. Haven't logged yet. Where is the cache?
2b. Move a cache. Have logged it, but only after my co-ordinates are in my GPS. Where is the cache?
3. Log a find with new co-ordinates. Where is the cache?
4. Find a cache but haven't logged it yet. Where is the cache?
5. Attend an event where there are caches logged. At the end of the event, where is the cache?
6. For the purpose of this exercise you must assume that people may not log in the order your proscribe or at all. Where is the cache?
7. Adding "found it" logs cannot be done as geocaches can be found more than once, are you moving a geocache you found recently, last week, last year? Have you already found it? Have you already moved it? Assumptions about log order and time are invalid.

I have not seen a solution that caters for all scenarios.

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Movables - better logging

Post by MavEtJu » 23 May 17 11:35 am

> Your suggestions assume that the person playing is going to followup the actions (which history shows they will not), they have an app which they can use to log actions in the field (which they may not), they log their actions at the end of the day (which they will not) or they use logs in the wrong order (which they will).

And now think about the people who want to do it properly. Help them.

Edwin

User avatar
caughtatwork
Posts: 17013
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Movables - better logging

Post by caughtatwork » 23 May 17 2:34 pm

Please explain how to address all the scenarios. This has discussed this in the past and we cannot resolve all scenarios so we haven't. It's not a case of not wanting to, it's a case of it can't be done. But if a new set of eyes can explain how to address all scenarios then the situation can be revisited. Until then there can be no progress.

Some previous discussions going back to 2012.
http://forum.geocaching.com.au/viewtopi ... =1&t=17019
http://forum.geocaching.com.au/viewtopic.php?f=1&t=1563

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Movables - better logging

Post by MavEtJu » 23 May 17 3:37 pm

> Please explain how to address all the scenarios

No, because you are going on a lot of corner situations which this cannot address properly neither.

What I'm trying to achieve is not the holy pureness of everything works, what I'm trying to achieve is to make it possible to make recording the status of movables easier.

<hr>

State 1: (long lived state)
Reality: Movable is at location A.

In the database without "in transit": Movable is at location A, status is available. Matches reality.
In the database with "in transit": Movable is at location A, status is available. Matches reality.

State 2: (short lived state)

Reality: Movable is logged as found, not picked up (either in the field or at an event).

In the database without "in transit": Movable is at location A, status is available. Matches reality.
In the database with "in transit": Movable is at location A, status is available. Matches reality.

State 3: (short lived state)

Reality: Movable is picked up by somebody who holds it in their pocket (either in the field or at an event), not yet logged as such:

In the database without "in transit": Movable is at location A, status is available. Doesn't match reality.
In the database with "in transit": Movable is at location A, status is available. Doesn't match reality.

State 4: (long lived state)

Reality: Movable was picked up by somebody who holds it now in their pocket, logs it as "found" or "in transit":

In the database without "in transit": Movable is at location A, status is available. Doesn't match reality.
In the database with "in transit": Movable is at location A, status is unavailable. Matches reality.

State 5: (short lived state)

Reality: Movable was picked up by somebody who holds it now in their pocket, somebody else logs it as "found":

In the database without "in transit": Movable is at location A, status is available. Doesn't match reality.
In the database with "in transit": Movable is at location A, status is unavailable. Matches reality.

State 6: (short lived state)

Reality: Movable was moved by somebody who had it in their pocket, not yet logged as "moved":

In the database without "in transit": Movable is at location A, status is available. Doesn't match reality.
In the database with "in transit": Movable is at location A, status is unavailable. Matches reality.

State 7: (long lived state)

Reality: Movable was moved by somebody who had it in their pocket, now is logged as "moved":

In the database without "in transit": Movable is at location B, status is available. Matches reality.
In the database with "in transit": Movable is at location B, status is available. Matches reality.

And now see how many times each approaches are correct (. is correct, x is incorrect)

Code: Select all

                                 1 2 3 4 5 6 7
Database without “in transmit”   . . x x x x .
Database with “in transmit”      . . x . . . . 
It goes back from four times a mismatch with reality to once, which is only a short lived state (say a day or so, considering that these get found once a month if you are optimistic, that is just background noise) and it gets rid of one long-lived state mismatch.

Well worth it.

Edwin

(Oh,

Code: Select all

 and [table] don't work)

User avatar
caughtatwork
Posts: 17013
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Movables - better logging

Post by caughtatwork » 23 May 17 4:38 pm

When a geocache is logged as found, where is it?
Is it at GZ?
Is it in my pocket because I haven't yet logged an in-transit?
Is it at a new GZ but I haven't yet logged a move.

Movable is logged as found, (picked up or not picked up) (either in the field or at an event), where is it?
Is it at GZ because there is no in-transit or moved?
It is in my pocket because I didn't log it according to the new method?
Is it awaiting a new GZ and I haven't logged the move yet because I don't have co-ordinates?
Is it at a new GZ and I'm waiting to log the moved?
Until a statement is made about whether it has been picked up it's Schrödinger's cache, both in place and not in place.

You are constructing scenarios where you know the outcome. When you can appreciate that when you don't know the outcome, increasing the complexity doesn't yet help.

Here, let's play a game and keep it simple and not edge case.

You see a geocache listed at a location.
Is it there?

You see a geocache listed at a location but the last log was a "found it".
Is it there?

You see a geocache listed at a location and the last log was a "found it" with co-ordinates.
Is it there?

You see a geocache listed at a location but the last log was a "moved it".
Is it there?


Remember you're reading the logs. Tell me where the geocache is before you decide to head out and find it. Assume nothing. Do not assume I have completed logging. No assume I have more logging. Based on what you see on the site, tell me where the geocache is.

Now let's play the game according to the new rules.

You see a geocache listed at a location.
Is it there?

You see a geocache listed at a location but the last log was a "found it".
Is it there?

You see a geocache listed at a location and the last log was a "found it" with co-ordinates.
Is it there?

You see a geocache listed at a location but the last log was a "moved it".
Is it there?

You see a geocache listed at a location but the last log was a "in-transit".
Is it there?

From what I can tell, there is a non-trivial amount of additional work and effort for a logger to make a log about whether something is in-transit to confirm 1 scenario where it has been taken from the location.

I am yet to see the benefit of such activity increasing the code base, the user experience and what will be needed when people do not log an "in-transit".

Remember that an "in-transit" will be a note so GSAK or my GPS won't help me. I still need to read the logs which is what I need to do right now.

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Movables - better logging

Post by MavEtJu » 23 May 17 5:15 pm

> You see a geocache listed at a location.
> Remember you're reading the logs.

The logs is one part of the geocache, the meta data like the terrain, coordinates and availability status is another part.

#1

> You see a geocache listed at a location. Is it there?

It should be.

> You see a geocache listed at a location but the last log was a "found it". Is it there?

It should be.

> You see a geocache listed at a location and the last log was a "found it" with co-ordinates. Is it there?

It should be.

> You see a geocache listed at a location but the last log was a "moved it". Is it there?

It should be.

#2

> You see a geocache listed at a location. Is it there?

It should be..

> You see a geocache listed at a location but the last log was a "found it". Is it there?

It should be.

> You see a geocache listed at a location and the last log was a "found it" with co-ordinates. Is it there?

It should be.

> You see a geocache listed at a location but the last log was a "moved it". Is it there?

It should be.

> You see a geocache listed at a location but the last log was a "in-transit". Is it there?

No

<hr>

Now, these same questions answered for the backend system:

#1

> You have a movable registered at a location. Is it there?

The backend system shows that the movable should be there.

> You have a movable registered at a location but the last log was a "found it". Is it there?

Undetermined as found may mean "I saw it and signed the log" or "I saw it and took it".

> You have a movable registered at a location and the last log was a "found it" with co-ordinates. Is it there?

The backend system shows that the movable should be there.

> You have a movable registered at a location but the last log was a "moved it". Is it there?

The backend system shows that the movable should be there.

#2

> You have a movable registered at a location. Is it there?

The backend system shows that the movable should be there.

> You have a movable registered at a location but the last log was a "found it". Is it there?

The backend system shows that the movable should be there.

> You have a movable registered at a location and the last log was a "found it" with co-ordinates. Is it there?

The backend system shows that the movable should be there.

> You have a movable registered at a location but the last log was a "moved it". Is it there?

The backend system shows that the movable should be there.

> You have a movable registered at a location but the last log was a "in-transit". Is it there?

The backend system shows that the movable is not there.

And as such the backend system has a better way to display the reality:

'You have a movable registered at a location but the last log was a "found it". Is it there?' is now not ambiguous anymore and 'You have a movable registered at a location but the last log was a "in-transit". Is it there?' shows that the movable is not at the registered location.


<hr>

> From what I can tell, there is a non-trivial amount of additional work and effort for a logger to make a log about whether something is in-transit to confirm 1 scenario where it has been taken from the location.

Geocachers happy to do the right thing when they are given the options and they are smart enough to determine what the right things are when provided with a set of sane defaults.

> what will be needed when people do not log an "in-transit".

You already have that problem currently, this will remove the problem for the people who want to do the right thing.

> Remember that an "in-transit" will be a note so GSAK or my GPS won't help me. I still need to read the logs which is what I need to do right now.

You are still missing the toggling of the "available" part for the cache when the movable goes into "in transit" mode. Yes, you don't have an "in transit" log, but you have a "write note" to make sure that you see the data for the "in transit" log and you have the "available" field in the meta data which shows that it is not at the registered location right now.

<groundspeak:cache id="4158509" archived="False" available="True" xmlns:groundspeak="http://www.groundspeak.com/cache/1/0">

^^^-- that red text. GSAK honours it in the displaying of the data in the overview. The website honours it in the displaying of the data in the overview. Any other third party app honours it.

Edwin

User avatar
caughtatwork
Posts: 17013
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Movables - better logging

Post by caughtatwork » 23 May 17 5:42 pm

Ok. You have a copy of our database schema and code base. Please make the changes you propose and I will run some tests. You know how to get the code back to me.

User avatar
CraigRat
850 or more found!!!
850 or more found!!!
Posts: 7015
Joined: 23 August 04 3:17 pm
Twitter: CraigRat
Facebook: http://facebook.com/CraigRat
Location: Launceston, TAS
Contact:

Re: Movables - better logging

Post by CraigRat » 23 May 17 6:03 pm

Movables are tricky buggers.

There's so many edge cases which make it impossible to make it transnational based without gumming up the works.

A good example is when people had gnome events. There were gnomes being passed around and moved multiple times during the events and during the day.
Some people logged straight away, some didn't. It can become a right mess very quickly.

I do like the idea of some way to indicate it's gone/in transit (I've proposed it myself) , however we keep falling back on the fact that people will do things the wrong way (tm) in this case, out of sequence. It's so tricky to find something that is an acceptable medium.

All input is valuable, and bringing this up isn't a bad thing, we've been over this many a time now!

Laighside Legends
10000 or more caches found
10000 or more caches found
Posts: 1304
Joined: 05 October 10 10:20 pm
Location: Australia

Re: Movables - better logging

Post by Laighside Legends » 23 May 17 6:26 pm

I thought we agreed on a solution to this all those years ago!
And it's currently the first item on the development list!

User avatar
CraigRat
850 or more found!!!
850 or more found!!!
Posts: 7015
Joined: 23 August 04 3:17 pm
Twitter: CraigRat
Facebook: http://facebook.com/CraigRat
Location: Launceston, TAS
Contact:

Re: Movables - better logging

Post by CraigRat » 23 May 17 7:19 pm

Part of where we come from on the developers side is the immense amount of effort there is in 'rectifying' a stuffed up sequence of logging, especially at game times.

If this was a live game and didn't have people logging things weeks down the track it would be SO much easier.

If I had a crystal ball, I don't know if I'd do it much differently give reasons in the above comments.(a lot of this is my fault)

User avatar
caughtatwork
Posts: 17013
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Movables - better logging

Post by caughtatwork » 23 May 17 7:36 pm

Laighside Legends wrote:I thought we agreed on a solution to this all those years ago!
And it's currently the first item on the development list!
Read that thread carefully. The best we could suggest after 8 pages was an icon. Not important to me with other more important matters. Edwin is now charged with the solution including the new log type handling including removing multiple logs when one is deleted and dz points calculations and trophies. GPX handling and API need to be catered for s well as other download types. It's a big job and will only partially address part of the issue. But if Edwin in willing to put in the effort the least we can do is offer him a challenge.

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Movables - better logging

Post by MavEtJu » 25 May 17 9:56 pm

caughtatwork wrote: But if Edwin in willing to put in the effort the least we can do is offer him a challenge.
I surely missed the announcement for this promotion I had in the GCA hierarchy.

Edwin

Post Reply