Hynr

HiddenGnome, thank you for joining the discussion. I am a fan of adding a Markdown WYSIWYG editor to the log creation page at the website. It is after-all about beauty and self-expression, and that will make it feasible for those who do not code hmtl or bb to express themselves with a little more eloquence. Some would argue that beauty is not necessary, but I bet you and your colleagues are proud of the current beauty of the page and, of course, the fact that nothing is broken. Quite awesome, really. So when I read "Existing logs will display any old HTML and UBB code as of February 2." (in the announcement), I understand that you will knowingly and deliberately configure your main product (the web page) so that it will look broken to anyone who is not a computer programmer? I guess that as a webpage programmer you might consider <Large>HTML tags</Large> to be pretty; or perhaps you are so accustomed to seeing the tags that you are blind to them. But you may be surprised at how many of Groundspeak’s clients don’t see it that way. While only 3.5% of the logs are apparently affected, how many web pages? I analyzed my current home database around my home in California and I have only 2.2% logs (out of ~540,000 logs) affected (I am counting logs containing these two-character sequences: </ or [/ ), but 35% of the 20353 caches in this database are affected. I note that the beautiful logs section, in which you invested all that hard work to cleverly pull and show logs as the user scrolls down, will ultimately show a broken log for more than a third of the active caches. Don’t you think you and Moun10bike will get tired of the stream of folks coming to this forum webpage in perpetuity, each with yet another observation that some logs are broken at the website but not in the GPSr or other software?

+1 (actually + as many as the spam messages I got today) I want them out of my system forever, not just hidden.

The more I think about this, the more I am puzzled/intrigued. No data are changed and if I send in a log via the API, it will go in exactly as the string of characters that I submit even if that includes non-Markdown tags. There won't be processing because they don't know how to do that without breaking things (per their quote). The change will be primarily at the page on the geocaching.com website where you edit logs. There we will see a Markdown WYSIWYG editor (stripped down a bit from the one they show at the link in the announcement). I really do like the idea of having a WYSIWYG editor there. So what will happen is that all modern devices will be OK with HTML and BB, but the website will clearly look broken on some logs if they strip codes during the display of logs section of the web page. There will be a never ending stream of newbies asking why some logs are broken and then the website will be fixed and the display system will then support Markdown, HTML, and BB codes. You will be able to use the new editor to edit in HTML codes as you do now because it is fundamentally designed to leave all fancy formatting in the hands of the user. If it is as I am guessing, then adding that WYSIWYG editor for Markdown would also be neat enhancement the cache description editing fields also. Obviously a full WYSIWYG HTML editor would be better but that has been a need since day 1 of the website, so clearly that will never happen. A WYSIWYG Markdown editor there would be better than nothing as long as we can still do what we do now. If I have understood this correctly, then I would ask for one enhancement to the Markdown editor for the website. We need to be able to switch between the default font and a "fixed font" (e.g. Courier New) so that some primitive tabulation is possible (aligning columns by inserting spaces).

I am ambivalent about the change. My main concern is how it will affect what I see in my GPS. In my current dataset (northern California) I have 532161 logs. Of these 2.26% contain two sequential characters [/ (which appears in closing bb codes) or the two sequential characters </ (which appears in closing html tags). So the impact would be small. Further, since old logs are not affected, and I get them via gpx files, I anticipate no change on my GPSr. But I do find the arguments for the change to be bogus. Consistency across devices will be lost, not gained. Geocaching apps render html, as do most modern GPSr devices. But NONE render Markdown. On the GPSrs there will be a dependence on the fact that Markdown does not use a lot of mark-up and is readable without rendering. So what will happen is that instead of the logs looking the same on my Garmin Montana, as on my smartphone, as at the website, as is the case now, these will all show differently due to a lack of rendering on devices. And if the website stops rendering html and bb codes in the logs, while my devices still do, then clearly the appearances (and certainly also readability) will be different. Does anyone think that Garmin will implement Markdown rendering in firmware updates on GPSrs given that Markdown has already been obsolete for 10 years and has no industry standard? That seems very unlikely to me.

Is the "Message Center" still in beta? If so, why is the survey closed? If not why has the relevant documentation (FAQ) not been updated? If it is still in beta testing, what is the method for getting feedback to the development team? I am not seeing that described in the FAQ; instead it leads to a survey that is closed. "Hide" (at the Message Center) appears to be a euphemism for either "archive" or "delete". I cannot tell which. If it means "archive", then how do I view the messages that have been "hidden"? If it means "delete" then why does it not simply say "delete" instead of "hide"? I have the sense that all messages are being retained forever on a server. Is that true? Is there a way to prevent that for message that I receive or send? Who has the ability to view messages that are archived? Where does one find information about retention of messages and privacy issues regarding the Message Center? Am I right or wrong to have an expectation of privacy about things sent through the message center?

The only way that could be made to work is if you go back after you found puzzles and multi-caches and entered the final locations into the database as corrected coordinates. It seems to me that you will have an ongoing hassle regardless of how you do it. But if your collection is of value to you, then perhaps it is worth it. In any case, you could probably maintain a Found database with GSAK and regularly update it by loading your My Finds PQ into that. You can refresh those records to get the API version of data if you want that. There is a corrected coordinates feature which would help with the puzzles and multies. Matching images to caches could be done with a macro which offers you all potentially relevant photos to attach to the record. GSAK lets you create and maintain custom fields and you could store the image file name there; alternately in the usernote which has the ability to have images within notes. If you have macro writing experience, then this would seem to be entirely feasible. You just have to build the system and maintain it. The answer is "yes". The reasons are rather complicated and I don't recall the details. You might want to look at this pagehttp://gsak.net/help/hs23810.htm and scroll down to g_GcDate() and look at the text there. If there is a better way to find the absolute correct time that a log was generated, then I do not know what that is. You might also note that the API delivers two dates for a log, one is the date that represents the date when the cache was found and the other is the time-stamp when the log was put into the logs database in Seattle. The former is what is sent in the PQ because that is what has traditionally been important to folks and that has no useful time information anyway. The latter would be reasonably accurate if it were not for the fact that there were programming errors along the way so that some of those time-stamps are off. Then you start factoring in issues with time-zones and daylight-savings-time and it will make your head spin.

The original post is a fine idea and clearly there are persons who would enjoy that. As such Groundspeak might see this as something positive for those who would enjoy interacting this way. As log-writer, I would probably not enjoy this as proposed. I can see having my feelings hurt by someone evaluating and judging my log. In which case I, and probably many others, would simply not write logs, even short ones. So this could back-fire. But what I would find useful if others could rate a particular log as "useful", particularly to have others note if coordinates or photos attached to a log are useful. My main use for logs is that I have as many in my GPSr as possible and I scan down through them when I cannot find a cache. At that point it would be helpful for me to note the ones that others have found "useful". And as I think about it, if logs had some indication of favoriteness or likability or degree of enjoyment, then I might set my software (eg GSAK) to not purge those logs. So I guess I would use the feature, even if don't like all facets of it. As such I see merit in the core proposition.

It is probably possible to get something put together even if you do not have a camera with an integrated GPS receiver feature. Generally all modern GPRs units have a track log feature. You may need to set the option in the GPSr to save those. You can load those into the software that comes with your GPSr. Each point that is in the track log has a time-stamp to at least the nearest second. The files that are your photos in the camera will also have time-stamps, also to the nearest second. So you would find the point in the tracklog that is closest in time to the file timestamp. For this to work accurately, you need to set the date and time in the camera to be exactly as on your GPSr. For each of your found goecaches find the point in the tracklog that is nearest to those coordinates. I cannot imagine even considering to do something like this without automation software. I would certainly get GSAK involved to avoid having to go to each web page. I vaguely recall that someone did some macro programming for GSAK to do this sort of processing (using the track-log to match things up). So if you feel that using GSAK might be an option for you, then post at the GSAK forums. Here is a link that might show you the direction this might take: http://gsak.net/board/index.php?showtopic=16480&st=0entry204898 If your photos do have coordinates in their EXIF info (i.e. if you are taking the photos with a GPR enabled device such one of the Garmin units with a camera feature) then this macro probably does what you are asking.

At this time (for the past half hour) I am finding the API so slow as to be unusable. Refreshing one cache (with GSAK) takes 40 to 120 seconds to get data back. Various tries simply time out. Pulling the API help using browser (Firefox) also takes a minute or longer. Ditto for clicking on any link on that page. For example, just now refreshing one cache, on the dialog I see: SocketConnect: api.Groundspeak.com:443 HostnameResolve: api.Groundspeak.com SocketConnected: api.Groundspeak.com:443 SslHandshake: Starting ... no response after 100 seconds Sometime between 100 and 120 seconds it does complete. Perhaps the last lines of the API log reveal something to those who understand the lingo: ... ---- Reading HTTP Response ---- No transfer-encoding header field. sslContentLength: 15085 extraLen: 12907 readResponseTime: Elapsed time: 102516 millisec responseStatus: 200 --sendRequestGetResponse_1 Success. --PostXml --ChilkatLog Generally the request do complete but the process is too slow to be usable at this time.

When I view some cache pages in Firefox at the zoom level that is best for my set-up, I see the logs table shifted and clipped. The zoom level below that or above that does not exhibit this behavior. So if you do not see this, then zoom in a few levels, or out a few levels, while looking that the transition on the page between the "Logged visits" section and the Log table. Tested with Firefox version 30.0 in OS/X 10.7.5 Firefox version 31.0 in Windows 7 (64bit) Enterprise with SP1 Some cache pages where this happens: http://coord.info/GC9CE0 http://coord.info/GCK36V (apparently it makes a difference how many logs there are or how old the cache is) With the Firefox (the Windows version where they have hidden the "about" dialog so I don't know the FF version - probably the latest), with Internet Explorer 11 (ver 11.0.12 for Windows 7) and Safari (ver 6.1.6 for OS/X) this is not the case but zooming to the level that I need on my system does widen the log table to not fit on the page (instead of keeping it at a particular percentage of the displayed area).

You then are obviously not aware that when you are the only one who can post there (I see "You cannot start a new topic") that you are actually only listening to yourself and hearing what you want to hear, but apparently have no interest in listening to what we might want to tell you. I interpreted it that way when you first set it up. I did think it was a good idea (certainly better than nothing) but wish you would have put it to use with the new "email notification bloating feature" and "let's save bandwidth by not e-mailing gpx files anymore".

Thank you, Mount10Bike, for the very valuable information. I know there are software developers out there who have been wondering whether to start the work to fix or whether to sit tight. Your message is that a reversion is in the works so that sitting tight makes sense. What about, in the short term, having “Mystery” types be those puzzles for which the user has entered corrected coordinates, and using “Unknown” for ones that do not have that. When the numeric cache-type IDs are implemented, I would suggest that a different value be used for those caches where the user has entered corrected coordinates versus ones where the user had not solved the puzzle. As you can see already here in just a few posts, there is lots of interests in having the new gpx schema resolve various issues. Would you please suggest to Jayme H to open a thread in the User Insights forum to accept our input on what we users would love to see implemented in the new schema?

Yes, they did... And it's back to <type>Geocache|Mystery Cache</type> again. *sigh* My Garmin 450 is now showing just a general Treasure box instead of a "?" icon for the Mystery/Unknown/Puzzle/whatever-they're-called caches... Same here on my Garmin Montana when I give it gpx files downloaded from the geocache pages. Looks like geocaching.com is delivering gpx files that are not compatible with Garmin's current product line. Moun10Bike, could you clarify for us if the intention is to leave this defect in the system or to change it back to the way it was as you had stated earlier.

The Montana has a feature called "dashboard". The unit has several different dashboards that you can select and "geocache" is one of those. When you have it selected, it shows a rectangle at the top (or side) for the geocache that is closest to you. You can select this and navigate to it; if you do, then the selected geocache displays in the dashboard. The link in this message shows a Garmin Opencaching geocache in the dashboard; the Grounspeak geocaches look a little different in the dashboard, the the functionality is the same.

I am surprised you are getting a 4 gB SD card to work in a 60CSx. The largest I ever got to work was 2 gB.

There is absolutely no reason why one would not go geocaching in Mexico. The issues are the same as in the US. A tourist walking around with an electronic device is going to be treated with the same suspicion in Mexico as in most places in the US. Every state in the US and Mexico has it's "don't go there" places. Mexico is a very large country, and there are many places to go explore. Generally local geocachers won't set caches into places where they should not take others. My sense is that the percentage of placements that take you to interesting spots is much greater there than in the US. If a cacher errs on the side of the "adventurous" then the logs will give you hints as to what you are likely to encounter. My experience with Mexico is that it is a great place to go and there are many friendly persons. But there are fewer geocachers and thus also fewer geocaches. If there is any aprehension about caching in Mexico then look at the map and see what is there; if there are a few clusters of geocaches at your destination, then read the descriptions and if you note that many belong to one particular geocacher, then contact that person. You may well make a new friend.

Brdhntr54, I have a few suggestions. 1. note that on any issue at this website you will typically get both sides of the story. It is quite rare that an issue is discussed where the opinions are as unanimous as what you are seeing here. 2. I have the Montana 650t and it is my opinion that the "t" is not worth the money because in my region (Northern California) streets on the topo map are not resolved with adequate accuracy. I installed routable OpenStreet maps and that is adequate for my needs. I sometimes turn the topo on when I am in areas where the contour lines are interesting but have found the accuracy to not be to my liking. I bought my 650t when it was on sale at a price that was essentially the same as the 650. I bought a 650 (without the camera) for my wife for her birthday and she loves it. I feel that the Montana is the best GPSr I have had (I have had about 10 of them). It is not perfect, but it serves me very well. I have found that I really need the big screen. 3. But before you pull the trigger: go to a nearby geocaching event as soon as you can; take your Monterra with you and at some point announce that you have one and are looking for help. You might also mention that you are considering trading it in for a Montana and that you'd like to hold one to see how it works. I guarantee you that you will make some new friends and come away with the correct decision.

Most users would probably assume that since Google is being used for maps that it would also be used for geocoding. So this is not obvious. I suppose that this is due to the fact that Google is charging for the service. OSM/Mapquest APi does return geocode data for the town in question: http://open.mapquestapi.com/nominatim/v1/search?format=xml&q=Jork+Germany So if this is not one of the services that is being used, then perhaps that offers a solution to the identified problem. If that is one of the services, then perhaps there is indeed a bug in the geocaching.com website code which could be remedied.

If you go to Google maps and type in a name of a German town (including Jork) it is found readily. If you visit https://developers.google.com/maps/documentation/javascript/examples/geocoding-simple and type in Jork, Germany it geocodes it without any trouble at all. That suggests to me that there is indeed something that can be done at the Groundspeak end.

On the "Create / Edit a Route" page, the ability to "Edit" (I believe that previously there was a button to "Modify") is gone. Moun10bike, is that intentional? If so, then the title of that page is just plain wrong as one can do neither create nor edit from this page at this time. Losing the ability to edit a route is unfortunate. In fact, I had hoped that at some point it would be "fixed" to where it might save for editing all the route modifications that one makes in a session, rather than having the edit function offer only the endpoints and the auto-calculated route.

Garmin eTrex is a series. Which model do you have?

I have a jar of rechargable batteries that won't hold much of a charge anymore (waiting for proper disposal). There is not a single Eneloope in the jar. Many other brands are in there. Even some other Sanyo types which I figured were probably similar to Eneloopes, but they were the worst rechargables I ever had. Many of the ones in the jar ended up there within a few weeks after I quick-charged them once. I used to think Eneloops were too expensive so I kept buying the cheaper ones, but as I got Eneloopes as gifts I now have mostly those. Not sure what they actually cost but my sense is that they are a better deal than the cheaper ones.

Since you find your present way of doing things perfect (without a premium membership) then the answer to your question is "yes". The premium membership is specifically designed to give you more options regarding data; that is why so many are advising this route. But if you know you won't go that route, then you can still do what you want with your style of geocaching. You can use the geocaching.com website to show caches nearest New Windsor and you can then select the checkmarks for the ones you want in the GPSr. At the bottom of the search results pages is a button "Download Waypoints" for sending up to 20 on that page as a LOC file into your computer (the browser should ask you where you want the file or show you the location). This is not a gpx file (which is what your gps needs); so use Windows software like EasyGPS or GSAK to combine these into one database and then transfer all that as one GPX file into the GPSr. You will then see them on the map when you are in New Windsor and you will be able to geocache just like you do now. Note that if the total number of geocaches that you would have in your gpsr is less than 500 then you could also just click the "send to gps" icon for each cache individually. It would take a bit of time, but ought to work. The problem is that this will create one file per geocache so you are limited to 500 rather than 2000.

Try this without skipping any steps: 1. Attach gps to computer; delete all gpx files from all Garmin\gpx folders that the unit makes available on the computer (i.e. both internal and SD card if there is one). 2. If you are on a Mac then now also empty the Trash; 3. Disconnect and restart GPSr and verify that nothing now shows (to assure that the internal database is completely cleared). 4. Attach gps to computer via USB again and when the drives show up put the desired gpx files back. 5. Disconnect GPS from computer and start it up.

I am excited by new things. Innovation and experimentation is my business (at work). If I were to ever even contemplate involving the "production side" of my world without an alpha and beta stage, then that would have serious negative consequences, even if everything worked perfectly. The various policy violations that I now see on the production side of geocaching.com are going to cause huge issues in terms of credibility. In placing a recent event cache I was motivated by the reviewer to reduce the number of times I mention a particular commercial entity in the description. I am baffled at what I now see on the "production side" of the geocaching web site, especially since it is being put in place by folks who make the policy, yet I see no alteration in the policy that would allow what I am seeing. You are poisoning your own water by letting these new experimental things count on the production side of your operation. I think stability is important, particularly when you consider all the reviewers who are now left scratching their head and trying to defend a policy that is suddenly not defensible, and even more individuals who want very much to place interesting and useful caches. My sense is that if I were in your position, I would make some quick adjustments to pull these things out of the production side, move them into a beta site, give users the assurance that if this does get into "production" that then their finds will count. This then gives you time to do a thoughtful, careful revision of the policy, announce it for a particular effective date and then shift the beta stuff to production. If there was an alpha or beta stage, then you need to consider how you do this sort of testing because it was a significant failure in reducing your risks. It should have identified for you the needed policy changes and you would have had time to carefully do what you must now do in haste with lots of band-aids. Please do NOT give up on lab caches. The idea is great and will give you very valuable information that you need to grow and develop.