Additional Waypoints

[Lactodorum]

As most, if not all of you will know since January of this year it has been possible to include "Additional Waypoints" on cache pages. Instructions on how to add them can be found in the FAQ.

 

As well as providing extra information for geocachers, these waypoints are now used to streamline the reviewing process, for example when checking proximity issues.

 

As the number of new cache submissions has been increasing Deceangi and I need to make use of every tool available and this includes Additional Waypoints. Manually transcribing coordinates from "Notes to Reviewer" is no longer an acceptable way of working I'm afraid and could lead to an extra delay in getting your cache published.

 

With immediate effect we are asking every person who submits a multi or puzzle cache to supply details of ALL intermediate and final waypoints as Additional Waypoints. We are continuing to suggest that details such as parking coordinates and suggested routes be entered this ay as well on ALL caches.

 

I hope you understand whay we are doing this. Many thanks for your cooperation.

 

Lactodorum & Deceangi

[+Learned Gerbil]

How do you input "suggested routes" when there is no suitable Waypoint category provided?

[Lactodorum]

I agree there's an apparent omission in the aypoint types. Until this is rectified I find most people are using the "Trailhead" type. This seems to work adequately.

[+Kryten]

How do you input "suggested routes" when there is no suitable Waypoint category provided?

 

There has been a lot of discussion of this point on the web features forum with many demands for a type "other" waypoint but so this has fallen on deaf ears. It seems we are stuck with only those waypoint categories deemed appropriate by TPTB.

[Lactodorum]

How do you input "suggested routes" when there is no suitable Waypoint category provided?

 

There has been a lot of discussion of this point on the web features forum with many demands for a type "other" waypoint but so this has fallen on deaf ears. It seems we are stuck with only those waypoint categories deemed appropriate by TPTB.

 

Just been discussing this with TPTB and a "Reference" waypoint will be added shortly.

[+Learned Gerbil]

I am well experieinced regarding the deaf ears - I fully intend to add the "other" waypoints when there is a category appropriate for them. "Trailhead" just doesn't do for me. I am afraid I am a "if they broke it, why should I fix it?" sort of person.

 

I also wish these waypoints were easier to uinput. If you have half a dozen or more it takes ages entering each one at a time instead of completing them in one go.

 

BTW, TPTB are not in my good books at the moment as they also will not fix the broken email address validation in the sign-up dialogues. A good friend has started caching but cannot register finds as her only email address is flagged by GC.com as illegal when it is perfectly legitimate. Her only internet access is at work, her employer has a strict email address allocation policy (as is essential when you have well over 100,000 users) and they discipline people using third party mail accounts on the work system for understandable security reasons.

 

So far the suggested solutions are - she a) buy a computer, or go to an internet cafe, create a new mail account, and visit the cafe every time she needs to access her account. She has no interest in doing either when she has a perfectly good internet connection at work. Instead she has sensibly chosen option c) abandon geocaching and adopt more welcoming hobbies.

[+Kryten]

Just been discussing this with TPTB and a "Reference" waypoint will be added shortly.

 

I heard the term banded about but what is a "reference" waypoint ?

[Lactodorum]

Just been discussing this with TPTB and a "Reference" waypoint will be added shortly.

 

I heard the term banded about but what is a "reference" waypoint ?

 

It's essentially "Other" - it can be used to "Reference" places along a trail etc.

[+dino-irl]

.....A good friend has started caching but cannot register finds as her only email address is flagged by GC.com as illegal......

 

....So far the suggested solutions are - she a) buy a computer, or go to an internet cafe, create a new mail account, and visit the cafe every time she needs to access her account. She has no interest in doing either when she has a perfectly good internet connection at work. Instead she has sensibly chosen option c) abandon geocaching and adopt more welcoming hobbies.

Why can't you create a webmail address for her, accept the validation email and validate it, log in and change it to her work email?

 

Or am I missing something?

[+Chaotica_UK]

Do you have a really good example of a cache with waypoints added so we can all see how to do this in the best way?

[+Learned Gerbil]

Thanks forthe news about the reference point It is very welcome - Lacto, I had not seen your post when I wrote mine!

 

As for dino's suggestion, what do you think the validation routine does when you change the address to the work address with the perfectly valid non-alphabetic character in it? There is also a second problem, she is no longer interested in geocaching, or registering with the site as it unreasonably rejects a part of her name! Note this is not an uncommon character in names from Africa, or indeed, Ireland.

[+Hi-Tek]

Just been discussing this with TPTB and a "Reference" waypoint will be added shortly.

I heard the term banded about but what is a "reference" waypoint ?

It's essentially "Other" - it can be used to "Reference" places along a trail etc.

On a similar topic, Jeremy did say a while ago link in a response to this post that there would be a mechanism in place to stop entering co-ords for the various 'additonal waypoints' that are identcal to the 'main' cache co-ords. Do you know if this has been implemented yet Lacto?

[Lactodorum]

On a similar topic, Jeremy did say a while ago link in a response to this post that there would be a mechanism in place to stop entering co-ords for the various 'additonal waypoints' that are identcal to the 'main' cache co-ords. Do you know if this has been implemented yet Lacto?

 

 

I don't think so. I'm fairly sure I've seen it happen in the past few days.

[Lactodorum]

Do you have a really good example of a cache with waypoints added so we can all see how to do this in the best way?

 

I've seen quite a few very good examples but of course I can't recall them now . So if anyone has a cache which they think is a good example of Additional Waypoint usage please feel free to post a link here. In the circumstances you won't be accused (by me!) of "cache advertising"

[+Lost in Space]

 

I've seen quite a few very good examples but of course I can't recall them now .

 

Red wine and scrumpy tends to do that to you............

[+Jango & Boba Fett]

I've seen quite a few very good examples but of course I can't recall them now . So if anyone has a cache which they think is a good example of Additional Waypoint usage please feel free to post a link here. In the circumstances you won't be accused (by me!) of "cache advertising"

In NC5 The Nelson Touch there are 13 Waypoints, but then it is about 10 miles from the nearest cache. As its a longish walk there are two alternative car parks, one for each of the 6 stages of the multi, a Final Cache and 4 other waypoints which relate to the overal maritime theme of the cache.

[+The Golem]

Do you have a really good example of a cache with waypoints added so we can all see how to do this in the best way?

 

I've seen quite a few very good examples but of course I can't recall them now . So if anyone has a cache which they think is a good example of Additional Waypoint usage please feel free to post a link here. In the circumstances you won't be accused (by me!) of "cache advertising"

 

 

Here's one...

[+dino-irl]

As for dino's suggestion, what do you think the validation routine does when you change the address to the work address with the perfectly valid non-alphabetic character in it?

I was assuming that validation was to validate the account only and that you could use whatever email you wanted thereafter. Obviously I was wrong.

 

There is also a second problem, she is no longer interested in geocaching, or registering with the site as it unreasonably rejects a part of her name! Note this is not an uncommon character in names from Africa, or indeed, Ireland.

Fair enough but if you/she had stuck at it and maybe got a reviewer involved then maybe you might have got it sorted out and the problem wouldn't happen for other people in the future.

 

Out of interest what is the character anyway and why is it so bad?

[+Learned Gerbil]

'

 

As for why it is so bad - badly written mail validation routines assume that as a non-alphanumeric character it is not valid in the local part of addresses, however, the relevant protocols do not list it as a non-valid character and my friend has never had problems connected with her email address so obviously the character is valid.

[Alan White]

On a similar topic, Jeremy did say a while ago link in a response to this post that there would be a mechanism in place to stop entering co-ords for the various 'additonal waypoints' that are identcal to the 'main' cache co-ords. Do you know if this has been implemented yet Lacto?

I do hope not, as that would defeat the purpose of having structured data for the waypoints.

 

Thankfully, I don't see anywhere in that thread where Jeremy said he would do it.

[alistair_uk]

On a similar topic, Jeremy did say a while ago link in a response to this post that there would be a mechanism in place to stop entering co-ords for the various 'additonal waypoints' that are identcal to the 'main' cache co-ords. Do you know if this has been implemented yet Lacto?

I do hope not, as that would defeat the purpose of having structured data for the waypoints.

 

Thankfully, I don't see anywhere in that thread where Jeremy said he would do it.

I have to say that I agree with you Alan, but Hi-Tek and I have had this discussion and after an in-depth look at the situation had to agreed to respectfully disagree. What I guess I am saying is that it is probably best to to discuss that in this thread or it will just run and run.

[+rutson]

'

 

As for why it is so bad - badly written mail validation routines assume that as a non-alphanumeric character it is not valid in the local part of addresses, however, the relevant protocols do not list it as a non-valid character and my friend has never had problems connected with her email address so obviously the character is valid.

 

As I read RFC2822, the following characters are valid in the username portion of an email address:

 

abcdefghijklmnopqrstuvwxyz0123456789!#$%&*+-/~

[+Hi-Tek]

On a similar topic, Jeremy did say a while ago link in a response to this post that there would be a mechanism in place to stop entering co-ords for the various 'additonal waypoints' that are identcal to the 'main' cache co-ords. Do you know if this has been implemented yet Lacto?

I do hope not, as that would defeat the purpose of having structured data for the waypoints.

 

Thankfully, I don't see anywhere in that thread where Jeremy said he would do it.

Oh he did see Link

 

I have had this discussion with Alastair and others and still cannot see any valid reason why an 'additional' waypoint should be the same as the 'main' cache. If it is then it is not an 'additional' waypoint in my view.

 

As I discussed with Alastair, when using mapping programs on your GPS it is not very helpful to have icons superimposed over one another! There is a cache listed in the UK that has the exact same co-ords for the 'main' cache, 'parking' and 'stages for a multicache'. When I drive past what icon do I see? Yes, I can program GSAK or whatever to ignore the 'spurious' waypoints but why post them in the 1st place? Why not just post the 'main' co-ords and leave out the duplicate ones?

[alistair_uk]

I have had this discussion with Alastair and others and still cannot see any valid reason why an 'additional' waypoint should be the same as the 'main' cache. If it is then it is not an 'additional' waypoint in my view.

...and my view was that as an additional waypoint is the only way for me to automatically identify that a particular coordinate is specifically parking of whatever, and that any filtering for the GPS that has problems with this data should be done at the upload stage and not cripple the database for us with devices that this actually helps on. I also have safety concerns about Hi-Tek logging caches while travailing at 70mph.

 

Why not just post the 'main' co-ords and leave out the duplicate ones?

Because the computer does not know that the main coordinates are the... No, wait, we are going round in circles again. I will be quite now :-)

[Alan White]

I have had this discussion with Alastair and others and still cannot see any valid reason why an 'additional' waypoint should be the same as the 'main' cache.

I can see your argument in the case of a traditional cache. For multis and mysteries then the main coords have to be something which is bound to be repeated in the additional waypoints, since the main coords can't be that of the cache.

 

Why not just post the 'main' co-ords and leave out the duplicate ones?

The problem is historical, because caches have to have main coords but those coords can't be classified. If the cache database were being designed from scratch with the knowledge we have now, then the likelihood is that there would be no main coords. All the coords would be in the "additional" waypoints so they could be correctly classified. With the current design, and like it or not, there is a need to have duplication.

 

All that said, I've just seen a couple of traditional caches which do have additional waypoints of type FINAL and the coords the same as the main coords. I can't see a lot of point in that. And just to make it worse, the owner says "Plenty of free parking" but doesn't provide the coords for it

[+mumbo jumbo]

Not sure quite how on topic this is but what are the prefixes for on the additional waypoints? They seem completely superfluous to me. Also, I was under the impression that as a cache owner I would be able to see all additional waypoints including ones hidden from other cachers eg final co-ords. This doesn't seem to be the case with any of my caches.

 

MJ

[Alan White]

what are the prefixes for on the additional waypoints? They seem completely superfluous to me.

The prefix is simply to provide uniqueness of the waypoint code. There are few restrictions on what you can use, and no guidelines on what you should use.

 

Also, I was under the impression that as a cache owner I would be able to see all additional waypoints including ones hidden from other cachers eg final co-ords.

You can see the hidden waypoints only on the waypoint maintenance page. It was done like that so that cache owners didn't think that everyone could see the hidden waypoints.

[+mumbo jumbo]

Thanks Alan.

[+Kryten]

New additional waypoint type "reference" now available from a browser near you.

[+Learned Gerbil]

 

As I read RFC2822, the following characters are valid in the username portion of an email address:

 

abcdefghijklmnopqrstuvwxyz0123456789!#$%&*+-/~

 

I am not sure which bit you are reading but the bit that says ' is valid in the username is -

 

addr-spec = local-part "@" domain

 

local-part = dot-atom / quoted-string / obs-local-part

 

atext = ALPHA / DIGIT / ; Any character except controls,

"!" / "#" / ; SP, and specials.

"$" / "%" / ; Used for atoms

"&" / "'" /

"*" / "+" /

"-" / "/" /

"=" / "?" /

"^" / "_" /

"`" / "{" /

"|" / "}" /

"~"

 

dot-atom = [CFWS] dot-atom-text [CFWS]

 

dot-atom-text = 1*atext *("." 1*atext)

[+Simply Paul]

"!" / "#" / ; SP (eh?), and specials.

"$" / "%" / ; Used for atoms

"&" / "'" /

"*" / "+" /

"-" / "/" /

"=" / "?" /

"^" / "_" /

"`" / "{" /

"|" / "}" /

"~"

dot-atom = [CFWS] dot-atom-text [CFWS]

dot-atom-text = 1*atext *("." 1*atext)

Isn't that how Pete on Big Brother speaks?

[+Hi-Tek]

...and my view was that as an additional waypoint is the only way for me to automatically identify that a particular coordinate is specifically parking of whatever,

precisely what I was trying to get across to you in our earlier discussion.

and that any filtering for the GPS that has problems with this data should be done at the upload stage and not cripple the database for us with devices that this actually helps on.

So how do you deal with a multi cache that has the same main cache co-ords, the same parking co-ords and the same co-ords for 'stages of a multicache? I use GSAK/Memory Map and MapSource and find I need to manipulate the co-ords to get rid of the unnecessary duplicates to make the maps /sensible/readable.

I also have safety concerns about Hi-Tek logging caches while travailing at 70mph.

Ha bloody ha, you are a comedian aren't you? Unless you're a pheasant you have no worries driving with me (ask Pharisee or Omally, we've spent many a mile together in my car/s). For clarity what I said was when I was driving I look at the map to see if there are any potential caches nearby - I certainly made no reference to 'logging' caches at 70mph, though even if I did it is no concern of yours - we each play this game as we please.

[Alan White]

So how do you deal with a multi cache that has the same main cache co-ords, the same parking co-ords and the same co-ords for 'stages of a multicache?

I know you were asking alistair_uk, but I'm also interested in this discussion. If I could just clarify the question: this cache has the main coords (naturally); it has parking coords; and it has a stage of a multicache coords. All these coords are the same. Have I got that right?

 

So let's consider why those sets of coords are there. The main ones, as I said in a previous post, are historic. Each cache page must have a set of coords and until recently those were the only ones which were structured. But even though they were structured there was and is no way, other than textual, of classifying what those coords were. Now that we have properly structured and typed coords in the "additional" waypoints, the main coords of a multi can be regarded as redundant. Provided, of course, that the cache owner has given the same coords in the waypoints. So the best way to deal with these main coords could be simply to ignore them.

 

The parking and stage coords are presumably the same because the first stage is at or close to the parking. A information board in a car park, typically. In this case, it is in my view correct that there are two waypoints with the same coords because they are different types. The only other option for a cache owner is to have just one waypoint and classify it in a way which isn't representative of the true meaning. So no-one would be able to tell what those coords were: parking, stage, or a combination. Separate waypoints provides clarity and aids programming.

 

I use GSAK for all cache trip planning. When I grab parking coords for a trip I want to get all the parking coords. I also want all the stage coords. I want these to be named differently and to have different symbols when they get to the GPS/PDA. Multiple waypoints is the only way to do this. If the cache owner hasn't provided them then I add them myself. So that's how I deal with them, because it's "the right way". Yes, this means that waypoints can overlay each other. If I were bothered by that then I'd simply exclude some waypoints, but that would remove the benefits of having the other waypoints.

 

"Additional" waypoints provide capabilities that we didn't have before, and those capabilities are evolving to make trip planning much easier and more informative than it used to be. And because the data is properly structured it's simple to ignore/include/exclude any waypoint according to one's own requirements. I just don't think that restrictions on what coords can be stored will help either of us.

[+Pharisee]

"Additional" waypoints provide capabilities that we didn't have before, and those capabilities are evolving to make trip planning much easier and more informative than it used to be.

 

Exactly so... "Additional" waypoints, to my mind, should be just that... additional. On my caches they do not include the main cache co-ordinates. On some of my multis, the main quoted co-ordinates are for a suitable parking place and this is quite clearly stated in the cache page text. I do not then include parking co-ordinates as additional waypoints.

 

That will probably upset some and raise a cheer from others.... You can't please everybody and has been said so many times before..... "It's only a game. Play it your way."

[+purple_pineapple]

I've been watching both sides of this debate with interest, and have to say I was originally siding with Hi-Tek. However, Alan's excellent post above has changed my view completely! A single point may well be both parking coords, a multi stage, and possibly also the main cache coords.

 

As far as I can see, the only way of avoiding 'unnecessary' duplication would be to have the main cache coords as something rather random - a local train station maybe? Would this help? Is that allowed (making it clear on the cache page, of course)? If so, I may start doing that on our own caches!

 

Dave

[+GeoJohar]

 

With immediate effect we are asking every person who submits a multi or puzzle cache to supply details of ALL intermediate and final waypoints as Additional Waypoints.

Lactodorum & Deceangi

 

I'm guessing that you would delete these additional waypoints at the end of the review and before publishing. Right?

 

GeoJohar

[+Pharisee]

As far as I can see, the only way of avoiding 'unnecessary' duplication would be to have the main cache coords as something rather random - a local train station maybe? Would this help? Is that allowed (making it clear on the cache page, of course)? If so, I may start doing that on our own caches!

 

Dave

 

Doesn't that defeat the object of having a 'Main' cache co-ordinate at the top of the page? If TPTB had intended you to include the 'Main' co-ordinates, why did they call the new feature 'Additional' waypoints and still leave the main co-ordinate field as a compulsory feature on the cache submission page?

[Deceangi]

 

With immediate effect we are asking every person who submits a multi or puzzle cache to supply details of ALL intermediate and final waypoints as Additional Waypoints.

Lactodorum & Deceangi

 

I'm guessing that you would delete these additional waypoints at the end of the review and before publishing. Right?

 

GeoJohar

 

The Additional Waypoints requested are submitted as "Hidden" ones. This means that only the cache owner and reviewers can see them, the cache owner can only see them if they go to the Edit Waypoint page for that cache.

They are used when we review new caches to insure that the new cache does not break the 0.10 mile guideline.

 

Deceangi

[+civilised]

 

 

The Additional Waypoints requested are submitted as "Hidden" ones. This means that only the cache owner and reviewers can see them, the cache owner can only see them if they go to the Edit Waypoint page for that cache.

They are used when we review new caches to insure that the new cache does not break the 0.10 mile guideline.

 

Deceangi

 

Just to clarify - what happens if an Additional Waypoint ( ie a stage of a multi ) is within .01 of a mile of another Additional Waypoint ( ie a stage of a multi ) - but the 2 actual cache locations are outside the .01 of a mile ?

 

What I'm trying to ask is - do stages of a multi count towards the .01 of a mile guideline ?

 

Thanks Deceangi

 

civilised

[+purple_pineapple]

As far as I can see, the only way of avoiding 'unnecessary' duplication would be to have the main cache coords as something rather random - a local train station maybe? Would this help? Is that allowed (making it clear on the cache page, of course)? If so, I may start doing that on our own caches!

 

Dave

 

Doesn't that defeat the object of having a 'Main' cache co-ordinate at the top of the page? If TPTB had intended you to include the 'Main' co-ordinates, why did they call the new feature 'Additional' waypoints and still leave the main co-ordinate field as a compulsory feature on the cache submission page?

 

It does rather, I agree. However, Alan posted a good argument (for me anyway!) that the structured additional waypoints are most helpful if they include all the relevent points. So multi stages can each be called S1, S2 and so on, and the parking as CP or P1 or whatever you fancy. If one or the other of these (say S1) is actually the main coords, and not repeated further down, then the structured numbering goes out the window.

 

I haven't particularly got a problem with duplicating the points in this case, and that might be the best compromise!

 

Finally, I think GSAK has a feature for removing duplicate waypoints in these cases - can it be set to delete the main coords rather than the duplicated child? I'm guessing no, but haven't looked!

 

Dave

[Deceangi]

Just to clarify - what happens if an Additional Waypoint ( ie a stage of a multi ) is within .01 of a mile of another Additional Waypoint ( ie a stage of a multi ) - but the 2 actual cache locations are outside the .01 of a mile ?

 

What I'm trying to ask is - do stages of a multi count towards the .01 of a mile guideline ?

 

Simple answer yes, but there is some leeway if they are virtual stages.

 

Deceangi

[Alan White]

"It's only a game. Play it your way."

Sure, but this isn't about how we play the game. Rather it's about how we manage and present the data on which the game depends such that it allows the game to be played effectively. Cache owners provide coords for the benefit of the finders - the owner presumably knows where the waypoint is.

 

A single point may well be both parking coords, a multi stage, and possibly also the main cache coords.

Indeed so. A particular point on the planet may serve several purposes. That doesn't mean that it can be described only once, and doesn't mean that there's duplication unless it's the same place and the same purpose.

 

have the main cache coords as something rather random

That's often done for mystery caches. The problems with doing so have been discussed elsewhere. Aside from those problems my view is that if an application needs to fudge data to make it work then the data model needs re-visiting.

 

There's a clear comparison here with Locationless caches. They didn't fit the data model and so first the coords were hidden and then later the entire concept was moved to a data model which had been designed for the purpose.

 

If TPTB had intended you to include the 'Main' co-ordinates, why did they call the new feature 'Additional' waypoints and still leave the main co-ordinate field as a compulsory feature on the cache submission page?

I don't want to get into a discussion on semantics, but the waypoints are only called "additional" in one place - the cache page as normally viewed. On the cache page as viewed by the owner they're called just "waypoints", and on the Managing Waypoints page they're called "Waypoint Collection". And in the email accompanying Pocket Queries they're called "supporting waypoints". So I don't see that anything can be inferred by choosing any particular description for them.

 

It's interesting to note that the hint, of which there is only one, is called "Additional Hints".

 

I can only speculate as to why the main coords are still there. I think that, even if TPTB thought they should be removed, it would be very unwise to remove such a fundamental element of the system. I also think that if we were re-designing the system from scratch then there would be no main coords.

 

The real problem here, of course, is that cache owners have been given no guidance as to how the waypoints feature should be used. No doubt some uniformity will evolve over time.

 

A simple solution in the meantime would be to allow the main coords to be classified in the same way as the waypoints are. The problem with a multi/mystery is that the main coords can be parking, a stage (often, but not always, the first stage), or some random spot. And so the finder has no way - especially programmatically - of determining what type they are. If the main coords were classified then that would go some way to solving the problem (depending on what one thinks the problem is ). As I recall the original discussions when Jeremy first suggested the waypoints feature, his vision was that waypoints wouldn't be directly attached to caches as they were (and are). Rather, a waypoint would be a standalone entity, an instantiation of which would be associated with one or more caches. I suspect pragmatics got in the way of that idea, but it's certainly the more correct one from a data modelling point of view.