Jump to content

Release Notes (Website: New Search Map) - April 25, 2019


Recommended Posts

Noticed this bug today.  When viewing the cache shown in the screenshot below, the "Description & Hint" section does not show up at all.  I clicked on a couple other caches that show up on the map, and they showed the "Description & Hint" section, but this particular one did not.

 

ETA:  I noticed the same thing on another cache on the map, and noticed it has the same CO. That made me suspicious that the issue relates to how the CO builds his cache pages.  The buggy instances have no content in the Long Description, or Hint.  Everything is in the Short Description.  It seems that the side panel does not display the entire "Description & Hint" section when the Long Description and Hint fields are blank, even if there is content in the Short Description.

 

Firefox 66.0.3 on Windows 10 Pro

 

image.png.a674235eb9007655938266e29eb0b44d.png

Edited by noncentric
added 2nd instance
Link to comment
On 5/5/2019 at 3:29 AM, gimme5 said:

set the browse map as default

 

Yes, please.  The Search map is too slow and too buggy right now. 

 

EDITED to add OS Windows Pro and Browser Firefox 62.0.2

 

[BUG] Agreeing with Marko Ramius post above, there's some random drop out of caches returned.  I clicked the Geocaching.com link from GC6YDVG which went to Search Map and returned 62 caches.

Simply clicking the "Search this area" option on the map changed the return to  66.  The distance from center has not changed.

They're ranked on distance from GC6YDVG - the max distance is 3.41 miles, and the furthest cache returned is the same before and after using "search this area".  Randomly failing to return 6% of caches is a bug.  I have not seen it fail to return the cache I started from.

 "search this area" doesn't appear for me on the original map.  Moving the map changes the area, and of course, always triggers the option.  Simply clicking somewhere on the map, or a cache icon  sometimes triggers the "search" button and sometimes doesn't.

 

It's comparable to, but less robust and slower than working from a  PQ - set up filters, get results, map. Refine filters.

Or from Search, set up filters, map, refine search.

 

 

Edited by Isonzo Karst
  • Upvote 1
Link to comment
23 hours ago, on4bam said:
23 hours ago, rapotek said:

So everyone has to stop requiring any improvements or bug fixes, then? These are release notes and users here give feedback how do they perceive the changes and new functionalities, not how to bypass them, am I wrong?

That's not what I mean. I'm just saying not to hold your breath for all the fixes. If I have a choice of using a broken tool or fixing the shortcomings at my end then it's a no-brainer what I will go for.

 

Then maybe answering "Huh??" wouldn't be the best response to a question with a straightforward answer. Rather, "Correct, it's not possible with the website. But you could look into installing Tampermonkey/Greasemonkey and running these scripts which make the website much more usable."  Then this little thread of comments probably would never have happened...

 

I have greasemonkey and tamptermonkey both installed for Firefox and Chrome. I run GME which adds a whole lot of features for the GC map, and would highly recommend it. Heck even if they fixed outstanding issues, these scripts also add features (not just necessarily fixing bugs) that give them more value. And I've also added some of my site-adjusting features.

And none of that is any reason, as stated, for GS to shrug off fixing anything on the website :P

 

But I'd recommend having the add-ons purely for the flexibility they can add to the site regardless of bugs, perceived or real.

Link to comment

Hi. I'm here not to complain, but just to report a bug/feature request regarding the new search map. Three of them:

1. I've noticed that when entering a location in the search bar, the map will move to that location, but it will not activate a search, instead requiring that I click "Search here" on the map. Is this intentional? It might be nice if the search automatically returned results when a location is entered.

2. Am I imagining things, or did the the new search map, when it was first implemented, include a search radius? I'm back and forth on whether the radius is necessary. But.... Given that the new search map is almost a proxy for a Pocket Query preview, the option to input a radius with the filters would make it easy for us to get an idea of how to set up our PQs for an area.

2.5. If a radius were included with the filters, it shouldn't be too hard to then provide a button/link in order to switch back and forth between map view and table view for search results.

3. I know that for a lot of folks here, including myself, the new vector maps with the "Geocaching" layer tend to chug and slow down our machines. This is especially true for those of us running older hardware. The option to switch to the Google map layer speeds things up considerably. Could you possibly add a Search map preference that either remembers the last map layer used, or lets us choose a default? I like the Geocaching map, it's just resource intensive for me at the moment.

Edited by Mineral2
  • Upvote 1
Link to comment
1 hour ago, flowten said:

Please allow us the ability to set  Search geocaches  as our default map view. 

 

Groundspeak, you see what happened here? There's nothing that says, this is the Search Map or this is the Browse Map.  So (quite naturally), that rectangle in the top corner - that happens to be a button - gets mistaken for a title.

 

Design needs work.

  • Upvote 1
Link to comment
15 hours ago, Mineral2 said:

1. I've noticed that when entering a location in the search bar, the map will move to that location, but it will not activate a search, instead requiring that I click "Search here" on the map. Is this intentional? It might be nice if the search automatically returned results when a location is entered.

 

The counter to that is I might want to go that location but not do an automatic search and lose my previous results. So the question is how could UI accomodate both options?

 

14 minutes ago, Viajero Perdido said:

Groundspeak, you see what happened here? There's nothing that says, this is the Search Map or this is the Browse Map.  So (quite naturally), that rectangle in the top corner - that happens to be a button - gets mistaken for a title.

 

Good point, hadn't even considered that aspect...

Link to comment
3 hours ago, thebruce0 said:

The counter to that is I might want to go that location but not do an automatic search and lose my previous results. So the question is how could UI accomodate both options?

Can you give a use case? The only one I can think of is where I want to see where my PQ covers...and that's a feature the browse map has, but, as I recall, the search map doesn't. If I did a search with a radius of, say, 10 miles, and then I moved the map outside those 10 miles, I'm not convinced there's a compelling reason for concluding anything except that I've changed my mind about exactly which circle I was interested in. It strikes me like asking for google maps to show me the map 10 miles around Indianapolis and then expecting the map to stop showing roads when I pan beyond that 10 mile limit.

Link to comment
40 minutes ago, dprovan said:
4 hours ago, thebruce0 said:

The counter to that is I might want to go that location but not do an automatic search and lose my previous results. So the question is how could UI accomodate both options?

Can you give a use case?

 

Yeah: I do a search in a location and I touch/slide the map to move somewhere else but not do an automatic search and lose my previous results.

That is a use case.

I don't want the map updating my search results when I've done a specific search at a specific location, without me letting it do so. (implied: if there's an option to turn it on, and it's on)

 

Cachly and the official app had the same issues. Touching to pan the map consistently requerying to the center of the map was awful!

Heck at least the apps allow you to keep your previous search results. On the web map it's a fresh query.  Again, the difference between a browse map and a search map. The apps don't have a "Browse" map, they are all search maps. I think Groundspeak thinks the Browse map is the 'exception', and everyone (inferred, coming from the app) is used to the Search map.  Which again comes back to the problem of them seeming to be pushing aside the desktop demographic.

Edited by thebruce0
Link to comment

@thebruce0 @dprovan I want to clarify that my original request only pertained to entering a location in the search bar. It moves the map, but does not begin a search from that location. It's a search bar on a search map, and that's what it should do.

I DO NOT recommend automatically refreshing the search results based on panning, sliding, or zooming the map.

  • Upvote 1
Link to comment
1 minute ago, Mineral2 said:

@thebruce0 @dprovan I want to clarify that my original request only pertained to entering a location in the search bar. It moves the map, but does not begin a search from that location. It's a search bar on a search map, and that's what it should do.

I DO NOT recommend automatically refreshing the search results based on panning, sliding, or zooming the map.

 

Agreed. It's another interesting point - It might be that I want to go to the new location, make some changes, or maybe I mistyped - so not auto-update. But in the context of changing my search parameters, I might want to change the center point and perform the search in one go (as you did).

Right now the search box is kind of handling two tasks: it serves to shift the map location, and it serves as the centerpoint for the search parameters. So when you submit a new location, are you intending to just move the map, or to submit a new search query?  The UI should address that.

Link to comment

Honestly, for the search map, I think it should just perform a search. The byproduct of such is that the map will be moved to be centered on the location of the search provided in the search bar. What I'd eventually like to see, and perhaps maybe it's already on the developer's agenda, is that the search bar on the map and the search bar on the home page be interchangeable. Currently, we can do a traditional search, which returns a list of results in tabular form and there is a link to map the results. I'd like to see a link on the search map to show the results in table form. Easily swap back and forth between the two interfaces.

  • Upvote 1
Link to comment
9 hours ago, Mineral2 said:

I'd like to see a link on the search map to show the results in table form. Easily swap back and forth between the two interfaces.

I think the intent is that the left pane is "the results in table form".  Perform a search with filters and then the results will be on the map and also listed, all in one screen.

 

16 hours ago, flowten said:

Please allow us the ability to set  Search geocaches  as our default map view. 

The default map view is "Search".  From your post in another thread, it sounds like you have reversed ideas of Search vs Browse.  Reading the OP in this thread might help understand the differences, or see the image below.

 

The map that shows "a list of caches in the left pane" is the Search Map.

If all you need is a quick filter of "my finds, my hides, my DNFs, and cache types", then that is the Browse Map.

 

image.png.be81b95d0fdf3cebb6a3a42c76733340.png

Link to comment
6 hours ago, noncentric said:

The default map view is "Search".  From your post in another thread, it sounds like you have reversed ideas of Search vs Browse.  Reading the OP in this thread might help understand the differences, or see the image below.

Thanks for the explanation.  I guess I need to reword my request.  Please give us the option to choose which map is default. I would rather have the opposite of what is happening now. Thanks

  • Upvote 2
Link to comment
20 hours ago, thebruce0 said:

 

Agreed. It's another interesting point - It might be that I want to go to the new location, make some changes, or maybe I mistyped - so not auto-update. But in the context of changing my search parameters, I might want to change the center point and perform the search in one go (as you did).

Right now the search box is kind of handling two tasks: it serves to shift the map location, and it serves as the centerpoint for the search parameters. So when you submit a new location, are you intending to just move the map, or to submit a new search query?  The UI should address that.

Personally, I would want it to perform a new search at the new location or zoom level - always.  I can't think of a time where I thought to myself "OK, I've searched at this location for a particular thing.  Now let's zoom out and not refresh the search to show me the results in the area I'm now viewing."  Kind of like if I search hotels on Google, it updates the view to show me the hotels in the area I'm currently viewing.  (This is all things being equal and server hits not being considered, of course.  Although, zooming in wouldn't require a new search, I suppose, for the view, but the list of caches on the sidebar would need to pay attention to the new viewing area.)

 

 

Link to comment
13 minutes ago, GO Geiger said:

Personally, I would want it to perform a new search at the new location or zoom level - always.  I can't think of a time where I thought to myself "OK, I've searched at this location for a particular thing.  Now let's zoom out and not refresh the search to show me the results in the area I'm now viewing."

 

I never said there was no reason why one might want to auto-refresh on every single movement of the map (though I can't fathom why that would always be the case). On the contrary I've given perfectly legitimate reasons why I would want to move the map - any amount - and not auto-refresh my query.

Most blatantly - if I move it a fraction of my intended amount mistakenly, even, that is not a time when I want to requery. And ALL of those little 'unintended' movements will be blasting their server continuously. That is the main problem with auto-updated map panning, especially without a movement threshold (move the centerpoint a certain distance before auto-refresh triggers). That's why the mobile apps do not force this mechanic on people. Especially if adjusting the map clears the previous query results, which I also addressed earlier.

 

So I'm, I'm still absolutely, fervently, against supporting the idea that the map must auto-update with every single movement or zoom of the map, both from a usability standpoint and technical one. Nothing will change that.

Provide an option? Yes, that would address usability. But it would not address the technical. If HQ can handle the technical requirement, then it would be fine (as user-optional). If they can't, then I support their decision not to implement it for purely technical reasons.

 

 

ETA: Side note for a previous comment - The Google Maps app also now provides a 'Search this area' button after having searched for something and adjusted the map. There are a few search contexts though and I'm pretty sure not every context provides this button. As I noted earlier, there are times when the live-updated map results do auto-update with map adjustment, but IMO almost chaotically like a curated list (and we all know how FB and twitter like to do this) based on assumptions the app makes about what I want to see more/less prominently when there are too many results to display above their arbitrary threshold (see prior comment for detail).

Edited by thebruce0
Link to comment

Right - I agree with you on the technical aspects - that's why I said "All things being equal and server hits not being considered."  If it were totally free to do so (from a hardware and processing time perspective), I'd love to see the search updated whenever I changed the view.  But, server load and processing time are not negligible for something like this, so (not for the first time) what I'd like to see and what it is possible to see are two distinctly different result sets.  (Although having a reasonable trigger distance for auto-refreshes is an interesting idea, so long as it couldn't be abused  to re-query every time the view was panned 6 feet.  But then we'd have the attendant problem of "what does reasonable distance" mean?  *sigh*  This is why I'm glad I'm not a UI developer.)

 

My most recent use-case: I was looking for a series of caches beginning with "CCG".  The initial search showed a small area.  I zoomed out, but the search results didn't auto-update.  Fine, I refreshed the search, then saw I wasn't looking in quite the right area.  I panned the map, then refreshed the search again.  It took a few iterations to get the view and results that I wanted.

In the series I was interested in, there were only 23 caches.

 

Those extra button clicks were an annoyance.  Not the end of the world, either, but still an annoyance.

Now, the server hit might not have been huge from my search I don't really know).  However, searching for all caches containing the letter 'A' would have been a different story.  So my idea of constantly re-querying obviously isn't workable (even if I'd prefer the results to always pertain to the area I'm viewing.)

 

A don't know what the right answer is, but it seems pretty clear that a one-size-fits-all approach isn't working.

Link to comment
11 minutes ago, GO Geiger said:

A don't know what the right answer is, but it seems pretty clear that a one-size-fits-all approach isn't working.

 

Yep!

 

11 minutes ago, GO Geiger said:

My most recent use-case: I was looking for a series of caches beginning with "CCG".  The initial search showed a small area.  I zoomed out, but the search results didn't auto-update.  Fine, I refreshed the search, then saw I wasn't looking in quite the right area.  I panned the map, then refreshed the search again.  It took a few iterations to get the view and results that I wanted.

In the series I was interested in, there were only 23 caches.

 

See to me, this is more like a browse activity of search results. In my mind, the search query would be far greater than my little view (the upper end of course being worldwide). Basically, what you're describing is like the Browse map but with more detailed filters. That's a UI that's hoping for the best of both worlds. And we agree, technically, that's not really feasible. I have what I feel are reasonable and legitimate concerns about forcing an auto-update (w/o the option) on every map adjustment (apart from the technical limitations), but the technical issues themselves are quite significant for GS to deal with.

 

So the issue I still have isn't the usability of the interface so much as the presentation (understanding) of the interface, and existence of optional usability features some people may wish to have, balanced with the technical requirements to implement them sufficiently.

 

And of course, the links and what they imply the user is about to be able to do...

Link to comment
3 hours ago, GO Geiger said:

Right - I agree with you on the technical aspects - that's why I said "All things being equal and server hits not being considered."  If it were totally free to do so (from a hardware and processing time perspective), I'd love to see the search updated whenever I changed the view.  But, server load and processing time are not negligible for something like this, so (not for the first time) what I'd like to see and what it is possible to see are two distinctly different result sets. 

I could sympathize if GS admitted this was limited functionality because they were making a trade off between usability and system load. So far they haven't made that case, so I feel justified in ignoring the possibility militantly.

 

3 hours ago, GO Geiger said:

A don't know what the right answer is, but it seems pretty clear that a one-size-fits-all approach isn't working.

As far as I can see, the one-size-fits-all approach would work if it was the old size. So far, the only serious case where it doesn't work is the system load question, and if system load is the problem, then GS has a specific reason for saying the old size is the one that can't be accommodated.

Link to comment
38 minutes ago, dprovan said:

As far as I can see, the one-size-fits-all approach would work if it was the old size. So far, the only serious case where it doesn't work is the system load question

 

If the 'new' size is the one with the option for auto-requery, then I'd agree wit this. (absolutely not if the auto-requery is forced without being optional)

 

But as it stands, the actions of GS in regards to how much server activity is generated imply that technical limitations are a factor; that's my interpretation coming from an IT/web-app development standpoint. Also the fact that there have been HUGE slow downs when other game-related 'features' have been released that involve online activity.  They don't need to explicitly say "our servers can't handle the load" when we can clearly see the effect.

Link to comment
35 minutes ago, thebruce0 said:

But as it stands, the actions of GS in regards to how much server activity is generated imply that technical limitations are a factor;

Would I be out of line if I read this as saying the UI makes no sense unless there's some back end explanation that hasn't been concretely expressed?

 

36 minutes ago, thebruce0 said:

They don't need to explicitly say "our servers can't handle the load" when we can clearly see the effect.

We can see the effect? I'm not sure what you mean by that. The only effect I've heard anyone notice is that the new search map uses way more CPU resources on our systems just when it's sitting there not doing anything, and I'm not convinced our desktops can handle the load. I haven't noticed any problem in refreshing the map if I just always click on the search again button every time I move the map. Have you?

Link to comment
2 minutes ago, dprovan said:

I haven't noticed any problem in refreshing the map if I just always click on the search again button every time I move the map. Have you?

As it is, just moving the map is laggy for me. Laggy to respond, laggy to draw. It's a lot less laggy when I switch the map to Google Street, but it's still slower than the browse map. I suspect it's a webGL issue with my ancient machine (we did decide that the new map is built upon WebGL, right?). 

  • Upvote 1
Link to comment
21 minutes ago, Mineral2 said:

just moving the map is laggy for me

 

I see that hasn't changed since the beta preview period.  Panning is unusable for me (never mind that the underlying map doesn't display; I just see smileys and the like, and they're reluctant to pan).

 

22 minutes ago, Mineral2 said:

(we did decide that the new map is built upon WebGL, right?)

 

We forum folks have reverse-engineered that detail.  Haven't heard a peep from GS though to confirm.  System requirements?

  • Upvote 1
Link to comment
38 minutes ago, dprovan said:
1 hour ago, thebruce0 said:

But as it stands, the actions of GS in regards to how much server activity is generated imply that technical limitations are a factor;

Would I be out of line if I read this as saying the UI makes no sense unless there's some back end explanation that hasn't been concretely expressed?

The rest of the quoted paragraph explains the point.

 

39 minutes ago, dprovan said:
1 hour ago, thebruce0 said:

They don't need to explicitly say "our servers can't handle the load" when we can clearly see the effect.

We can see the effect? I'm not sure what you mean by that.

All the complaints about slowness, almost 24/7, in various aspects of the website.

 

40 minutes ago, dprovan said:

The only effect I've heard anyone notice is that the new search map uses way more CPU resources on our systems just when it's sitting there not doing anything, and I'm not convinced our desktops can handle the load. I haven't noticed any problem in refreshing the map if I just always click on the search again button every time I move the map. Have you?

The local front-end load on a browser is not server/back-end load.

 

If you're in any kind of IT, you should have some kind of idea of how much of a difference in request quantity there would be given a worldwide 24/7 active userbase, between explicit manual requests for a requery and automatic requests generated by any map adjustment whatsoever.  If you're not in IT, or you don't understand that, then I'm saying - there would be a huge difference in server activity between the amount of complex filter queries per second hitting the server when manually requested vs when automatically requested with any amount of map adjustment interaction with the scope of a worldwide active user base.  If I'm wrong about that, only Groundspeak would be able elucidate the situation by providing stats on their server activity comparing the two strategies.  But from my observation (as in, implied by their feature development and the effects of new features that hammer the servers with activity), they've shied away from heavy back-end server load features.

 

As I said, if their servers can handle worldwide auto-refreshing of the map with any map adjustment whatsoever, then let them enable the option for people to use. But until then, it seems clear that no, the servers are not sufficient to handle that kind of server load. They ain't google.  They evern created (IIRC) their own server farm to handle their own mapping tileset provider which we know as "Geocaching" (or Trails on mobile). How they've got the infrastructure set up to optimally handle both A] the Browse map cache icon tileset overlays (which is a beast in itself and has gone through its own issues over the years) and B] the new Search request querying for overlays - I don't think we're privy to that. So at this point we're all talking speculative.

Link to comment
41 minutes ago, thebruce0 said:

If you're in any kind of IT, you should have some kind of idea of how much of a difference in request quantity there would be given a worldwide 24/7 active userbase, between explicit manual requests for a requery and automatic requests generated by any map adjustment whatsoever.  If you're not in IT, or you don't understand that, then I'm saying - there would be a huge difference in server activity between the amount of complex filter queries per second hitting the server when manually requested vs when automatically requested with any amount of map adjustment interaction with the scope of a worldwide active user base.

 

There are compromise solutions, such as initially conducting the search over a somewhat larger area than requested and caching the result, so that small amounts of map panning and zooming don't require a fresh search, just a different subset of the original search's results. The mobile app seems to do something like that, with "loading geocaches" only appearing when moving the map by a large amount.

Link to comment
7 minutes ago, barefootjeff said:

There are compromise solutions, such as initially conducting the search over a somewhat larger area than requested and caching the result, so that small amounts of map panning and zooming don't require a fresh search, just a different subset of the original search's results. The mobile app seems to do something like that, with "loading geocaches" only appearing when moving the map by a large amount.

 

Yep, and I'd think that Groundspeak would experiment with functionality like that. If they do that in the mobile app, then the only difference to applying similar to techniques to the desktop would be the manner of interacting with the map (finger vs mouse) and screen realestate. Anyway, that's all part of the development process. Personally, all I care about is that IF auto-requerying is enabled (assuming it doesn't slow down the servers worldwide), that I have the option to turn it off or on.

Link to comment
31 minutes ago, thebruce0 said:

 

Yep, and I'd think that Groundspeak would experiment with functionality like that. If they do that in the mobile app, then the only difference to applying similar to techniques to the desktop would be the manner of interacting with the map (finger vs mouse) and screen realestate. Anyway, that's all part of the development process. Personally, all I care about is that IF auto-requerying is enabled (assuming it doesn't slow down the servers worldwide), that I have the option to turn it off or on.

 

The other thought that comes from all of this is that, if the search map has a much greater server load than the browse map, why on Earth make it the default for all mapping tasks when most of the time it's not being used for filtered searching but just to see what other caches are in the vicinity?

  • Upvote 4
Link to comment

Yep, though I'd say the search map has a much greater potential server load depending on how many queries there are per second/minute on average at any one time.   Beginning with a single query wouldn't be any much more than currently happening with the search list view, possibly even much less.  I think the issue is more about the front-end experience they want to (or think they are) providing the end-user. And there's a whole lot of hubbub about that alone. :P

Link to comment
59 minutes ago, thebruce0 said:

Yep, though I'd say the search map has a much greater potential server load depending on how many queries there are per second/minute on average at any one time.   Beginning with a single query wouldn't be any much more than currently happening with the search list view, possibly even much less.  I think the issue is more about the front-end experience they want to (or think they are) providing the end-user. And there's a whole lot of hubbub about that alone. :P

 

When going to just Play - View Map in the top menu bar, with no filters set, the search map is an order of magnitude slower to load than the browse map, so there's something a lot more intensive going on somewhere between the contents of the database and the pixels on my screen. I can't tell whether that time-consuming processing is on the client or server side, but my desktop machine is a fairly high end model only a couple of years old (quad core 3.5GHz processor with 8GB of RAM), and whatever it is it's a lot more sluggish.

  • Upvote 1
Link to comment
8 hours ago, thebruce0 said:

All the complaints about slowness, almost 24/7, in various aspects of the website.

The only complaints I heard involved a sudden change in performance that clearly was some change or failure on the GS end, not a problem of increased load resulting in servers being unable to keep up.

Link to comment
1 hour ago, dprovan said:

The only complaints I heard involved a sudden change in performance that clearly was some change or failure on the GS end, not a problem of increased load resulting in servers being unable to keep up.

 

Lots of complaints throughout the recent promotion...

 

  • Upvote 1
Link to comment

Zdravím všechny příznivce Geocaching. I já jsem jeho velký příznivec, ale co mě bohužel štve, že díky nedávné aktualizaci map 25.4. 2019 na geocaching.com mě úplně přestali fungovat mapy, na které jsem měl několik let přístup po přihlášení na mém účtu. Ano, používám ještě nepodporovaný Windows XP Proffesionál, ale nechápu, proč jste díky aktualizaci map úplně zablokovali přístup z tohoto systému.. :-(  Přitom ostatní mapy i současné, které jsou rovněž zabezpečené jako mapy google a jiné mě do dnes v tomto systému bez problému fungují. To jste nemohli i díky nové aktualizaci tam dát odkaz na starší původní mapy, které do teď bez problémů všem fungovali... aby i ti, kterým nové mapy nefungují, mohli ty staré na dále využívat....??  Krom toho a je to jen můj názor byli jednodušší a pro běžného uživatel přehlednější a rychlejší. Ty nové mapy po aktualizaci na mém mobilu pustím, ale z mého pohledu jsou zbytečně zkomplikované a méně přehledné, než ty původní. Ale to je věc názoru. Je nějaká možnost, jak mohu ještě využívat ty staré původní mapy před touto aktualizací? Děkuji za informace.                                                                                                                                                                                                                                                                                                                                                                               ENG:   All supporters, Geocaching. I'm a huge fan of his, unfortunately, that the recent update map 25.4. 2019 on geocaching. com I ceased to function maps a few years I had access to login to my account. I still use Windows XP Proffesionál unsupported, but I don't understand why you update the maps completely blocked access from this system.. :- To adjust other maps and the like, which are also secured to the google maps and other problem in this system. And you can't put a reference to the new update older original maps, which all worked without problems..even those that don't work, new maps, the old....?  And besides my current user were simpler and clearer and faster. New maps after the update you on my cell phone, but, from my perspective are unnecessarily messy and less clear than the original. But that's a matter of opinion. He's a way I can use the old original maps before this update? Thank you for the information.                      

Link to comment
30 minutes ago, Matrix-1 said:

Zdravím všechny příznivce Geocaching. I já jsem jeho velký příznivec, ale co mě bohužel štve, že díky nedávné aktualizaci map 25.4. 2019 na geocaching.com mě úplně přestali fungovat mapy, na které jsem měl několik let přístup po přihlášení na mém účtu. Ano, používám ještě nepodporovaný Windows XP Proffesionál, ale nechápu, proč jste díky aktualizaci map úplně zablokovali přístup z tohoto systému.. ?  Přitom ostatní mapy i současné, které jsou rovněž zabezpečené jako mapy google a jiné mě do dnes v tomto systému bez problému fungují. To jste nemohli i díky nové aktualizaci tam dát odkaz na starší původní mapy, které do teď bez problémů všem fungovali... aby i ti, kterým nové mapy nefungují, mohli ty staré na dále využívat....??  Krom toho a je to jen můj názor byli jednodušší a pro běžného uživatel přehlednější a rychlejší. Ty nové mapy po aktualizaci na mém mobilu pustím, ale z mého pohledu jsou zbytečně zkomplikované a méně přehledné, než ty původní. Ale to je věc názoru. Je nějaká možnost, jak mohu ještě využívat ty staré původní mapy před touto aktualizací? Děkuji za informace.                                                                                                                                                                                                                                                                                                                                                                               ENG:   All supporters, Geocaching. I'm a huge fan of his, unfortunately, that the recent update map 25.4. 2019 on geocaching. com I ceased to function maps a few years I had access to login to my account. I still use Windows XP Proffesionál unsupported, but I don't understand why you update the maps completely blocked access from this system.. :- To adjust other maps and the like, which are also secured to the google maps and other problem in this system. And you can't put a reference to the new update older original maps, which all worked without problems..even those that don't work, new maps, the old....?  And besides my current user were simpler and clearer and faster. New maps after the update you on my cell phone, but, from my perspective are unnecessarily messy and less clear than the original. But that's a matter of opinion. He's a way I can use the old original maps before this update? Thank you for the information.                      

You need to upgrade your operating system. Many websites may not function properly for you. But more importantly, because Windows XP has not been receiving security updates for many years now, your whole computer is vulnerable to attack. It's not just for geocaching. It's for your general safety interacting with the web.

Link to comment
17 hours ago, Matrix-1 said:

I still use Windows XP Proffesionál unsupported, but I don't understand why you update the maps completely blocked access from this system..

 

Install Firefox 52.9.0. It is the latest version for XP and maps works as they should.

Link to comment
1 hour ago, arisoft said:

 

Install Firefox 52.9.0. It is the latest version for XP and maps works as they should.

 

You really don't want to go online with that setup. If cost for win10 is an issue Linux may be a solution.

 

Link to comment
9 minutes ago, arisoft said:

 

Your solutions to use Windows 10 is not acceptable if security is important factor. Firefox 59.9.0 is still better than IE 8.0.

??? Did I say to use IE?

XP is unsupported and should no longer be used online. So update to win 10 should be done.  Then using FF 66.* is the better option.

If Matrix-1 can't or won't pay for the win7 > win10 upgrade then a free up-to-date OS (linux) is the way to go.

 

If security is important than it makes little difference to use FF59, It's Win7 that should be taken care of first. Anti-virus and firewall software might not even get updates on Win7 anymore either.

 

Link to comment

Hi everyone,

 

Thanks for sharing all your feedback on the new map, it is much appreciated. Once again, I should note that all of the feedback is read, considered, and serves as a valuable input when we decide what to work on next.

 

Today’s deployment consists of the following:

 

  • We have a fix for users that are running browsers that do not support WebGL.  For those that are affected by this issue, they’ll now get a modal window with a link to access the older Browse map.  As a reminder here’s the URL to the older Browse map https://www.geocaching.com/map/
  • The map will now only use the corrected coordinates to plot cache markers if the user has not found the cache.
  • Fixed some placed-date issues with caches on the Search map.

 

Please stay tuned to this forum thread for further updates.

 

Best,

Brendan

  • Upvote 1
Link to comment
12 minutes ago, brendanjw said:
  • The map will now only use the corrected coordinates to plot cache markers if the user has not found the cache.

 

Can someone confirm how this affects users? IIRC, before this change, the Browse map showed found+corrected caches at the posted coordinates, while the new Search map showed them at corrected, right? If so, then the method for viewing the found+corrected caches at the corrected coordinates has just been removed.

 

Also, it looks like we've gotten our answer regarding which map would be presented for the various links (ie. the default map). Despite it being the #1 issue, it wasn't addressed at all, which seems to imply that their decision is made.

  • Upvote 3
Link to comment
1 hour ago, brendanjw said:
  • The map will now only use the corrected coordinates to plot cache markers if the user has not found the cache.

Please provide a way for users to choose whether to display found puzzle caches at their corrected coordinates or at their bogus posted coordinates.

  • Upvote 3
Link to comment
52 minutes ago, The A-Team said:

 

Can someone confirm how this affects users? IIRC, before this change, the Browse map showed found+corrected caches at the posted coordinates, while the new Search map showed them at corrected, right? If so, then the method for viewing the found+corrected caches at the corrected coordinates has just been removed.

  

Also, it looks like we've gotten our answer regarding which map would be presented for the various links (ie. the default map). Despite it being the #1 issue, it wasn't addressed at all, which seems to imply that their decision is made.

Hi,

 

To clarify, this change is specific to the Search map only, we did not make changes to the Browse map.

 

We received a report that the Search map was showing markers at the corrected coordinates in ALL cases.  This was intended.  The fix that we implemented yesterday ensures that the Search map will only show markers at the corrected coordinates if the cache has NOT been found.  If the cache has been found the map will show the marker at the posted coordinates.

 

Best,

Brendan

 

Link to comment
13 minutes ago, brendanjw said:

We received a report that the Search map was showing markers at the corrected coordinates in ALL cases.  This was intended.  The fix that we implemented yesterday ensures that the Search map will only show markers at the corrected coordinates if the cache has NOT been found.  If the cache has been found the map will show the marker at the posted coordinates.

 

It was not a "report". I just expressed my satisfaction when all caches were at the corrected coordinates. Now I am not satisfied at all.

 

How much is cost to add a checkbox [X] Show all caches at corrected coordinates? We may try to use crowdfunding if the price tag is reasonable.

Edited by arisoft
  • Upvote 2
  • Funny 3
  • Helpful 1
Link to comment
1 hour ago, brendanjw said:

To clarify, this change is specific to the Search map only, we did not make changes to the Browse map.

 

We received a report that the Search map was showing markers at the corrected coordinates in ALL cases.  This was intended.  The fix that we implemented yesterday ensures that the Search map will only show markers at the corrected coordinates if the cache has NOT been found.  If the cache has been found the map will show the marker at the posted coordinates.

 

As arisoft mentioned, several users were glad that the Search map showed corrected coords in ALL cases.  Because that allowed users to see both corrected and posted coords when planning their own hides, by having two windows (one with Search and the other with Browse).  We need to see where the corrected coords are located on the map, so that we know that area is not available for a new hide.  The ability to see both views was something cachers liked and I would presume that's why it was the intended behavior.  It's not something that needed to be fixed.  It would be most appreciated if the change that was made today is reverted.

 

 

  • Upvote 1
  • Helpful 1
Link to comment
2 hours ago, The A-Team said:

Can someone confirm how this affects users? IIRC, before this change, the Browse map showed found+corrected caches at the posted coordinates, while the new Search map showed them at corrected, right? If so, then the method for viewing the found+corrected caches at the corrected coordinates has just been removed.

 

Yep.  I just tried it and now neither map view shows me the location of corrected coords for found caches.  :(

 

 

 

gc-map-correctedcoords.png

  • Helpful 1
Link to comment

Meanwhile, here is a bug that I just noticed.  The cache displayed below is currently Disabled.  The Browse Map correctly shows the icon greyed out, but the Search Map shows the icon as though it is an enabled cache.

It looks like the issue is only related to the puzzle piece icon, as I see cache icons are greyed out for disabled Trad, Multi, Myst (unsolved) caches on the Search Map.

 

image.png.1a69bb5797f921788599cab630a7e635.png

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...