Additional Waypoints For Geocaches

[+Markwell]

Okay, correct me if I am wrong but arent there some letters that are NOT used in current waypoints. Let's say the letter "L" is unused. We can now use "L" in place of my hyphens (see my post above)

 

GC1234 = Posted coords

GC1234LP1 = Parking coords 1

GC1234LM1 = Multi coord 1

 

etc.

 

I still like the idea of the waypoints for a cache being sorted together...

 

I know this goes over the 8 character limit...

6 character limit. That's part of the problem.

[Jeremy]

Scary, but how about a hybrid solution, both single-digit prefix and suffix?

 

GC#### stays as is.

P####1 = parking option 1

The current belief is that the first two digits of any Geocaching.com waypoint can be removed since it is merely an identifier for geocaches. It would be far easier to continue this idea by prepending both characters to the front than to put one character on each end.

[+RJFerret]

It would be far easier to continue this idea by prepending both characters to the front than to put one character on each end.

 

But then in a simple GPSr, you'd have this for caches GC0000, GC080B, GC0880, GC8B0B:

 

GC0000

GC080B

GC0880

GC8B0B

P10000

P1B088

M1080B

M10880

M18B0B

M2080B

M20880

M28B0B

M3080B

M38B0B

 

My idea would keep same cache waypoints sorted together, rather than sprinkling them throughout the list as so:

 

GC0000

GC080B

GC0880

GC8B0B

P00001

PB0881

M080B1

M080B2

M080B3

M08801

M08802

M8B0B1

M8B0B2

M8B0B3

 

Now imagine if there were more than just three multicache waypoint sets loaded!?!!

 

(This also solves the problem of using both characters as a suffix creating possible dupes.)

 

Just a thought,

 

Randy

[+RJFerret]

Not so bad displayed there, painful in a fixed-width font! --Randy

[Jeremy]

Why would it matter if the cache waypoint names are listed in alphabetical order?

 

As an aside, after some additional thought I am planning to provide the coordinates in both the long description and the additional gpx file. This will allow the new waypoints to be backward compatible and entered as waypoints in the GPS unit and make the long description a way to reference the supporting waypoints.

[CoyoteRed]

Let me ask a question from a layman's, pseudo-"big thinker's" point of view.

 

Considering a few points:

• A "waypoint" is burned off for each successful listing of a cache, never to be used again.
  
• I'd say somewhere in the neighborhood of 95% of all individual active waypoints are completely useless to any one person simply because of the sheer numbers.
  
• As the years go by, the numbers of waypoints archived will far exceed the number of active waypoints.
  
• You will run out of solutions with the present scheme eventually.
  
• This site and the real Big Thinkers have a propensity for conservatism, i.e. resistance to change because of the way it's always been done.
  
• Waiting for a change further down the road is more painful than doing it now.
  
• Waypoints are only really needed to be in the GPS, not used as a discription of the cache.
  

Why not do away with the waypoints to discribe cache hunts in a static manner?

 

Yes, I understand how hard it would be to do that at this point in time. However, you're not going to be able to keep adding digits forever. Eventually, something will change.

 

Why not look to that future today?

 

Forget static waypoints. Force a change on how the waypoints are referenced. Forget about trying to shoehorn the 1,000,000,000th waypoint into a GPS with the fewest digits.

 

Disconnect the "Geocache Reference Number" from waypoint. A user need only be able to match a waypoint in his GPS with the same number in his PDA. The discription in the PDA can then hold the "GRN." The "GRN" could be of any practical size and won't be limited to the ability of any hardware.

 

I'll close for now as I'm picturing those interested in this topic reading this and just going back to the dicussion already in progress. If there are any questions about some of the other affected issues caused by this, I'm all ears. Like, what about those who use the GPX file straight versus those who use GSAK or other software. How do you change the mindset of GRN versus waypoint? Etc.

[Jeremy]

I have to say that the waypoint name is working quite well. And we pretty much figured out a good solution. I'm not sure why we have to wax philosophic at this point.

[CoyoteRed]

From a standpoint of getting the waypoints out, it works.

 

The way I, and I'm sure plenty of the others, use GSAK, it's not so good. I replace the GC with single character representations of type, size, difficulty, and terrain. This produces an eight character waypoint which in the max for my Magellans.

 

It might be an idea to jump over to the GSAK thread and talk about how they use the program. I think it would be a dis-service to those to introduce a scheme that would through a major monkey wrench into things.

 

Just a thought.

[Jeremy]

Huh. What a great idea. I guess I should create a thread to address changes to the existing schema and announce these changes so developers know how to address and comment on it.

[CoyoteRed]

I'm sure Clyde is well aware of that thread. I'm talking the users.

 

Eh. If the present solution is workable, it's workable. I've worked with everything thrown at me so far. I adapt. Work around. No problem.

 

Just trying to be helpful, but I'll shut up now.

[Jeremy]

I'm sure Clyde is well aware of that thread. I'm talking the users.

Well shouldn't he represent his own customers? I don't know how GSAK works or how you use it. Even not knowing the intricate details of the application I can think of several ways to adapt to the change if I were to write a GPX tool. So can fizzymagic and robertlipe so unless any other developers speak up I can assume that it is ok.

[Jeremy]

Just an update. As I posted above I decided to imbed the coordinates in the long description of the cache in addition to adding another gpx file containing the waypoints. This is what it would look like appended to the bottom of the description:

 

Additional Waypoints

P1K894 - A park. Yay!

N 47° 12.654 W 122° 45.978

This is a description. Whee!

Q1K894 - How old is this tree?

N 47° 00.000 W 122° 00.000

What is the age of this tree? Make it XYZ.

S1K894 - Stage 1

N 47° 12.000 W 122° 13.000

This is just a basic description for testing.

S2K894 - Stage 2

This is stage 2. Coordinates are found at the final location.

S3K894 - Stage 3

This is stage 3

S4K894 - Stage 4

N 47° 00.000 W 122° 00.000

There's something here that will get you the tools you need.

 

And this would be the accompanying GPX file (in addition to the regular GPX file):

 

<?xml version="1.0" encoding="utf-8"?>
<gpx xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.0" creator="Groundspeak, Inc. All Rights Reserved. http://www.Groundspeak.com" xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.Groundspeak.com/cache/1/0 http://www.Groundspeak.com/cache/1/0/cache.xsd" xmlns="http://www.topografix.com/GPX/1/0">
 <name>Waypoints for Cache Listings Generated from Geocaching.com</name>
 <desc>This is a list of supporting waypoints for caches generated from Geocaching.com</desc>
 <author>Various users from Geocaching.com</author>
 <email>contact@geocaching.com</email>
 <url>http://www.geocaching.com</url>
 <urlname>Geocaching - High Tech Treasure Hunting</urlname>
 <time>2005-12-31T00:32:37.4843750-08:00</time>
 <keywords>cache, geocache, waypoints</keywords>
 <bounds minlat="47" minlon="-122.7663" maxlat="47.2109" maxlon="-122" />
 <wpt lat="47.2109" lon="-122.7663">
   <time>2005-12-16T18:15:43.6500000-08:00</time>
   <name>P1K894</name>
   <cmt>A park. Yay!</cmt>
   <desc>This is a description. Whee!</desc>
   <url>http://www.geocaching.com/seek/wpt.aspx?WID=c8898fce-4542-46ac-93a6-e38057043f37</url>
   <urlname>A park. Yay!</urlname>
   <sym>Parking Location</sym>
   <type>Waypoint|Parking Location</type>
 </wpt>
 <wpt lat="47" lon="-122">
   <time>2005-12-18T17:04:23.1670000-08:00</time>
   <name>Q1K894</name>
   <cmt>How old is this tree?</cmt>
   <desc>What is the age of this tree? Make it XYZ.</desc>
   <url>http://www.geocaching.com/seek/wpt.aspx?WID=f37f0c7e-d534-49be-b737-4f64dba5be71</url>
   <urlname>How old is this tree?</urlname>
   <sym>Question to Answer</sym>
   <type>Waypoint|Question to Answer</type>
 </wpt>
 <wpt lat="47.2" lon="-122.216666666667">
   <time>2005-12-18T15:58:15.5730000-08:00</time>
   <name>S1K894</name>
   <cmt>Stage 1</cmt>
   <desc>This is just a basic description for testing.</desc>
   <url>http://www.geocaching.com/seek/wpt.aspx?WID=e4d54a49-5f1b-46c8-bced-9d4d80a5eee2</url>
   <urlname>Stage 1</urlname>
   <sym>Stage of a Multicache</sym>
   <type>Waypoint|Stage of a Multicache</type>
 </wpt>
 <wpt lat="47" lon="-122">
   <time>2005-12-18T17:20:57.3370000-08:00</time>
   <name>S4K894</name>
   <cmt>Stage 4</cmt>
   <desc>There's something here that will get you the tools you need.</desc>
   <url>http://www.geocaching.com/seek/wpt.aspx?WID=06a11b1c-deac-4559-ba71-c25c997b5bfa</url>
   <urlname>Stage 4</urlname>
   <sym>Stage of a Multicache</sym>
   <type>Waypoint|Stage of a Multicache</type>
 </wpt>
</gpx>

[+The Blue Quasar]

Totally agree that it is far simpler to continue with the first two character of 6 being designated to describe the kind of waypoint name.

 

GCWXYZ as the Geocaching ID tag (sorry if Tag is the wrong term)

PKWXYZ as the Suggested Parking tag

 

But I really don't understand how you can say this Jeremy

Why would it matter if the cache waypoint names are listed in alphabetical order?

 

The additional points HAVE TO be sorted alphabetically in the GPS to be useful. I suppose people can use the "find nearest" feature, but often people sort the stage data alphabetically/numerically so they do the multi/puzzle in the right order.

 

Wild thought here, and probably a lot of work.. but here goes... can you change the naming structure so that the GC is the suffix and not the prefix? Hence GCWXYZ becomes WXYZGC ? I know that GC infront is a self-promotion item, nothing wrong with that. But it really prevents a sortable solution, in my opinion.

 

RJFerret's example makes it crystal clear... and also illustrates the problem of the "strip the first two characters' problem.

 

The only solution that popped into my head regarding the use of the suffix for the additional waypoints beyond the GC and PK was if there is a non-letter or non-numerical character that can be used. Someone said the hyphen is not an option, is there another 'placeholder' character that is universal to all GPS units?

 

Still doesn't solve the "strip the first two charaters" problem, but that would be a third party software problem, not a Groundspeak one. I'm no programmer, but I would like to dream it would be easy to convert the %drop2 code to something like

 

"%drop2 if =GC, else ignore"

 

It still looks like the problem of the painted into a corner of the first two characters being dedicated to some form of Groundspeak identifier, the next four as unique cache indentifier yet maintaining a 6 character system, still exists.

 

The Blue Quasar

[+Pasha]

I'm no programmer, but I would like to dream it would be easy to convert the %drop2 code to something like

 

"%drop2 if =GC, else ignore"

Well, for that matter, check out %notgc. Not really a concern for the third party app to which you're referring; there's already support for waypoints that don't start with GC. Sorting/associating would still require development for these apps, I think, but the system Jeremy's described sounds workable to me.

[+Chwiliwr]

Jeremy

 

I can see that you may have already decided to have an 'alpha' + 'numeric' with the 'alpha' meaning something like 'p = parking' but from experience in designing and updating a code set for a large law enforcement database you will come to a point where you get to a code that will not actually mean what you originally meant it to.

 

You are far better off not having the first two characters mean anything other than the sequence they should be in for the cache they are being associated with.

 

The benefits of this approach is firstly you can also get rid of a significant amount of code to do with checking as the entry page can sequence them for you (ie number them)

 

Secondly, if they have no meaning apart from the sequencing, then there will never be any questioning or arguments over what letter should be for what.

 

Thirdly you open it up to have as many types of waypoints that you need by using only the description to describe them.

 

Finally a sequence approach allows an owner to order mutlple types of waypoints in a logical order that he wants and not having them ordered by type, which may not be appropriate for him. (This may have been covered somewhere but both topics have a lot of replies and I didn't see if it was)

[+The Blue Quasar]

Well, for that matter, check out %notgc. Not really a concern for the third party app to which you're referring; there's already support for waypoints that don't start with GC. Sorting/associating would still require development for these apps, I think, but the system Jeremy's described sounds workable to me.

 

Thanks! I never knew about that... that really helps. Off to re-read the "special tags" again.

 

The Blue Quasar

[+Hynr]

I don't know how GSAK works or how you use it.

Wow - very sad that you are so out of touch. Maybe you should get to know this tool for the sake of us, your clientelle.

Even not knowing the intricate details of the application I can think of several ways to adapt to the change if I were to write a GPX tool. So can fizzymagic and robertlipe so unless any other developers speak up I can assume that it is ok.

Are you kidding us? I think this bit of arrogance is going to come back to haunt you. You have only heard from 2 developers of 3rd party software and you think that means that everything is OK?!? Are you equally ignorant about Spinner, EasyGps, Mapsource, ExpertGPS, etc.

 

If the new scheme causes problems for your clients (ie. by working poorly with such software), then it will be the gpx files that will be deemed to be defective, not the software that has been working well for years. I know that you know who the developers are; you owe it to them and us to make contact to assure that major changes are not going to cause us problems. In cases where you cannot find out or get their attantion (e.g. Garmin's Mapsource), you should at least do some testing.

[+beejay&esskay]

I think we need to calm down.

 

I don't know that Clyde is aware of this, but I'm sure he'll find a way to take care of the GSAK users.

 

It does seem that Jeremy might want to contact the major consumers of PQs (viewing the programs as the actual consumers), but if he chooses not to that's up to him.

[+Kai Team]

I think we need to calm down. 

 

I don't know that Clyde is aware of this, but I'm sure he'll find a way to take care of the GSAK users.

 

It does seem that Jeremy might want to contact the major consumers of PQs (viewing the programs as the actual consumers), but if he chooses not to that's up to him.

Yes - calm down and dispense with gratuitous slights. This is a Holiday week - perhaps we should consider that in timing discussions about significant changes that will impact software developers...

 

Edit: PS - As an end user, I like the way this feature is shaping up. It's intuitive, which is always good for the end users.

Edited January 1, 2006 by Kai Team

[+The Blue Quasar]

Without knowing Jeremy or any of the other executives, I would think that not only would Jeremy attempt to implement this with marginal impact to third party applications, he would keep them abreast of the possible changes.

 

We already have seen Robert in here, and since he works closely with Clyde, I suspect Cylde knows too.

 

But it may be unrealistic to expect that Jeremy can always ensure 100% compliance with third party applications. I think Microsoft certainly taught us that. Sometimes changes need to be made, and it causes a trickle down effect.

 

Everyone's suggestions in here will help to provide a solution that ends up serving the end user in the best possible way, while being limited by what is actually attainable.

 

PQ's have been around for a long time too, just like GSAK and Expert GPS and GPS Babel. They grow and change from enhancements and new ideas. That is what is going on here, a next evolution in PQ's.

 

The Blue Quasar

 

edit: typo

Edited January 1, 2006 by The Blue Quasar

[CoyoteRed]

Oh, and can you give the option of NOT downloading these extra waypoints if it breaks our present and preferred scheme?

 

Thanks!

[+sTeamTraen]

Having upgraded from a Geko (6 char max) to a 60cs a few months ago, I'm pleased to be able to vote that any solution should not worry too much about the 6-character limit.

 

However, the 60cs has a limit of 10, so I'm prepared to make a strong case for that. In other words, GCXXXXPARK, ok, but GCXXXXQUESTN would be too long...

[+ClydeE]

Ok, a little late coming on board in this thread - took a short break over the new year (quite surprised to see this thread so active during this time)

 

I can see the issues raised this far and I (from a personal and GSAK perspective) am perfectly happy with the proposed solution. It is not an easy nut to crack and there are going to be "issues" no matter what the final solution is.

 

Given the restrictions and problems already outlined I think this is very workable. I don't see anything here that will "break" GSAK. Sure, users may now want extra features that will help them work with the new waypoints, but this is something they will need to communicate to me, and I in turn will work through them.

 

It would be foolish for anyone to assume you could implement such changes without a bit of effort to make it workable, and some of this "effort" may/will be required by the end user.

 

In the long run, it will be Geocachers in general that will benefit, so I think we all need to embrace the changes - free of angst

[CoyoteRed]

As long as Clyde is confident he can provide a workable solution, I'm happy.

[+The Blue Quasar]

CoyoteRed  Posted on Jan 2 2006, 03:48 AM

  As long as Clyde is confident he can provide a workable solution, I'm happy.

 

Me too. I use GSAK every single day, and it does all I need (and a lot more too).

 

But for those that DON'T use GSAK , it doesn't help to provide a solution that forces a Premium Member to have to change.

 

Groundspeak sells a service (Pocket Queries), and it should be sold equally to all subscribers regardless of after-delivery applications.

 

It's one thing to modify data after the fact, but to make it a requirement just to use it is unethical. That would be like saying "Groundspeak offers all of the cache descriptions to Premium Members via Pocket Query, but to see the coordinates contained within the PQ file you must also purchase MicroSoft Streets and Trips and view as individual push pins"

 

It doesn't matter to me, I have GSAK and with Cylde saying he can work his magic I am comforted. I just look back on the way Waymarking was accepted and the comments that came forward there. I hope that whatever method is adopted for the new version of PQ's that there isn't another revolt from people thinking they are being cheated because they don't have the same rights as others.

 

Any way it plays out, I'll adapt... that's the fun part for me. Some don't share that, and they will complain anyways.

 

The Blue Quasar

[+Lil Devil]

Just a note that I've been watching this thread since it started and only see possibilities in all the suggested solutions. Whatever is finally implemented, Spinner will be updated to handle it.

[+Panther in the Den]

When will this feature be implemented?

 

I saw the feature briefly appear (incomplete) as I was creating some caches before the holidays and I think it will be very cool!

 

I need it NOW!

[+Tharagleb]

Why would it matter if the cache waypoint names are listed in alphabetical order?

When I am keying into my Garmin Etrex Legend, if I key in GC12 then all the WP's that start with GC12 are listed alphabetically. I can then chose the one I want. It is *not* critical, but I think it would be nice. It is true that I can use nearest WP's but what if I am looking for parking for GCXYZ, then I key in GCXY and I can quickly jump to GCXYZ-P (or whatever). I can do this even if GCXYZ is not close.

 

It isn't critical, but alpha proximity would be handy.

[Jeremy]

I can see that you may have already decided to have an 'alpha' + 'numeric' with the 'alpha' meaning something like 'p = parking' but from experience in designing and updating a code set for a large law enforcement database you will come to a point where you get to a code that will not actually mean what you originally meant it to.

I am not using alpha + numeric. It could have been AB or CA or 12. The first two digits, as long as they don't use GC, WM, TB or WP (added just in case) are acceptable. This, combined with the XXXX part of the GC code will make them unique. Additionally, the URL will be unique for each waypoint added.

 

This fits within the current design that the first two codes are throwaways and generally just indicate where the waypoint is coming from (on geocaching.com).

 

Sorting is irrelevant on the GPS unit. It would be obvious on a map view whether parking is helpful. Any other waypoints would be referenced in the description by waypoint name which can be entered into a search on the GPS unit. Puzzle questions and multicache stages would require looking back at the details of the cache anyway.

 

By function the decided solution looks like the best one considering the issues surrounding GPS units and their requirements. The additional waypoints will be in a seperate file unless they are downloaded directly from a cache page, so you can decide whether or not you wish to use them.

 

We will implement this feature once we update the readonly databases to accept the new tables. This will allow us to integrate it with the Pocket Queries to complete the feature set.