Program to download raw data via API?

[+W4G_SOTAGoat]

Does anyone know if there is a program that will download raw data from the API? I'd like to write a program to massage the data the way I want it (GSAK will not do what I want) to create a GPX to upload to my Garmin. PQ's limited to 1000 caches and every few days won't cut it.

 

Thanks!

[+Walts Hunting]

You can run 5 pq's a day at 1000 each for 5000. The daily limit on the api is 6000. Seems you could accomplish what you wanted that way.

 

I am pretty sure the api is restricted to authorized programs and is not released to the general public.

[+duncanhoyle]

Does anyone know if there is a program that will download raw data from the API? I'd like to write a program to massage the data the way I want it (GSAK will not do what I want) to create a GPX to upload to my Garmin. PQ's limited to 1000 caches and every few days won't cut it.

 

Thanks!

 

Do you mind if I ask what it is you're trying to do? Perhaps there are other utilities available which would help

[AZcachemeister]

I don't think Groundspeak would allow the whole database to be downloaded on a daily basis.

 

I can't imagine what useful 'massaging' GSAK won't do for you, and at 6000 updates using the API, it has the most powerful downloading capacity available.

[+W4G_SOTAGoat]

GSAK will not provide the additional waypoints in the <long_description> field when a GPX file is exported from a database created with an API download. So, when you view a cache on your GPS you don't know if there are any waypoints for parking, trailheads, puzzle multis, etc.

 

It will give you the waypoints in the export if you build the database from a PQ, but if I run multiple PQs I can just send them to my GPS directly.

 

Clyde says that the API doesn't provide that data, so he can't export it. However, the additional waypoints DO show up when you view the long description inside GSAK. So, for the life of me, I can't understand why a GPX export from GSAK doesn't provide that information if it's available when you view the description within GSAK.

[+bflentje]

GSAK will not provide the additional waypoints in the <long_description> field when a GPX file is exported from a database created with an API download. So, when you view a cache on your GPS you don't know if there are any waypoints for parking, trailheads, puzzle multis, etc.

 

It will give you the waypoints in the export if you build the database from a PQ, but if I run multiple PQs I can just send them to my GPS directly.

 

Clyde says that the API doesn't provide that data, so he can't export it. However, the additional waypoints DO show up when you view the long description inside GSAK. So, for the life of me, I can't understand why a GPX export from GSAK doesn't provide that information if it's available when you view the description within GSAK.

 

Even if the information was there (and I don't know), a GPX file is not a flat set of data. A program WOULD need to be written in order to put it in a useful state for you. I am looking to see what Cache Report can do..

[+W4G_SOTAGoat]

GSAK will not provide the additional waypoints in the <long_description> field when a GPX file is exported from a database created with an API download. So, when you view a cache on your GPS you don't know if there are any waypoints for parking, trailheads, puzzle multis, etc.

 

It will give you the waypoints in the export if you build the database from a PQ, but if I run multiple PQs I can just send them to my GPS directly.

 

Clyde says that the API doesn't provide that data, so he can't export it. However, the additional waypoints DO show up when you view the long description inside GSAK. So, for the life of me, I can't understand why a GPX export from GSAK doesn't provide that information if it's available when you view the description within GSAK.

 

Even if the information was there (and I don't know), a GPX file is not a flat set of data. A program WOULD need to be written in order to put it in a useful state for you. I am looking to see what Cache Report can do..

 

I know, it's basically an XML file. The main thing I'm looking to do is take the data from the API and verify whether or not the additional waypoints are passed, and if so what format they're in. Then, massage the API data to create a GPX containing this data in the long_description field. I have years of "real world" programming experience so I don't think it would be too hard to do.

[+duncanhoyle]

GSAK will not provide the additional waypoints in the <long_description> field when a GPX file is exported from a database created with an API download. So, when you view a cache on your GPS you don't know if there are any waypoints for parking, trailheads, puzzle multis, etc.

 

It will give you the waypoints in the export if you build the database from a PQ, but if I run multiple PQs I can just send them to my GPS directly.

 

Clyde says that the API doesn't provide that data, so he can't export it. However, the additional waypoints DO show up when you view the long description inside GSAK. So, for the life of me, I can't understand why a GPX export from GSAK doesn't provide that information if it's available when you view the description within GSAK.

 

That's strange.

I just did a quick test on 2 clean dbs, one with data imported from a zip and one with the same data got using the 'Download pocket queries' option on the Geocaching.com access menu. In each db I filtered to show a cache which I know has a parking waypoint and then exported the GPX file. Doing a Compare on both files gives a perfect match except for the time stamp. Both exported files have an additional waypoint in the Long Description and separate waypoint element in the file.

 

I know that I've modified the GPX export form within one of my macros so perhaps what you're wanting can be achieved by playing with the GPX export dialog.

 

Hope this helps

 

Duncan

[+dakboy]

Why not use GSAK & PQs to get the data, then write your own code & queries to do the massaging? There's nothing special about how GSAK stores its data, it's just a SQLite database and there are SQLite clients/libraries/what have you for every platform, using myriad languages.

[+dfx]

Personally I'd like to see a universal, open-source command-line tool ala gpsbabel (or even just a library from which such a tool could be made) to receive Groundspeak's "blessing" to be allowed to use the API. I would even volunteer to develop and maintain it. But I don't think such a thing would match the "spirit" in which Groundspeak likes to see its API used, so I don't see it happening.

[+NYPaddleCacher]

Personally I'd like to see a universal, open-source command-line tool ala gpsbabel (or even just a library from which such a tool could be made) to receive Groundspeak's "blessing" to be allowed to use the API. I would even volunteer to develop and maintain it. But I don't think such a thing would match the "spirit" in which Groundspeak likes to see its API used, so I don't see it happening.

 

And as Walts Hunting wrote earlier:

 

I am pretty sure the api is restricted to authorized programs and is not released to the general public.

 

I could write a command line tool and/or create a library as well but since I don't have a specific program that could be authorized I can't get access to the API. It would be nice if there was a way for developers that just wanted to kick the tired on the API and see what it was capable of. I have on many instances discovered and API/library that upon further examination conceived a useful application which made use of it. I wouldn't even require access to "real" data behind the API but if I can't see what the API can do unless I already have an "authorized program" it kind of stifles new application development.

[+W4G_SOTAGoat]

That's strange.

I just did a quick test on 2 clean dbs, one with data imported from a zip and one with the same data got using the 'Download pocket queries' option on the Geocaching.com access menu. In each db I filtered to show a cache which I know has a parking waypoint and then exported the GPX file. Doing a Compare on both files gives a perfect match except for the time stamp. Both exported files have an additional waypoint in the Long Description and separate waypoint element in the file.

 

 

Did you populate one of the databases from the API download function? I didn't use the "download PQs" option, but the "Get Geocaches" option.

[+duncanhoyle]

That's strange.

I just did a quick test on 2 clean dbs, one with data imported from a zip and one with the same data got using the 'Download pocket queries' option on the Geocaching.com access menu. In each db I filtered to show a cache which I know has a parking waypoint and then exported the GPX file. Doing a Compare on both files gives a perfect match except for the time stamp. Both exported files have an additional waypoint in the Long Description and separate waypoint element in the file.

 

 

Did you populate one of the databases from the API download function? I didn't use the "download PQs" option, but the "Get Geocaches" option.

 

Sorry, I used the 'download PQs' option rather than the 'Get Geocaches' one. A quick test this morning showed the behaviour that you report - the Long Description doesn't include the text at the end even when there are child waypoints in the DB.

 

It would appear to be a fault with the api and something that should be brought up on their support forum.

 

In the meantime, it should be possible to write a GSAK macro that scans through the whole db to find caches where the child waypoints are > 0 and there are no child waypoints mentioned in the long description. If caches are found where this is the case then it should be possible for the macro to change the long description. A quck look through the macros shows one called ChildrenToHTML which almost does the opposite and scans for caches where there are children mentioned in the long description but no actual children in the db. It should be possible to reverse this. (there may already be such a macro or something simliar in existence but I didn't have time for a thorough look)

[AZcachemeister]

Since the content of the description nor the presence of child waypoints are particularly volatile, you could populate your database with PQs via the 'regular' (download) method, and then maintain it with the 'Refresh Cache Data' function.

Then, you would only need one PQ daily to keep up with new publications.

[+W4G_SOTAGoat]

 

Did you populate one of the databases from the API download function? I didn't use the "download PQs" option, but the "Get Geocaches" option.

 

Sorry, I used the 'download PQs' option rather than the 'Get Geocaches' one. A quick test this morning showed the behaviour that you report - the Long Description doesn't include the text at the end even when there are child waypoints in the DB.

 

Did you notice that the waypoints appear when you view the cache description within GSAK? That's why I'm confused. Why don't they show up on an export when they show up in the description displayed in GSAK?

 

Here is a link to the discussion that was going on over on the GSAK board. I never really got a straight answer as to why they are displayed in the description but not exported to the GPX file.

 

http://gsak.net/board/index.php?showtopic=20406