Jump to content

Are We About To Run Out Of Waypoint Codes?


Nudecacher

Recommended Posts

How about you keep the prefix G, then add the next letter depending on the type of cache being placed: M - Multi, T - Traditional, U - Unknown (if there are new ones..?!), S - Small (Micro), E - Earth etc.

 

I think the other methods of stripping out letters for the GPSr are possibly confusing and although i'm sure people will find a way it sounds rather time consuming.

Link to comment
How about you keep the prefix G, then add the next letter depending on the type of cache being placed: M - Multi, T - Traditional, U - Unknown (if there are new ones..?!), S - Small (Micro), E - Earth etc.

No.

 

From a database perspective it's NOT a good idea to house anything in the unique identifying field (like the Waypoint Code) that constitutes data from the database.

 

First, the size of the cache already exists as another field, and is not a type, so please exclude "S" from your possibilities.

 

Second, there are PLENTY of pieces of software out there that can take the waypoint code and spin it based on personal preferences to add data to the code for the GPS. Personally since my GPS can house 10 character waypoints, I add "D4T7" or something similar to the GC code, where 4 is a 1-9 rendering of the 9 possibilities of difficulty (1.0, 1.5, 2.0, etc.) and 7 is a 1-9 rendering of the 9 possibilities of terrain (1.0, 1.5, 2.0, etc.). I can then easily figure out the difficulty and terrain by looking at the waypoint - GCTPEED2TT5 would be a Difficulty 1.5, Terrain 2.0.

 

BUT...

 

In rare instances, caches can change their type. It has happened before (although it is VERY rare now) that a multi-stage cache changes to a traditional, or (worse yet) it is mislabeled in the system. If the mislabeled multi is GMZ424, and there's already a GCZ424, then you'd create a duplicate ID.

 

From my VERY first database class, it was stated that there should be a unique identifying code for each table in the database, and that this code should NOT contain variable data. The GC**** code is a rendering of a numeric sequence of when the cache is entered. Please don't suggest messing with it.

 

The website has already announced that the next step will be adding an additional character, so GC10000 will follow GCZZZZ.

Edited by Markwell
Link to comment

When will the search feature be fixed?

 

I didn't know it was broken. Was it?

It was a way of suggesting that the OP didn't use the search feature before posting since there are a godzillion posts asking this question already. Not a helpful post, I know, but since the answer had already been given I was being ironical.

Edited by Mushtang
Link to comment

I see what you mean Markwell, didnt realise how the DB worked. My main concern with the other method is the knowledge involved it setting up the conversion. I'm reletively new to the hobby/sport/pastime (delete as approipriate...) and would have been put off if I had to figure out all that coding before I could go and try it. (Your method is obviously very personalised...)

 

With the addition of the extra digit to the end of the GC code, will the Downloadable .LOC files include all the figures or will the user have to do this? If so it could be a lot of work for a trip out that could stop people from enjoying the activity. I like the fact that when I go to an area, I just drop on a loc file with all the caches in the area on it and go - figuring out what to do once i'm there. Not possible if I have to sit and remove a G from each reference beofer uploading. (Obviously this is worst case scenario....)

Link to comment

An easier way would be to shorten the prefix from "GC" to "G" and then you'd have exponentially more space for caches without requiring more memory or risking GPS incompatibility. To avoid conflicts, in the Gxxxxx version, you don't allow "C" as the second digit and the system could continue to differentiate between 4 and 5 character codes.

 

I love these kinds of design issues - that's one of my specializations. My last big project was the online hotel reservation system that was acquired by hotels.com -- you want to talk about some complex queries!! The hotel industry has some really bizarre requirements and restrictions when it comes to manipulating inventory data.

Edited by arpegio
Link to comment

First of all fixing the waypoint ID is simple: go download GSAK then when you export to the GPS you can modify or shorten the name all you want.

 

I started thinking quite a way down the road when we will be near GC1ZZZZ. At that point even dropping the GC will leave EVERY waypoint under the "1" tab in your waypoint list. That would mean 500 caches for my Etrex to scroll through.

 

I posted over on the GSAK forum and KAI TEAM wrote this nice GSAK macro for me:

 

#Transpose >6 digit GC Codes to drop2, with 1st digit moved to the last place;

#otherwise use drop2 (for GC codes of 6 digits or less)

If len($d_code) <= 6

$_Special=Right($d_code, 4)

ELSE

$TempCode=Right($d_code, 4)

$TempCode=$TempCode+Substr($d_code, 3, 1)

$_Special=$TempCode

EndIF

 

What it does it to drop the GC and then additionally if there were more than 6 letters in the name, it moves the leading "1" to the far right. An example: GC12345 becomes 23451. This will allow the waypoints to spread out over all the alpha numeric tabs but still retain all the digits and every ID stays unique. It will continue to work into the future. So when we have GC5XXXX it will do the same thing and just move the 5.

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