New Waypoint IDs

8.9k · November 14, 2002

My response was actually to unclerojelio (everytime I see that login, I think "opaque gelatin").

But I guess my response equally applies to Jiminiaz.

Markwell

Chicago Geocaching

November 29, 2002

Might I suggest semi-meaningful GC#'s

Gxxxxx - standard geocache

Vxxxxx - virtual geocache

Mxxxxx - micro

Txxxxx - multi

Lxxxxx - locationless

Wxxxxx - webcam

Exxxxx - Event

Hxxxxx - Hybrid

Uxxxxx - Unknown/Surprise

A)Supports over one million caches...

B)Six letters supports older gps (, like mine)

C)Continues to be simple hex translation to decimal

D)Since access is done using decimal record number, the current display of CGxxxx could be updated to new format while still retaining searching support for GCxxxx.

E)Solves number limit problem and adds significant benefit to map displays.

8.9k · November 30, 2002

quote:
Originally posted by bspeng:
Might I suggest semi-meaningful GC#'s

...

C)Continues to be simple hex translation to decimal

D)Since access is done using decimal record number, the current display of CGxxxx could be updated to new format while still retaining searching support for GCxxxx.

I'm confused on these two points.

Since the hexidecimal conversion from decimal only applies to the last four characters, how would changing the first letter expand the availability?

Remeber that the "unique" portion of the number is the final four digits. I believe Jeremy's decided solution is to change the number after the G and before the hex (GD####, then GE####). That makes the programming much easier. (IF Decimal<65598, then GC&Hex, else GD&Hex).

And what happens if someone converts a multi cache to a traditional, or an event cache to a virtual? You can end up with duplicates.

Markwell

Chicago Geocaching

November 30, 2002

AND off the first nibble or '0' plus five bytes (depending on your favorite method), then convert six byte hex to decimal...

in any case...

the time to improve is NOW, before entrenching in an archain method of GD's GE's and GF's ...

what happens after GF?

(this occurs in approx. 2 years - my guess)

you may as well get rid of "GC" all together.

In other words, "GC" provides little or no value... the prefix code would allow some significance to the 5,8,10,20 mile display on the GPS (and other associated map displays and printouts.)

[This message was edited by bspeng on November 30, 2002 at 07:11 AM.]

November 30, 2002

"what happen if someone changes cache type?"

... prefix would be appended at print time...

in other words, do not have eight separate series, just one...

V10009

G1000A

L1000B

G1000C

etc, etc, etc...

therefore, G1000A, V1000A & M1000A are all the same cache... in the extreme case this may be confusing, but, changing cache type doesn't happen that often. the benefit outweighs the risk.

this still yield over one million numbers... 980,000 if you skip the "C" series... presumably it would be ok to drop the GCxxxx to Gxxxxx conversion by the time you get to 'gc0001' in five digit format.

[This message was edited by bspeng on November 30, 2002 at 07:18 AM.]

2.5k · November 30, 2002

quote:
Originally posted by Markwell:
(IF Decimal<65598, then GC&Hex, else GD&Hex).

IF Decimal<65536

2.5k · November 30, 2002

quote:
Originally posted by bspeng:

what happens after GF?

(this occurs in approx. 2 years - my guess)

Then GG. That's betting that the C in GC is in Ascii format, just like the G in GC is.

Let me Markwell you over to here , where I go into it in more detail.

December 1, 2002

Why does there seem to be support for a naming system that is useless?

Seriously, GC to GD to GE???

Why?

Prefixing the type would provide benefit, otherwise you may as well drop the GC thing all together.

6.5k · December 1, 2002

quote:
Originally posted by bspeng:
Why does there seem to be support for a naming system that is useless?

Seriously, GC to GD to GE???

Why?

Prefixing the type would provide benefit, otherwise you may as well drop the GC thing all together.

I think it because from GC to GD would be a simple way to fix an upcoming "problem" , but making lots of changes would be complex & confusing.

December 1, 2002

simple? simple for who?

none of us are doing the programming.

the system i proposed is not programatically difficult... it is "simple"

i've read about support for base36 and/or stacks of "if" statements... those method are complex, shortsighted, and confining.

the use of the extra nibble (half byte) adds sufficient numbering for the near future. the proposal to prefix simply adds benefit while working in this area of the program. in other words, since you gotta go in there and fix a problem, why don't you make it worth your while? Add signicant benefit while fixing a program shortcoming. the reality is that the original numbering system was under-spec'd, the mistake should not be repeated.

the addition of new caches is increasing geometrically... the "GD" fix is too "simplistic".

~bspeng

6.5k · December 1, 2002

quote:
"simple? i have no interest in simple. i want improvement with change."

i realize that, but it doesnt look like an "improvement" is going to happen.

quote:
Originally posted by bspeng:
simple? simple for who?

none of us are doing the programming.

Simple for whoever IS doing the programming.

quote:
the system i proposed is not programatically difficult... it is "simple"

But its "difficult" to get everyone to understand the proposed system.

quote:
i've read about support for base36 and/or stacks of "if" statements... those method are complex, shortsighted, and confining.

And?

quote:
the use of the extra nibble (half byte) adds sufficient numbering for the near future. the proposal to prefix simply adds benefit while working in this area of the program. in other words, since you gotta go in there and fix a problem, why don't you make it worth your while?

Thats something only Jeremy can answer.

quote:
Add signicant benefit while fixing a program shortcoming. the reality is that the original numbering system was under-spec'd, the mistake should not be repeated.

Repeated?

quote:
the addition of new caches is increasing geometrically... the "GD" fix is too "simplistic"

But it is a fix, even if it is "simplistic".

December 1, 2002

i'm passionate about an idea that seems clear to me... lack of comprehension by others is unfortunate...

support for a the 'GD' numbering system by others who have posted in this forum seems misguided.

If repeating statements seems unnecessary, well that's one way to restate my ideas.

I feel it important to defend my idea over one that i feel is lackluster and insufficient.

Again, the use of non-meaningful prefix, such as "GC", "GD", "GE", etc., provides zero benefit. It would be helpful to have the cache type in the waypoint. This would allow you (me) to make decisions about where to head when looking for the next closest waypoint... for instance, if the next closest waypoint was a virtual, I wouldn't go there if I didn't have the cache description.

It is important to keep the total waypoint under six characters.

A five digit hexidecimal can store number up to 16*65535 = over one million.

An algorithm to generate a waypoint that is a single character type plus five digit for record number would maximize the space... such as 'V100A1" (equivalent to your GD00A1)... My method would tell to this is a virtual, the "GD" method tells you nothing... presuming knowing the record number is pretty useless...

If the "GD" method has already been chosen by Jeremy... well, that's too bad, but, not too late.

~bspeng

December 1, 2002

quote:
Originally posted by bspeng:
i've read about support for base36 and/or stacks of "if" statements... those method are complex, shortsighted, and confining.

Actually, base36 (i.e. "[0-9A-Z]"), if coupled with a prefix change, is quite simple indeed. It is no more shortsighted or confining than any other method. There are two "good" ways to implement a change to Base36 waypoints:

Change the waypoints to "GI%%%%", where "%%%%" is a zero-padded Base36 representation of the cache ID. (Total IDs available: 1,679,615)
Change the waypoints to "C%%%%%", again where "%%%%%" is a zero-padded Base36 representation of the cache ID. (Total IDs available: 60,466,175)

There are also several "bad" ways to make new IDs:

"GC%%%%", where the '%'s are Base36. (This set is a superset of the current IDs, which would be an inelegant kludge.)

"G%%%%%", where the '%'s are Base36. (The same problem.)

"G%%%%%", where the '%'s are Base36, except the first, which cannot be 'C'. (This is an obvious kludge and does not yield monotonically increasing waypoint IDs given monotonically increasing cache IDs.)

"$%%%%%", where the '$' is a type designation. (This adds no information, so it is irrelevant to the exhaustion of cache IDs. However, if 'G' is a type designation, it will suffer the same problem as the two above.)So, given this short overview of my views on a few proposed situations, and taking only the exhaustion of cache IDs into account, let me make my opinion known. (Note: the type designations can be quite easily done by the user, and if anyone wants a program/web site to automatically change the prefix on all the waypoints in your .loc file, or your .gpx when that happens, I will *personally* write it just to make that irrelevant.)

Anyway, so, in my opinion, the waypoints should be "C%%%%%", with '%%%%%' being a zero-padded Base36 number. Why?

Stability: The new waypoint IDs are distinct from the old waypoint IDs. (Existing caches may continue to use "GC####".)

Inclusiveness: All caches can be referenced with the new waypoint IDs. ("GC21" is also "C0000X".)

Distinctness: Those of us who have waypoints from geocaching and other sources will still be able to sort waypoints simply, although by a new prefix.

Compatibility: The waypoint IDs will still be compatible with all 6-character GPS receivers. (Even Sis-o-Clay still uses a yellow eTrex!)

Simplicity: Base36 is quite simple to code, and the independence of prefix and cache ID is a good thing. ("GD####" and the like create a situation where the cache ID and prefix are intertwined.)

Sortability: With the zero-padded Base36 representation, any simple alphanumeric (ASCII) sort will put the caches in cache ID order. (The current non-padded waypoint IDs are not easily sortable, which makes selecting one of the newer caches in some GPS receivers and programs *much* harder than necessary.)

Durability: By using five (zero-padded) Base36 digits, the waypoint IDs use the most possible address space while maintaining the above requirements.So, now that I've said that, does anyone have any commentary on any of my particular points? I'd be more than happy to discuss particulars (but if you really want to flame, I'll send in an "Ask Slashdot" on it

).

December 1, 2002

If Base36 is used in any form then some numbers would have to be skipped to avoid the appearance of some four letter combinations which would not be appropriate for a family friendly site like geocaching.com

December 1, 2002

my opposition to base36 is simply because of the difficulty communicating both verbally (f - s, p - t) and in written form (zero - Oh, one - el).

(apologies for 'too complex')

Additionally base16 transports to other programming languages a little easier, algorithm-wise... for those of us playing with the data...

Other than that, i love it!

I'm interested in the prefix... the rest is immaterial.

~bspeng

December 1, 2002

quote:
Originally posted by orange:
The thing is now is the time to convert to a system to allow the first letter to represent something and going to GD after GC makes little sense to me. The C is meanlingless once D starts to be used. Before we hit GD why not use a system perhaps modify existing just a bit and do:

G%XXXX

where % is base 36 and XXXX is old base 16 this then gives 2,359,296 possible caches and allows for a logical progression with less chance of those accidental politically incorrect names.

Also the G could represent the cache type and as some one mentioned earlier if type change just the first letter changes but %XXXX would always only be given to only one cache.

1.4k · December 1, 2002

I already do something like this. When I started using a PDA and receiving the .loc files I was shown how to change the symbol. I took it one more step. Now I have 5 separate queries sent to me weekly. This is what I get and what I do to get it.

· Virtual un-found (eBook) (LOC) Change symbol to Lodging. Change GC to VC

· Found (eBook) (LOC) Change symbol to Dot. Change GC to AC

· Traditional un-found (eBook) (LOC) Don't change symbol. Don't change GC

· Multi un-found (eBook) (LOC) Change symbol to Hunting. Change GC to MC

· All other un-found (eBook) (LOC) Change symbol to Information. Change GC to OC

Works pretty well for me. It takes about 10 mins to get it all set up and loaded into my GPSr, EasyGPS and Mapsource mapping software. This system keeps traditional caches (the largest number) in the E-H section of the GPSr, Virtuals (second largest) in the U-Z section, Found in the A-D section and groups the Multis & others (smallest number) together.

If geocaching.com makes changes similar to this I'll go with the flow. Until then this serves me well.

====================================

As always, the above statements are just MHO.

====================================

December 1, 2002

quote:
Originally posted by bspeng:
my opposition to base36 is simply because of the difficulty communicating both verbally (f - s, p - t) and in written form (zero - Oh, one - el).

As for the verbal communication, well, we'll probably have to say more "b as in boy"-type things. Relatively speaking, though, we rarely verbally communicate waypoint IDs, and then not in bulk.

As for the written form, the numeral one/letter el issue can be remedied by using CAPS when writing the waypoint. The numeral zero/letter oh issue is less easily remedied, as different cultures use crossed/uncrossed O-shaped characters for either. (In the US, a crossed O-shaped character is a numeral zero, but in some cultures, it's exactly the opposite.) If there is a problem with the zero/oh pair, however, it would almost always be negligible. If the ID is online, copy/paste will get it right. If it's written/printed, it'll usually be with the cache name. If it's in a GPS receiver, usually the zero/oh characters are distinct enough. (Of course, you could go Base35 and just drop the letter oh to prevent the problem altogether... it'd just make the code a little worse.)

quote:
Originally posted by bspeng:
Additionally base16 transports to other programming languages a little easier, algorithm-wise... for those of us playing with the data...

Hex (Base16) is a very natural way of doing code, however, since some expansion is or will be necessary, Base36 (or Base35) seems the simplest and likely best of the alternatives available.

5k · December 1, 2002

I dunno... I'm still voting that when we hit GCFFFF, no more new caches until old ones are archived and their ID's can be recycled.

Jamie

December 2, 2002

If we can agree to disagree on the numbering(id) system, or agree as the case may be, or simply say "who cares? the numbering method is unimportant to me".

Can we agree that prefixing with the location type would be of benefit? And that since the time for change is now, because of the numbering(id) system, that this would be a good time to make the transition.

~bspeng

8.9k · December 2, 2002

Nope. Sorry.

I still disagree that variable information be kept in the waypoint name. Even if the prefix is assigned at time of printing, you have a problem with people making a reference - or a reference with any offline data.

Hey - did you see the new cache V234A4? It's pretty cool.

No - I did a search and can't find that reference anywhere

It was there yesterday - they must have archived it

Oh wait, I found it. They must have changed it to a traditional cache, because it's now C234A4. No wonder my search on waypoint names didn't work.

==================

If there is a necessity to change the system, then I vote for using a single digit prefix with the hex system (leading zeroes!). Start at H and move up from there. When we exhaust the next 1,048,575 caches, move to "I", etc. - skip the "O" (because of the similarity to between oh and zero) and the "S" because some displays make it look too close to "5".

You would STILL have 17,825,775 new cache possibilities before the system would run out. At the rate of 18,000 caches per year, it would take 990 years to run out.

Markwell

Chicago Geocaching

December 2, 2002

the waypoint search would still work!

it would disregard the first letter!

it should also properly lookup the "GC" number by recognizing (and ignoring) the "GC" (as it does now).

December 2, 2002

All this reminds me of another set of objects that need to be cataloged in large numbers... stars. We might think of geocaching numbers much like the history of star designations. Stars even have longitudes and latitudes (right ascension and declination actually) and these are sometimes used in designations.

The earliest designations were names, the majority of which were in arabic (Rigel, Betelgeuse, Aldebaran, etc.)

Bayer in his Uranometria gave greek letters to stars in each constellation. Alpha was the brightest and so on. These ran out pretty fast. (Alpha Centauri, Tau Ceti, etc.)

Flamsteed (in 1712) gave numbers to the brighter stars in each constellation going from one side of the constellation to the other (61 Cygni, 51 Pegasi, etc.)

Various big star catalogs came out that included a letter designation from the title, followed by numbers. (SAO 23454, HD 65421, BD+50°1725, etc.)

Vega, the star in the movie Contact is also called:

BD +38°3238, Alpha Lyrae, 3 Lyrae, HR 7001, GC 25466, HD 172167, SAO 67174, ADS 11510, etc.

One system similar to our present predicament is the one used for variable stars. The first variable stars catalogued by Argelander were given letter designations starting with R and going to Z within each constellation. These ran out so they went to RR-ZZ. These eventually ran out also and they went to AA-QZ. This provided for up to 334 variable stars per constellation. With photographic comparisons being done, the numbers jumped, so they gave up on letters and went to V335, V336, etc.)

Let's be farsighted and come up with a logical, not stopgap, system.

A few things to think about though:

Who wants a cache with the designation CISUCK or CMESUK, etc.? I'm sure you can think of other colorful examples.

If we do get to 8 billion caches, we wont be able to walk out our door without stepping on one. As it is right now, some US states are becoming solid green on the maps.

Star designations

Backyard Astronomer Star Names

Parsa

December 2, 2002

URL's (to cache pages) use the decimal equivalent NOT the GC#, so the only the application affected is the Waypoint Lookup (and the Cache List and Cache Page, which are display only).

Therefor, giving someone a link to a cache page is completely oblivious to the prefixing of the cache type in the waypoint.

And giving a prefixed waypoint is also oblivious to the cache type prefix.

I still say, the the upside outweighs the downside.

~bspeng

2.5k · December 4, 2002

quote:
Originally posted by Markwell:
If there is a necessity to change the system, then I vote for using a single digit prefix with the hex system (leading zeroes!). Start at H and move up from there. When we exhaust the next 1,048,575 caches,

1,048,576 caches if you start at H00000

quote:
Originally posted by Markwell:
move to "I", etc. - skip the "O" (because of the similarity to between oh and zero) and the "S" because some displays make it look too close to "5".

Actually move to J since I looks too close to "1"

H thru Z minus I,O and S leaves 16 letters

quote:
Originally posted by Markwell:
You would STILL have 17,825,775 new cache possibilities before the system would run out.

16,777,216 = 16 letters * 1,048,576 combinations

quote:
Originally posted by Markwell:
At the rate of 18,000 caches per year, it would take 990 years to run out.

932.067, and now what do you do with the extra nibble you gain when you change from the ASCII character (8 bits) to a hex character (4 bits)?

December 4, 2002

pointing out trivial errors seems(is) rude.

I don't agree with Markwell's proposed plan, but, I understood what he was talking about. I respect his opinion even though I disagree with it.

What's next? Grammar and/or spelling errors?

...'nuf said

Here's a thought to the 'bad' words problem... leave out the VOWELS... then there's no troublesome words... mostly... this is what? Base30 (no Y)?... 24 Million numbers

i don't need a system that supports 990(932) years... just about 40-50, then it's my kids problem...

For me, prefixing would be nice.

Gxxxxx - standard geocache

Vxxxxx - virtual geocache

Mxxxxx - micro

Txxxxx - multi

Lxxxxx - locationless

Wxxxxx - webcam

Exxxxx - Event

Hxxxxx - Hybrid

Uxxxxx - Unknown/Surprise

Kxxxxx - Benchmark

This would make the 2"x2" display on the gps just more informative. I think that the confusion when a cache changed type would be nearly transparent as to be ignored. And the Base30(ish) number representation would withstand the test of time.

~bspeng

8.9k · December 4, 2002

I'm getting more convinced. As long as there's a distinct gap between the coding for the old system and the coding for the new system, AND the coding for the new system makes computer logic sense, then I have no problem.

Leaving out the vowels is not a good solution, IMO. That kinda makes the programming more difficult. I think it would be better to reserve the cache ID of ID=1329077 as unavailable in base36. I'd suggest using some other STANDARD base conversion rather than piecemeal creating on to our own choosing. That way the computers do all the work.

I'd be happy with bspeng's suggestion under 4 conditions:

It would not be necessary for the search engine to have that prefix character
If someone enters the waypoint with the prefix character, it IGNORES the prefix character (harder to do...)
Leading zeroes need to be added, and
Whatever system we used to create the waypoints is an established base system, not ad hoc.

Markwell

Chicago Geocaching

December 4, 2002

See, i knew we could agree to disagree AND agree to agree!

Now, i just hope the "powers that be" are listening!

-bspeng

December 4, 2002

This has definitely been a very interesting discussion and a lot of good points have been made on how to address this problem. Let me outline our current idea and some of the reasons we've chosen it.

The current plan is to maintain the "GC" prefix, and roll over from GCFFFF to GCG000, using some form of base-36 (I'm currently working with base-32, but this can change). If I've done my math correctly, this will give us 589,832 new cache-ids. If we ever approach anywhere near that number of caches on the site, then we'll have to completely rethink the design of the site - the GCxxxx methodology will be toward the bottom of our issue list.

As Clayjar correctly pointed out, this is a kluge. When we started Geocaching.com two years ago we had no idea how this sport was going to grow. At the time, it made sense (and was super easy) to just use hex, and as a result, we inadvertently introduced the GCFFFF problem.

I understand the desire to change the prefix to provide a visual representation of the cache type, and this clearly doesn't address that. There are a couple of reasons we don't want to do this:

1. We've found that when working with geocachers, press, park officials, etc... we can almost always ask for the "gee-see" number of the cache in question. The "GC" number has become universally recognized, and from an administrative/customer service point of view, this is really important and makes our lives much easier.

2. There's an equally interesting thread on the status of the GPX format we're working on releasing soon. GPX will become the standard for downloading cache data, and it contains a ton of additional information that isn't available in the current LOC format. There's a field in the GPX file that indicates the cache type, and using this information would make it trivial for anyone to renumber the "GC" prefix to their liking based on cache type. Because of this, we feel that this renaming is best handled client-side.

I'll be more than happy to provide my code for doing this to anyone who would like it. I will require a licensing agreement though, the complete text of it will read, "You can do anything you wish with this code so long as you don't publicly make fun of Elias for his coding skills."

For those interested, here are the characters I'm using for my base-32 function. Comments on these are welcome.

0123456789ABCDEFGHJKMNPQRSTVWXYZ

-Elias

[This message was edited by Elias on April 02, 2003 at 03:24 PM.]

December 4, 2002

i still think it's okay to get away from "GC"

in several months, noboby will remember "GC"... and start using "waypoint".

I still want to "band the drum" on the points I've made... in ONE well orchestrated move, the waypoint list provided, the .LOC file, would be complete and multi-versatile (without the desire for secondary processing). At least for me... and I can't believe that I'm alone. Most of the adversity about the ideas that I've championed, seems to be against ANY change with the strongest argument being "confusion". I think that the average player would a) being able to convert, and/or not really care, c) and/or appreciate the change.

This would be a good time... when there's only 50,000 records instead of 500,000 (plus 50 times as many players) and we're firmly entrenched in a "kluge" naming system.

If you've read the original posts... the you realize the "my idea(s)" are not mine alone... and that I won't take credit for them... I will champion them, because it's a good plan.

~bspeng

December 4, 2002

quote:
Originally posted by Elias:
The current plan is to maintain the "GC" prefix, and roll over from GCFFFF to GCG000, ...
0123456789ABCDEFGHJKMNPQRSTVWXYZ
-Elias

I can't resist being the first to say this but I can't wait to find the GCGSEX cache.

I am sure there will be some other interesting combinations too.

Also be prepared for the thread from cachers wanting to name there own GC whatever when you go beyond F. (I know it has been brought up before.)

1.5k · December 4, 2002

quote:
Originally posted by orange:
I can't resist being the first to say this but I can't wait to find the GCGSEX cache.

Any four-letter word you can think of would eventually be issued, unless the code filters those in the series.

Exept that I'm dumb, and was thinking base-36 rather than base-32, with full alphanumeric... oh well.

December 4, 2002

some people look for SEX in the most usual places.

...where YOU are the search engine...

8.9k · December 4, 2002

quote:
0123456789ABCDEFGHJKMNPQRSTVWXYZ

Is this a standard somewhere in mathematical usage? That was my last point. Right now, even the simple calculator found in Windows can convert to Hex from decimal. If you're going to use a base system, why not an established one?

I still see digital display issues with S/5 and 2/Z. But like I said - can we find an established base system that is in common use today rather than just coming up with one for our own uses?

Markwell

Chicago Geocaching

December 4, 2002

In the one-five system (first digit = type, 5 digit = record number), the next occurance of "GC" does happen for long, long time.

For instance, presume this:

"GC" is equivalent to "G0" (G zero) for now.

then the sequence goes like this:

GCFFFE

GCFFFF

G10001

G10002

or

VCFFFE (virtual)

GCFFFF (regular)

L10001 (locationless)

G10002 (regular)

The entire website could (not necessarily) replace the waypoint display from "GCxxxx" to "G0xxxx" (again, G zero). This includes the .LOC files... possibly by an option flag in the user profile(?) for those that want to continue using the "GC" moniker.

The waypoint lookup application need a single IF that checks for "GC" ("xC") and maps it to "G0", then does the lookup, ignoring the "G" and converting the remainder to the record number.

This doesn't become ambiguous until after "GBFFFF" (or "GBZZZZ"), which will be a long time from now. Plenty enough time to wean off the "GC" passification.

I would like this A WHOLE LOT better than "GCGxxx".

Please, please, sleep on it...

~bspeng

December 4, 2002

It doesn't have a name... it's a programming trick. you can use FIND(excel), instr(qbasic) against the given table to determine multiplier.

some languages(utilities) do this better than others.

they're (geocache.com) doing this in order to maximize the three digits. this is why i prefer to use five digit HEX system. I think one million+ is adequate numbering (and it doesn't have the SEX problem)

i think i said this correctly.

~bspeng

[This message was edited by bspeng on December 05, 2002 at 05:16 AM.]

December 4, 2002

quote:
Originally posted by orange:
I can't resist being the first to say this but I can't wait to find the GCGSEX cache.

Good catch. I'll drop the "S".

-Elias

December 4, 2002

0123456789ABCDEFGHJKMNPQRTVWXYZ

Okay, let me make sure I'm following. So, GCFFFF is the last GC+4H (hehe) cache. After that, we're moving to GC+4 Base31 digits. The current idea is to start with GCG000 and continue from there. I'm assuming that then when we get to GCGZZZ, the next cache will be GCH000?

In other words, the first 65535 (decimal) caches are sparsely populating the Base31 numbers from 0000 (b31) through FZZZ (b31), and the caches after that will be fully populating G000 (b31) through ZZZZ (b31). So, we'll have a lot of caches left before it's time for another system.

So, am I following?

December 4, 2002

quote:
Originally posted by ClayJar:
The current idea is to start with GCG000 and continue from there. I'm assuming that then when we get to GCGZZZ, the next cache will be GCH000?

Yep, exactly.

quote:
In other words, the first 65535 (decimal) caches are sparsely populating the Base31 numbers from 0000 (b31) through FZZZ (b31), and the caches after that will be fully populating G000 (b31) through ZZZZ (b31).

I'm not sure I follow you when you say "sparsely [populated]", but the logic works like this:

If ID < 65536 then use Hex, else use Base31[iD)-411120

The 411120 is the offset between Base31(FZZZ) and Hex(FFFF). So by using hex up to FFFF and starting base 31 at G000, we've "lost" 411120 numbers. So if I've done my math right:

Hex(FFFF)=65535

and

Base31(G000)-411120=65536

quote:
So, we'll have a lot of caches left before it's time for another system.

I think that should be sufficient for a while...

-Elias

2.5k · December 4, 2002

quote:
Originally posted by bspeng:
pointing out trivial errors seems(is) rude.

I wasn't trying to be rude at all. I was just pointing out the the letter "I" would need to be removed as well, since it looks too close to the number "1". Out of curiousity I redid the calculation. I think everyone is coming up with good ideas and it's interesting to hear them all. I still think the best idea is to drop the GC altogether and utilize that word of memory to continue counting the caches in hex.

December 4, 2002

i suspect that the "GC" number is not stored in the system at all... it's constructed at print/display time from the database record number.

the field size restriction is a compatibilty issue with various GPS's, like the Magellan 315 & etrex, which are limited to six alphanumeric characters.

the "GC" moniker is a comfort issue... a "feel good" that helps slice through the techno-babble. At least that's the feeling I get from Elias' comments.

I think there's too much weight being applied to the "GC" of the waypoint display... I think we (the geocaching community) could be unfettered from this moniker.

I am aghast at the "GCG" numbering system... I can't think of anything nice to say about, so I'll keep my mouth shut... and continue to expound on the virtues of the One-Five system.

~bspeng

December 5, 2002

quote:
Originally posted by Elias:
I'm not sure I follow you when you say "sparsely [populated]", but the logic works like this:

Sparsely populated meaning the lower Base31 numbers aren't all used. By example, here are the first few Base31 waypoint IDs, with the used ones bold and the unused ones italic:

GC0001, GC0002, GC0003, GC0004, GC0005, GC0006, GC0007, GC0008, GC0009, GC000A, GC000B, GC000C, GC000D, GC000E, GC000F, GC000G, GC000H, GC000J, GC000K, GC000M, GC000N, GC000P, GC000Q, GC000R, GC000T, GC000V, GC000W, GC000X, GC000Y, GC000Z, GC0010, GC0011,...

Sparsely populated is just mathematical shorthand for saying, "There are a bunch of holes (the italics) between the numbers we're actually using (the bolds)."

December 8, 2002

Here's an extension of the ONE-FIVE system (One character cache type - five hex digit numbering system), Parking Coordinates in the ".LOC" file.

Assuming that the cache page will be expanded to include a field for suggestion parking coordinates, a waypoint with type "P" could be included in the file

for instance:

GC7FF0 N 41° 37.768 W 088° 31.527

P07FF0 N 41° 37.860 W 088° 31.252 (parking)

I sure that some of y'all with poo-poo this idea, it's just a thought... perhaps turned on/off as on option on the profile page(?).

~bspeng

8.9k · December 8, 2002

I'd Markwell you on to the other thread, but I'm too tired.

Markwell

Chicago Geocaching

December 10, 2002

Several people have commented that they have some sort of vested interest in mainting certain consistencies in the waypoint names...references to databases and 'hours of work', etc.

I'm very curious to learn specifically what folks are doing with these waypoint names and why they're so important to some?

I'm heading toward a suggestion along the lines of "do whatever you want with the waypoint names, but also give those who want it access to a raw serial number that they can convert into whatever format makes their databases happy."

ApK

December 10, 2002

quote:
Originally posted by ApK:
I'm heading toward a suggestion along the lines of "do whatever you want with the waypoint names, but also give those who want it access to a raw serial number that they can convert into whatever format makes their databases happy."

Might I rather happily comment that you are quite too late to suggest that?

In the GPX files, the "ID" is the raw, decimal serial number, and so anyone who wants to generate waypoint names from cache size, ID, type, or even the spelling quality of the hider can do so already! Isn't it a wonderful world!

(And so, once again, the virtues of the GPX files are extolled on the forum.)

8.9k · December 10, 2002

quote:
Originally posted by ClayJar:
(And so, once again, the virtues of the GPX files are extolled on the forum.)

You keep saying that, but I'm not convinced. I have yet to see an application (other than EasyGPS) that CORRECTLY handles the new format.

Markwell

Chicago Geocaching

December 10, 2002

quote:
Originally posted by Markwell:
You keep saying that, but I'm not convinced. I have yet to see an application (other than EasyGPS) that CORRECTLY handles the new format.

Oh, come on! GPX only was officially released YESTERDAY, and I had to run a little chat! At least give me a week before you start complaining I'm LATE!

(Oops, I'd better add some smileys so people don't think Markwell and ClayJar hate each other or something... Neocachers can be impressionable. )

[This message was edited by ClayJar on December 10, 2002 at 02:15 PM.]

8.9k · December 10, 2002

Nah - it's just my frustration at not being able to "do-it-myself." The web is woefully lacking in simplified explanations of how to figure out XML into something meaningful.

What I need is XML for Dummies - and how to get it into a usable format like ASCII delimited.

Then - I'm happy.

Markwell

Chicago Geocaching

5.3k · December 10, 2002

quote:
Originally posted by Markwell:
I have yet to see an application (other than EasyGPS) that CORRECTLY handles the new format.

Come on now...Within two hours of receiving the bug report you sent me I had a new release of gpsbabel on the web that fixed it. (The source version was fixed two months ago.) That meant the fix was available the same day that the Groundspeak GPX stuff was made available.

New Waypoint IDs

Recommended Posts

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment

Link to comment