Jump to content

Additional Waypoints


Jeremy

Recommended Posts

Now curious how GSAK and other will exploit the potential of this!

It would have been better if the authors of GSAK and the rest had had the opportunity to review this feature before it went live so that the impact on the programs could have been assessed in advance, and any changes made beforehand.

 

Especially those changes which are necessary to prevent the feature from breaking things :lol:

Link to comment

For testing, I've just got the individual GPX for GC7E12 (simply because it was mentioned earlier in the thread). I loaded this GPX into GSAK.

 

There are two waypoints in this file: GC7E12 and TH7E12, the latter obviously being the additional waypoint.

 

So, two obvious things. Why does it have a different prefix? Surely it should be GC7E12<something> (My preference is GC7E12-01, but YMMV). That way the cache and the addl wpts sort together.

 

Secondly, are all these addl waypoints prefixed TH? So I can just delete all such wpts from GSAK?

Link to comment

First impressions are that it's a superb feature - thank you! :lol:

 

Only one thing: I was hoping that one of the waypoint types would be "password protected". This would cater for the following; decipher the code or solve the puzzle on the cache page to get the password, which allows you to "unlock" the waypoint and see the final cache location.

 

Perhaps that's planned for the future?

 

HH

Link to comment
It would have been better if the authors of GSAK and the rest had had the opportunity to review this feature before it went live so that the impact on the programs could have been assessed in advance, and any changes made beforehand.

Gee, what a great idea!

 

Maybe that's why Jeremy started this thread for exactly that purpose. The issues you raise were discussed and all the software authors were aware of them.

 

What I can't understand is why you simply assumed that this feature was released without notice or discussion...

Link to comment
It would have been better if the authors of GSAK and the rest had had the opportunity to review this feature before it went live so that the impact on the programs could have been assessed in advance, and any changes made beforehand.

Gee, what a great idea!

 

Maybe that's why Jeremy started this thread for exactly that purpose. The issues you raise were discussed and all the software authors were aware of them.

 

What I can't understand is why you simply assumed that this feature was released without notice or discussion...

Yes, I saw that thread. It hardly constitutes testing and development, does it?

Link to comment
There are two waypoints in this file: GC7E12 and TH7E12, the latter obviously being the additional waypoint.

 

So, two obvious things. Why does it have a different prefix? Surely it should be GC7E12<something> (My preference is GC7E12-01, but YMMV). That way the cache and the addl wpts sort together.

 

Secondly, are all these addl waypoints prefixed TH? So I can just delete all such wpts from GSAK?

When creating an additional waypoint, the cache owner enters the prefix for each additional waypoint. There are no restrictions, except 'GC', 'TB', 'WP' and 'WM' are not allowed.

 

For the cache you mention, the additional waypoint is the Trailhead, so the owner has chosen 'TH', but they could have chosed anything (except GC, TB, WP, WM). If there several additional waypoints, they must all have different prefixes.

e.g.

PKxxxx Parking

THxxxx Trailhead

W2xxxx Waypoint 2 for a Multi (Presumably GCxxxx would be the first waypoint)

W3xxxx Waypoint 3 for a Multi

 

This means that:

In an alphabetical list, the waypoints for a single cache will be all over the place :lol:

Unless there is a standard adopted by all cache owners, there will be no way of knowing what the additional waypoint names will be :lol::P

 

A suffix would be much more useful, but some GPSrs cannot cope with waypoint names longer than 6 characters. I suspect this is why a prefix was chosen.

 

I can see a great demand for scripts which will convert additional waypoint names.

 

EDIT:

Could the PQ page include an 'Additional Waypoints Name Format' option?

 

If GC1234 has an Additional Waypoint AW1234:

 

'No Additional Waypoints' - only GC1234 is included in the file

'6 Character Prefix Format' - GC1234 and AW1234 are included (as now)

'6 Character Suffix Format' - 1234GC and 1234AW are in the file

'8 (or 9) Character Suffix Format' - GC1234 and GC1234AW (or GC1234-AW) are in the file.

Edited by MarcoXono
Link to comment
For the cache you mention, the additional waypoint is the Trailhead, so the owner has chosen 'TH', but they could have chosed anything (except GC, TB, WP, WM). If there several additional waypoints, they must all have different prefixes.

e.g.

PKxxxx Parking

THxxxx Trailhead

W2xxxx Waypoint 2 for a Multi (Presumably GCxxxx would be the first waypoint)

W3xxxx Waypoint 3 for a Multi

 

This means that:

In an alphabetical list, the waypoints for a single cache will be all over the place :lol:

Unless there is a standard adopted by all cache owners, there will be no way of knowing what the additional waypoint names will be :lol::P

That is just crazy. It would be hard to think of a scheme which would be more difficult to work with than that one.

 

Could the PQ page include an 'Additional Waypoints Name Format' option?

One of which should be "Don't download any additional waypoints". (As you say - just emphasising the point.)

Link to comment

Could the PQ page include an 'Additional Waypoints Name Format' option?

One of which should be "Don't download any additional waypoints". (As you say - just emphasising the point.)

And the same option needs to apply to individual GPX files, which currently work differently from PQs because the addl wpts are in the same file!

Link to comment

At first sight: Nice!

 

Will this data be available to reviewers?

 

What I'm trying to say: Will it be automatically checked (during approval) if any "stage of a multi"/"final"-coordinates of existing cache are within 168m of any "stage of a multi"/"final" coordinates of the newly placed cache? IMHO it should be.

 

cheers,

Gert

Link to comment

If GC1234 has an Additional Waypoint AW1234:

 

'No Additional Waypoints' - only GC1234 is included in the file

'6 Character Prefix Format' - GC1234 and AW1234 are included (as now)

'6 Character Suffix Format' - 1234GC and 1234AW are in the file

'8 (or 9) Character Suffix Format' - GC1234 and GC1234AW (or GC1234-AW) are in the file.

That's a good idea.

 

I also think it would be good for "someone" to establish recommended standards for the two-character identifiers. Is PK going to be parking, or will some use PA...or something else? (OK, this is horribly English-centric. How about "standards by language"?)

Edited by beejay&esskay
Link to comment

How about a miscellanous category. I added parking to my caches where it had been part of the original write-up. On a couple I have turn coords. I tossed those into answer a question, with the description, turn off. Stage coords might work too - sort of Pre-stage.

I'm sure this will sort itself out as folks get used to it. THANK YOU THANK YOU - I'm loving the parking coords already. No manual loading whoopee!

Edited by Isonzo Karst
Link to comment
At first sight: Nice!

 

Will this data be available to reviewers?

 

What I'm trying to say: Will it be automatically checked (during approval) if any "stage of a multi"/"final"-coordinates of existing cache are within 168m of any "stage of a multi"/"final" coordinates of the newly placed cache? IMHO it should be.

 

cheers,

Gert

Yes, reviewers can see all the additional waypoints, including "secret" waypoints for the final location of a puzzle, stages of a multicache, etc., just as if the reviewer was the cache owner.

 

Yes, it is planned that the review process will become more automated through a new tool that will search for nearby "additional waypoints" when a new cache has been submitted. Of course, this will only be meaningful if the existing multicaches and puzzles are converted over to make use of the additional waypoints.

 

This has been the number one feature enhancement request in our Reviewers Forum for quite some time. And we can be very persistent and obnoxious. :lol: On behalf of all the volunteer cache reviewers, THANK YOU to Jeremy and the rest of the programming team for the great progress on this feature.

Link to comment

Personally, I don't care about the prefix. I always use the nearest waypoints listing on my GPS anyway.

 

One problem I see is that even when there is no public waypoints, the titles for extra waypoints still show up. They're not needed since you can't actually see anything. GCKEVA is a good example of this.

 

I would like to see a verify coords variation of this for mystery caches. Saves the owner alot of emails. Put a 3 guess limit or something on it though to stop someone from just mass running all the nearby coords through it.

Link to comment
Possible bug?

 

This cache: http://www.geocaching.com/seek/cache_detai...3a-1be487c3ff5a shows two additional waypoints on the page.  Park 1 at N 41° 43.055 W 088° 04.228 and Park 2 at N 41° 42.701 W 088° 04.804.  However, in the PQ I just received, there are three additional waypoints for this cache -- the two listed above (P1T246 and P2T246) plus one more.  The third additional waypoint has the code PKT246 with the coords of N41° 43.083  W88° 03.783.  There is no mention of this third waypoint on the cache listing.  Could this have been a deleted additional waypoint that is somehow being picked up by the PQ?

Those "extra" coords are actually the parking coords for another one of my caches nearby, GCT23E

Are you sure the "extra" coords aren't listed under PKT23E?

Edited by Stunod
Link to comment

<name>P2T246</name>

<cmt>Delaware Circle Trail Access</cmt>

<desc />

 

Shouldn't "Delaware Circle Trail Access" be the description? <cmt> is supposed to be for data intended for the GPS, and most GPS receiver don't even support it.

 

I've never seen a GPX file from geocaching.com with any data in <cmt> before.

Link to comment

I was dimly aware of the earlier thread where the additional waypoint implemention was discussed. I never felt I understood it well enough to comment on the GPX aspect.

 

I would ask that you document some of the implementation details of this and put it somewhere where software developers can find it in the future. The discussion thread has several different proposals discussed at once, and I have no idea what decisions you finally made and implemented.

 

For example:

 

Is there a 'primary key' that somehow links the waypoints to their cache, or the cache to the waypoints? (A text mention in long_desc doesn't help if you're a computer)

 

Can two caches both reference a single parking waypoint?

 

Will we ever see an additional waypoint that doesn't have the same 4-character code as its parent geocache?

 

Is there any indication to the GPX reader software that displaying a particular waypoint is going to give away the final location of a cache?

 

What is the complete list of additional waypoint types/symbols?

 

Having documentation on the current implementation at a known location would be very helpful.

Link to comment

I've just added Question to Answer waypoints as well as a hidden final location waypoint to one of my caches.

I checked out the GPX and found that the hidden waypoint is hidden in the long description, but is shown further down the file.

 

In the long description

HIDDEN: JGQCFM - Final Location<br />N/S  __ ° __ . ___ W/E ___ ° __ . ___ <br /&gt

 

At the bottom of the file (I've censored the coords, yes I'm that paranoid)

<wpt lat="53.xxxxx" lon="-1.xxxx">
   <time>2006-01-20T11:12:00.3100000-08:00</time>
   <name>JGQCFM</name>
   <cmt>Final Location</cmt>
   <desc />
   <url>http://www.geocaching.com/seek/wpt.aspx?WID=a0bb81d5-e5db-4dfc-aba3-d0d5f34f1b8c</url>
   <urlname>Final Location</urlname>
   <sym>Final Location</sym>
   <type>Waypoint|Final Location</type>
 </wpt>

 

Hope this is of use.

Link to comment
The new Additional Waypoints feature has been released. It's also the first time I've been able to start the topic about a new feature. <_<

 

Fortunately it is one of those things that will be slow to grow, although I do know that reviewers have been maintaining lists of waypoints in anticipation of this new feature. Well sorta. Many of them have been maintaining offline databases to make sure that there is little confusion regarding final coordinates of multicaches when someone places a new cache.

 

So feel free to ask questions. I'll do my best to answer them. Also please let me know of any bugs or issues.

On the additional Waymarks. I see you can hide them, but my question is if someone would look at the source code could they find the info or a link to the info?

Or is it completely locked out except to the owner and admin?

 

Thanks.

Link to comment

I still get the .net error on clicking "add/edit waypoints":

http://www.geocaching.com/hide/wptlist.asp...RefWptID=305424

 

Server Error in '/' Application.

Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 

Exception Details: System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

 

Source Error:

 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

Stack Trace:

 

[FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).]

System.Guid..ctor(String g) +3302

Geocaching.UI.hide_wptlist.Page_UserLoggedIn(Object sender, EventArgs e) +259

Geocaching.UI.WebformBase.IsLoggedIn() +1092

Geocaching.UI.hide_wptlist.Page_Load(Object sender, EventArgs e) +92

System.Web.UI.Control.OnLoad(EventArgs e) +67

System.Web.UI.Control.LoadRecursive() +35

System.Web.UI.Page.ProcessRequestMain() +744

 

Version Information: Microsoft .NET Framework Version:1.1.4322.2032; ASP.NET Version:1.1.4322.2032

Edited by team_wolfje
Link to comment
I've just added Question to Answer waypoints as well as a hidden final location waypoint to one of my caches.

I checked out the GPX and found that the hidden waypoint is hidden in the long description, but is shown further down the file.

 

In the long description

HIDDEN: JGQCFM - Final Location<br />N/S  __ ° __ . ___ W/E ___ ° __ . ___ <br /&gt

Jaz666 -

 

As I suspect was examined by others earlier in this thread, I downloaded the GPX from your cache page, and in importing it into GSAK, I only get the 6 question waypoints -- JAQCFM - JFQCFM.

 

Looking inside the GPX file also did not reveal your prized final coordinate JGQFCM.

  <wpt lat="53.8542166666667" lon="-1.86006666666667">
   <time>2006-01-20T11:10:14.2970000-08:00</time>
   <name>JFQCFM</name>
   <cmt>Question 6</cmt>
   <desc>Which direction is this facing (roughly)?</desc>
   <url>http://www.geocaching.com/seek/wpt.aspx?WID=9231fe9b-2261-41dc-9e46-38dbd0ceb609</url>
   <urlname>Question 6</urlname>
   <sym>Question to Answer</sym>
   <type>Waypoint|Question to Answer</type>
 </wpt>
</gpx>

 

I didn't try setting up a PQ to grab this cache, so I can't comment for that one, but it seems like you, as the owner, are getting a different GPX file download than the rest of the world will get.

 

So, your secret's safe with Jeremy (& your reviewer). <_<

 

---------

Side note/request:

 

Can the search page be updated to allow me to find the cache page associated with a waypoint created with this new feature?

 

For example, when I enter "JEQCFM" in the waypoint search box, today it tells me that all waypoints must begin with 'GC'. I feel that it should go ahead and do the search for GCQCFM for me.

Link to comment

 

What I'm trying to say: Will it be automatically checked (during approval) if any "stage of a multi"/"final"-coordinates of existing cache are within 168m of any "stage of a multi"/"final" coordinates of the newly placed cache? IMHO it should be.

To make that work, there would need to be a different category for virtual waypoints and for waypoints of a multi cache where something is hidden and even more for artificial waypoints which, for example, are just used by the hider for remembering certain waypoints which play no role for searching the cache.

 

Cezanne

Link to comment

 

What I'm trying to say: Will it be automatically checked (during approval) if any "stage of a multi"/"final"-coordinates of existing cache are within 168m of any "stage of a multi"/"final" coordinates of the newly placed cache? IMHO it should be.

To make that work, there would need to be a different category for virtual waypoints and for waypoints of a multi cache where something is hidden and even more for artificial waypoints which, for example, are just used by the hider for remembering certain waypoints which play no role for searching the cache.

 

Cezanne

1. At this time, reviewers continue to follow prior practice and *do* enforce the 528 foot proximity guideline with respect to virtual stages of existing multicaches and puzzle caches. You may be thinking of the guideline interpretation change triggered by the grandfathering of all existing virtual and webcam caches. From and after 2 November 2005, the proximity guideline does not apply with respect to grandfathered virtual and webcam caches.

 

2. For all your examples, this illustrates the need for human judgment. The tool for checking against additional waypoints is just a tool. The reviewer will see the results of the proximity test on a special search screen, and then decides whether further investigation of the alternate coordinates' meaning is necessary. It will not be a fully automated process, just an aid to flag nearby waypoints for additional research.

Link to comment
<name>P2T246</name>

<cmt>Delaware Circle Trail Access</cmt>

<desc />

 

Shouldn't "Delaware Circle Trail Access" be the description? <cmt> is supposed to be for data intended for the GPS, and most GPS receiver don't even support it.

 

I've never seen a GPX file from geocaching.com with any data in <cmt> before.

Good catch. I'll switch it with desc since that's how it works with caches.

 

Thanks!

Probably too late, but why not put the "Lookup Code" into the <cmt> field? It sounded from your earlier comment like that's what it's eventually meant for anyway.

Link to comment
One problem I see is that even when there is no public waypoints, the titles for extra waypoints still show up. They're not needed since you can't actually see anything. GCKEVA is a good example of this.

I also tried to ask about this earlier in the thread, but thought I'd bring it up again. Right now, if there aren't any public waypoints the "Prefix", "Lookup", "Name", and "Coordinate" titles still appear. Can it be set up to ignore those if no waypoints are visible (for instance, when I only have the puzzle's actual coordinates as a waypoint)?

Link to comment

 

What I'm trying to say: Will it be automatically checked (during approval) if any "stage of a multi"/"final"-coordinates of existing cache are within 168m of any "stage of a multi"/"final" coordinates of the newly placed cache? IMHO it should be.

To make that work, there would need to be a different category for virtual waypoints and for waypoints of a multi cache where something is hidden and even more for artificial waypoints which, for example, are just used by the hider for remembering certain waypoints which play no role for searching the cache.

 

1. At this time, reviewers continue to follow prior practice and *do* enforce the 528 foot proximity guideline with respect to virtual stages of existing multicaches and puzzle caches. You may be thinking of the guideline interpretation change triggered by the grandfathering of all existing virtual and webcam caches. From and after 2 November 2005, the proximity guideline does not apply with respect to grandfathered virtual and webcam caches.

 

No, I was talking about virtual stages of physical caches, not about virtual caches or webcam caches.

 

The coordinates of virtual stages are typically not even required by the reviewers for cache approval in the areas I am familiar with. A German reviewer (who is from time to time helping the reviewer for Austria) told me (in December 2005) that there even is no problem at all with two caches sharing the same virtual point (say they both the same sign for different purposes).

 

In a city like for example Vienna which has many mystery caches and multi caches (their overall number is much higher than the number of traditional caches!) with a high number of virtual stages, it would not be meaningful at all to require the various virtual stages which deal with completely different objects to be 0.1 miles apart from each other.

 

Are virtual stages best mapped into the system by using the "Answer to question" type?

 

Cezanne

Edited by cezanne
Link to comment
To make that work, there would need to be

Well, there are.

 

a different category for virtual waypoints

"Question to answer"-Waypoints

 

and for waypoints of a multi cache where something is hidden

"Stages of a multi"-Waypoints

 

and even  more for artificial waypoints which, for example, are just used by the hider for remembering certain waypoints which play no role for searching the cache.

 

I think hidden "Trailhead" coordinates could be "abused" for that (they should not play a role in aproval. Of course it would be fine to have a category named "Other".

 

Gert

Link to comment

A possible problem...

 

The whole "Extra-waypoints-in-a-PQ" thing appears to be broken. These extracts are taken from a PQ which was generated yesterday - there are multiple waypoints in the file which all have the same waypoint name. Examples...

 

<wpt lat="55.9313" lon="-3.25648333333333">
   <time>2006-01-19T19:20:40.1230000-08:00</time>
   <name>HHRYKC</name>
   <cmt>Stenhouse Crescent/Ford’s Road</cmt>

<wpt lat="55.9140666666667" lon="-3.3986">
   <time>2006-01-19T19:09:55.6530000-08:00</time>
   <name>HHRYKC</name>
   <cmt>Parking</cmt>

<wpt lat="55.9171333333333" lon="-3.39513333333333">
   <time>2006-01-19T19:12:24.0130000-08:00</time>
   <name>HHRYKC</name>
   <cmt>Parking</cmt>

<wpt lat="55.946" lon="-3.15385">
   <time>2006-01-19T19:29:05.3430000-08:00</time>
   <name>HHRYKC</name>
   <cmt>Parking</cmt>

 

The first of these applies to cache GCRYKC. The others are from a different cache - possibly GCHK62

 

The fault does not appear if the GPX file is downloaded from the individual cache page, so it seems to be a problem associated with PQ generation.

 

Jeremy: e-mail me if you need additional details of this sample.

 

-Wlw.

Link to comment

I'm getting the same problem in my PQ just generated. All of the waypoint names have the same last 4 characters which seem to be derived from one of the caches in the main PQ that has an additional waypoint.

 

The net result is that all of my parking waypoints that were prefixed with PK end up with the same name PKXXXX (where XXXX is identical).

 

Great Feature though!

 

Thanx, Tony

Link to comment

Could the PQ page include an 'Additional Waypoints Name Format' option?

 

If GC1234 has an Additional Waypoint AW1234:

 

'No Additional Waypoints' - only GC1234 is included in the file

'6 Character Prefix Format' - GC1234 and AW1234 are included (as now)

'6 Character Suffix Format' - 1234GC and 1234AW are in the file

'8 (or 9) Character Suffix Format' - GC1234 and GC1234AW (or GC1234-AW) are in the file.

In case there is an unexpected christmas: This is also on my wishlist. The prefixing makes the additional waypoints relatively useless, the not standarzised prefixes make the additional waypoints completely useless.

 

I think the two-letter-code should be fixed by waypoint type (when multiples are required that is a problem, I know). The path choosen now means, we can never have anything new, which requires a new two-letter-code, because by saying "anything not used yet is allowed" means now all codes are blocked.

 

Additionally this means, that the waypoint name gives no hint about what this waypoint is, which I think is a disadvantage (if I prefix my parking coordinates with "th" and my trailhead coordinates with "pa" that only increases the confusion).

 

I think the additional waypoints are a really nice idea, but not implemented all too well. But with some changes this can become a powerful feature.

 

Nils

Link to comment
there are multiple waypoints in the file which all have the same waypoint name.

I just archived all the hidden additional waypoints on my caches until I know what is happening. On one of my caches with hidden waypoints I had an additional waypoint added by GSAK. Now this is on a cache that I own so maybe they only went to me. I don't know that. Three of the four had a name inidicating one of the three. The fourth had a name that went along with the description I put in for it.

 

Now this may be a problem with GSAK handling these additional waypoints and I will post over there as well. I did not unzip the file, just dragged it to GSAK and let it do it's thing like I normally do.

 

This only happended on one of my caches, but the others may not have been in any PQ I ran last night. I have to check the dates on the cache and the PQ to be sure.

Link to comment
Jaz666 -

 

As I suspect was examined by others earlier in this thread, I downloaded the GPX from your cache page, and in importing it into GSAK, I only get the 6 question waypoints -- JAQCFM - JFQCFM.

 

Looking inside the GPX file also did not reveal your prized final coordinate JGQFCM.

That's coz I removed (archived) the waypoint :(

 

EDIT:

 

OK, I've added a hidden waypoint to another of my caches, with random coords.

Could someone download the GPX file from the cache page and see what you can see right towards the end of the file.

http://www.geocaching.com/seek/cache_detai...5e-d2cadd5e55d6

 

Cheers.

Edited by Jaz666
Link to comment
Would someone mind trying a GPX and PQ for my cache? I have parking coordinates and the intermediate and final waypoints. You should get the parking coordinates, but not the others.

I see we had the same idea at exactly the same time!

 

I don't see any hidden waypoints in your GPX file.

It seems they only appear in the GPX file if you are the cache owner.

 

Hopefully someone else will verify this is correct from my cache.

Link to comment
In case there is an unexpected christmas: This is also on my wishlist. The prefixing makes the additional waypoints relatively useless, the not standarzised prefixes make the additional waypoints completely useless.

 

I think the two-letter-code should be fixed by waypoint type (when multiples are required that is a problem, I know). The path choosen now means, we can never have anything new, which requires a new two-letter-code, because by saying "anything not used yet is allowed" means now all codes are blocked.

 

Additionally this means, that the waypoint name gives no hint about what this waypoint is, which I think is a disadvantage (if I prefix my parking coordinates with "th" and my trailhead coordinates with "pa" that only increases the confusion).

 

I think the additional waypoints are a really nice idea, but not implemented all too well. But with some changes this can become a powerful feature.

 

Nils

Please, please, please: There should be a forced association between the code prefix/suffix (I also second the suggestion to allow choosing prefix or suffix in setting up a PQ) and the waypoint type so that the prefix/suffix is standardized and meaningful. The problem with multiples of the same type could easily be solved (at least up to 18 multiples of the same type) by using letter/number (except zero) combinations as outlined below:

 

Final location: Prefix/suffix forced to "F1" (there's only one of these per cache, but I'm suggesting letter-number combos for reasons mentioned below, and I assume final location will almost always be hidden);

Parking Area: forced to P1, P2, P3...P9;

Question to Answer: Q1, Q2, Q3...Q9;

Stages of a multi-cache: S1, S2, S3....S9;

Trailhead: T1, T2, T3....T9 (unlikely to be more than a few of these either)

 

I'd also suggest adding one more option to the types:

Other: O1, O2, O3....O9

This would give you 9 more choices, which really means that you could have 18 questions, stages, trailheads or parking areas :( by combining a specific type with the "other" type - seems like plenty for 99.99% of the caches out there.

 

You could get more waypoints of each type if you used letter-letter combinations (e.g. PA, PB, PC...), but I don't like that because using letter-number combinations wouldn't eat up any possible two letter prefixes for future Groundspeak use, and it would automatically eliminate conflicts with the existing reserved prefixes (GC, TB, WP and WM). I also think letter-number combinations are more intuitive (how many stages in is SH? - S7 is a lot easier :P ).

 

Forcing prefix/suffix association with waypoint type would also make it simpler to add additional waypoints (one less choice to make on the add screen)!

Edited by Kai Team
Link to comment

I have just been in contact with another cacher who pulled a PQ last night on one of my caches that had a hidden waypoint along with six open waypoints. He only saw the open wps and not the hidden one so I have to assume that the only reason I got the hidden waypoints on my cache was because it was my cache.

 

As a result, I will put the waypoints back in that I archived this morning.

 

Hidden does mean hidden on this.

Link to comment
I still get the .net error on clicking "add/edit waypoints":

http://www.geocaching.com/hide/wptlist.asp...RefWptID=305424

 

Server Error in '/' Application.

Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

 

Exception Details: System.FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).

 

Source Error:

 

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

 

Stack Trace:

 

[FormatException: Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).]

  System.Guid..ctor(String g) +3302

  Geocaching.UI.hide_wptlist.Page_UserLoggedIn(Object sender, EventArgs e) +259

  Geocaching.UI.WebformBase.IsLoggedIn() +1092

  Geocaching.UI.hide_wptlist.Page_Load(Object sender, EventArgs e) +92

  System.Web.UI.Control.OnLoad(EventArgs e) +67

  System.Web.UI.Control.LoadRecursive() +35

  System.Web.UI.Page.ProcessRequestMain() +744

 

Version Information: Microsoft .NET Framework Version:1.1.4322.2032; ASP.NET Version:1.1.4322.2032

Bumping this one.

 

The URL I get when choosing the edit/add waypoin option is:

http://www.geocaching.com/hide/wptlist.asp...RefWptID=305424

and that one gives me the .net error.

 

Then I copy the guid I get in the address bar of the browser before choosing the link and copy/past and combine it I get the link:

http://www.geocaching.com/hide/wptlist.asp...62-82fd56883498

Which seems to work ok.

 

Is this correct? I think the link under the edit/add waypoint is not ok.

Link to comment
there are multiple waypoints in the file which all have the same waypoint name.

I just archived all the hidden additional waypoints on my caches until I know what is happening. On one of my caches with hidden waypoints I had an additional waypoint added by GSAK. Now this is on a cache that I own so maybe they only went to me. I don't know that. Three of the four had a name inidicating one of the three. The fourth had a name that went along with the description I put in for it.

 

Now this may be a problem with GSAK handling these additional waypoints and I will post over there as well. I did not unzip the file, just dragged it to GSAK and let it do it's thing like I normally do.

 

This only happended on one of my caches, but the others may not have been in any PQ I ran last night. I have to check the dates on the cache and the PQ to be sure.

When something unusual happens in GSAK when a new function is implemented here, I don't think you should start by assuming it's a problem here. (Even though I am a very happy user of GSAK.)

 

No changes have [yet] been made to GSAK to handle the additional information in the PQs, so what you are seeing could be the "fault" of GSAK.

 

The only way to know for sure is open the PQ in Wordpad (or equivalent) to see what is REALLY there.

Edited by beejay&esskay
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...