Jump to content

Pocket Query Limit


Plasma Boy

Recommended Posts

Did a search and did not find an answer. If this has been answered, just point me to the forum.

 

Why is the number of pocket queries that you can hold on your account limited to 40. These queries do not take up that much space. Performing the query requires time and resources, but storing them can not require that much space.

Link to comment

It's an evil plot by "the Man" to keep us down. :rolleyes:

40 PQs is a lot but there really isn't a valid reason why GS couldn't offer more. I can see the need to minimize how many are run in a day but, as stated, the query itself doesn't take much space. Not any more space than a small text file.

Edited by bittsen
Link to comment

My previous post wasn't clear. I don't want to be able to download more than 2500 caches per day, 17,500 per week or however you want to look at it. I would just like the ability to save more than 39 PQ setup files (for lack of a better word). 39 because 1 is used for the My Finds file.

 

I have no need for 17,500+ caches per week and download FAR less than what is currently available to me, usually grabbing around 2500 caches per WEEK at the most. If the number were raised and we had the ability to create 100 PQ setup files, I'd still only download 2500 caches per week. I just wouldn't have to delete some of them to create a new one in a different area.

 

Editing to add that buying a second membership wouldn't help because there's no way to filter out caches found by the first account. The second account would use up all the available PQ slots downloading caches found by the first account unless the second account went through and marked all the caches found that the first account had found. That would be a pain, and cache owners probably wouldn't like it.

Edited by Skippermark
Link to comment

My previous post wasn't clear. I don't want to be able to download more than 2500 caches per day, 17,500 per week or however you want to look at it. I would just like the ability to save more than 39 PQ setup files (for lack of a better word). 39 because 1 is used for the My Finds file.

 

I have no need for 17,500+ caches per week and download FAR less than what is currently available to me, usually grabbing around 2500 caches per WEEK at the most. If the number were raised and we had the ability to create 100 PQ setup files, I'd still only download 2500 caches per week. I just wouldn't have to delete some of them to create a new one in a different area.

 

Editing to add that buying a second membership wouldn't help because there's no way to filter out caches found by the first account. The second account would use up all the available PQ slots downloading caches found by the first account unless the second account went through and marked all the caches found that the first account had found. That would be a pain, and cache owners probably wouldn't like it.

The easiest workaround for that is to use the second account for 'traveling' PQs. Another is to use the second accounts 'ignore' feature on all found caches and filter those out of its PQs. Edited by sbell111
Link to comment

My previous post wasn't clear. I don't want to be able to download more than 2500 caches per day, 17,500 per week or however you want to look at it. I would just like the ability to save more than 39 PQ setup files (for lack of a better word). 39 because 1 is used for the My Finds file.

 

I have no need for 17,500+ caches per week and download FAR less than what is currently available to me, usually grabbing around 2500 caches per WEEK at the most. If the number were raised and we had the ability to create 100 PQ setup files, I'd still only download 2500 caches per week. I just wouldn't have to delete some of them to create a new one in a different area.

 

Editing to add that buying a second membership wouldn't help because there's no way to filter out caches found by the first account. The second account would use up all the available PQ slots downloading caches found by the first account unless the second account went through and marked all the caches found that the first account had found. That would be a pain, and cache owners probably wouldn't like it.

The easiest workaround for that is to use the second account for 'traveling' PQs. Another is to use the second accounts 'ignore' feature on all found caches and filter those out of its PQs.

 

Any idea how long it would take to ignore 2300 finds? Not to mention if the Ignore feature supports that many.

Link to comment

My previous post wasn't clear. I don't want to be able to download more than 2500 caches per day, 17,500 per week or however you want to look at it. I would just like the ability to save more than 39 PQ setup files (for lack of a better word). 39 because 1 is used for the My Finds file.

 

I have no need for 17,500+ caches per week and download FAR less than what is currently available to me, usually grabbing around 2500 caches per WEEK at the most. If the number were raised and we had the ability to create 100 PQ setup files, I'd still only download 2500 caches per week. I just wouldn't have to delete some of them to create a new one in a different area.

 

Editing to add that buying a second membership wouldn't help because there's no way to filter out caches found by the first account. The second account would use up all the available PQ slots downloading caches found by the first account unless the second account went through and marked all the caches found that the first account had found. That would be a pain, and cache owners probably wouldn't like it.

The easiest workaround for that is to use the second account for 'traveling' PQs. Another is to use the second accounts 'ignore' feature on all found caches and filter those out of its PQs.

 

Any idea how long it would take to ignore 2300 finds? Not to mention if the Ignore feature supports that many.

Since you have your PQs ordered by 'date placed' AND many of those old finds are archived, you need not ignore all found caches. Remember also that it's not important the you block all found caches from appearing in a PQ because you can still easily factor them out on the GSAK side.
Link to comment
Since you have your PQs ordered by 'date placed' AND many of those old finds are archived, you need not ignore all found caches. Remember also that it's not important the you block all found caches from appearing in a PQ because you can still easily factor them out on the GSAK side.

If the PQs you're planning on running are in the same area as caches you've already found (which most of the ones I want to run are), and you've found a lot of caches in those areas, you'd have to filter them out on the server side.

Link to comment
Since you have your PQs ordered by 'date placed' AND many of those old finds are archived, you need not ignore all found caches. Remember also that it's not important the you block all found caches from appearing in a PQ because you can still easily factor them out on the GSAK side.

If the PQs you're planning on running are in the same area as caches you've already found (which most of the ones I want to run are), and you've found a lot of caches in those areas, you'd have to filter them out on the server side.

You are not fully reading my posts.

Link to comment
You are not fully reading my posts.

I re-read your post and had misunderstood what you are saying. I wasn't thinking about all the caches that have been archived, which is a large chunk.

 

I did some scouting around and found a great form addon for Firefox that will pretty much do what I want. Basically, it just saves the options that you want to have in the form. Then, if you need to delete some PQs to create another one, no big deal. You just have the form addon automatically fill in the form info for the area where you want to cache and then save it.

 

You're still limited to 40, which is okay because you can delete them and create others when you need to.

 

The inanity of the "limit" of 40 is made more obvious by the fact that they are still on the server, just not readily available unless you have saved the URL.

I've tried saving the URL and pasting it in, but it never works. I remember a previous thread about it where it worked for some but for most it didn't.

Link to comment

But apart from some useful and other not so useful workarounds, what about the original question?

 

Did a search and did not find an answer. If this has been answered, just point me to the forum.

 

Why is the number of pocket queries that you can hold on your account limited to 40. These queries do not take up that much space. Performing the query requires time and resources, but storing them can not require that much space.

 

I don't see the point of limiting saved queries to 40 (39). Like the OP states, I also assume it's not because of server load or space, as the number of stored PQ's (=set of PQ settings on the server) hardly affect server load in any way. And as there ARE workarounds to easily delete/recreate PQ's, I don't see why we couldn't just keep the old ones. It's not that we would run more queries or get more data because of this, it's just more convenient for people who regularly cache in different areas and need a bunch of PQ's for each area when they go there (even if it's just a once or twice a year thing.. why the need to recreate the PQ's each time?).

 

But if we really need to stick to the 39 active queries limit, I would suggest an "unarchive PQ" feature: As pocket queries settings are actually not deleted but "archived", it should be easy to create a way to "unarchive" them. They are in any case still there and their results can still be viewed online if we have the link, just not sent as email PQ. If I go into the settings of an archived (deleted) query and save it again, it looks if it would restore it, but actually it doesn't. Basically, doing so would allow to keep the number of active queries to 39, but allow to restore a former pocket query (=set of PQ settings) without creating a new set of settings each time and hence avoid creating a load of redundant and thus useless datasets on the server.

 

This would also be useful if the "Delete this query" button at the bottom of the form is pressed by mistake instead of the submit button... happened to me more than once. Why is the DELETE button actually on the right side, on most other forms on the site (logs etc.) the SUBMIT button is there... And why why why is there no confirmation on deleting a pocket query, as for deleting a log etc.?

Edited by luzian
Link to comment

But apart from some useful and other not so useful workarounds, what about the original question?

 

Did a search and did not find an answer. If this has been answered, just point me to the forum.

 

Why is the number of pocket queries that you can hold on your account limited to 40. These queries do not take up that much space. Performing the query requires time and resources, but storing them can not require that much space.

Because if the limit were 50 some chucklehead would still claim that he 'needs' more.

 

There had to be some limit. 40 is a whole lot of queries and most of us should find the number to be adequate. The that don't are welcome to use one of the workarounds.

Link to comment

40 PQs are still a honking lot.

 

Luckily, if someone 'needed' more, they could simply buy an extra membership.

 

Question. Do charter members pay a membership fee?

Yes, but the fact that we don't have that 20 minute delay on getting Instant Notifications that regular members have makes up for it.

 

Uh, never mind. Wasn't supposed to talk about that to non-Charters.

Link to comment

we recently did a caching tour of scotland and the lake district and many caches in between building the pqs was a nightmare as we didnt know which caches we would be doing and with limited web access in the highlands we wanted a offline database . maybe we could have done along a route but that would have limited us so in the end we ran 35 pqs . if only we could download all uk caches in one go this would save building pqs and stress on the server

Link to comment

I think having the limit to the 35 PQ's run per week is okay. But it would be nice to be able to save more PQ's in our list. An even 100 would be nice :huh:

 

Alot of power trails have there own PQ's already created that we can all add to our list vs having a PQ for the whole area around the trail. This adds to the list qty for future possible caching weekend runs, yet, may not be used in the immediate time frame. So while it sits there, it takes up one of the 40.

 

Alot of us pre-plan our cache runs, upwards of weeks / months ahead, so having a larger limit would be beneficial for storing them.

Link to comment

More pocket queries is the only answer to the inane 500 cache limit. 40 PQs and the 500 limit might have been adequate in the early years of geocaching but since the huge gain in popularity they are a hindrance. Raising the cache limit to 1000 or even 2500 will not affect database performance and would ease the need for 40+ PQs.

Link to comment

More pocket queries is the only answer to the inane 500 cache limit. 40 PQs and the 500 limit might have been adequate in the early years of geocaching but since the huge gain in popularity they are a hindrance. Raising the cache limit to 1000 or even 2500 will not affect database performance and would ease the need for 40+ PQs.

 

What possible need is there to PQ 2500 caches? Even the claimed record number of finds claimed for one day is less than the limit of 500 caches. So much easier to just run a fresh PQ when you are ready to go.

 

Bookmark those power trails you want to chase down. Then when you are ready you can zip of a run and head for the area.

Link to comment

More pocket queries is the only answer to the inane 500 cache limit. 40 PQs and the 500 limit might have been adequate in the early years of geocaching but since the huge gain in popularity they are a hindrance. Raising the cache limit to 1000 or even 2500 will not affect database performance and would ease the need for 40+ PQs.

 

What possible need is there to PQ 2500 caches? Even the claimed record number of finds claimed for one day is less than the limit of 500 caches. So much easier to just run a fresh PQ when you are ready to go.

 

Bookmark those power trails you want to chase down. Then when you are ready you can zip of a run and head for the area.

 

I don't see the relevance of your link between my need of a greater PQ limit and the number of caches found in a day. It's all about maintaining an offline database and geocaching the way I want to.

Link to comment

As CheesePizza says, it is all about database management. I use GSAK to manage my cache data. It is a very high powered extremely useful database management tool. The authors and contributors are to be commended.

 

I have a set of base PQs for NS, another for PEI, another for NL and another for NB. I also have a set of last 7 day PQs that I access every week. The base ones I only access when I need to rebuild my database, so are not used often, but to rebuild them and recalculate the dates would be a pain in the a**. I also request PQs for areas that I will travel to in the future, like NWT, Yukon and California.

 

If these PQs sitting in my account took up a lot of storage space or a lot of cpu time on the GC servers then I could see the limit of 40, but until a PQ is requested, it takes up very little storage space and no cpu time. 100 PQs sitting in my account would most likely take up less than 100 K of storage space.

 

There are lots of features on the Premier Membership, that I have no use for, but just because I do not need them, I do not speak against the wants of other cachers. I do not have an Iphone, so I don't need that one. I do not cache along a route, so that one is useless to me. I only ever watchlist ~10 caches, so unlimited watchlists is not needed. I could live without the MAP IT feature and I really do not need to be notified about new caches ahead of the non PMs. I am not really into commando FTFs.

 

The one feature that I use a lot and think needs improving are the PQ limits. Yes, it would be even more handy if the PQs could be larger, but that is not an issue for me, but if other paying clients wanted it, I would not object.

 

If you do not need or want more PQs, it will not affect you if others want and or need more. Just like if someone wants to watchlist 1000 caches, I could care less.

Link to comment

finally ... finally ... we come to what i really really have been watching for. "offline database management" ... which is EXCACTLY the way i like to geocache. GPS is loaded ... grab the keys to the jeep and hit the road for where ever the wind takes us.

 

and with the option of an offline data base and unlimited PQs ... we can simply do a quick update of whatever direction we have chosen ... and head out in that area.

 

as for the cachers who mention caching in the UK ... wouldn't it be nice to do a PQ on an entire country or province ... WOW. now there's a GREAT idea!!

IMAGINE THE SCENARIO:

mr canuck ... we need you to hop on the plane for manitoba.

no problem mr boss, let me send this PQ for the entire province of manitoba so when i land i can simply dump it into my GPS and go geocaching along the way to that important meeting. WOW!

 

geocaching is growing ... and Groundspeak needs to grab the REAL bull by the horns and provide us with inovative ideas ... what WE need!!! like access to manageable offline database sources!!!

 

*steps off his box*

thank you

Edited by canuck thistles
Link to comment
no problem mr boss, let me send this PQ for the entire province of manitoba so when i land i can simply dump it into my GPS and go geocaching along the way to that important meetingdiscover that the GPX file has several times more caches than my unit can handle, thus causing it to lock up until I can get to a PC. WOW!

Fixed that for you. Wow, indeed.

Link to comment

More pocket queries is the only answer to the inane 500 cache limit. 40 PQs and the 500 limit might have been adequate in the early years of geocaching but since the huge gain in popularity they are a hindrance. Raising the cache limit to 1000 or even 2500 will not affect database performance and would ease the need for 40+ PQs.

 

What possible need is there to PQ 2500 caches? Even the claimed record number of finds claimed for one day is less than the limit of 500 caches. So much easier to just run a fresh PQ when you are ready to go.

 

Bookmark those power trails you want to chase down. Then when you are ready you can zip of a run and head for the area.

 

I don't see the relevance of your link between my need of a greater PQ limit and the number of caches found in a day. It's all about maintaining an offline database and geocaching the way I want to.

 

That is my question. What is the need or usefulness of your offline database? It is more efficient to pick the area you are headed to and run a fresh PQ without all the work to clean the data in an attempt to ensure it is up to date. You can't find more than 500 caches in a day anyways. Even if you could you get 5 PQs to do it in. I honestly do not understand why anyone would want to keep a large database full of outdated information.

Link to comment

If these PQs sitting in my account took up a lot of storage space or a lot of cpu time on the GC servers then I could see the limit of 40, but until a PQ is requested, it takes up very little storage space and no cpu time. 100 PQs sitting in my account would most likely take up less than 100 K of storage space.

 

 

To get back on topic (which is not about how many PQs you can run or how many caches they provide, but how many PQs you can save at one time...)

 

Not only do PQs take up little space, after you delete (archive) them, they remain on the server. So there would be no added space used by allowing us to be able to easily access 100 or more PQs.

Edited by beejay&esskay
Link to comment

That is my question. What is the need or usefulness of your offline database? It is more efficient to pick the area you are headed to and run a fresh PQ without all the work to clean the data in an attempt to ensure it is up to date. You can't find more than 500 caches in a day anyways. Even if you could you get 5 PQs to do it in. I honestly do not understand why anyone would want to keep a large database full of outdated information.

 

I don't understand why your insistent on raising irrelevant points about number of caches found in a day...it has no bearing on the want to keep an offline database, which is the point of the thread. The answer to your question is simple: It allows me to geocache the I way want to!

Edited by cheesepizza
Link to comment

That is my question. What is the need or usefulness of your offline database? It is more efficient to pick the area you are headed to and run a fresh PQ without all the work to clean the data in an attempt to ensure it is up to date. You can't find more than 500 caches in a day anyways. Even if you could you get 5 PQs to do it in. I honestly do not understand why anyone would want to keep a large database full of outdated information.

 

I don't understand why your insistent on raising irrelevant points about number of caches found in a day...it has no bearing on the want to keep an offline database, which is the point of the thread. The answer to your question is simple: It allows me to geocache the I way want to!

 

Well then, the simple answer is that this is the way that Groundspeak wants to run their business. Sorry.

Link to comment

But GOF gave the correct answer to the OP and to the topic of offline databases.

 

Creating and maintaining offline databases is not supported by Groundspeak and is not the purpose of Pocket Queries ... whether "that's how you want to cache" or not.

 

So requesting a feature change based upon that rationale isn't going to elicit a change from Groundspeak.

Link to comment

But GOF gave the correct answer to the OP and to the topic of offline databases.

 

Creating and maintaining offline databases is not supported by Groundspeak and is not the purpose of Pocket Queries ... whether "that's how you want to cache" or not.

 

So requesting a feature change based upon that rationale isn't going to elicit a change from Groundspeak.

 

I beg to differ. Groundspeak has a page devoted to advertising third party software packages (such as GSAK, Cachemate and others) that make offline databases possible. Offline databases, lower the need for cachers to constantly download PQs. I would imagine that these software packages make caching more enjoyable and I would say that they are part and parcel responsible for geocachings popularity. Without third party software packages, geocaching would be very difficult to manage. GC.com does not supply it's members with a database management tool of their own. They rely on the third party software packages to manage their PQs.

 

The OP's (me) original question was asking why there can not be more PQs stored in our accounts. Offline DBs are a result of pocket queries. Having a higher limit will just make the administration easier for both the cacher and will reduce bandwidth load on GC servers.

Link to comment
Creating and maintaining offline databases is not supported by Groundspeak and is not the purpose of Pocket Queries

This is the current stance of Groundspeak. Saying that you "beg to differ" and that they provide links to useful tools including a waypoint management tool doesn't mean that Groundspeak supports offline databases.

Link to comment
Creating and maintaining offline databases is not supported by Groundspeak and is not the purpose of Pocket Queries

This is the current stance of Groundspeak. Saying that you "beg to differ" and that they provide links to useful tools including a waypoint management tool doesn't mean that Groundspeak supports offline databases.

 

From the pocket query page

Pocket Queries are custom geocache queries you can have emailed to you on a daily or weekly basis. They are in a format you can bring along with you on cache hunts on your GPS and/or PDA. You can select a GPX or LOC text file that works with supported software applications.

 

AND from the PM features page

The Pocket Query Generator allows you to create custom geocache queries and have them emailed to you on a daily or weekly basis. You can also run these queries on the "seek a cache" page as a customized search query. Check the supported software applications page for updates on existing and new software that can take advantage of Pocket Queries.

 

Both of these refer you to third party software that are used on GPSrs and PDAs. PDAs use these third party software packages as database managers. Importing PQs into a database manager whether it be on a GPSr, PDA, laptop or desktop is exactly what they are used for.

 

What other reason would anyone want this data? You put it into a DB and sort and query it as a subset of the larger GC database.

Link to comment
Creating and maintaining offline databases is not supported by Groundspeak and is not the purpose of Pocket Queries

This is the current stance of Groundspeak. Saying that you "beg to differ" and that they provide links to useful tools including a waypoint management tool doesn't mean that Groundspeak supports offline databases.

I don't believe that it is the current stance of Groundspeak. Offline databases are clearly anticipated by pocket queries. What Groundspeak doesn't support is the maintenance of large offline database that replicates a significant portion of the online data. What is significant is not spelled out but one can make the assumption that having several thousand local caches in an offline database for planing geocaching days and being able to load your GPS without going online is well within the legitimate uses for Pocket Queries. The limits on the number of pocket queries you can run along with the fact that archived caches aren't returned essentially enforces a limit on how big your offline database can get. To find which caches have been archived you essentially have to download all caches in your pocket queries and see which ones didn't get updated. The offline database is really only useful for keeping more that the last five logs and having a way to add notes and corrected coordinates for puzzles. So long as you update it every week or so, you have relatively recent data should you be unable to get updated pocket queries from Geocaching.com in a timely manner. Once you go outside your closest 5000 or 10000 caches (or the caches you are most likely to hunt), then it becomes more reasonable to use fresh data from a new pocket query. It seems the effort to maintain larger offline databases gives you diminishing returns for the effort involved.

 

The OP request is not to maintain a larger offline database but instead to have more saved Pocket Queries. I think this is a good idea. If there are locations you visit a few times a year, you don't need to keep the most up to date data for them. You can have your notes and corrected coordinates for puzzles you solved and then when you know you are going to visit that area you can get the latest data, merge that with your offline data, delete the caches which didn't get updated in the PQ (because these are archived and be ready to go. The more saved PQ you can have the more of these areas can be setup and for many people that can mean a smaller area to keep up to date for spur of the moment geocaching. I am opposed to suggestions meant to allow for larger offline database. I am for suggestions that make it easier to setup and run pocket queries for outlying areas that reduce the need for larger offline database and may even let me shrink the areas I update weekly.

Link to comment

My apologies to Plasma Boy for somewhat hijacking his thread. In my view more PQs and greater cache limit aren't mutually exclusive. In response to the OP, I agree that more PQs would allow for efficient targeting of specific geocaching areas with more up to date data....and therefore would be a good thing. There's a BUT in here......but I'll let it go.

Edited by cheesepizza
Link to comment

and with the option of an offline data base and unlimited PQs ... we can simply do a quick update of whatever direction we have chosen ... and head out in that area.

 

But you STILL have to do the "quick update of whatever direction" you have chosen... otherwise you might be chasing a cache that was archived after your last database update.

 

So if you need to do an update every time you head out, what's the point of keeping all that data offline? I use GSAK and I love it, but I'm happy to let Groundspeak maintain the active database. I only need current data for the area where I'm about to go hunting.

 

I'm not saying GS should NOT provide more pocket queries; I'm just saying I still don't see what purpose they would serve.

Link to comment

and with the option of an offline data base and unlimited PQs ... we can simply do a quick update of whatever direction we have chosen ... and head out in that area.

 

But you STILL have to do the "quick update of whatever direction" you have chosen... otherwise you might be chasing a cache that was archived after your last database update.

 

So if you need to do an update every time you head out, what's the point of keeping all that data offline? I use GSAK and I love it, but I'm happy to let Groundspeak maintain the active database. I only need current data for the area where I'm about to go hunting.

 

I'm not saying GS should NOT provide more pocket queries; I'm just saying I still don't see what purpose they would serve.

How about planning for that caching trip? Knowing what's there (somewhat, things change of course) helps me figure out where I might be looking at. Also, having more than the last 5 logs is very helpful at times.

 

BTW, every PQ is an "offline database" as soon as it's sent. Whether it's sent straight to a GPSr, a PDA or GSAK, it's no longer 'live' data, but a stale, offline database.

Link to comment

Both of these refer you to third party software that are used on GPSrs and PDAs. PDAs use these third party software packages as database managers. Importing PQs into a database manager whether it be on a GPSr, PDA, laptop or desktop is exactly what they are used for.

 

What other reason would anyone want this data? You put it into a DB and sort and query it as a subset of the larger GC database.

Seriously? How about...

  • Changing the icon to represent the cache type
  • Replacing solved puzzle coordinates with the actual cache location
  • Changing the waypoint ID to include the Difficulty and Terrain ratings
  • Merging multiple GPX files into a single file
  • Putting hints in the description section, or creating a hint POI file
  • Filter out caches that the PQ generator couldn't.

All of these useful things can be done with the PQs, without adding them to a persistent database.

 

Need more? I'm sure others can chime in.

Edited by Prime Suspect
Link to comment

The main thrust of my post was not to get more PQs so that I could build an enormous offline data base. That is how I use the PQ data. I put a base set for my area in GSAK and then use a series of last 7 days PQs to update that so that at any given time I can run a query on the GSAK DB and output a series of caches I am interested at that time.

 

The thrust of my post was why can I only store 39 small text forms on the GC server? These file take up little or no space. Most of them serve as archival backup, so that if I need to recreate my GSAK data base, I do not need to recalculate all of the date brackets.

 

To date I have 14 base PQs for NS, Newfoundland is 5 PQs, PEI is 8, New Brunswick is 10 or so. So, my archival backups are already near my limit.

 

I do a 7 day set for NS which is 11. These are my active PQs. The rest are backups, but they eat up my 39. In fact I had to delete some, because they are over 39.

 

The question is would having more PQs available to cachers who want them hurt you as a cacher? If you do not want them don't use them. Just like I do not use watchlists that much. Would it be a hardship on the GC servers to store more than 39 PQs per cacher. I really do not see that

 

At the moment there are 950,000 cachers (not sure how many are PM). If they all stored 39 PQs @ 50 KB , that would be ~2 terrabytes. About 500 bucks.

Link to comment

BTW, every PQ is an "offline database" as soon as it's sent. Whether it's sent straight to a GPSr, a PDA or GSAK, it's no longer 'live' data, but a stale, offline database.

 

Perhaps, but it is not meant to be maintained. It is meant to be used and discarded.

Says who?

Edited by Plasma Boy
Link to comment

BTW, every PQ is an "offline database" as soon as it's sent. Whether it's sent straight to a GPSr, a PDA or GSAK, it's no longer 'live' data, but a stale, offline database.

 

Perhaps, but it is not meant to be maintained. It is meant to be used and discarded.

Says who?

Groundspeak

Show me where it says that on the webpage.

Link to comment

BTW, every PQ is an "offline database" as soon as it's sent. Whether it's sent straight to a GPSr, a PDA or GSAK, it's no longer 'live' data, but a stale, offline database.

 

Perhaps, but it is not meant to be maintained. It is meant to be used and discarded.

Says who?

Groundspeak

Show me where it says that on the webpage.

 

Tell you what, why don't you just ask them. Contact@geocaching.com

 

Everything that TPTB have ever said on the subject has been of the opinion that they will not support off line databases. People keep telling you the same thing. Repeatedly. Yet you choose to think that we are all lying to you. Email Jeremy Irish and ask him.

 

Things may change in the future but I highly doubt it.

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...