Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise Cache filter (make it checkbox based) #135

Open
RevZero opened this issue Aug 10, 2011 · 27 comments

Comments

Projects
None yet
@RevZero
Copy link

commented Aug 10, 2011

I am not sure about how c:geo queries the data from gc.com but i think there is some room for improvement here.

For example it would be nice if it would be possible to show Traditional AND Multi instead of only one type at a time.
Even if it may require to query data from gc.com than is filtered out afterwards its worth the effort since filtering is a powerful tool.

Maybe the "hide my finds" and the "hide disabled" checkboxes from the settings menu could then be moved to the new filter dialog for better overview.
On the gc.com page for example, you have all the filter options in one place as well.

@SammysHP

This comment has been minimized.

Copy link
Member

commented Aug 10, 2011

It's not so easy to filter for more than one type at loading, because Groundspeak doesn't support this. But it's an idea for offline stored caches.

@RevZero

This comment has been minimized.

Copy link
Author

commented Aug 10, 2011

But it wouldn't hurt much to get a superset of the data needed, and filter out the desired caches afterwards wouldn't it?
Currently you would have to enable "All" anyway if you want to view Tradi+Multi.

Or am i missing something here?

@SammysHP

This comment has been minimized.

Copy link
Member

commented Aug 10, 2011

There are 20 caches on every result-page. Now you want to filter them for earthcaches and mysteries. Now there are only 3 under the first 20 results, so only 3 are displayed. And what if there are none? I think it's not possible to filter searches for more than one type.

@RevZero

This comment has been minimized.

Copy link
Author

commented Aug 10, 2011

Ok, but how is this working in the first place then? Don't you have to always request all cache types?
How is Tradi only filtering handled?
I realize that there is no API and that the information is probably parsed directly from the web page.

@SammysHP

This comment has been minimized.

Copy link
Member

commented Aug 10, 2011

You can set a type in search at gc.com, that's why we can easily filter for a single type.

@RevZero

This comment has been minimized.

Copy link
Author

commented Aug 10, 2011

Ah ok, i never used the advanced search on gc.com, only basic and live map. So thats used for all Cache queries?

Well then the approach should be to execute multiple queries for each Cache Type thats selected from the filter?
Problem could be that its probably pretty slow if multiple Cache types are selected.

Hmm...

@realdadfish

This comment has been minimized.

Copy link

commented Jan 5, 2012

Honestly, I pretty much find this feature useless, especially as it is displayed so prominently in the app. If you look at the statistics most people find Traditionals, Multis, Unknowns and some then even Earth Caches, but the rest is, well, more to have such a type in the statistics (whereigo, virtual, events and all the other "exotic" ones) and there are rather rarely hidden and therefor also rarely found.

What I'm saying is that there is probably nobody who wouldn't like to visit an earth or simple offset / multi / unknown cache if on a tour, so in my (very) humble opinion there should not be many people interesting in filtering these out. And if there are people who'd like to do that, then it should be such a rarely used feature that it could be put into a settings dialog somewhere...

@RevZero

This comment has been minimized.

Copy link
Author

commented Jan 6, 2012

Well, i wouldn't call it useless, but its far from mandatory.

For example I wouldn't bother solving a Mystery while away from home. And since there are tons of Mystery Caches in almost every city region, i would prefer to filter those out. Tradi, Multi and maybe Earth are of primary interest while traveling or having a short stay somewhere. If i could, i would filter only those out.

Whatever, thanks again for developing this great app.

@SammysHP

This comment has been minimized.

Copy link
Member

commented Jan 6, 2012

There are two issues:

a) Filter data from gc.com. We have two possiblities: loading everything or one type - that's a limitation of gc.com

b) Filter data stored in c:geo. Here we have to implement the checkbox-based filtering.

@RevZero

This comment has been minimized.

Copy link
Author

commented Jan 6, 2012

Well so a) would require either

  1. multiple queries for each selected type
    or
  2. one query for all types (lots of overhead) and post-query-filtering

Don't keep this open for me. If its not worth the effort or just impractical this can be closed.

@SammysHP

This comment has been minimized.

Copy link
Member

commented Jan 6, 2012

No, b) will be implemented if somebody has time for it.

@pilhuhn

This comment has been minimized.

Copy link
Contributor

commented May 28, 2012

What about running multiple queries, one per type selected in the checkbox case - perhaps up to a threshold, t, and if more then t types are requested, ask for all types and do post-receive filtering?

@tommyd3mdi I think this feature is useful, as if you don't have too much time, you probably don't want to do multi-caches, but trad + mystery

@triakcz

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2012

This is definitely good idea (and it's not important to users how will it be implemented). I vote +1 for this.

@SammysHP

This comment has been minimized.

Copy link
Member

commented Jun 6, 2012

and it's not important to users how will it be implemented

Well, it is. It defines how long the user must wait until he will see the result and how many caches it contains.

@triakcz

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2012

You are right in this, but it's not that point of view what I have meant. It's straightforward, that it will have to be implemented by two or more requests when queryiing gc.com.

@SammysHP

This comment has been minimized.

Copy link
Member

commented Jun 7, 2012

Not sure. Here a simple demonstration:

Imgur

Let's assume that each result page contains 5 caches. Filter for traditional and mystery caches.

Now, which caches does an user expect?

  1. 5 traditional caches in the center, no mysteries
  2. 5 traditional caches in the center, 5 mysteries

The first one would say: "Hey, in this distance there are 5 caches matching your filter." The problem would be if the nearest 5 caches are multi caches because then we have 0 that matches the filter. Possible solution: request up to x page and wait for a matching cache.

The second one: "Here are 10 caches that match your filter, but in this distance there might be more matching caches." The problem is, that we show caches from different regions and that we cannot be sure that there are no matching caches in between.

Here a better visualization showing the result sets:

Imgur

@pilhuhn

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2012

Well, it is. It defines how long the user must wait until he will see the result

The waiting for the results would not be so bad, if the finds are already shown after each remote call (and the loading indicator would still spin).

Wrt the matching elements: wouldn't that already today the case? c:geo requests the innermost circle, finds 5, thinks it needs 20 and extends the search to the next larger circle, until we have 20.

And even in this case, couldn't there be 23 caches, of which only 20 are shown?

@triakcz

This comment has been minimized.

Copy link
Contributor

commented Jun 7, 2012

I agree with pilhuhn, there will be more requests needed. And dynamic updating of result set will be really good aproach. Am I missing something ?

@SammysHP

This comment has been minimized.

Copy link
Member

commented Jun 8, 2012

Wrt the matching elements: wouldn't that already today the case? c:geo requests the innermost circle, finds 5, thinks it needs 20 and extends the search to the next larger circle, until we have 20.

No, you can set up to one parameter for type filtering when searching for caches.

@pilhuhn

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2012

I am not sure If I understood this. Suppose each search filter would return 7 entries and the user had 3 items checked, he would get 21 items instead of the desired 20; getting more caches back shouldn't be an issue.

Back to local filtering - if c:geo would request ~30 entries (a classes) and then filter, the result could be well less than 20, but again if the user knew this and he is only requesting of a certain kind, that should be ok too?

@campbeb

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2012

@pilhuhn The problem with the first method (for example, traditional, mystery and multi checked) is that the 7 traditional caches might be within 1mi/km of you. But, the 7 mystery might be go out to 20mi/km away. That isn't what the user is expecting. They are expecting 20 closest caches of those three types.

Local filtering is easy to implement, but would definitely result in fewer results per each search.

@RobinAllen

This comment has been minimized.

Copy link

commented Dec 9, 2012

I'm definitely +1 for a checkbox-based filtering approach. Something accessible directly from the 'more' option on the live map would be best, as dropping back to the main menu to change what is or is not visible in the live map seems backward.

For me, typical usage is with a large GPX import pre-loaded, so better filtering/excluding/including of my stored caches based on info already stored on the device would be a boon.

Filtering of caches at the point of live download isn't such a concern - It would be nice to save on bandwidth sometimes, but other than that it's fine to download all and then filter on the device. I imagine many people would be filtering for a set which includes traditionals anyway, in which case the bandwidth increase of downloading all caches wouldn't be too significant in most cases.

@SammysHP

This comment has been minimized.

Copy link
Member

commented Jun 4, 2013

UML

@Q-Owl

This comment has been minimized.

Copy link

commented Jul 7, 2014

I would really like a checkbox-based filtering!! It would help to show only the few cache types I like most, and I can see much more of the map behind them. There are too many cache types on it, I don't like or don't need.
The filtereing of the owned, found or deactivated caches is already checkbox-based. Why not the cache-types, too? And it would really be easier to use, if tis filter can be reached directly from the live map screen.

@rsudev

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2014

As you can read above, especially for the live-map (and also searches) we are also constrained by the features gc offers. And as I wrote in the other issue, even if the path to implement it is clear, there needs to be someone with enough time and energy to do it...

@UniQP

This comment has been minimized.

Copy link
Member

commented May 31, 2016

gc.com's new search allows to filter for multiple cache types at once. It's still a bunch of work, though.

@okainov

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2018

Any updates on it? If it's now supported from the server side, it shouldn't be very difficult to implement, right?

And I'd like to notice that there are more GC services than just GC.com and if for GC.com you don't have normal API, you may have one for other services like OpenCaching, so checkbox-based filter will make sense in any case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.