I Have 3 Requests.

[+simpjkee]

1. I would a fourth feature along with size, terrain, and difficulty, adressing the ligthing around the cache and if it is accessible at night. I have more caching time at night than during the day and there is nothing worse than going to a cache and finding out that the park is closed, etc.

 

2. I would like to be able to search by zip code and only recieve geocaches in that zip code only. I geocache by paper and it would be soooooo helpful to be able to "clear" the caches in a zip code and then move to the next zip code, but as far as I can tell when you search by zip code you get an endless number of caches with the first in the list being the closest to the zip code.

 

3. I would like to be able to take my "found" caches off the search map. I can remove the found caches from the list search, but on the map they show up as number balloon and a smiley face on it. I would much much much rather they not show up at all.

[+Theseus]

1. I would a fourth feature along with size, terrain, and difficulty, adressing the ligthing around the cache and if it is accessible at night. I have more caching time at night than during the day and there is nothing worse than going to a cache and finding out that the park is closed, etc.

 

2. I would like to be able to search by zip code and only recieve geocaches in that zip code only. I geocache by paper and it would be soooooo helpful to be able to "clear" the caches in a zip code and then move to the next zip code, but as far as I can tell when you search by zip code you get an endless number of caches with the first in the list being the closest to the zip code.

 

3. I would like to be able to take my "found" caches off the search map. I can remove the found caches from the list search, but on the map they show up as number balloon and a smiley face on it. I would much much much rather they not show up at all.

 

1. If used properly, cache attributes would accomplish this. Tough to rely on them, though.

 

2. An easy workaround is to shorten the mileage in the search. For example, search on your zip but limit the radius to five miles (or whatever is the appropriate distance).

 

3. I agree with this request. The old maps could accommodate this but the new ones do not, to the best of my knowledge.

[+normandcat]

1. I would a fourth feature along with size, terrain, and difficulty, adressing the ligthing around the cache and if it is accessible at night. I have more caching time at night than during the day and there is nothing worse than going to a cache and finding out that the park is closed, etc.

 

2. I would like to be able to search by zip code and only recieve geocaches in that zip code only. I geocache by paper and it would be soooooo helpful to be able to "clear" the caches in a zip code and then move to the next zip code, but as far as I can tell when you search by zip code you get an endless number of caches with the first in the list being the closest to the zip code.

 

3. I would like to be able to take my "found" caches off the search map. I can remove the found caches from the list search, but on the map they show up as number balloon and a smiley face on it. I would much much much rather they not show up at all.

 

1. If used properly, cache attributes would accomplish this. Tough to rely on them, though.

 

2. An easy workaround is to shorten the mileage in the search. For example, search on your zip but limit the radius to five miles (or whatever is the appropriate distance).

 

3. I agree with this request. The old maps could accommodate this but the new ones do not, to the best of my knowledge.

 

2 - Although mostly correct. Because of the odd shapes of some zip codes, this can still be an issue. I personally don't find this a problem.

 

3 - PLEASE fix this feature of the mapping system. It is really annoying!

 

Just my $.02

[+Markwell]

2 - The database doesn't look at the zipcode as a shape, it's a point - derived from a list of zipcode-to-coordinates received back when the website started. Limiting it to the zipcode area doesn't even make sense (especially when these zipcode areas are constantly changing).

 

Better to limit the search by adding &dist=5 for 5 miles on to the end of the URL.

[+simpjkee]

2 - The database doesn't look at the zipcode as a shape, it's a point - derived from a list of zipcode-to-coordinates received back when the website started.

 

thats the problem

 

Limiting it to the zipcode area doesn't even make sense (especially when these zipcode areas are constantly changing).

 

I assure you, it makes sense to me. It was the best idea for mapping out areas in the Phoenix area. And the zip codes dont change that much. It would be much easier to just be able to hunt according to zip code and clear each zip code than having to create my own zones covering the area.

[+welch]

2 - The database doesn't look at the zipcode as a shape, it's a point - derived from a list of zipcode-to-coordinates received back when the website started.

 

thats the problem

 

Limiting it to the zipcode area doesn't even make sense (especially when these zipcode areas are constantly changing).

 

I assure you, it makes sense to me. It was the best idea for mapping out areas in the Phoenix area. And the zip codes dont change that much. It would be much easier to just be able to hunt according to zip code and clear each zip code than having to create my own zones covering the area.

 

I don't see what gc.com can do unless they start rewriting the zip code database. I was under the impression the coord for a zipcode is supplied by whoever gc.com gets the info drom (USPS maybe??), so whereever in that zip code the waypoint for that one happens to be is what is used for figuring distances.

[+welch]

1. I would a fourth feature along with size, terrain, and difficulty, adressing the ligthing around the cache and if it is accessible at night. I have more caching time at night than during the day and there is nothing worse than going to a cache and finding out that the park is closed, etc.

If the page stats what park/trail the cache is on, you could try and compare this with rules for that park. Many park systems have all their areas 'close' at the same time. So if you know the cache is in an X county park, and you know those parks close at say 10pm then you have a good idea if that cache is doable or not. Not a fool proof plan, but should help narrow it down.

Edited June 26, 2007 by welch

[+Theseus]

I assure you, it makes sense to me. It was the best idea for mapping out areas in the Phoenix area. And the zip codes dont change that much. It would be much easier to just be able to hunt according to zip code and clear each zip code than having to create my own zones covering the area.

 

It's fine to search by zip, but I have to imagine most folks just look at an area without worrying about the town lines.

 

You could create your own zones by starting with a zip code, using a 5-mile radius, clearing it out, then starting over with another zip code.

[+BlueDeuce]

I assure you, it makes sense to me. It was the best idea for mapping out areas in the Phoenix area. And the zip codes dont change that much. It would be much easier to just be able to hunt according to zip code and clear each zip code than having to create my own zones covering the area.

 

A premium account and mapping software will provide far greater options than gc.com can code in the short term.

Edited June 26, 2007 by BlueDeuce

[+TotemLake]

2 - The database doesn't look at the zipcode as a shape, it's a point - derived from a list of zipcode-to-coordinates received back when the website started.

 

thats the problem

 

Limiting it to the zipcode area doesn't even make sense (especially when these zipcode areas are constantly changing).

 

I assure you, it makes sense to me. It was the best idea for mapping out areas in the Phoenix area. And the zip codes dont change that much. It would be much easier to just be able to hunt according to zip code and clear each zip code than having to create my own zones covering the area.

What you see as minimal change in your area is looking at the smaller picture. You have 2 problems that I can see with this request.

 

1. The search is by radius from the center point of the zipcode. It has nothing to do with the polygraphic form of the zipcode; which is subject to change whether you see it happen or not. That's why the radius from the pont makes much better sense.

 

2. The bigger picture is zipcode areas change all the time across the nation... can't speak for other countries. Asking Groundspeak to keep up with that is very problematic and does not make sense for the best bang out of the buck they receive from premium memberships.

 

I'll add my favorite statement here: This is not AOL where you get spoonfed. You do have to work a little bit for what you want when you pay little or nothing for the service.

Edited June 26, 2007 by TotemLake

[+Markwell]

2 - The database doesn't look at the zipcode as a shape, it's a point - derived from a list of zipcode-to-coordinates received back when the website started.

thats the problem

Limiting it to the zipcode area doesn't even make sense (especially when these zipcode areas are constantly changing).

I assure you, it makes sense to me. It was the best idea for mapping out areas in the Phoenix area. And the zip codes dont change that much. It would be much easier to just be able to hunt according to zip code and clear each zip code than having to create my own zones covering the area.

What you see as minimal change in your area is looking at the smaller picture. You have 2 problems that I can see with this request.

1. The search is by radius from the center point of the zipcode. It has nothing to do with the polygraphic form of the zipcode; which is subject to change whether you see it happen or not. That's why the radius from the pont makes much better sense.

2. The bigger picture is zipcode areas change all the time across the nation... can't speak for other countries. Asking Groundspeak to keep up with that is very problematic and does not make sense for the best bang out of the buck they receive from premium memberships.

Maybe I should have been clearer with what I meant by "doesn't make sense". It does make sense in the real world, but not in the database world of Geocaching.com. Let me tackle two problems:

 

Problem 1: Polygon vs. Point

Take a look at the zip codes for the wide area surrounding Chicago

 

Now take a look at my zip code (60544)

 

To copy that rough map of my zip code, it would take a definition of at least 86 separate points. As far as I know, even the census bureau and the USPS don't have precise lat/lon maps. There are GIS maps available, which could be used, but to what end?

 

Right now, Geocaching.com DOES have an approximate single point for zip code 60544: N 41.6158°, W 88.1984°. When I search on that SINGLE point, I can be given points in a radius of that zip code. Simple math from a simple lookup. It's worked that way for six years, and this is the first request that I think I've seen to limit it by a zip code region. Instead, if you were to suggest something - why not suggest a limitation to a county - which brings us back to the following statement:

 

GSAK (and other programs like GPSBabel) will take polygons and filter cache coordinates to determine if it is within a certain region or not. There are already county polygons set up at the GSAK site to download.

 

- OR -

 

You could use the center point of the zip code that you're looking for and overshoot it (5 miles, 10 miles?) and map your own polygons to filter them accordingly in a program like GSAK or GPSBabel.

 

Problem 2: Morphing Regions

Since that map was drawn, that zip code region has now divided into three zones, 60585 to the north, 60544 in the middle and 60586 to the south. Geocaching.com doesn't recognize those codes, so if I search by zip code, which I rarely do, I search with 60544. How could Geocaching.com possibly keep up with the changing zip codes?

 

Problem 3: Making the zip code regions perfectly aligned

If the contiguous zip code maps didn't use the precisely same intersection points, then if I were to query a zip code AND it's neighbor, there might be a gap in between those polygons that would cause a cache to literally slip through the crack.

 

Take a look at this ficticious polygon map of zip codes:

Looks fine and dandy until you increase the resolution and zoom in:

 

Because those two points that are arrowed in the last picture are not precisely the same, anything falling between them would not be considered "in" the polygon.

 

I've found this problem out already with poorly mapped polygons for States and Counties in GSAK. The problem is bad enough with STABLE regions like counties and states. The task seems almost insurmountable with changing regions like zip codes.

[+simpjkee]

1. I was unaware of the attributes. My fault. there are enough so scratch that off the list.

 

2. I see this is unfixable. Scratch it off the list. I'll do without and just get the premium memberships.

 

3. This still needs to be fixed fo sho. It would be very helpful.

 

 

Oh yeah, and I have a new request.

 

4. Add a general chit chat area to the forums so that people such as myself can go on and chit chat with other cachers about a variety of topics not just geocaching and geocaching alone.

[+FamilyDNA]

Oh yeah, and I have a new request.

 

4. Add a general chit chat area to the forums so that people such as myself can go on and chit chat with other cachers about a variety of topics not just geocaching and geocaching alone.

That would be the "Off Topic" forums. They already exist, but they require a Premium Membership for you to see them.

[+benh57]

For #2:: There is a google maps overlay of zip codes available here:

http://maps.huge.info/

Gc.com could use the source data of this as a rough guess to guess which zip a cache is in. It wouldn't be always perfectly accurate, but it would be close enough. It is nowhere near insurmountable, and i'm always amazed at how fervently people argue against new features on this web site for no good reason. itsnotaboutthenumbers.com already has automatic county detection, which is not always perfect, but it's good enough for our purposes.

 

For #3::

 

With a premium membership, it is very easy to get a google map of just your unfound caches, without downloading them.

 

1. Create a pocket query on the build pocket queries page

2. Check 'that i haven't found'

3. Enter the center point of your query (home coords if you want)

4. Do not select any days to run the query and click submit

5. Click "back to list"

6. Then click the small map-looking icon (second one) in the preview column next to the pocket query.

Done. You now have a google map of your unfound caches. If you want to view it again, you can go to build pocket queries and click the icon again, or just bookmark the page you are at with the map!

 

You can then also now download this query as GPX, and import it to google earth application for XP and Mac, which is much easier and faster to use.

Edited June 27, 2007 by benh57

[+simpjkee]

Oh yeah, and I have a new request.

 

4. Add a general chit chat area to the forums so that people such as myself can go on and chit chat with other cachers about a variety of topics not just geocaching and geocaching alone.

That would be the "Off Topic" forums. They already exist, but they require a Premium Membership for you to see them.

 

i will be getting a premium membership very shortly

[+simpjkee]

Alright. All I need now is to erase all the caches I've already found off the map.

[+simpjkee]

For #2:: There is a google maps overlay of zip codes available here:

http://maps.huge.info/

Gc.com could use the source data of this as a rough guess to guess which zip a cache is in. It wouldn't be always perfectly accurate, but it would be close enough. It is nowhere near insurmountable, and i'm always amazed at how fervently people argue against new features on this web site for no good reason. itsnotaboutthenumbers.com already has automatic county detection, which is not always perfect, but it's good enough for our purposes.

 

For #3::

 

With a premium membership, it is very easy to get a google map of just your unfound caches, without downloading them.

 

1. Create a pocket query on the build pocket queries page

2. Check 'that i haven't found'

3. Enter the center point of your query (home coords if you want)

4. Do not select any days to run the query and click submit

5. Click "back to list"

6. Then click the small map-looking icon (second one) in the preview column next to the pocket query.

Done. You now have a google map of your unfound caches. If you want to view it again, you can go to build pocket queries and click the icon again, or just bookmark the page you are at with the map!

 

You can then also now download this query as GPX, and import it to google earth application for XP and Mac, which is much easier and faster to use.

 

woah. i didnt see this.....hold on a second here. let me try this.

[+simpjkee]

For #2:: There is a google maps overlay of zip codes available here:

http://maps.huge.info/

Gc.com could use the source data of this as a rough guess to guess which zip a cache is in. It wouldn't be always perfectly accurate, but it would be close enough. It is nowhere near insurmountable, and i'm always amazed at how fervently people argue against new features on this web site for no good reason. itsnotaboutthenumbers.com already has automatic county detection, which is not always perfect, but it's good enough for our purposes.

 

For #3::

 

With a premium membership, it is very easy to get a google map of just your unfound caches, without downloading them.

 

1. Create a pocket query on the build pocket queries page

2. Check 'that i haven't found'

3. Enter the center point of your query (home coords if you want)

4. Do not select any days to run the query and click submit

5. Click "back to list"

6. Then click the small map-looking icon (second one) in the preview column next to the pocket query.

Done. You now have a google map of your unfound caches. If you want to view it again, you can go to build pocket queries and click the icon again, or just bookmark the page you are at with the map!

 

You can then also now download this query as GPX, and import it to google earth application for XP and Mac, which is much easier and faster to use.

 

HOLY NUTS! thats awesome. Thanks

Edited June 29, 2007 by simpjkee

[+benh57]

 

HOLY NUTS! thats awesome. Thanks

 

I'm still awake too

 

You're welcome.

[+trainlove]

Wow, that http://maps.huge.info/ link is just great. Thanks.

Now if only I can use it to hide a county ground zero or a state ground zero.