Jump to content

New Waypoint IDs


MedicP1

Recommended Posts

The only immediate problem I see with that is if someone changes the cache type... Hmmm, unless when the type was changed, only the first two letters changes and no duplication of numbers was alowed to the right of the first two. In other words, the cache numbers would still increase seqentially as they are submitted, but the first 2 letters would determine the type, like:

 

GC1000

LC1001

GC1002

GC1003

VC1004

 

Women are like guns, keep one around long enough and you're going to want to shoot it.

Link to comment

I have over the past few weeks noted, on these threads, the continued complaints that people have about downloading a list of caches for an area they are going to be in, without viewing or printing the description page. They go out and hunt the area and come up with nothing icon_confused.gif, get back to their computer only to find out it was a virtual or multi-stage or other 'non traditional' cache. All because their GPSr showed them a GCxxxx cache at that location.

 

Solution why not revise the Waypoint IDs so that they show what type of cache it is. Virtual=VC, Multi=MC, etc. This way someone who doesn't like a certain type can filter out or delete them prior to downloading, or note that they have to check the page prior to hunting that one down blindly. I presently manually do this in EasyGPS prior to sending them to my unit and when I'm in an area I know what ones I want to attempt or get recon on if I have forgotten my printouts.

 

It seems like a simple solution to a ongoing problem. I am still relatively new on here, but my searches of the threads over the last couple of weeks have not turned up this topic or suggestion previously. I am unsure if it is possible or even wanted by the throngs on here so I put it forth for discussion.

 

If there is enough interest maybe we could suggest it to the powers that be.

 

It would have a few nice side benefits also, in that it would

 

1) at least triple the number of possible waypoint IDs available to be issed for caches

 

2) allow for sorting of caches by type/waypoint in EasyGPS

 

3) Give another sorting/search variable for "pocket queries" (I haven't done one so I am speculating on this one)

 

4) Allow those that dislike certain types of caches to easily delete them from their units, after a bulk download, prior to throwing their blood pressure through the stratosphere on a hunt icon_eek.gif

 

5) save space on this server and within these threads normally resultant from indivuals from 4) venting icon_mad.gificon_mad.gif

 

Hope this thread stirs up some comments.

 

GPSr's...A step in the right direction!

Link to comment

I just went surfing the other postings and found it also, I guess I should have done one more search this morning instead of just loggin on and quickly posting before I got busy at work.

 

That is very spooky though, I wonder how long they have been pondering the concept.

 

I had a few other ideas but I'll be sure to search right before I hit "Post Now"!!! LOL

 

GPSr's...A step in the right direction!

Link to comment

The thread BassoonPilot started only 3hrs before this one is right here.

This is a great idea from both of you! I also manually do something sort of like you. Originally, I appended a V/M etc to the end of GCID. Then later I just used different icons. Like i used the scenic location icon (a camera) for virtuals. Both methods require alot of manual work though, and with over 400 caches just within 35 miles of home, it rarely gets done anymore. Granted, it can turn into a adventure when you dont know icon_smile.gif, see my log from Aug.20, 2002 forMonmouth Battlefield Troop Movements for an example! It also demonstrates WHY I think you 2 are on to something good

 

Illegitimus non carborundum!

Link to comment

First let me say to BASSOONPILOT, OK how weird is it that we were both thinking about the same idea at the same time? You have to get up early to beat me to the posting...and it looks like you did LOL. I should have searched one more time this morning before posting. Was it just a brainstorm you had or have you been mulling on it for a while? Either way great idea, IMO.

 

BRDAD - I think that if it is possible to change the caches already on the system then they should have their new ID mirror their old ID as you suggested. I don't know how easy it would be to write the script to alter them, but it should only require a few downloads for most users to update the GPSr, as I see it. Then the old GCxxx ID should be recycled into the system and be reused the same as I think any deleted caches IDs should be. If our hobby continues to grow at this rate and we only use the 'GC' prfix,I wonder when we would run out of GCxxx IDs

 

GPSr's...A step in the right direction!

Link to comment

quote:
Originally posted by MedicP1:

 

Was it just a brainstorm you had or have you been mulling on it for a while?


 

I've been thinking about it for a while now ... I think we really need the ability to quickly and easily diffentiate between the various types of caches, both for planning our searches and tabulating our finds.

 

quote:
Originally posted by brdad:

The only immediate problem I see with that is if someone changes the cache type... Hmmm, unless when the type was changed, only the first two letters changes and no duplication of numbers was alowed to the right of the first two. In other words, the cache numbers would still increase seqentially as they are submitted, but the first 2 letters would determine the type, like:

 

GC1000

LC1001

GC1002

GC1003

VC1004


 

Right; with the number of caches that would need to be converted, it makes sense that the numbers should run sequentially with only the prefix changing. I think the GC prefix would still serve well as the designator for standard, "box with trinkets at the end of the walk."

 

I do realize this idea could get out of hand ... I can think of at least a dozen prefixes that might be requested (like multicaches, hydrocaches, puzzle caches, etc.) I think most of those types should remain under the generic "GC" designation ... some are already easy to distinguish by the icon the cache owner chooses to place atop the page. I'd suggest that increasing the number of icons might be of use, but that wouldn't help EasyGps users ...

 

[This message was edited by BassoonPilot on October 04, 2002 at 08:56 AM.]

Link to comment

The current waypoint assigning system (GCXXXX), can only be used for 65536 caches. Today the numbers are up to 38632. I think Jeremy has decided that the waypoints then will be called GDXXXX, GEXXXX and so on.

 

In a few years, we will need all six letters just for making unique Geocache waypoints.

Link to comment

quote:
Originally posted by Gustaf:

The current waypoint assigning system (GCXXXX), can only be used for 65536 caches. Today the numbers are up to 38632. I think Jeremy has decided that the waypoints then will be called GDXXXX, GEXXXX and so on.

 

In a few years, we will need all six letters just for making unique Geocache waypoints.


At that point we could go to:

GD1000

MD1001

VD1002

and so on, as brdad suggested.

 

Illegitimus non carborundum!

Link to comment

quote:
Originally posted by Gustaf:

The current waypoint assigning system (GCXXXX), can only be used for 65536 caches. Today the numbers are up to 38632. I think Jeremy has decided that the waypoints then will be called GDXXXX, GEXXXX and so on.


 

Not sure what school you went to, but the was I see it, if the first 2 digits represent the cache type, leaving the last 4 for the cache number, then your math is different than mine. Looks like you are using 16 bit binary to get your result?

 

Each digit in the cache number can be represented by 36 chartacters if you assume using the 26 letters of the alphabet and the numbers 0-9. Therefore, the numer of possibilities is equal to:

 

36 X 36 X 36 X 36 = 1679616

 

My math is only right if my assumption Jeremy is using all 26 letters and 10 numbers, correct me if I am wrong...

 

Women are like guns, keep one around long enough and you're going to want to shoot it.

 

Women are like guns, keep one around long enough and you're going to want to shoot it.

Link to comment

quote:
Originally posted by Elias:

The current GC numbers are generated by the 'GC' and then the hex version of the cache_id. This is how you get 65535 as the maximum number of caches.


However, having said that, I've been toying with the idea of changing the GC numbers to something closer to what brdad suggests. I wouldn't use base 36 since some characters like 'O' and 'l' look too close to other characters, but the basic idea is the same. My question is, should we renumber all previous caches to take advantage of this new proposed convention, or should we pick a "convenient" point in the number sequence and say that everything after this number uses the new format?

 

-Elias

Link to comment

quote:
Originally posted by Pubo:

What about dash marks + - and & signs?? Are there any GPS units that can't make use of these?


 

God, that avatar is disturbing, go put a dress on or something! icon_wink.gif

 

I thought about the other signs too, good idea, but if we have capability for over 1,000,000, by the time that happens probably GPSrs will have totally different naming conventions.

 

I'd vote for renaming all existing caches if it wasn't much trouble, will be a lot less confusing for newbies and those that are well, not so quick on the draw...

 

Another idea that might be good... changing all archived caches to an "AR" prefix or something similar?

 

Women are like guns, keep one around long enough and you're going to want to shoot it.

Link to comment

quote:
Originally posted by Elias:

The current GC numbers are generated by the 'GC' and then the hex version of the cache_id. This is how you get 65535 as the maximum number of caches.


 

But why do you need to stick to a two-byte cache ID? Why not GCxxxxx or GCxxxxxx?

 

OR, even if you want to stick to 6 alphanumeric characters for the waypoint names, you can still use anything up to base 33 and stick to alphanumerics, just don't use I O or S. No one says we have use the alphabet in order to represent numbers.

 

Or is there some cool technical detail I'm missing here?

 

ApK

Link to comment

Two points:

 

- I don't like the idea of changing the ID's of established caches. It'd throw too much a curve into things. There are a lot of people linking to their caches on geocaching.com from the outside.

 

Instead, use A-Z [except I, O, S, & Z] and 0-9. (In the routines that count convert excluded letters to numbers.) That gives you 32 characters and at 4 places that gives you 1048576 caches. Start at the beginning and start assigning caches in the "headroom" that you've now provided. This way no numbers go to waste. A simple check to see if the number is already assigned will do, if so, increment to the next number until you find one not used.

 

- Changing GCXXXX mulitcache into MCXXXX will not really solve the problem at hand. There are too many offset caches that are categorized as traditional caches. If you do the conversion, you'll still be running into caches that require a printout.

 

In principle, I like the idea. In fact, you could take it a little further and drop the second letter in the designation and use it in your increments. That'll give 5 places with 32 characters or 33554432--that's a lot of caches and probably wouldn't have to worry about new numbers for a while.

 

As for designations, simply use T for traditional, M for multi, L for letterbox, V for Virtuals, ...I think you get the picture.

 

CR

Link to comment

quote:
Originally posted by Sissy-n-CR:

- I don't like the idea of changing the ID's of established caches. It'd throw too much a curve into things. There are a lot of people linking to their caches on geocaching.com from the outside.


This is my feeling as well. That's why I came up with the idea of designating a number as the transition point between the old numbering and the new one.

 

quote:
Start at the beginning and start assigning caches in the "headroom" that you've now provided. This way no numbers go to waste. A simple check to see if the number is already assigned will do, if so, increment to the next number until you find one not used.

I don't want to do this. My goal is to keep the conversion based on relatively simple math. The original purpose of the GC numbering was to provide a way to "encode" the integer cache_id into something more compact. This way, other web sites or applications like Geobuddy can easily do the math to convert between the two.

 

-Elias

Link to comment

"...to provide a way to "encode" the integer cache_id into something more compact. "

 

My bad. I didn't realize my GCID was the hex of the cache_ID. Maybe I should pay more attention to earlier posts? icon_wink.gif

 

Well, as for picking a number, just pick one, a GCxxxx number that is. When ever you go Base32 you'll have a huge gap in interger numbers, but at least you wouldn't have to worry about an overlap. If you pick a interger number to start at, the GCxxxx number will be real low and you'll have duplicate waypoints.

 

Heck, you're getting pretty close to A000. That's as good of a start as any. If you have the time, that is... You'll have over 700,000 caches left to go before you have to worry about it again, instead of 24,000.

 

CR

Link to comment

Just thought of something that would make it even easier. Drop the second letter designation when it "rolls over" and go from there. You'll get almost 1 million more numbers without the hassles. Of course you'll have to skip the C0000 to CFFFF range, but you can at least wait a while before you have to deal with that.

 

Wait a little while and I might come up with something else...

 

CR

Link to comment

quote:
Originally posted by Sissy-n-CR:

Two points:

 

- I don't like the idea of changing the ID's of established caches. It'd throw too much a curve into things. There are a lot of people linking to their caches on geocaching.com from the outside.

 

CR


I thought the same thing, at first. However, changing the GC part of GCxxxx doesn't effect any links to current caches. Since the xxxx is just a hex conversion of the decimal webpage ID number used in the URL, GC1234 would still have the same URL as VC1234.

If you continue to assign caches in numerical order, then just convert them to hex and prefix the cache type, all current links will stay the same. Sure, a link labeled "GC1234" might now go to a cache page with a GCID of "VC1234", but it will still be the same cache page it always was. That slight change seems minor to have a standardized naming convention, as opposed to continually having to explian to each crop of newbies WHY some virtual caches are VCxxxx, and some are still GCxxxx.

 

Illegitimus non carborundum!

Link to comment

Can we not just take the hex value of the whole ID "GC1234" there by giving us

 

8 values (all present cache types: G=general, K=benchmarks, V=virtual, L=letterbox, M=multicache, E=event, W=webcam, U=unknown) for the first digit

 

1 value (C) for the second digit

 

34 values (0-9 A-Z omitting the O's, I's, S's, and Z's) for each of the last four digits

 

making the total number of possible cache IDs:

 

8 X 1 (32 X 32 X 32 X 32)=

8 X 1048576=

8388608

 

I don't fully understand Hex so forgive me and correct me if my equation is wrong.

 

With this thinking we will have a potential 1048576 for every catagory of cache ID we create.

 

But most important is not running out of cache IDs, as the numbers seem huge, but rather being able to sort and identify your potential cache type out in the field or at home when sorting the types you like to/don't like to hunt for.

 

GPSr's...A step in the right direction!

Link to comment

**Addendum to my last post.**

 

Or change to G to a T=tradional to match the types exactly. Then only use these new IDs for caches at some magic/opertune date. The newbies will just know that from this date forward the caches have a more specific ID system.

 

quote:
From Mopar: Sure, a link labeled "GC1234" might now go to a cache page with a GCID of "VC1234", but it will still be the same cache page it always was.

What ID will be downloaded to EasyGPS the GC1234 or the VC1234? icon_confused.gif

 

GPSr's...A step in the right direction!

Link to comment

Hows about this:

Keep the old GCxxxx intact for current caches.

 

A new numbering system with a 1 letter prefix not starting with "G" and a 5 digit Hex number (over 1000000 there)

 

The first letter would be your

T=Traditional, K=benchmarks, V=virtual, L=letterbox, M=multicache, E=event, W=webcam, U=unknown, etc.

That way you have 8 million or more cache numbers and can still use Hex. Not that I have anything against going beyond hex, but it would be much eazier to translate between hex and base10 when need be. All this while retaining GCxxxx and no new number would ever start with GC. Again, making coding of other programs eazier.

-Centaur

 

logo_small.jpg

Link to comment

If the point is to find an efficient way to designate caches after 65,535 are placed then it makes more sense from a memory perspective to just use the first two characters, ie. after GCFFFF is reached to just go with GD0001. This uses a total of two memory words (4 bytes)

 

The first two characters, GC are in ASCII and require one word of memory, one byte per character. The number after the GC requires another word of memory, one nibble per hex characters 0 thru F.

 

What makes more sense to me, is to drop the GC altogether and utilize all 32 bits of memory presently being used to count up to 4,294,967,295 caches (4,294,967,296 if you want to include a cache number zero). Then when this site is as big as McDonald's, you could brag about over 4 billion caches hidden. The waypoints can then go from 00000000 to FFFFFFFF.

 

My GPS is capable of holding an 8 digit waypoint, I assume this is the same with other GPS as well, so this system would work well into the future.

 

As for going to a base 36 numbering system for the sake of displaying waypoints, this makes less sense to me. The reason is, to store each ASCII character takes one byte of memory. Therefore, while you may be able to display a cache as GCZZZZ, the ZZZZ will cost 2 words (4 bytes) of memory plus another word (2 bytes) to display the GC, for a total of 3 memory words (6 bytes), as opposed to 2 words (4 bytes) in the example above. In either case, the max number of caches is going to be 4,294,967,296 (if you utilize all of the available memory). But who wants to count numbers with ASCII? This is illogical as well as confusing, and buys you nothing extra except for a headache.

 

So why drop the GC? Because I think we all know that we are searching for geocaches, we don't need the GC to remind us.

 

Now, if the point of changing waypoint designation is so that the hider knows whether he is looking for a virtual or multi, there already is a system in place for this. When you search for a cache by zipcode or by state, there is an icon next to that cache indicating what kind it is. Just click or unclick the caches you wish to seek before downloading the waypoints. You can edit the waypoints however you like in EasyGPS, so if you want to call it MC for multi-cache, you can already do that without disrupting the present system.

 

If you sign up for a membership, you will be given the opportunity to use pocket queries, where you can sort caches however you like and still change waypoint names in the EasyGPS software. And as a bonus, if you use a palm device, you won't even need to change the name of the waypoints, since you will have the description already. If you don't have a palm device, there is a utility to view and print pocket queries from your computer.

 

Changing the waypoint names makes little sense, and in a way takes some value away from the charter membership which pays dues to be able to have tools for better waypoint management.

 

Anyway, I'm sure that the more experienced users have already learned that it makes little sense to go searching without printouts or a palm device, or at least a little sticky note telling them which caches are virtuals.

 

[This message was edited by cachew nut on October 04, 2002 at 06:53 PM.]

Link to comment

I'll spare the non-programmers the preachy discussions about blurring namespaces and permanence of records, but most of the posts on this thread seem to be jumping on the wrong problem. Don't confuse a record number/gc#/part number/whatever with a description or thingy type. One is meant to be used by machines or processes and the other by humans for convenience.

 

What is surely one of the most popular receivers for geocaching, the yellow etrex family, only handles six character waypoint names. I think the Magellan 315 has the same limit. Yes, you can make the names even more incomprehensible and fit "more" of them in the unit; potentially even preserving some kind of prefix. It's a losing battle to attempt this up front.

 

What it sounds like most of you are really wanting is A) better searching (a problem pretty much solved by pocket queries if we could get the message out that pocket queries aren't just for PDAs) and :P smarter tools that give you a human-readable waypoint name that at least sort of matches the description but is tailored to the receiver (a problem solved somewhat by EZ/ExpertGPS and described in the forums before (hint: delete the names before handing the file to EZ) and by tools like gpsbabel) but even the accuracy of that compression can be greatly aided by having things in the *.loc like cache type and size. That's currently being spelled "GPX".

 

If the markup was present in the GPX file, the software used for waypoint upload would be free to put diff/terr/cache type in the waypoint comment if talking to a unit with waypoint comments or to smoosh them into the name. Doing it on the server side in the cache name is the Wrong Place. It's a client side decision becuase only the client knows the capabilities of the target device.

Link to comment

This issue (and many more) will be resolved when the results of Pocket Queries get returned as GPX files. I have a whole set of scripts just waiting for them to arrive. I will rename my waypoints in a manner similar to what is proposed in this thread: GC for caches, GL for locationless, GV for virtual, etc. In addition, I already generate meaningful comments using the cache name, unlike the ridiculous thing EasyGPS does where it takes out the vowels. When GPX files arrive, I'll be able to include the date the cache was last found in the comment, too, so it will be in the GPS. And, of course, we'll be able to generate our own Palm pages so we don't have to use MobiPocket.

 

Jeremy has recently said that the GPX upgrade is more than 90% complete, so I am quite hopeful that it will get rolled out this month.

Link to comment

Being a shadetree programmer, and a lousy one at that, I still don't comprehend everything just said. I'd just like to be able to download the waypoints into my GPSr and have them all sorted in there by the cache type. I have all of Maine's caches in there, so right now, my E-H section has 200+ waypoints all beginning with GC. The icon and comments won't help me there without editing the waypoints myself.

 

Also, if this is done from a clean slate, not altering existing caches, maybe GC should not be used at all anymore, so that the old ones can be identified.

 

Always proof-read carefully to see if you any words out.

Link to comment

quote:
Originally posted by MedicP1:

Can we not just take the hex value of the whole ID "GC1234" there by giving us

 

_8_ values (all present cache types: _G_=general, _K_=benchmarks, _V_=virtual, _L_=letterbox, _M_=multicache, _E_=event, _W_=webcam, _U_=unknown) for the first digit

 


 

I just want to chime in that some sort of system like this would be great!

 

I have suggested before and seems appropriate again that a P value for parking would be good too if the cache download could also have parking coordinates for those of us who like to provide them to. The P#### would then match to one of the other values and #### to let you know this is where to park for this cache.

Link to comment

quote:
I have suggested before and seems appropriate again that a P value for parking would be good too if the cache download could also have parking coordinates for those of us who like to provide them to. The P#### would then match to one of the other values and #### to let you know this is where to park for this cache.

 

Could that not be done by making it a 'route', with 'parking spot' as the start, as well as waypoints. Then it would download to the Easy/ExpertGPS, and finally our GPSrs as a route with a Geocache ID rather than a waypoint with a Geocache ID. I am still new and don't know if this is feasible.

 

GPSr's...A step in the right direction!

Link to comment

quote:
Originally posted by MedicP1:

 

Could that not be done by making it a 'route', with 'parking spot' as the start, as well as waypoints. Then it would download to the Easy/ExpertGPS, and finally our GPSrs as a route with a Geocache ID rather than a waypoint with a Geocache ID. I am still new and don't know if this is feasible.


 

I am not aware of the Geocaching site being able to download a route. It just downloads a single waypoint per cache. If a cache could be made to download a Parking coordinate too then it could be a P #### that matches to the #### of the cache of whatever type. And then when I look at my nearest points I know that first I head to the P to park and then hike to the cache from there.

Link to comment

I agree usig GD prefix after the GCFFFF, it's nice to have the G-identifier to separate the caches from my other cryptic waypoints.

Also using the whole alphabet set sounds good (restricting some characters as i & o), in that case we might need to censor certain four-letter combinations that might embarras some people icon_redface.gif

Link to comment

quote:
Originally posted by Elias:

My question is, should we renumber all previous caches to take advantage of this new proposed convention, or should we pick a "convenient" point in the number sequence and say that everything after this number uses the new format?


 

Please don't renumber. I was told previously, by Groundspeak (I can find the message if need be), that the waypoint IDs would not change. I asked in advance because I have based work on using those as unique identifiers.

 

Please, please, please don't renumber currently existing geocaches.

 

snazzsig.jpg

Link to comment

Simple solution? If the "new" waypoint convention is different than the "old" waypoint convention, just use both on the ones that have "old" waypoint IDs:

 

Waypoint Name: GHX-1138

Old Waypoint Name: GC3528

 

If there is no "old" name, just don't show it:

if ($id < 0xFFFF) printf("Old Waypoint Name: GC%x", $id);
Link to comment

quote:
Originally posted by ClayJar:

Simple solution? If the "new" waypoint convention is different than the "old" waypoint convention, just use _both_ on the ones that have "old" waypoint IDs:

 

_Waypoint Name:_ GHX-1138

_Old Waypoint Name:_ GC3528


 

If that was in reply to my post, my post was in response to the notion of reassigning currently existing caches to new IDs, which would render their old IDs invalid... The convention doesn't matter to me at all, its the reassignment of currently existing geocaches...

 

snazzsig.jpg

Link to comment

I don't see a need to change the way cache points are named. Just use your pocket queries and/or do some research and you can find out pretty quickly if a cache is a virtual or not.

 

If I check nearest caches, I can then look them up on my PDA in my pocket query to find out what kind they are.

 

I would imagine it's a pretty big change to the way the site is run, when the information can be gathered rather quickly using already established functionaliy.

 

Just my two cents.

 

--------

trippy1976 - Team KKF2A

migo_sig_logo.jpg

Link to comment

quote:
Originally posted by trippy1976:

I don't see a need to change the way cache points are named. Just use your pocket queries and/or do some research and you can find out pretty quickly if a cache is a virtual or not.


 

The reason I want them named with a distinguishing first letter is so when they are downloaded to my GPS. I can tell what the point is. If I am near a TC - traditional cache I may be able to hunt it without any other info. But if it is a VC then I know I need the info from the cache page for sure.

 

I don't own a PDA yet or carry one into the field.

 

If caches were named in new way my GPS would tell me more about nearest caches when I am hunting a specific one that I took printout for.

Link to comment

However, if you could take the existing *.LOC files resulting from a pocket query (which has NOTHING to do with a palm), and summarily change the resulting waypoints in the query, then there's little impact on the database, and still get the results you're looking for.

 

I think this would be a perfect solution for integration into the next version of Geobuddy. With Geobuddy now, you can summarily change the icons to a specific type, and also do a parameter delete using coordinate boundaries (north, south, east and west) like I had suggested in a previous thread.

 

Topografix people are you listening? In the next version of Geobuddy, some way to group change waypoint characters: GCxxxx -> TCxxxx or MCxxxx.

 

Markwell

Chicago Geocaching

"Therapy is expensive but bubble wrap is free."

Link to comment

quote:
Originally posted by Markwell:

However, if you could take the existing *.LOC files resulting from a pocket query (which has NOTHING to do with a palm), and summarily change the resulting waypoints in the query, then there's little impact on the database, and still get the results you're looking for.


 

That is a good suggestion but still most times I go out to hunt my selection is from online. I pick a cache I am going for then use the nearest feature to list them. Check off ones I want. I agree I could change stuff after download but if all new caches could be created with a distinquishing first character it would be a much easier solution.

 

I don't need more software to frustrate me.

 

Will have to look into Geobuddy. I haven't tried that. I just use the EasyGps.

Link to comment

Could the server not provide the new waypoint names in EasyGPS downloads onlywhen so requested?

 

Ie, in the DB the waypoint/cache woudl still be GCxxxx

(or GXxxxx if the DB needs to roll over to the second

character anyway), but when downloading, all waypoints

could be either listed with their DB name or descriptive

name (VXxxxx).

 

I really want the new names on my GPSr, so that I can

know whether a cache I am hunting up is a real or virtual one

(no, when I start going for a cache, I mostly have no

PDA nor notebook or web-access handy).

 

I actually suggested GCxxxx-T a few weeks ago, which would

be fine for me as myLegend takes 10 char names.

 

Again, the server could maybe also generate that format for the EasyGPS .LOC files (and the user's preference could be

stored with his user profile).

 

as for Web references. If necessary, the server could

redirect queries with the alternate names to the main page anyway.

regards

Link to comment

quote:
Originally posted by matjes:

Could the server not provide the new waypoint names in EasyGPS downloads onlywhen so requested?


This really is a client-side thing. Unfortunately, the current data format (.loc) doesn't provide the "right" information to the client and the right data format (gpx) has become the Great Unspoken Thing.

quote:

I really want the new names on my GPSr, so that I can know whether a cache I am hunting up is a real or virtual one


The post 1.0 versions of GPSBabel can make up waypoint names (no GCBLAH at all; you get real names) and when given GPX input with the Groundspeak extensions, can pick different icons in the receiver based on cache type. Right now, for example, the Magellans get binoculars for virtual caches. (Becuase you LOOK for them...)

 

I'd still rather see GPX available so client things like GPSBabel or EasyGPS can DTRT than eternal hacks on the web services...

Link to comment

quote:
Originally posted by Markwell:

The standard little yellow etrex will only accept 6 characters. Higher end models will accept 10.


Ah. Thanks Markfield for clearing that up. I guess I should do my research before opening my mouth. I used to own a yellow, and I based my information on my experience with just that one unit.

 

Jamie

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