7-Letter GC Codes

[+Fuzzywhip]

When GC codes went from 6-letters to 7, what was the first code?

 

I can think of several variations depending upon which letter is first:

 

GC10000?

 

GC11111?

 

GC1AAAA?

 

This also will refer to the next big step (approaching soon), for GC2????.

[+Lil Devil]

GC10000

[+ecanderson]

When GC codes went from 6-letters to 7, what was the first code?

It's still there, just NW of Toronto: http://www.geocaching.com/seek/cache_detai...c2-fc433db84e4a

 

Yup - looks like we will be seeing GC20000 before long.

[+Fuzzywhip]

Thanks for the quick answer

 

I saw last night that the number is up to GC1Z9YQ

 

Yup, GC20000 is coming RSN (Real Soon Now) :-)

[+Okiebryan]

Wow. seems like just yesterday we were discussing Y2K type scenarios when the cache ids rolled over to GC10000... lol

[+DENelson83]

The characters that are valid in a GC code are the digits zero through nine and all letters of the Roman alphabet, except for the letters in the name "Louis".

 

You know, I think that, for consistency purposes, all GC codes less than 7 characters in length should be completely retired, and replaced with 7-character codes with enough leading zeroes after the "GC" part, so GCAAA, for example, becomes GC00AAA, and GCAAAA becomes GC0AAAA.

 

Edit: Thanks, sTeamTraen!

Edited October 1, 2009 by DENelson83

[AZcachemeister]

I would have thought it would be GC00001, but that one is unpublished.

[+DENelson83]

GCD is the first published, non-archived cache in the database. GC0000D should also refer to that cache, but it doesn't. Maybe Groundspeak should change that.

Edited October 1, 2009 by DENelson83

[robertlipe]

The guys that write the software that needs to understand this arcana (a few of which have piped in on this thread) are comfortable with the whole concept of leading zeros being insignificant and don't see a reason to burn elements from a well defined namespace every time a bump is in order. The change from hexadecimal to base [whatever it is now] was pretty well communicated to the external developers and is pretty clear.

 

Lil Devil's answer was the correct one to the OP. When the extra digit was added, the four character codes (and they were four digits with implied leading zeros, base 16) were well defined and shoved into a known space with the full knowledge that there was some dead space between GCFFFF and GC10000.

[+DENelson83]

Well, some database developers and programmers are more comfortable with fields that use data types providing a fixed number of characters, or simply a straight numerical value. Using a variable-length mixed alphanumerical ID can require, to them, some very complex work to define the data type properly.

[+Lil Devil]

Using a variable-length mixed alphanumerical ID can require, to them, some very complex work to define the data type properly.

True. But that work is already done. Years ago. Why go back and change it now? What would it really accomplish?

 

Especially when there are much more important things to work on today.

[+sTeamTraen]

Well, some database developers and programmers are more comfortable with fields that use data types providing a fixed number of characters, or simply a straight numerical value. Using a variable-length mixed alphanumerical ID can require, to them, some very complex work to define the data type properly.

The GC Code isn't really fundamental at all - in fact, I'm guessing that it may not even be stored in the database in its GCxxxxx form.

 

A cache is represented first and foremost by the GUID (32 hex digits, so there's your fixed-length field) of its top-level database element. The easiest way to represent the GC code is with an auto-incrementing sequence number in a 32-bit INT field (so when we have 2**31-1 or 2**32-1 caches, we might have a problem).

 

If that's the case, the GC Code can be derived in all cases from the cache sequence number. For sequence numbers above 65535, you do some base-31 (!) arithmetic on the number, then map the resulting base-31 values onto letters (minus, as someone nearly pointed out above, those which make up the word "LOUIS" ) and numbers. Below 65535, a straightforward hex mapping is used (GC1 through GCFFFF). Perhaps, way back when, leading zeroes should have been introduced, but it would have looked rather pretentious to publish cache "GC0000000F" as the 15th ever.

Edited October 1, 2009 by sTeamTraen

[+DENelson83]

(minus, as someone nearly pointed out above, those which make up the word "LOUIS" )

"Louis"! YDITOT?!?!

Edited October 1, 2009 by DENelson83

[+sTeamTraen]

YDITOT?!?!

Sorry, I googled but I don't know what that means.

[+DENelson83]

YDITOT?!?!

Sorry, I googled but I don't know what that means.

"Y (Why) Didn't I Think Of That?"

[+DENelson83]

A cache is represented first and foremost by the GUID (32 hex digits, so there's your fixed-length field) of its top-level database element. The easiest way to represent the GC code is with an auto-incrementing sequence number in a 32-bit INT field (so when we have 2**31-1 or 2**32-1 caches, we might have a problem).

Except that the GUID is not even remotely used by humans as much as the GC code.

 

Just add a regex that allows any number of leading zeroes (within reason) to be put in between the "GC" and the rest of the code, and yet still resolve to the same GUID.

Edited October 1, 2009 by DENelson83

[+RoPeHe]

 

When the extra digit was added, the four character codes (and they were four digits with implied leading zeros, base 16) were well defined and shoved into a known space with the full knowledge that there was some dead space between GCFFFF and GC10000.

 

GCFFFF (the last hex code) was followed by GCG000 (the first "base 31" code, but still 6 characters)

 

then, much later, GCZZZZ was followed by GC10000 (the transisition point from 6 characters to 7 characters, both "base 31" code)

[+Prime Suspect]

A cache is represented first and foremost by the GUID (32 hex digits, so there's your fixed-length field) of its top-level database element. The easiest way to represent the GC code is with an auto-incrementing sequence number in a 32-bit INT field (so when we have 2**31-1 or 2**32-1 caches, we might have a problem).

Except that the GUID is not even remotely used by humans as much as the GC code.

 

Just add a regex that allows any number of leading zeroes (within reason) to be put in between the "GC" and the rest of the code, and yet still resolve to the same GUID.

It's a poor programmer who can't adapt to the situation at hand.