Jump to content

Corfman Clan

+Premium Members
  • Posts

    482
  • Joined

  • Last visited

Posts posted by Corfman Clan

  1. 12 hours ago, SpiritGuide said:

     

    Not completely true.

     

    Geooh GO was set up and doing the "required authorization method" years ago from the beginning of the API, but an incorrect parameter didn't surface until the new method went live. A technical mistake for sure, but one which Groundspeak could have prevented by reviewing server logs and informing partners of problems before go-live. I don't know about the other two apps, but don't assume application providers didn't try. Groundspeak can share some of the blame.

    This wasn't just turned on, it's been available for years. I know, I'm a 3rd party developer for Geocaching and implemented this a long time ago. My application has been using it since it first became available. GC HQ finally turned off the old method for authentication after well over a year of notice.

    • Upvote 1
  2. This is not an issue on the Groundspeak side. Groundspeak has finally shut off an archaic and less secure authorization method and the apps in question have not updated to the now required authorization method. Groundspeak has been advertising this change to the API partners literally years. The application providers have no excuse for not updating their applications as there has been more than ample notification.

    • Upvote 2
    • Helpful 2
  3. I have a pocket query set up to list unfound geocaches in Arizona. If I click on the "Preview Pocket Query" icon, only unfound geocaches are listed, as expected. If I click on the "Preview in Geocaching Maps" icon, this is not the case. It used to work correctly, but no longer does. I'm not sure when this changed but probably within the past two months.

  4. On 3/20/2022 at 2:49 PM, MNTA said:

    Today I'm quite proud to say I found a just over 8.5 years lonely cache. A record for me for sure. It was the oldest last found cache in my 30 mile radius and has been a goal of mine for a few months now.

    Congratulations, that's a great accomplishment!

     

    Now to plan your next adventure chasing down a lonely cache in Oregon, this may help: Longest Time Alone Geocaches Oregon

  5. On 1/7/2021 at 10:44 AM, IDILIO49 said:

    So this mean on API is not possible?

    I'm unable to come up with a way to do so. You might be able to search for certain log types for the user to get a few, but that's not very satisfying. This limitation may be a HQ business decision. I'd contact apihelp and ask there. They've always been responsive for me.

  6. 20 minutes ago, Corfman Clan said:

    You may have to set the isActive filter to false to get archived caches. You also may only be able to get the archived caches if you are their owner. Not sure about that though.

    So I tried this out. I wasn't able to get a list of another's archived caches nor of my own archived caches. :sad:

  7. 3 hours ago, IDILIO49 said:

    Thanks Corfman Clan!
    Besides the hiddenBy filter suggests is the "placed by" and not the Owner it is really the Owner.

    The only problem is that search will not return the archived caches. Any way to get the Owned archived caches?

    Placed by is just text and not a real reference to any cacher. That is, the cache owner can edit the Placed by text to anything.

     

    You may have to set the isActive filter to false to get archived caches. You also may only be able to get the archived caches if you are their owner. Not sure about that though.

  8. On 10/9/2020 at 4:49 PM, colleda said:

    New deadline: December 31, 2020

    In response to COVID-19, Geocaching HQ is extending the deadline for all unpublished Virtual Reward 2.0 Caches. The last day to submit your Virtual Cache for review is now December 31, 2020 (5:00pm Pacific Daylight Time).

    On November 20, the deadline was extended once again to June 4, 2021.

     

    At any rate, I can't see GC HQ announcing a virtual rewards 3 until a time after 2 is complete.

    • Upvote 2
  9. 19 hours ago, GO Geiger said:

    On a pc monitor there is a lot of wasted space to both sides of many pages because it is sized for a phone and does not adjust to the size of a computer monitor. 

     

    For example the souvenir list only goes 3 wide but is extremely long  rather than going 6 or 7 wide based on the amount of space on the screen that it is being shown on. We have about 225 souvenirs.  With them spaced out and  3 columns and so much space between rows it makes the page very long.  This is true of a lot of pages not just the souvenir page.  I was just using the souvenir page as an example

    geocaching profile [age.jpg

     

    I had to check that because I've always had four souvenirs per row with the new profile. Now it's three :sad:

     

    I suppose that change was made the same time the profile image was squished.

    • Upvote 2
    • Helpful 1
  10. 21 hours ago, Geocaching HQ said:

    Release Notes (Website: Upcoming retirement of old profile page)

    The main feedback we have received about the new profile page was that the cover image was so large that it required scrolling down the page to see the content. With today’s release, we have reduced the height of the cover image on the new profile page to give the content more space. We have also, for the first time, opted all players into the new profile page.

    Please don't. The new size is too thin. Besides, there's lots of space below it that used to be the image that is now just white space. Plus you're inconveniencing everyone that has created an image for the previous size with having to redo it.

    • Upvote 4
  11. 2 hours ago, thebruce0 said:

    Text and [n/varchar fields are stored differently. Text is there specifically to handle bulk text over 4000 characters. They both have benefits and drawbacks, as I mention in my comment. MS put the threshold at 4000 because that was to them a reasonable threshold to balance fast/small with slow/large.  You wouldn't create a 200 character field as a text type, and you can't create an 8000 character field as a varchar/nvarchar. As a datasystems developer that's my best understanding. A UI/UX reason for limiting to 2500 instead of 400 feels extremely arbitrary. I would assume there was statistical research and data covering everything from internal network bandwidth to user-end bandwidth to server CPU and storage requirements provided before presenting 2500 as the limit, especially with a data system the size of GC.

    You're out of date. text/ntext/image are deprecated and varchar(max), nvarchar(max), varbinary(max) should be used instead. Using, max instead of n <= 4000 changes the storage, as you mention and as I previously mentioned too.

  12. 49 minutes ago, dprovan said:

    So you're saying the GS developer is an idiot for limiting the length to 2500 instead of 4000 for no good reason?

    No, I'm not saying that at all. There are other concerns that would cause one to limit the field size. There are business decisions, UI/UX reasons etc. Ignoring whatever those forces are that caused the notes to be limited to 2500 characters, it would be trivial to increase the limit up to 4000 (probably but not necessarily) if it is an nvarchar column. Beyond that, other factors come into play.

  13. On 6/12/2020 at 7:47 AM, thebruce0 said:

    When it comes to large amounts of data like that, depending on the database server, if it's stored as a text block instead of a set character length, the limit is arbitrary. If it were 5000 characters, the row would simple store a pointer to the text data which would be stored however long it is. Each row wouldn't have 5000 characters allocated, only the data required for the pointer. Then a row can have 100 characters of 5000 characters and no space is wasted. It's less optimal because the text data has to be looked up rather than retrieved implicitly with the row, but that's a tradeoff for data columns with large amounts of data. 

    All that said, it really depends on how HQ stores their data and which server is used. They may compress the data if not already. And I highly doubt they use a format that allocates 2500 characters (at multiple bytes each) for every row.

    If increasing the limit doesn't immediately add terrabytes of data, and the length of data is effectively arbitrary, then the only downfall would be people who immediately make maximum use of the additional characters to use up server space. In the grand scheme, that seems relatively infinitesimal overall. Especially if compressed (text is enormously compressable).

     

    However, from my experience, the only time I've ever needed more than 2500 chars in the personal note was storing puzzle data, progress with solutions. And even those, only puzzles that may have large grids of content that I'd be updating.  Earthcache answers? point form, no need to copy questions as well, not an issue. It's really only been those large matrix-style puzzles where the whole thing is needed.  Other than that (even then it's a choice) I can't imagine a situation needing more than 2500 characters that can't be reduced in some manner.

    Though I don't know, I'm fairly certain, GCHQ uses SQL Server and the notes are probably a column in some table of type nvarchar(x) where x can be specified from 1 to 4000 characters or "max". It's probably set to 2500 now. There would be no data size impacts to increase from nvarchar(2500) to nvarchar(4000). switching to max would impact things. Whether one can actually store the specified number of characters depends on what character encoding is used so the actual number may be less than specified. https://docs.microsoft.com/en-us/sql/t-sql/data-types/nchar-and-nvarchar-transact-sql?view=sql-server-ver15

  14. 6 hours ago, barefootjeff said:

    I'd like to see it made an option for all COs and not just for those owning "pioneer" caches. I guess my preference would be for my caches to be archived and retrieved in the event of my demise as I don't think any are worthy enough to warrant preservation. Hopefully when the time comes to hang up my GPSr, I'll have enough advance warning to go out and do that myself or get a friend to do it.

    That's my feelings too. I think there should be an option on every cache for the CO to specify how to handle the cache in these situations, not just some set of "historic legacy" caches. I'm actually a bit loath to specify how mine should be handled when I feel this option should be available for all caches.

    • Upvote 2
  15. 11 hours ago, L0ne.R said:

    I assume by "it isn't an issue and not do anything" that you are OK with the listing being archived if you should suddenly kick-off.

    No, I'm not okay with that. If I suddenly kick-off, then it is up to my wife/family to decide what to do with the cache. I do know that my geocaching friends would also help out and help her take care of things. Geocaching HQ need not get involved. If, in the future, I am no longer able or motivated to manage my caches, I'll deal with that then but at this time, that is not an issue and nothing needs to be done.

    • Upvote 1
  16. I believe Geocaching HQ has been heading this way for awhile now. Early last year, I was contacted about what I would like them to do with my Y2K geocache if I became inactive, died, or whatever. They gave a few choices. I told them, it isn't an issue and not do anything.

     

    Quote

    Hello Corfman Clan,

     

    Greetings from Geocaching HQ. One month ago, we reached out to all the owners of active geocaches that were placed in the year 2000. We offered each of them an opportunity to protect their historic legacy geocache from being archived if it needs attention and they cannot be contacted. Many of those cache owners responded quickly to share their wishes for their cache should they ever be impossible to contact, and those caches are now protected.

     

    We have not heard back from you yet, which means your cache is still at risk if you cannot be reached. Because it is your property, there is little that can be done to save it if you are unreachable and unable to care for it. Therefore, we are providing you with an opportunity to state your wishes now for the future care of GC7B T824 Table Mesa. We will record this information and refer to it only if your cache needs attention and you cannot be reached.

     

    Suggested requests you can make for your cache:

     

    Designate one or two specific geocachers to adopt the cache
    Designate a geocaching organization to choose an owner for it
    Give permission for HQ to choose a responsible cache owner to adopt it

     

    In the future, if your cache needs attention, your reviewer will contact you. If there is no response from you within 60 days, HQ will attempt to follow any written future care wishes you have provided to us.

     

    We emphasize that this is strictly a backup plan. You will retain control of your cache as long as you own it, including adopting it to anyone you wish without involving HQ. You can make changes to the future care wishes you have provided to us at anytime by contacting HQ and letting us know.

     

    Please reply to this email with one of the suggested requests above, or let us know that you don’t wish to take advantage of this opportunity.

     

    We look forward to documenting your wishes and ensuring that your pioneer cache will always be available for the geocaching community to find and enjoy.

     

    Kind Regards,

     

×
×
  • Create New...