Jump to content

Cachly 2.1 and map clustering input needed


Nic Hubbard

Recommended Posts

Clustering. This is a touchy subject. I too hate the idea of clustering pins on the map, and I know many do not love that the official app forces clustering of caches.

The reason for this topic. In Cachly 2.1 there have been some major performance improvements. Some users use Cachly in different ways, and some might have 20,000 caches in an Offline List. I have tested 50,000 caches with no performance overhead when loading the Offline List in list view.

However, how does one display 20-50k caches on a map? Currently trying to do this uses so much memory even an iPhone 7 crashes. Putting that many pins on a map just isn't feasible. This is where the idea of clustering come into play.

Here is what I want feedback about for 2.1:

  • Offline Lists will use clustering by default if the list has more than 1000 caches.
  • Clustering can be turned off for ALL lists with a warning that it might not be possible to show all the caches you want on the map, and it might be very slow.
  • Offline Lists will load in List View by default and not even load pins on the map if the user doesn't want to look at it, thus improving performance.
  • Other alternatives to clustering? So far, I have not gotten far with this.
Link to comment
Share on other sites

Is clustering something that is determined by the total number of possible map points in the set of possible map points or is it something that is more accurately discussed within any given map display window on the device at a given time? As an example, if a list has 2000 caches, but only 64 might be displayed at the current zoom level of the map and what is displayed, will clustering of those 64 possibly kick in or might they display the 64 individual map points like we see today?

I ask because if I use the official geocaching app, the clustering seems to remain even at a zoom level that Cachly has no issue displaying individual caches. So is the constraint the total number of map points (caches) on the map or total number of map points (caches) loaded that might display even if not on the active screen? And if the clustering would still be there, do you have control over when it unclusters as the geocaching.com app seems to still cluster when it shouldn't. 

Here's about the 2 same screens showing the clustering behavior in the official app vs what we see today in Cachly.  Of course I prefer the Cachly screen because I can see much more info. 

IMG_1456.jpeg

IMG_1454.jpeg

Link to comment
Share on other sites

I think clustering is a reasonable way to show there are a lot of caches in a relatively small bit of screen real estate without using up a ton of memory. My guess is that most people that are bothered by clustering dislike it because it is implemented too soon, meaning at the wrong zoom level. Team DEMP's comparison is a good example. All of the caches on the Cachly screenshot are still clearly identifiable as distinct caches at that zoom level, and I don't think the number of visible pins is enough to hurt performance. So clustering at that level feels more like an annoyance than a helpful feature. Once the pins start to overlap in a way that they can't easily be individually selected with a tap, that's the point when clustering feels to me like a useful feature. And it certainly would help display many thousands of caches on a map without bringing the app to a screeching halt.

I think your plan sounds pretty good. The one thing I'm curious about is allowing the user to disable clustering entirely. What would actually happen if a user tries to show the map with clustering disabled if there ere enough caches on the list to otherwise crash the app. Will you just load the first n caches where n is a number that will still allow the app to function?

Link to comment
Share on other sites

Team DEMPs pictures is a great example of why clustering with a low number of points is a very bad thing. With the official app you don't have any notion from that map of where trails lead. One of the key issues I'd see is the current zoom level caches vs the total list. If it is possible to determine the number of caches visible at that zoom before the map is drawn then I think that parameter should be the key.

So I'd suggest you consider two parameters :

Firstly as suggested is to set a cluster level below which clustering is simply off. Say 500 or maybe push it to 1000 caches, ie: if the current zoom level of the map contains more than X caches to display then clustering becomes a factor otherwise display the caches as is. Possibly user definable from 100-1000? ie: Turn on clustering if more than X caches visible.

Secondly I'd suggest a minimum cluster size. As the map shows above clustering small numbers is counter productive. A cluster of say 10 or more could fix that. ie: only group caches together into a cluster if the resulting cluster size would be 10 or more.

I have implemented a clustering algorithm in my Family Tree Analyzer program for mapping where ancestors lived and would be happy to share the source if that would help.

Link to comment
Share on other sites

I am also not at all a fan of clustering, but if you have thousands of caches in a list, I think that is completely reasonable. If all else, you can created another smaller list. I keep a list of around 1,000 of the caches nearest to my home, but I can't even imagine a 10k or 20k cache list. 

I think what you have proposed is very reasonable, though I wouldn't want offline lists to load up in list mode unless they were over 1000 caches (or maybe the user can set the default behavior). As noted above, I keep an offline list of the nearest 1,000 caches and that is how I do most of my local caching. It would be annoying to have an extra step of switching from list to map view every time I use my offline list, which is 90% of the time.

As always, fantastic job on the app and the updates. I introduced it to a couple more people at a recent geocaching event, and bought it for another friend for their birthday. 

Link to comment
Share on other sites

I played with clustering in Geosphere to get a sense of what the algorithm might be. It looks like at 250 or more pins in view triggers clustering and it is an all or nothing thing. Here are 3 screen caps of an upcoming trip with a total of 265 pins as I zoom in. When the visible count drops below 250, nothing is clustered. The small clusters of 1 and 2 are annoying. 

image.png

image.png

image.png

Link to comment
Share on other sites

1 hour ago, ShammyLevva said:

My point exactly rragan. Having small clusters of less than 10 is indeed annoying and easily fixed by having a minimum clustering size.

This for sure is something I will take into account. My plan is to not even show clustering after a certain zoom level. Stay tuned for more details and testing. :)

 

Link to comment
Share on other sites

Since you're asking for input I'll give you mine. Besides not having most of the features of the Classic app, my number one complaint about the new official Groundspeak app is the clustering of caches. There's no real way to tell at a glance if an area you're looking at is a Geoart series, a power trail of traditionals, several P&G's or a little of each. If people really want to load 10,000 caches into a list in the app (I see no reason to do that but I guess some might) and want to see clusters I suppose that option would be okay for them. But for me I don't ever want to see a cluster on my map so it would be great to have an option to disable that feature. 

Link to comment
Share on other sites

Playing with an alternative to clustering. This loads x number of caches at a time, and tapping a button allows you to load the next x number of caches.

It is really easy to cycle through 7543 caches in about 10 seconds. This also keeps memory low because all pins are never loaded on the map.

Thoughts on this proof of concept?

Link to comment
Share on other sites

Interesting idea. It feels a bit modal. What if the caches I'm interested in span two different display chunks? When do I drop out of this mode to swing into action on some of the caches? Don't you need to keep state when I still down to a cache and come back?

i think I prefer clustering with an option to disable and a fairly high threshold that would generally be safe. 1000 threshold ought to show most geoart. 

Link to comment
Share on other sites

At the zoom level in the video, if all caches couldn't be loaded I might rather see clustering as it could provide an overview of the entire displayed map vs no idea about the areas in the video. But at the zoom level you were at I'm not sure clustering would be very beneficial either.

What about a map display area that's maybe 50 miles by 50 miles with a few thousand caches? The zoom level in the video, if showing all of Ireland is about 300x171 miles and I'm not sure the use case and how practical it is to show an area that large within Cachly populated with all possible caches.

Link to comment
Share on other sites

I came back to thread when I was notified Nic replied and I see what I thought was a comment I made earlier this morning not posted to the thread. I guess it's sitting unsubmitted on my ipad at home. 

My comment had to do with the display window in your video. I'm not sure I'd look at (approx) a 300 mi x 175 mi area like the screen covers and try to find caches. For me, I'd say a 25x25 square mile area is probably the absolute biggest I'd look at on a cachly screen. Maybe others have a *need* to see all of a country like in the video but I definitely don't. I don't see myself needing to see an entire US state at one time. But if there is a need or a viable solution could allow for it, then great. If not, maybe a smaller coverage area should be the target to come up with the best solution?

 

Link to comment
Share on other sites

16 minutes ago, Team DEMP said:

For me, I'd say a 25x25 square mile area is probably the absolute biggest I'd look at on a cachly screen. Maybe others have a *need* to see all of a country like in the video but I definitely don't. I don't see myself needing to see an entire US state at one time. But if there is a need or a viable solution could allow for it, then great. If not, maybe a smaller coverage area should be the target to come up with the best solution

I think regardless of the viewing size, if it is a full country, state or even just a city that the solution I posted proves to be interesting, but not practical. It was fun to build, but as much as I would like to be able to implement a simple solution like this, I can see how it won't work.

Link to comment
Share on other sites

2 hours ago, Nic Hubbard said:

I think regardless of the viewing size, if it is a full country, state or even just a city that the solution I posted proves to be interesting, but not practical. It was fun to build, but as much as I would like to be able to implement a simple solution like this, I can see how it won't work.

I didn't make my point well. I was suggesting that maybe there are options for large areas being displayed, medium areas being displayed, and smaller closeup areas being displayed and the approach could be different. What might work for a country view covering 200 miles x 200 miles might be different from say 25 miles x 25 miles and different from say 5 miles x 5 miles.  Or maybe it's less the display area then # of map points/caches. Of course if there was 1 solution that covered all, no worries. But if not, maybe pick a target to shoot for delivering the optimal experience and let the larger areas have a different experience. 

Link to comment
Share on other sites

6 minutes ago, Team DEMP said:

Or maybe it's less the display area then # of map points/caches.

This is key. It is the amount of caches/pins on the map, and doesn't really matter the map span.

7 minutes ago, Team DEMP said:

Of course if there was 1 solution that covered all, no worries.

Clustering should solve this, as it can be turned on and off based on what zoom level the user is at, which should solve pretty much all the problems, including memory.

Link to comment
Share on other sites

7 hours ago, Nic Hubbard said:

This is key. It is the amount of caches/pins on the map, and doesn't really matter the map span.

Clustering should solve this, as it can be turned on and off based on what zoom level the user is at, which should solve pretty much all the problems, including memory.

Nice proof of concept, but even though clustering can be a pain I do agree that it's the better option to pursue. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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...
×
×
  • Create New...