improved search - by date placed

[+str8upcacher]

I apologize if this has already been mentioned somewhere in the discussion board(s).  The change / upgrade that I would most like to see is the ability to search for caches by date placed. I know you can do this by sorting the resulting cache listing, but it would be so much more efficient to be able to pick only caches from a certain date range initially. 

Thanks,

str8upcacher

 

[RuideAlmeida]

7 minutes ago, str8upcacher said:

... but it would be so much more efficient to be able to pick only caches from a certain date range initially. 

Certainly you already know... but with a Pocket Query you can do that... under certain limitations.

[+str8upcacher]

Yes, I am currently using pocket queries, but this is not too efficient, and as you indicate, has some limitations.

I also use the main search function, and then re-sort the list of resulting caches within the search area by date placed, but it would be great if I could restrict the date range so only the specific caches I want can be seen and mapped.  

[+badlands]

Only The Frog knows why the key date field is user update-able however by using GSAK you can search by placed date.

[+HHL]

1 hour ago, badlands said:

[...] however by using GSAK you can search by placed date.

No. The Api search (done by GSAK) is using "Publish Date".

[+badlands]

 

3 hours ago, HHL said:

No. The Api search (done by GSAK) is using "Publish Date".

What they said.

[+str8upcacher]

I don't use GSAK, and have no intention of starting to do so. I'd rather see geocaching.com updated with additional search options.  

[+thebruce0]

No, if you download caches into GSAK, you can indeed search by Placed Date as it's a listing-specific data field.

However I wasn't aware that the API (which wouldn't be just GSAK) now allows searches by Publish Date, since that date is only available via the Publish LOG itself (for caches that have one - old caches do not).  That has always been a difficult one to implement because it meant seeking the first publish log for a cache to determine that date, rather than merely returning a date field of the listing itself. (programmatically simple, but still more complex than a simple field retrieval, without knowing the complexities of Groundspeak's database backend setup).  In GSAK (at least apart from the API) it meant retrieving ALL logs for a single cache until you got the Publish log.

[+NYPaddleCacher]

On 4/10/2018 at 9:37 AM, thebruce0 said:

No, if you download caches into GSAK, you can indeed search by Placed Date as it's a listing-specific data field.

However I wasn't aware that the API (which wouldn't be just GSAK) now allows searches by Publish Date, since that date is only available via the Publish LOG itself (for caches that have one - old caches do not).  That has always been a difficult one to implement because it meant seeking the first publish log for a cache to determine that date, rather than merely returning a date field of the listing itself. (programmatically simple, but still more complex than a simple field retrieval, without knowing the complexities of Groundspeak's database backend setup).  In GSAK (at least apart from the API) it meant retrieving ALL logs for a single cache until you got the Publish log.

I was curious so I ran a "Not Yet Found" PQ, which includes cache which were recently published.  For each waypoint (in GPX format) there are up to five Groundspeak:log elements.  Each of those logs contains a Groundspeak:type element which is a string of the "log type".  On one recently published cache, the log types are "Write Note", "Found It", "Found It", and "Publish Listing".  All of the logs include a date, for example:

<Groundspeak:log id="755479709">
          <Groundspeak:date>2018-04-01T15:07:05Z</Groundspeak:date>
          <Groundspeak:type>Publish Listing</Groundspeak:type>
          <Groundspeak:finder id="714325">Redacted</Groundspeak:finder>
          <Groundspeak:text encoded="False">Published</Groundspeak:text>
 </Groundspeak:log>

To me, it would be less useful to able to "search by" published date than to simply be able to "sort by" publish date (by clicking on the column name).  It seems to me that, because every log has a "type" that retrieving the log with "Publish Listing" for the type, then adding a "Published" column with the date would allow for that.  

[+thebruce0]

Right, it's been a feature that's been on the request docket for some time. In GSAK I created a custom Published column and I occasionally run a script that updates that value IF the cache being checked has an associated Published log. Otherwise GSAK doesn't have the actual Published date in the database yet. For old caches, it means retrieving ALL logs for the listing, and then hoping that there even is a Published log. The oldest caches don't have them; can't remember exactly when that log type was created. Groundspeak could 'simply' add a distinct Published column in their listing database to keep an easily searchable record of that date, then whip through all the existing publish logs and update their assocatied cache listings.  But, IIRC they mentioned it was something were working on... a long time ago... haven't heard any update on that yet. =/

[+NYPaddleCacher]

1 hour ago, thebruce0 said:

Groundspeak could 'simply' add a distinct Published column in their listing database to keep an easily searchable record of that date, then whip through all the existing publish logs and update their assocatied cache listings.

Without being able to see the code and database schema, I can only speculate that there is a "logs" database, which has a key to the geocache id and the log type.  As you mention, not all geocaches have a published log so a query of that table with the geocache id and a log type of "Publish Listing" wouldn't return a result.  If there is a result it would contain the date of the log.   As an added bonus, the GPX file generation code that returns the five most recent logs could instead return the five most recent logs and the publish log (if it exists).  As GSAK uses the API, instead of having to run a separate script the code that returns a list of caches could also call the method to retrieve the published log and a Publish column be included as one of the default columns in a database.

[+thebruce0]

That would be one way to quick fix for the end user, yeah. Ideally moving it to a dedicated column would be the end goal; there'd be less database table connecting and querying to get one point of data. But that's a structure update which is different than scripting a return of the desired data. So it's really a matter of where they're at, and what their end goal is for that data point. If any at all.  I hope it's still a feature they are working to enable for the public.

Nonetheless, the data exists in some manner in their database right now. So providing a search by published date is technically feasible. Programmatically and financially feasible for them at this point? I would think and hope so, but something tells me nope. At least, it's not a high enough priority.  Since we can work our way around that by putting extra work into getting the data ourselves, then it's not really an essential provision to implement.  I'd love to see it added to the GPX though, so we don't have to go digging down into every log's history just to find the related Publish log.