Finding All The Caches In My State

[+ScoutingWV]

I'm wanting to generate a list of all the caches in WV for a project I'm working on.

 

When I use the "Hide and Seek a Cache" link and search only by state, I get a list of 706 items returned. If I use the same feature and choose to search by the area code (WV only has one - 304) I get a list of 1929 items returned and they are in multiple states.

 

I think that when listing a cache only the state is chosen, not the area code. Could the area codes not be correctly associated within the database?

 

And yes I'm a premium member and I know how to use PQs. However, I believe they still search the same database. Anyone know why this would happen and/or a better way to get the right results? Should I do this through multiple PQs instead?

 

<edit: spelling>

Edited February 6, 2006 by ScoutingWV

[+altosaxplayer]

Not sure if I can help you here. Sounds like the state boundaries provided by GC.com are different than what the zip code search thinks they are.

[+tozainamboku]

Search by zip code is really a nearest to search. GC uses a post office database to find the coordinates for the zip code. This has been discussed in several threads example My guess is that area codes are done similarly.

Edited February 6, 2006 by tozainamboku

[+Stunod]

The area code search (like zip-code) simply returns the caches within 100 miles of the "center" of the area code. Click the >> on the page index at the top of your results page and look at the last cache listed. It will be listed as (about) 100 miles away.

Edited February 6, 2006 by Stunod

[+sbell111]

The bloody chicken is pretty smart. You need to bound the results by selecting caches only in WV.

 

Probably, what I would do is run two PQs. One would use a zip at the western-most edge of the state. The other would use a zip at the eastern-most edge. Set both PQs to only return caches in WV. Dump the results of both PQs into GSAK to combine them and get rid of the duplicates. Finally, export it to whatever format you want.

[+WeightMan]

Actually, if you just select the state in the PQ and then select dates in that section, you should be able to make sure you get them all in just a few PQs. I have WA done that way, but that takes 14 PQs. If there are just over 700 caches in WV, then two PQs will do the whole state and you don't have to mess with coordinates.

[Keystone]

WeightMan describes the method that I always recommend for splitting up a state into multiple PQ's. As the cache reviewer for West Virginia, I just happen to have those PQ's set up already. If you run one pocket query for all active (not disabled) caches in West Virginia, a cutoff date of June 30, 2005 will return 498 caches in your query results. If you're also interested in disabled caches, ratchet the first query back to early June. There are only 17 disabled caches in all of West Virginia the last time I checked.

 

I know the special project you are working on. Using pocket queries and projecting the caches onto a certain mapped background is the way to go. I can hook you up with some technical experts if needed. Drop me an e-mail.

[+The Blue Quasar]

Definitely PQ's by Date is the best solution.

 

My friend tried the alternative of overlapping circles to cover the entire Province... it's messy. Often the number of caches inside the circle exceeds 500, and he has to adjust the parameters of the circle.

 

For the Date method... the number of caches only (well, usually) only ever decreases... All I ever need to do is tweak the dates to compensate for Archived caches....

 

I cover all of Ontario in just 9 PQ's... takes my buddy 18 to do the same.

 

But the one advantage is that if someone doesn't list the STATE/PROVINCE of placement... the Date method misses it.

 

The Blue Quasar

[+sbell111]

I agree that PQs by date are the best option for large states, WV, however, only has 700 caches. With this small amount, it appeared easier to do it by zip. That way you didn't have to tweak the dates to find the break point. Of course, since Keystone already did that work for you, it doesn't really matter which method you use.

[+ScoutingWV]

Good stuff, folks. Thanks everyone for the help!

 

I tried it with two PQs and it looks like this will be able to get just what I need, maybe only need to add one more. I had not considered using the date ranges to search. Interesting, though, that the zip code and area code searches still use a radial search method.

 

Ahhhhh, Keystone. It's only the beginning ... a simple test for something more sinister!!

 

I think I have what I need, but I'll leave the post open for a few days in case anyone has any additional suggestions that could benefit someone else.

[+Markwell]

Interesting, though, that the zip code and area code searches still use a radial search method.

 

Remember that the system only considers a zip code to be a point, not a region. The location of the zip code 60544 is here, but the zip code region is this (well it was before it split into 3 zip codes last year).

[+ScoutingWV]

WOO HOO!

 

Now I can log MFM (My First Markwell) !!!

 

I didn't know the zip was considered a point. I like learning new stuff...

[+ScoutingWV]

I can hook you up with some technical experts if needed.

 

Thanks very much for your offer. From my own background and some folks at my office, I think we 've pretty much got it under control. I also had some good suggestions from one of our more prominent geocachers on the project you referenced.

 

Can't wait to get it going!