Report Site Issues Here

Discussion about the Geocaching Australia web site
MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Report Site Issues Here

Post by MavEtJu » 11 March 17 10:19 pm

Also at the update of a query if you fill in an end-date which doesn't exist (for example 31 June) it will default to 31 dec 2030.
Can this be changed to the first existing date like 30 June?

Even worse, if you run a query with that non-existing date in it, then it will return zero records.

Edwin

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Report Site Issues Here

Post by MavEtJu » 11 March 17 10:27 pm

And as the last one... The queries which can be downloaded via the API have a maximum size of 500 records.

The query for NSW from 1 September 2009 to 1 September 2009 returns 896 records.
As such you will never be able to import the full list of waypoints via the API.

Edwin

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Report Site Issues Here

Post by caughtatwork » 12 March 17 12:14 pm

The stats range is for GC only as that would be to set up your 500 PQ range. Your MyQuery has GCA caches and therefore has different criteria. The counter is only really there so you can more easily set your PQ ranges at GC. You can have every cache you want from GCA with no limit (apart from any memory issues), so there is no need for that function that we can see. If you would like this as a function start a new thread (this one is for issues only) and we can discuss what the need and criteria / requirements are.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Report Site Issues Here

Post by caughtatwork » 12 March 17 12:16 pm

MavEtJu wrote:Also at the update of a query if you fill in an end-date which doesn't exist (for example 31 June) it will default to 31 dec 2030.
Can this be changed to the first existing date like 30 June?

Even worse, if you run a query with that non-existing date in it, then it will return zero records.

Edwin
Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Report Site Issues Here

Post by caughtatwork » 12 March 17 12:19 pm

MavEtJu wrote:And as the last one... The queries which can be downloaded via the API have a maximum size of 500 records.

The query for NSW from 1 September 2009 to 1 September 2009 returns 896 records.
As such you will never be able to import the full list of waypoints via the API.

Edwin
This is not an issue, it is by design. You are not mean to use the API to get every cache in the database. You agree to that.
http://geocaching.com.au/api/services/
If you are looking for bulk data downloads from Geocaching Australia there are other means of providing this data, please contact one of the Site Administrators to work with you for your needs.
If you want something other than what the API will provide please start a new thread with your request. Please keep this thread for issues only.

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Report Site Issues Here

Post by MavEtJu » 12 March 17 8:39 pm

caughtatwork wrote:
MavEtJu wrote:Also at the update of a query if you fill in an end-date which doesn't exist (for example 31 June) it will default to 31 dec 2030.
Can this be changed to the first existing date like 30 June?

Even worse, if you run a query with that non-existing date in it, then it will return zero records.

Edwin
Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.
Users don't enter an invalid date on purpose.

It's all about end user experience, and not getting a warning about the invalidity of the date provided nor a silent fix for it (just try to reduce the day-of-month by one for times until you have valid date or run out reductions) does people make go from "Hmmm, not sure where this went wrong but it is surely something which could have been dealt with nicer".

Edwin

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Report Site Issues Here

Post by MavEtJu » 12 March 17 8:57 pm

caughtatwork wrote:
MavEtJu wrote:And as the last one... The queries which can be downloaded via the API have a maximum size of 500 records.

The query for NSW from 1 September 2009 to 1 September 2009 returns 896 records.
As such you will never be able to import the full list of waypoints via the API.

Edwin
This is not an issue, it is by design. You are not mean to use the API to get every cache in the database. You agree to that.
http://geocaching.com.au/api/services/
If you are looking for bulk data downloads from Geocaching Australia there are other means of providing this data, please contact one of the Site Administrators to work with you for your needs.
If you want something other than what the API will provide please start a new thread with your request. Please keep this thread for issues only.
The issue I reported wasn't a "I want to download all data", it is a "There is a problem with the maximum amount of data being able to be downloaded and the minimum amount of data provided by a certain query.".

You can download all caches in a certain state in one go as a GPX file, but cannot download that data via the API in smaller chunks because there is an artificial limit on it which clashes with the minimal amount of data provided for a certain chunk. Even changing the hidden date on half of them by one date would resolve this problem. (or 500 minus the number of caches hidden before that date).

Edwin

User avatar
Chwiliwr
10000 or more caches found
10000 or more caches found
Posts: 900
Joined: 10 April 05 10:39 pm
Location: Leeming Western Australia

Re: Report Site Issues Here

Post by Chwiliwr » 12 March 17 10:14 pm

MavEtJu wrote:
caughtatwork wrote:
MavEtJu wrote:Also at the update of a query if you fill in an end-date which doesn't exist (for example 31 June) it will default to 31 dec 2030.
Can this be changed to the first existing date like 30 June?

Even worse, if you run a query with that non-existing date in it, then it will return zero records.

Edwin
Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.
Users don't enter an invalid date on purpose.

It's all about end user experience, and not getting a warning about the invalidity of the date provided nor a silent fix for it (just try to reduce the day-of-month by one for times until you have valid date or run out reductions) does people make go from "Hmmm, not sure where this went wrong but it is surely something which could have been dealt with nicer".

Edwin
'end user experience' is up to the source program not the data source.

Your 'program' should be validating requests sent to the data source and also account for any errors gracefully not rely on the data source to do it all for you.

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Report Site Issues Here

Post by MavEtJu » 13 March 17 2:34 pm

Chwiliwr wrote: 'end user experience' is up to the source program not the data source.

Your 'program' should be validating requests sent to the data source and also account for any errors gracefully not rely on the data source to do it all for you.
The 'program' I refer to is the query generator as you can find at http://geocaching.com.au/my/query/.

Edwin

User avatar
Chwiliwr
10000 or more caches found
10000 or more caches found
Posts: 900
Joined: 10 April 05 10:39 pm
Location: Leeming Western Australia

Re: Report Site Issues Here

Post by Chwiliwr » 13 March 17 8:01 pm

MavEtJu wrote:
Chwiliwr wrote: 'end user experience' is up to the source program not the data source.

Your 'program' should be validating requests sent to the data source and also account for any errors gracefully not rely on the data source to do it all for you.
The 'program' I refer to is the query generator as you can find at http://geocaching.com.au/my/query/.

Edwin
If you try and enter the wrong date in the first date field of a pair it defaults back to 01 Jan 2000 and if you try and do the same in the second date field of the pair it defaults forward to 31 Dec 2030 as already indicated it was designed to do and not going to change.

Going back to your original post if you got a 0 result it was not the dates that caused it as they both end up with the defaults if entered wrong and would not cause an issue as they are this way for all queries not using specific dates.

Both problems seem to be user keyboard issues not site issues.

MavEtJu
Posts: 486
Joined: 07 January 15 9:15 pm
Twitter: @mavetju
Location: Caringbah
Contact:

Re: Report Site Issues Here

Post by MavEtJu » 13 March 17 8:40 pm

Chwiliwr wrote: Going back to your original post if you got a 0 result it was not the dates that caused it as they both end up with the defaults if entered wrong and would not cause an issue as they are this way for all queries not using specific dates.

Both problems seem to be user keyboard issues not site issues.
Scenario 1: Fill in a log between time of 1 jan 2015 till 31 oct 2015. You will get N caches.
Scenario 2: In that same query, fill in 31 nov 2015. You will get 0 caches.
Scenario 3: Edit that same query, just save it. You will get a number >N caches.

How is that an user keyboard issue and not a code in the site issue?

What goes wrong here is:
- data parsing issue that 31 nov 2015 get accepted and UX issue that it doesn't get reported.
- UX issue that a larger period than the previous period does return zero caches.
- UX issue that it suddenly shows up as 31 dec 2030 instead of the expected 31 nov 2015 (or something sane)

Edwin

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Report Site Issues Here

Post by caughtatwork » 14 March 17 8:04 am

MavEtJu wrote:
caughtatwork wrote:
MavEtJu wrote:Also at the update of a query if you fill in an end-date which doesn't exist (for example 31 June) it will default to 31 dec 2030.
Can this be changed to the first existing date like 30 June?

Even worse, if you run a query with that non-existing date in it, then it will return zero records.

Edwin
Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.
Users don't enter an invalid date on purpose.

It's all about end user experience, and not getting a warning about the invalidity of the date provided nor a silent fix for it (just try to reduce the day-of-month by one for times until you have valid date or run out reductions) does people make go from "Hmmm, not sure where this went wrong but it is surely something which could have been dealt with nicer".

Edwin
This is as per current site design so I would be happy to review the situation if you raised a new thread away from the issues thread.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Report Site Issues Here

Post by caughtatwork » 14 March 17 8:20 am

MavEtJu wrote:
caughtatwork wrote:
MavEtJu wrote:And as the last one... The queries which can be downloaded via the API have a maximum size of 500 records.

The query for NSW from 1 September 2009 to 1 September 2009 returns 896 records.
As such you will never be able to import the full list of waypoints via the API.

Edwin
This is not an issue, it is by design. You are not mean to use the API to get every cache in the database. You agree to that.
http://geocaching.com.au/api/services/
If you are looking for bulk data downloads from Geocaching Australia there are other means of providing this data, please contact one of the Site Administrators to work with you for your needs.
If you want something other than what the API will provide please start a new thread with your request. Please keep this thread for issues only.
The issue I reported wasn't a "I want to download all data", it is a "There is a problem with the maximum amount of data being able to be downloaded and the minimum amount of data provided by a certain query.".

You can download all caches in a certain state in one go as a GPX file, but cannot download that data via the API in smaller chunks because there is an artificial limit on it which clashes with the minimal amount of data provided for a certain chunk. Even changing the hidden date on half of them by one date would resolve this problem. (or 500 minus the number of caches hidden before that date).

Edwin
There is no issue. This may be an understanding issue. If you have a query with the potential to return more than 500 geocaches it will be rejected. The documentation has this advice in the validation rules:
Parameter 'query' has invalid value: The query you have selected may return more than 500 geocaches. You must set the number of geocaches to return to 500 or fewer.

This is by site design. The query via the API is limited to 500 geocaches. The limit on listed geocaches is also 500. If you want more than 500, then you will need to use the search by nearest API which allows you to specify a limit (up to 500) and an offset which allows you to move beyond the 500 limit.

We do not have an unlimited amount of monthly bandwidth and opening up the query to return every cache in the DB multiple times per day would exhaust our monthly limit. For this reason as well as being fair to those who are only viewing one or two geocaches at a time a limit has been set. The set of 16,000 geocaches plus a fair number of logs would be around 100MB in uncompressed JSON form. It is not reasonable to expect that a public API could easily provide 100MB of data to thousands of users without having some form of bandwidth issues.

We ask that you use the API fairly. http://geocaching.com.au/api/services/

If you would like more than 500 geocaches returned in the query or listed geocaches list, then please create a new thread where the merits and download limits can be discussed as well as other ways that the same result can be achieved. The ZIP download function from the My Query lists would allow you to retrieve any number of geocaches as a GPX file, then it would be up to you to parse it. This is existing, but not part of the API as the API is JSON, not compressed and expensive in terms of data download.

User avatar
caughtatwork
Posts: 17015
Joined: 17 May 04 12:11 pm
Location: Melbourne
Contact:

Re: Report Site Issues Here

Post by caughtatwork » 14 March 17 8:24 am

MavEtJu wrote:
Chwiliwr wrote: Going back to your original post if you got a 0 result it was not the dates that caused it as they both end up with the defaults if entered wrong and would not cause an issue as they are this way for all queries not using specific dates.

Both problems seem to be user keyboard issues not site issues.
Scenario 1: Fill in a log between time of 1 jan 2015 till 31 oct 2015. You will get N caches.
Scenario 2: In that same query, fill in 31 nov 2015. You will get 0 caches.
Scenario 3: Edit that same query, just save it. You will get a number >N caches.

How is that an user keyboard issue and not a code in the site issue?

What goes wrong here is:
- data parsing issue that 31 nov 2015 get accepted and UX issue that it doesn't get reported.
- UX issue that a larger period than the previous period does return zero caches.
- UX issue that it suddenly shows up as 31 dec 2030 instead of the expected 31 nov 2015 (or something sane)

Edwin
Please start a new thread. This is current site functionality and has been since the query generator was introduced just over 11 years ago. If you are seeking a change, please open a new thread to discuss the merits of applying that enhancement.

User avatar
Richary
8000 or more caches found
8000 or more caches found
Posts: 4189
Joined: 04 February 04 10:55 pm
Location: Waitara, Sydney

Re: Report Site Issues Here

Post by Richary » 15 March 17 7:17 pm

Seem to be having problems when it tries to connect to the forums using https.
Your connection is not secure

The owner of forum.geocaching.com.au has configured their website improperly. To protect your information from being stolen, Firefox has not connected to this website.
Using Firefox 52.0 (32-bit)

Post Reply