Report Site Issues Here
Re: Report Site Issues Here
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
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
Re: Report Site Issues Here
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
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
- caughtatwork
- Posts: 17024
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Report Site Issues Here
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.
- caughtatwork
- Posts: 17024
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Report Site Issues Here
Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.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
- caughtatwork
- Posts: 17024
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Report Site Issues Here
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.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
http://geocaching.com.au/api/services/
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.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.
Re: Report Site Issues Here
Users don't enter an invalid date on purpose.caughtatwork wrote:Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.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
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
Re: Report Site Issues Here
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.".caughtatwork wrote: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.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
http://geocaching.com.au/api/services/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.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.
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
- Chwiliwr
- 10000 or more caches found
- Posts: 900
- Joined: 10 April 05 10:39 pm
- Location: Leeming Western Australia
Re: Report Site Issues Here
'end user experience' is up to the source program not the data source.MavEtJu wrote:Users don't enter an invalid date on purpose.caughtatwork wrote:Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.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
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
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.
Re: Report Site Issues Here
The 'program' I refer to is the query generator as you can find at http://geocaching.com.au/my/query/.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.
Edwin
- Chwiliwr
- 10000 or more caches found
- Posts: 900
- Joined: 10 April 05 10:39 pm
- Location: Leeming Western Australia
Re: Report Site Issues Here
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.MavEtJu wrote:The 'program' I refer to is the query generator as you can find at http://geocaching.com.au/my/query/.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.
Edwin
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.
Re: Report Site Issues Here
Scenario 1: Fill in a log between time of 1 jan 2015 till 31 oct 2015. You will get N caches.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 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
- caughtatwork
- Posts: 17024
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Report Site Issues Here
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.MavEtJu wrote:Users don't enter an invalid date on purpose.caughtatwork wrote:Essentially if you make a bad date you live with the consequence. I can't see us validating this information any time soon.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
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
- caughtatwork
- Posts: 17024
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Report Site Issues Here
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:MavEtJu wrote: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.".caughtatwork wrote: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.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
http://geocaching.com.au/api/services/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.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.
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
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.
- caughtatwork
- Posts: 17024
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Report Site Issues Here
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.MavEtJu wrote:Scenario 1: Fill in a log between time of 1 jan 2015 till 31 oct 2015. You will get N caches.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 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
- Richary
- 8000 or more caches found
- Posts: 4189
- Joined: 04 February 04 10:55 pm
- Location: Waitara, Sydney
Re: Report Site Issues Here
Seem to be having problems when it tries to connect to the forums using https.
Using Firefox 52.0 (32-bit)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.