Allow a stored cache to belong to multiple lists

[Bonemaro]

I have a suggestion.

My caches are organized in lists like To Do, Events, My Hides, etc. Every time I import a new GPX file that contains a cache that is in one of my other lists, it pulls that cache out of the list and places it into the Stored list along with the others from that GPX.

Would it be possible to allow importing of a GPX without affecting other stored lists?

Thanks much! :-D

[SammysHP]

You can have every cache only in one list. We have to decide if we want imported caches in the current list or in the default/old list.

[Bonemaro]

Understood. I vote they stay where I put them.
On Aug 1, 2011 12:20 PM, "SammysHP" <
reply@reply.github.com>
wrote:

You can have every cache only in one list. We have to decide if we want
imported caches in the current list or in the default/old list.

Reply to this email directly or view it on GitHub:
#87 (comment)

[SammysHP]

But others want imported caches in the currently selected list. ;)

[Bonemaro]

That'll work too. I can just handle the organization within my pocket
queries.
On Aug 1, 2011 12:36 PM, "SammysHP" <
reply@reply.github.com>
wrote:

But others want imported caches in the currently selected list. ;)

Reply to this email directly or view it on GitHub:
#87 (comment)

[SammysHP]

Then there is no problem. Split your PQ and import the parts into the specific lists. ;)

[koem]

For me this sounds like a bug, though I didn't ever use lists nor imported anything from file or so. A cache in one list should just stay there if it is imported. There is a reason, why it is in that specific list.

[rsudev]

This caught my by surprise once, too. But it would not be so easy to tell the user that some caches of the import he expected in the current list were placed somewhere else.
Of course it could be an additional option in the import dialog to say 'leave existing caches in their current list' if you have more than one...

[Bonemaro]

If a cache is in a list other than stored, it was put there by the user.
On Aug 1, 2011 4:06 PM, "rsudev" <
reply@reply.github.com>
wrote:

This caught my by surprise once, too. But it would not be so easy to tell
the user that some caches of the import he expected in the current list were
placed somewhere else.
Of course it could be an additional option in the import dialog to say
'leave existing caches in their current list' if you have more than one...

Reply to this email directly or view it on GitHub:
#87 (comment)

[rsudev]

That's true, but he may not be aware of it when he imports 10 caches from a gpx and only finds three in the list after c:geo saying 10 imported...
That is just as confusing as caches that jumped from somewhere else to the current list due to the import.

[Bonemaro]

But, when I import 995 caches and have 5 in a special to do list...
On Aug 1, 2011 5:49 PM, "rsudev" <
reply@reply.github.com>
wrote:

That's true, but he may not be aware of it when he imports 10 caches from
a gpx and only finds three in the list after c:geo saying 10 imported...
That is just as confusing as caches that jumped from somewhere else to the
current list due to the import.

Reply to this email directly or view it on GitHub:
#87 (comment)

[SammysHP]

Then you have to split the GPX. I know, it's a bad compromise, but others think the other way. I'll tag this as frontend design and feature request but it can take a while.

[gcey]

IMO the problem is, that currently every cache can only be in one list.
When I have a list "caches not found and to be re-searched" and I craete a new list "caches near home" and import a PQ into that list, then both would be wrong:

• pulling caches out of my existing list
• not importing some caces into the new list
  So IMO the right solution would be to keep them in one list and additionally import them into the other list.

[Bonemaro]

That was my thinking as well.
On Aug 2, 2011 5:54 PM, "gcey" <
reply@reply.github.com>
wrote:

IMO the problem is, that currently every cache can only be in one list.
When I have a list "caches not found and to be re-searched" and I craete a
new list "caches near home" and import a PQ into that list, then both would
be wrong:

• pulling caches out of my existing list
• not importing some caces into the new list
  So IMO the right solution would be to keep them in one list and
  additionally import them into the other list.

Reply to this email directly or view it on GitHub:
#87 (comment)

[SammysHP]

But more than one list would result in other problems. What if you want to delete one? Is it deleted in only one list? I think this would not be so easy.

[Bonemaro]

Yes, each entry would have to be treated as an individual in this method.
On Aug 3, 2011 4:56 AM, "SammysHP" <
reply@reply.github.com>
wrote:

But more than one list would result in other problems. What if you want to
delete one? Is it deleted in only one list? I think this would not be so
easy.

Reply to this email directly or view it on GitHub:
#87 (comment)

[Bonemaro]

Then to further complicate it, what if you imported a cache into a specific
list where it already existed? At that point would it overwrite the old
record or would it create a duplicate. Tricky indeed.
On Aug 3, 2011 4:56 AM, "SammysHP" <
reply@reply.github.com>
wrote:

But more than one list would result in other problems. What if you want to
delete one? Is it deleted in only one list? I think this would not be so
easy.

Reply to this email directly or view it on GitHub:
#87 (comment)

[gcey]

But more than one list would result in other problems.
What if you want to delete one? Is it deleted in only one list?

IMO it would be deleted in this list.
And if this was the last list containing the cache, the whole cache data could be deleted.

[gcey]

Then to further complicate it, what if you imported a cache into a specific list where it already existed?
At that point would it overwrite the old record or would it create a duplicate. Tricky indeed.

I am pretty sure, that nobody wants duplicates in a list.
So re-importing should overwrite the old record.

[Bonemaro]

Indeed...
On Aug 5, 2011 11:23 AM, "gcey" <
reply@reply.github.com>
wrote:

Then to further complicate it, what if you imported a cache into a
specific list where it already existed?
At that point would it overwrite the old record or would it create a
duplicate. Tricky indeed.

I am pretty sure, that nobody wants duplicates in a list.
So re-importing should overwrite the old record.

Reply to this email directly or view it on GitHub:
#87 (comment)

[TeamHellspawn]

Hm,
after reading the other comments things should work like this i think:

• when importing a gpx file there should be an option to keep existing caches in their lists
• when deleting a cache there 2 optianal ways should be offered: delete from list and delete from phone. Just one more option when pressing long. If the cache is on no other list then the cache should be moved to the standart list.
• when importing a gpx file there should be an option to overwrite the old cache data with the new one, normaly set to yes (it´s the way it makes sense in the most cases imho)

LG

[SammysHP]

Just one more option when pressing long

Don't forget the two buttons on detail-view. ;)

[HansJA]

The error seems to be in the basic list design.
Why are you putting the actual physical data into the list?
Why not put just references into the lists?

Think files, hard links and symbolic links, like in any linux or unix.

[SammysHP]

Why are you putting the actual physical data into the list?

Why do you thinkt this? Do you know our database schema?

[HansJA]

If not, why is there a design decision that caches can only be in one list??

On 2011-09-21 18:40, Sven Karsten Greiner wrote:

Why are you putting the actual physical data into the list?
Why do you thinkt this? Do you know our database schema?

[Bananeweizen]

Because average users are confused if a cache reoccurs on a second list, if they deleted it from a first list. Just because some experienced users will take advantage of caches being present on multiple lists does not mean that the average user has any benefits from it.

[HansJA]

They are probably much much more confused by the consequences, like when downloading PQs.

Skickat från min Android Mobil

Bananeweizen reply@reply.github.com skrev:

Because average users are confused if a cache reoccurs on a second list, if they deleted it from a first list. Just because some experienced users will take advantage of caches being present on multiple lists does not mean that the average user has any benefits from it.

Reply to this email directly or view it on GitHub:
#87 (comment)

[gcey]

I fully agree with HansJA.

[HansJA]

Thank you!

As an aside:

I suppose one could have a single list of all active caches stored, and
multiple views of that list, which should be lists-of-references, that
could be generated from PQ downloads, or filtering, or manual selection
or searches or anything.

Importing a PQ gpx then stores any caches not previously present,
putting them all in the main list, and puts references to all caches
mentioned in the PQ in the current view.

Deleting a cache should only be done as an explicit "delete" on a cache
in one of its views or the main stored list, and kept separate from
"drop"-ing a cache ref from a view.

On 2011-09-21 20:46, gcey wrote:

I fully agree with HansJA.

[csuprin]

Hello, I am a long time cgeo user and started using lists today for the first time. I was confused/disappointed/befuddled by the fact that when I imported a GPX file into one list it removed the overlap from the other list.

As an anology, I found it like coffee being removed from the list of office supplies needed because I added coffee to the list of things needed at home.

Just to explain how I was hoping to use lists. I have pocket queries of unfound caches centered around different locations, home, work, friends, event, and the like. When I am near one of these places I was hoping to use the stored list for that location to help speed up sorting, limit the mapping and the like. However now many of these overlap and the caches end up in only one of the lists. Ok. Which one? Well that depends on the last one that loaded it.

Not to be completely unsympathetic to developers, it is easier to add a single field to a database than worry about creating a new table or tables to manage the lists. The earlier posts do discuss most of the issues.

Folks thanks for all the good work. Keep it up. CGEO remains my preferred geocaching app.

[RobinAllen]

Ability to have caches span multiple lists like this is something I've wanted for some time.

In my scenario, I have a 'local caches' list and I also have some 'special todo caches' list. If I re-load a GPX of local caches, then my reminder of a special 'todo' cache gets demoted to being just a 'local' cache.

I can see how there is worry that this would only be used / understood by experienced users, but I disagree. Handled automatically this would be transparent to the 'idiot' user - they would put a cache in a list and when they deleted it from the list it would disappear from the device, the same as before. They wouldn't know anything special had happened. The advanced user would be able to hit 'copy to list' as an option instead of just 'move to list', and copying the cache would just create another reference to the same cache data from the second list. Deletion from the device would be handled automatically at the point when the cache is no longer referenced from any lists. Updating caches would be handled automatically across multiple lists by the master data being stored outside the list.

[Amorak]

+1
For having the same cache in multiple lists.
Not having this makes c:geo rather unfriendly to use.

Consider this use case:
You have a list for the caches in the western Unite States that you need for your year/month placed calendar. There are only a very select few.
You create a PQ/list for caches along a route to an area you are visiting. The route has some of the caches from the year/month list. But, when you import the route, the year/month cashes are removed from that very exclusive list and mixed in with the hundreds of other caches in the route list. Rather frustrating.

I use c:geo exclusively and this is the only major complaint I have about the app.

Thanks,

DJL

[pstorch]

I was just curios about the oldest open issue. ;)
I also think it should be possible to put a cache in multiple lists. Same behaviour as Caches on Bookmarklists at geocaching.com.

[rsudev]

I think in principle we are all in the same book - but besides the effort required, also the details of how to present this to the user are IMO not final yet.

[pstorch]

I'm still curious about this issue and did some analysis.

Predefined Lists

StoredList.TEMPORARY_LIST_ID = 0 "temporary"
StoredList.STANDARD_LIST_ID = 1 "Stored"
PseudoList.ALL_LIST_ID = 2 "All caches"
PseudoList.NEW_LIST_ID = 3 "Create new list"
PseudoList.HISTORY_LIST_ID = 4 "History"

As far as I can see only the STANDARD_LIST is the only predefined list used in the DB.

Custom Lists

customListIdOffset = 10
First custom list has _id=1 in cg_lists and reason=11 in cg_caches.

Current DB Schema

cg_caches.reason
cg_lists._id

cg_lists._id +10 == cg_caches.reason

Model Class

cgeo.geocaching.models.Geocache
private int listId = StoredList.TEMPORARY_LIST.id;

Data Access Class

cgeo.geocaching.storage.DataStore

Methods / Queries involved

loadInViewport(): selects cg_caches where reason >= StoredList.STANDARD_LIST_ID
cleanIfNeeded(): deletes cg_caches where reason = 0
getLists(): joins cg_lists._id with cg_caches.reason

          SELECT l._id as _id, l.title as title, COUNT(c._id) as count
            FROM cg_lists l LEFT OUTER JOIN cg_caches c
            ON l._id + customListIdOffset = c.reason

MOVE_TO_STANDARD_LIST: UPDATE cg_caches SET reason = StoredList.STANDARD_LIST_ID WHERE reason = ?
MOVE_TO_LIST: UPDATE cg_caches SET reason = ? WHERE geocode = ?
COUNT_CACHES_ON_STANDARD_LIST: SELECT count(_id) FROM cg_caches WHERE reason = StoredList.STANDARD_LIST_ID
COUNT_ALL_CACHES: SELECT count(_id) FROM cg_caches WHERE reason >= StoredList.STANDARD_LIST_ID
LIST_ID_OF_GEOCODE: SELECT reason FROM cg_caches WHERE geocode = ?
LIST_ID_OF_GUID: SELECT reason FROM cg_caches WHERE guid = ?
COUNT_TYPE_ALL_LIST: SELECT COUNT(_id) FROM cg_caches WHERE detailed = 1 AND type = ? AND reason > 0
COUNT_ALL_TYPES_ALL_LIST: SELECT COUNT(_id) FROM cg_caches WHERE detailed = 1 AND reason > 0
COUNT_TYPE_LIST: SELECT COUNT(_id) FROM cg_caches WHERE detailed = 1 AND type = ? AND reason = ?
COUNT_ALL_TYPES_LIST: SELECT COUNT(_id) FROM cg_caches WHERE detailed = 1 AND reason = ?
QUERY_CACHE_DATA: SELECT * FROM cg_caches
dbCreateCaches = create table cg_caches ... reason integer not null default 0, ...
index: create index if not exists in_caches_reason on cg_caches (reason)

onUpgrade():

     if (oldVersion > 0) delete from cg_caches where reason = 0
     if (oldVersion < 64) update cg_caches set reason=1 where reason=2

storeIntoDatabase(): values.put("reason", cache.getListId());

loadBatchOfStoredGeocodes():

     select cg_caches where reason 
     if (listId != PseudoList.ALL_LIST.id)
          = Math.max(listId, 1)
     else
          >= StoredList.STANDARD_LIST_ID

##Comparison of DB Schemas for Tags
http://tagging.pui.ch/post/37027745720/tags-database-schemas
http://tagging.pui.ch/post/37027746608/tagsystems-performance-tests

As far as I can see right now I would propose the Toxi variant with a third n:m mapping table:
http://tagging.pui.ch/post/37027745720/tags-database-schemas#toxi

All in all it would be quite some change.

[Lineflyer]

Thanks for your deep analysis of the situation.
From (my) users perspective and taking into account your statement

All in all it would be quite some change.

I would simply suppose a middle way:
When importing a GPX or saving caches in general we could detect if caches are already stored on another list and ask the user how to proceed (keep it and maybe update it on the current list, move and update on the running process).

This will not fulfill the feature request but it would at least make the user aware, about what happens.
Most people contacting us on support do no neccessarily wish to have the cache on more than one list, but don't like it to get moved from the old to the new list in such cases.

[pstorch]

As mentioned in some previous comments, the offline_box in the CacheDetailActivity would need some redesign.

The offline state and the lists should be separated, because some buttons affect the Cache, some a specific List.
e.g.
The "Refresh" button works on the Cache independent of a List.
The "Store" button works initially on the Cache with a Listselection afterwards. Could be kept visible to be able to store the Cache on several Lists.
The "Drop" button could work on the Cache and on a specific List. Either remove the Cache from a List or remove the Cache from all Lists and from the DB.
The "Move" button would work on a specific List. Maybe this button is superfluous.

An Idea could be to simplify the view with "+" and "-" buttons. "+" add the Cache to a List "-" removes it from a List. The last hit on "-" removes the Cache from the DB.

[pstorch]

I would simply suppose a middle way:
When importing a GPX or saving caches in general we could detect if caches are already stored on another list and ask the user how to proceed

Yes, this could be a first step.

[caigner]

As I just experienced the "one list per cache" problem, I am motivated to join the discussion.

Right now a geocache can be downloaded and stored on a list. And only on one list.

My problem:
If I have a list of "the best caches in my area" and a list of "all the caches in my area", then the second list will not be complete, because some of the caches will be on the first list. And if I create a third list with "only caches with D>3 and T<5' then probably some of the caches on the first list will change to the third list which would be (actually: is) annoying. At least two of my lists would not be complete.

Having lists suggests to the user that he can put caches on them. What else are lists for then, right? And the user (rightly so) assumes that caches stay where he puts them. But he also assumes, when he downloads a PQ that all the newly downloaded caches will end up on the (new) list which the user specifies.

The solution:
(I assume that you developers are all familiar with a m:n relationship. So I skip explaining that.)
Would it be a great difficulty to have a m:n relationship between geocaches and lists?
With a m:n relationship a cache can be on more than one list and a list can have more than one caches. First problem solved.

Of course, as already mentioned above, we have to decide what to do, when the user wants to delete a cache.

I suggest to give the user a notification that the cache is on more than one list and whether he wants to remove it only from the current list (=change the m:n table) or from all lists (=delete it completely). Second problem solved.

Please discuss!
Regards,
Christian

[SammysHP]

That's not the problem. The problem is the current implementation which must be changed.

[Mainah]

As a user, I would greatly appreciate the effort put into fixing this 4.5yr old issue.
My opinion would be to go with "label" or "tag" terminology and maybe eliminate "lists".

[caigner]

I think, for the majority of users (who are not very tech affine) the word "list" is more familiar from daily life.

[MrYaz]

I agree completely with @caigner regarding the use of the word "list" instead of "tag" or "label". I believe it is much more natural for the majority of users.

[samueltardieu]

Please open new issues if you have new ideas about the UI for this "cache on multiple lists" feature, or about the use of tags vs. lists.

[caigner]

The UI is good as it is. For "cache on multiple lists" the list UI doesn't have to be changed. It is mainly a matter of how the database stores the relationships between caches and lists.
Just add the notifications I mentioned above (regarding deleting a cache from a list) and you are done.