Standard prefixes for Additional Waypoints

[+purple_pineapple]

I mentioned this low down in another thread, but thought it deserved its own topic, WITHOUT discussing the pros and cons and other aspects of additional waypoints…

 

In the absence of a GC.com prescribed format, would it be sensible for us to adopt a set list of two letter codes for additional waypoints?

 

For example

 

CP for car park

S1, S2 etc for stages of a multi (be it a fixed box or a question to answer)

T1, T2 for waypoints to guide you on a route

V1 V2 for other interesting sites to see ( a view for example)

Even BR for the nearest train station!!

 

Any others we can think of?

 

I would especially appreciate a reviewers opinion, as ideally they could request that new caches follow this naming system.

 

These are just examples – the actual codes could be discussed in a different thread if people agree it’s a good idea!

 

Cheers

 

Dave

[Deego]

TP for nice nearby trigpoint

[+Bambi&Thumper]

TP for nice nearby trigpoint

 

Used that!

 

We use PK for parking, I think because I read somewhere that PK was a compromise between the US "Parking Lot" and the UK "Car Park".

 

B.

[+Jonovich]

In the absence of a GC.com prescribed format, would it be sensible for us to adopt a set list of two letter codes for additional waypoints?

 

Why would it be sensible to lock down the aw prefix codes?

 

Jon

[+purple_pineapple]

In the absence of a GC.com prescribed format, would it be sensible for us to adopt a set list of two letter codes for additional waypoints?

 

Why would it be sensible to lock down the aw prefix codes?

 

Jon

 

Not so much locked down (that would require GC.com) but if everyone used a standard list, then (depending how we do our exports) I would know that on my GPS, a code of S1, S2 etc is part of a multi, CP or PK or whatever is parking and so on. At the moment, I have waypoints on my GPS that start with A1 - A9, B1-B9 and so on for almost every letter of the alphabet (including Z!) and lots of combinations of letters. I have no idea whether they relate to parking, multi points, or any other reason for having an additional waypoint...!

[+qichina]

I think it's a really good idea. It would really help make sense of the data with downloads to Cachemate, GSAK etc. Without a system, it's a bit of a dog's breakfast at the moment.

Cheers,

Qichina

 

 

In the absence of a GC.com prescribed format, would it be sensible for us to adopt a set list of two letter codes for additional waypoints?

 

<snip>

I would especially appreciate a reviewers opinion, as ideally they could request that new caches follow this naming system.

 

These are just examples – the actual codes could be discussed in a different thread if people agree it’s a good idea!

 

Cheers

 

Dave

[+Mad H@ter]

Don't start me on this one

 

I brought this up on the main forums when the additional waypoints were introduced but it appeared to be totally ignored. As you say it is a complete "dog breakfast", which is a real shame as this could have so easily have been a really useful addition.

 

I use the following on any caches that we place which is actually very similar to that suggested by PP:

 

They are all a letter followed by a sequential number on the basis that you may have more than one, i.e. you may have more than one recommended parking spot although it is unlikely that you will have more than one final location!

 

F1 – Final location

P1 – Parking area

Q1 – Question to answer

R1 – Reference point

S1 – Stage of a Multi-Cache

T1 – Trailhead (not too sure what this is!)

 

The only problem I can see is if you exceed 9 or 10 waypoints in a category, most likely for stages. A possible solution to this would be to have a numerical only prefix for stages i.e. 01 02 etc.

[+Munkeh]

bit late who is going to bother changing the waypoints that have already done

[+Jonovich]

Not so much locked down (that would require GC.com) but if everyone used a standard list

 

That is exactly the problem... If it is not Locked down then you can never rely on the prefix to adhere to a standard list. And if you do lock it down, you loose the flexibility of an open system.

 

As long as you have the cache description with you and the additional waypoint information is presented with it, then it's just a case of cross referencing the waypoint name and away you go.

 

Jon

[+purple_pineapple]

Not so much locked down (that would require GC.com) but if everyone used a standard list

 

That is exactly the problem... If it is not Locked down then you can never rely on the prefix to adhere to a standard list. And if you do lock it down, you loose the flexibility of an open system.

 

As long as you have the cache description with you and the additional waypoint information is presented with it, then it's just a case of cross referencing the waypoint name and away you go.

 

Jon

 

Agreed, but for ease of reference on a GPS like mine that only takes 6 digits, and also on cachemate, it would certainly be a help. If I see a CP/PK code on the GPS that relates to the cache I'm about to do, I can follow that to park the car, and then refer to the description to see what stages I need to do. Alternatively, I can use a map view and immediately see what order I have to do a series of multis in, without having to check the description every time, because the prefix doesn't use any sequential numbering. (Obviously, these are hypothetical situations, but I still maintain that uniformity is best!)

 

Another thought - as kiwi gary said, some people don't need parking coordinates, so the ability to strip them out of any exports from GSAK would be very helpful - this is only possible though if they follow a naming convention.

 

To try and maintain adherence to a standard list was the reason I asked for reviewer input, as it would be need a certain amount of input from them during the reviewing process (when they check the AWs anyway) to ask if the prefixes can follow a standard.

 

Surely a standard format is a plus point (and codes can be added to 'the list' whenever they are needed). This already exists for every cache anyway (the GC bit) and also for every Geocoin...

[+Bambi&Thumper]

Agreed, but for ease of reference on a GPS like mine that only takes 6 digits,

 

You are gonna have so much of fun when there are envough caches that we have to have 7 character codes!

 

and also on cachemate, it would certainly be a help. If I see a CP/PK code on the GPS that relates to the cache I'm about to do, I can follow that to park the car, and then refer to the description to see what stages I need to do. Alternatively, I can use a map view and immediately see what order I have to do a series of multis in, without having to check the description every time, because the prefix doesn't use any sequential numbering. (Obviously, these are hypothetical situations, but I still maintain that uniformity is best!)

 

I agree - Uniformity is best! And things do change as people do maintainance and update stuff and caches get archived. Just because there are caches that exist that have been grandfathered isn't an excuse for letting the chaos continue.

 

Another thought - as kiwi gary said, some people don't need parking coordinates, so the ability to strip them out of any exports from GSAK would be very helpful - this is only possible though if they follow a naming convention.

 

To try and maintain adherence to a standard list was the reason I asked for reviewer input, as it would be need a certain amount of input from them during the reviewing process (when they check the AWs anyway) to ask if the prefixes can follow a standard.

 

Yes, without reviewer/TPTB support, this is not going to be a success. Why don't you ask on the site forum and with a little support from the rest of us (like the livestock attribute) we might get them to listen. All it needs is a suggested set of characters on the create waypoints page... That way we have a formula and yet retain the flexibility.

 

Surely a standard format is a plus point (and codes can be added to 'the list' whenever they are needed). This already exists for every cache anyway (the GC bit) and also for every Geocoin...

 

Yes, there's GC but also also WP and WM, though I can't imagine what that might be protected for!

 

B.

[+Jonovich]

Agreed, but for ease of reference on a GPS like mine that only takes 6 digits, and also on cachemate, it would certainly be a help. If I see a CP/PK code on the GPS that relates to the cache I'm about to do, I can follow that to park the car, and then refer to the description to see what stages I need to do.

 

To find that the cache setter is not a forum reader and used PK prefix to indicate a nice nearby location play with Kites. (Obviously, these are hypothetical situations)

 

To try and maintain adherence to a standard list was the reason I asked for reviewer input, as it would be need a certain amount of input from them during the reviewing process (when they check the AWs anyway) to ask if the prefixes can follow a standard.

 

I thought the AW's were to simplify the appovers role.. adding naming conventions and rules that have to be checked will have the opposite affect.

 

J

[+purple_pineapple]

 

To find that the cache setter is not a forum reader and used PK prefix to indicate a nice nearby location play with Kites. (Obviously, these are hypothetical situations)

 

touche - although with standardised codes, the cacher would find out the PK is for parking, and therefore and he should use KP for kite playing (and don't even go down the crisp-eating-area road! And also, if PK was 'allowed' for a kite-playing area, then can you imagine all the cache-mobiles getting string round the axles

 

I thought the AW's were to simplify the appovers role.. adding naming conventions and rules that have to be checked will have the opposite affect.

 

 

Maybe, maybe not - thats why I was hoping for some reviewer opinion! If they're allowed one!

[+Jonovich]

I'm actually all for having a formalised Additional Waypoint naming standard, but I cannot see one working reliably based on simple recommendations or guides. Having Geocaching prompt you for the type of AW you are adding from a pull down list and then having it generate the prefix for you would be the only approach I can see where you would then be able to happily assume your PK's are nothing to do with Kites. And this of course assumes the cache setter is not a complete yoghurt.

 

Jon

[+Master Mariner]

I like uniformity and have tried to implement it for the multi-national company I work for. I forgot that not every one speaks English so had to ditch the idea as TPTB in my company would not support it. I think this is not "locked down" for this very reason.

[+purple_pineapple]

I'm actually all for having a formalised Additional Waypoint naming standard, but I cannot see one working reliably based on simple recommendations or guides. Having Geocaching prompt you for the type of AW you are adding from a pull down list and then having it generate the prefix for you would be the only approach I can see where you would then be able to happily assume your PK's are nothing to do with Kites. And this of course assumes the cache setter is not a complete yoghurt.

 

Jon

 

I must take issue with this post Jon.... Your last sentence caused a certain amount of sniggering in our very quiet write-up room at work, which was most embarrassing! Yoghurt???

 

Anyway, I totally agree that the above system would be ideal, and probably the best method. Until this time, I merely propose an alternative....

[+Jonovich]

I must take issue with this post Jon.... Your last sentence caused a certain amount of sniggering in our very quiet write-up room at work, which was most embarrassing! Yoghurt???

Sorry, blatently stolen punch line from Red Dwarf

 

Who would permit this man, this joke of a man, this man who could not outwit a used tee-bag, to be in a position where he might endanger the entire crew? who …. Only a yoghurt! This man is only guilty of being Arnold J Rimmer. That is his crime, it is also his punishment!"

 

Anyway, I totally agree that the above system would be ideal, and probably the best method. Until this time, I merely propose an alternative....

Indeed, and a very good idea, but I'm afraid there are too many Yoghurts about to make it reliable

 

Jon

[Deceangi]

Maybe, maybe not - thats why I was hoping for some reviewer opinion! If they're allowed one! biggrin.gif

 

Ok Reviewer here opening his mouth I'd suggest the following

 

Type: Drop Down List, pick choice

 

Name: GC???? Parking 1/2//3/4/5/6/7/8/9 Final [chose one choice plus the GC No]

 

Waypoint Lookup Code: Parkng stage1/2/3/4/5/6/7/8/9 Final [chose one choice]

 

Prefix Code: PK S1/2/3/4/5/6/7/8/9 FN [chose one choice]

 

Which is a standard format being suggested by other Reviewers to cachers in their areas.

 

Example

Type: Stages of a Multicache

Name: GC????1

Waypoint Lookup code: Stage1

Prefix code: S1

[Alan White]

Another thought - as kiwi gary said, some people don't need parking coordinates, so the ability to strip them out of any exports from GSAK would be very helpful - this is only possible though if they follow a naming convention.

That's not quite true. One of the benefits of the AWs (unlike the main coords ) is that they're typed. So it's easy to exclude parking coords from GSAK exports by not exporting waypoints which have a type of "Parking Area".

[+purple_pineapple]

Another thought - as kiwi gary said, some people don't need parking coordinates, so the ability to strip them out of any exports from GSAK would be very helpful - this is only possible though if they follow a naming convention.

That's not quite true. One of the benefits of the AWs (unlike the main coords ) is that they're typed. So it's easy to exclude parking coords from GSAK exports by not exporting waypoints which have a type of "Parking Area".

 

fair point, I stand corrected! I suspected as I was typing that this morning, and not having GSAK in front of me, that I would be proved wrong!

[+purple_pineapple]

I must take issue with this post Jon.... Your last sentence caused a certain amount of sniggering in our very quiet write-up room at work, which was most embarrassing! Yoghurt???

Sorry, blatently stolen punch line from Red Dwarf

 

Who would permit this man, this joke of a man, this man who could not outwit a used tee-bag, to be in a position where he might endanger the entire crew? who …. Only a yoghurt! This man is only guilty of being Arnold J Rimmer. That is his crime, it is also his punishment!"

 

Anyway, I totally agree that the above system would be ideal, and probably the best method. Until this time, I merely propose an alternative....

Indeed, and a very good idea, but I'm afraid there are too many Yoghurts about to make it reliable

 

Jon

 

A man with good taste there - both pineapples should have recognised it!

Oh, very cynical by the way - even if that might be the case!

 

Anyway, I'm getting off my soap box for a bit and see if anyone else wants to say anything!

[+Paul G0TLG]

I've come a bit late to this particular party - but I agree, a bit of standardisation must be good. GSAK exports the additional waypoints by waypoint code, rather than associating them with the cache name*, so the code is the first thing that pops up on the GPS screen. Knowing that having done "S1", the next stage is "S2" is helpful

 

*Unless someone knows different of course

 

And yes, there are some total yoghurts out there who'll stuff the system, either deliberately or through inexperience - we were all inexperienced once, and I'm sure we've all done daft things (I know I have). But the way to eat an elephant is one mouthful at a time, a convention is just that - it starts with a few people doing something, and then grows.

 

And if a few people still don't do it...a convention that's almost universal is still better than no convention at all.

[Lactodorum]

This reviewer also thinks a standard set of codes would be an excellent idea and I think Deciangi's suggestions are an excellent start. If/when a set are agreed I think we should create a reviewer note template to share them with new cache setters.

 

Just to correct one misunderstanding

I thought the AW's were to simplify the appovers role

No that is not the case. While it is true that they can be used in conjunction with a new reviewer tool when checking new caches this was NOT their primary purpose. As I see it, they are there to enable cachers to download extra information for THEIR use.

 

Of course whether or not this is being achieved yet is a matter for discussion elsewhere

[+wizard1974uk]

What about:

 

PH - Public House

[+ClydeE]

I've come a bit late to this particular party - but I agree, a bit of standardisation must be good. GSAK exports the additional waypoints by waypoint code, rather than associating them with the cache name*, so the code is the first thing that pops up on the GPS screen.

 

*Unless someone knows different of course

 

Yes, that is the default. However you can change your export to just about anything you like using special tags. For example, in your waypoint name you probably currently just have entered the special tag of %code. This will result in the "parent" waypoints having the GCXXXX code and the child/additional waypoints having the S1XXXX or S2XXXX or whatever code. Now if your GPSr will accept 8 characters or more you can configure GSAK to have the child/additional waypoints show up as GCXXXXS1, GCXXXXS2, etc. This will then bring your Parent and child waypoints together in your GPSr when you sort by waypoint name.

 

The corresponding special tags to do this would be:

 

%code %children %code%c_prefix

 

For more information on how GSAK handles the additional/child waypoints see this link

 

For more information of special tags see this link

 

Note: Even if your GPSr will only accept 6 character waypoint names you could still get parent and child waypoints to sort together using:

 

%drop2 %children %drop2%c_prefix

 

Well, at least until the GC codes roll over to 7 characters