Jump to content

Additional Waypoints For Geocaches


Jeremy
Followers 6

Recommended Posts

This is a reprint from the pinned topic for GPX application developers (read it first). So we can discuss this further I am reposting it in its own topic.

 

---

 

We're working on a new feature that will allow cache owners to add additional coordinates for their caches. As a result the GPX files will contain additional GPS coordinates that will not contain any of the Groundspeak:cache namespace items.

 

These waypoints will be for stages of a multicache, locations where you have to answer a question for a puzzle cache, or general waypoints like parking coordinates. Additional types may be added on the fly.

 

To link these new waypoints we will be prepending the name of the waypoint name of the cache that it belongs to. So a GPX file would have extra waypoints like:

 

GCXXX-PARK1

 

GCXXX-STAGE2

 

GCXXX-QUESTN

 

This will allow grouping of the cache and additional waypoints together. Of course, for those GPS units that only support 6 characters this could create a problem, so you would need to provide a feature for users to break the coordinates out in a way they can recognize them on a GPS unit.

 

This new information will be available in the next 2 weeks, hopefully at the latest.

Link to comment

I updated some example waypoints you would see in a GPX file:

 

  <wpt lat="47.2109" lon="-122.7663">

    <time>2005-12-16T18:15:43.6500000-08:00</time>

    <name>GCK894-PARK1</name>

    <cmt>A park. Yay! by iryshe</cmt>

    <desc>This is a description. Whee!</desc>

    <url>http://localhost/geolegacy/seek/wpt.aspx?WID=c8898fce-4542-46ac-93a6-e38057043f37</url>

    <urlname>A park. Yay!</urlname>

    <sym>Parking Location</sym>

    <type>Waypoint|Parking Location</type>

  </wpt>

  <wpt lat="47.2" lon="-122.216666666667">

    <time>2005-12-18T15:58:15.5730000-08:00</time>

    <name>GCK894-STAGE1</name>

    <cmt>Stage 1 by iryshe</cmt>

    <desc>This is just a basic description for testing.</desc>

    <url>http://localhost/geolegacy/seek/wpt.aspx?WID=e4d54a49-5f1b-46c8-bced-9d4d80a5eee2</url>

    <urlname>Stage 1</urlname>

    <sym>Stage of a Multicache</sym>

    <type>Waypoint|Stage of a Multicache</type>

  </wpt>

  <wpt lat="47" lon="-122">

    <time>2005-12-18T17:04:23.1670000-08:00</time>

    <name>GCK894-TREE</name>

    <cmt>How old is this tree? by iryshe</cmt>

    <desc>What is the age of this tree? Make it XYZ.</desc>

    <url>http://localhost/geolegacy/seek/wpt.aspx?WID=f37f0c7e-d534-49be-b737-4f64dba5be71</url>

    <urlname>How old is this tree?</urlname>

    <sym>Question to Answer</sym>

    <type>Waypoint|Question to Answer</type>

  </wpt>

 

There will be an option to create hidden waypoints (like final locations and stages of a multicache), or hidden coordinates (for revealing stages of a multicache without displaying the actual coordinates).

 

Hidden coordinates will not be waypoints but instead be appended to the end of the long description.

Link to comment

After reading the "Read me first" request... and taking a few aspirins...

 

If you are looking for XML suggestions... I have none.

 

But speaking for the average Geocacher or at least myself :o, I would welcome the additional fields for data coordinates.

 

To me, it's gotta be simple....

 

GC1234 = The usual thing people submit to mark their entry.

 

PS1234 or PL1234 = The 'parking spot' or 'parking location' for the GC#

 

1234-A = Stage A, or first stop, however you wanna word that.

 

1234-B = Stage B..... as above

 

The reason I suggest switching to 1234-A instead of using "letter-letter-number-number-number-number" is that with multiple entries, they would blend together in a list and become a jumbled mess. Obviously the 1234 matches the GC1234 so that the waypoints remain uniquely attached to the GCID.

 

Using 1234-A to Z allows 26 stops, and that otta be enough... I would hope.

 

:o The Blue Quasar

Link to comment

Several issues were raised in the original thread; sorting the waypoints unambiguously and dealing with short waypoint names, for example.

 

So I'll just reiterate my proposed solution, which (unfortunately) requires a minor addition to the Groundspeak namespace:

 

<wpt lat="37.31745" lon="-122.144883">
   <name>P1J1F6</name>
   <desc>Parking Coordinates for cache GCJ1F6</desc>
   <Groundspeak:cache_link id="126550" idx="1">Extra Text for link</Groundspeak:cache_link>
</wpt>

 

"id" is the ID of the cache the waypoint is linked to, and "idx" is the sort order index for that waypoint.

 

Why does the forum software automatically capitalize Groundspeak?

Edited by fizzymagic
Link to comment
Makes it so they are unique. Your proposal would make

 

GCXXX-PARK1 and GCYYY-PARK1 both PARK1.

Actually, no, my proposal said nothing about waypoint names; the idea is that every waypoint name will be unique, but you won't have to parse the waypoint name to figure out which cache it is attached to or how to sort it.

 

My example would have made P1XXXX the parking coord for GCXXXX, but that's really peripheral to the proposal; I only put it in to address robertlipe's concern about unique short waypoint names.

 

I understand the problem with making changes to the Groundspeak (I'll be this shows up capitalized! ;) ) namespace; it's a huge pain in the you-know-what. But it allows you to do things a lot more cleanly, in a way that is less likely to break in the future.

Link to comment
My example would have made P1XXXX the parking coord for GCXXXX, but that's really peripheral to the proposal; I only put it in to address robertlipe's concern about unique short waypoint names.

Ah. An interesting proposal. Unfortunately the issue for me here is that the prefix should be protected for Groundspeak's use. Ancillary waypoints really aren't meant for anything but supporting material for caches. But yeah PARK1 already breaks this so it is worth looking at.

 

I understand the problem with making changes to the Groundspeak (I'll be this shows up capitalized! ;) ) namespace; it's a huge pain in the you-know-what. But it allows you to do things a lot more cleanly, in a way that is less likely to break in the future.

 

Yeah. No kidding. I'm liking the route idea better though I don't like how the GPX schema does it. Really routes should just be pointers to waypoints instead of their own rtept entry.

 

I thought that GCXXX-NAME would work since the applications could merely chop off the GCXXX code and do whatever they want to the waypoints. I also thought NAME-GCXXX would be better since you could just lop off everything after and including "-" but sorting would be an issue.

 

Really we need to rework the whole GPX schema and this may mean we abandon the GPX schema entirely for a better XML document structure. It may seem extreme but the new structure for Waymarking pocket queries may require it.

 

This was just a summary of my thought process in implementing the current schema. At this point I'm just trudging ahead with the current implementation.

Link to comment
I'm liking the route idea better though I don't like how the GPX schema does it. Really routes should just be pointers to waypoints instead of their own rtept entry.

I agree with you there. I don't like the way routes are done.

 

There may be a problem with using routes, though -- some third-party software that can read GPX files may barf if the number of routes gets too large. I'm thinking Mapsend or Mapsource here, where the program only lets you read in as many routes as your GPS unit can hold. That would be very, very annoying.

 

As far as I am concerned, your current proposal will work just fine for what I need to do. I can identify which cache the waypoint is associated with, and I can sort them. That's all I really require.

Link to comment
There may be a problem with using routes, though -- some third-party software that can read GPX files may barf if the number of routes gets too large.

Not to mention many just ignore the descriptions. Puzzle locations will mean that the description will be very important to have.

 

I'm thinking Mapsend or Mapsource here, where the program only lets you read in as many routes as your GPS unit can hold.  That would be very, very annoying.

 

Agreed.

 

As far as I am concerned, your current proposal will work just fine for what I need to do.  I can identify which cache the waypoint is associated with, and I can sort them.  That's all I really require.

 

In retrospect it almost feels like I should provide a second file that contains all the supporting waypoints. I'm wondering how some people will react to these extra waypoints.

Link to comment

One of the two major brands of GPS doesn't support dashes in waypoint names, IIRC.

 

If the concern really is about mainting a unique namespace and keeping it withing 6 characters, we may have to rotate it so the namespace identifier is a single character and the last character is the sequencer. EK894A, EK894B, EK894C, ...

 

> I thought that GCXXX-NAME would work since the applications could merely chop off the GCXXX code

 

That's probably true if you assume most of the readers will be "geocaching aware" (and given your perspective, that's certainly not an unreasonable view) but it's my experience that GPX readers tends to simply truncate from the left. And if they ARE geocaching aware, it's more "XMLish" to put different fields in different tags instead of making readers divine what's in fields and sub parse them like they already have to do for UBB code or [] in hints.

 

I sense a fear of adding tags to the existing GPX namespace. As long as you're adding new features (like this) and not changing the meaning of existing ones, I really don't think that'll be a problem, Jeremy.

 

There's a lot of things GPX gets right, but it's not the end-all. The routing thing - which, if you're trying to produce a format that's independent of receiver limits, really does kind of make sense to punt to the endpoint software to resolve - is only one of several such examples. Consider waypoint namespace, (mixed case? ASCII only? utf-8? length? Must be unique? the list is long.)

 

The nice aspect is that even where it's not well thought out, it's better than most of the things it's replacing. :-)

Link to comment

yes, having additional points to download will be great. so that when i neglect to read cache description and arrive at coords--for parking--and can't find cache, i will have another option.

 

my gps gives me all the info from the cache page, EXCEPT the description and the hint will get cut off if too long. having more waymoints could split this info into smaller blocks to be shared among linked waypoints.

 

how is this going to affect the sizes of the file downloads--for both download time and pc/gps storage space?

 

it seems that handheld gps units (garmin/magellan) are lagging behind in application of the device in the field. i have a Magellan Explorist 500, with Cache software (as noted above). are the changes going to be compatable with this?

 

if a cache has parking coords, with that waypoint icon be the same as the cache--box(es), question mark, or ghost? could it not be a car for parking? how about the No Parking sign, small white square with crossed out P, without the 'crossout'? Then stages of the caches would be a small number associated with the stage.

 

the way i accomodate parking coords now, is to download the gpx to the cache manager. then in the mapsend software/gps unit create a waypoint with a 'GCXXXXpark' name. i create the stages as i go with the first 'unique' work in the cache name, as in 'Publix 1', 'Publix 2', etc.

Link to comment

Yes an additional GPX file that contained the "assiting" coordinates would be a good solution.

 

It would allow 'purists' to get their PQ's like they have now. The additional PQ for support would be for those that want everything.

 

You recently doubled the PQ's to some degree, and I don't think the double PQ to get the add-on info would be any concern, since people should only want that for caches they are really gonna do.

 

Not trying to start a debate about PQ's but requesting that much variety in PQ requests must be for offline databasing, and as such the additional fields are not required for that application.

 

This thread will remain XML codey above my head. That's fine to me. I only offer my input from a regular cacher level. I don't know if that is what you are looking for from anyone, or just want the actual logical application development.

 

I didn't understand Jeremy's comment of

Ah. An interesting proposal. Unfortunately the issue for me here is that the prefix should be protected for Groundspeak's use. Ancillary waypoints really aren't meant for anything but supporting material for caches. But yeah PARK1 already breaks this so it is worth looking at.

 

Does that mean you want a prefix like you have GC now? If so, unfortunately legacy equipment still exists and having anything beyond 6 characters, despite the applications and programs available to assit in management of that, you may end up isolating some members. Any new Premium Member may become overwhelmed trying to figure out how to manage the data.

 

Are you looking for a waypoint naming structure? I don't know if you guys are looking for packaging or delivery solutions. To the end user, most won't care how the product gets there, but it must be easy to operate for the common user.

 

Turn the key and drive.... how the car works or is made doesn't help me use it, for the most part.

 

Sorry, just trying to contribute.

 

:rolleyes: The Blue Quasar

Link to comment

My question has nothing to do with the xml/gps/whatnot setup.

 

I'm wondering how this new fields will show up on the cache submission form, and actual online cache page. Will the fields be open blanks? will they show up as question marks on the cache page?

Will I be tempted to put in extra junk just because it seems like its needed?? (sorta like some people seem to like doing with the hint :rolleyes: )

Link to comment

What do you think about the idea of matching the Urls for the waypoints to the cache? Instead of each waypoint having its own page, for example, it would just point back to the cache page.

 

That way Cache A and Waypoint A would have the same Url.

 

I don't really mind adding an additional tag to the namespace, but I don't think it addresses the issue with duplicate waypoint names.

Link to comment

As placer of several caches with many "extra" waypoints, I have a "retrograde" suggestion:

 

Go back to allowing .loc files to be uploaded like a picture. That worked just fine for the extra waypoints.

 

Appreciate all your efforts, but sometime the old ways work OK as well. With GPS Mfr software (e.g. latest Mapsend) and 3rd party packages (GSAK, Google Earth) now accepting .loc files, we aren't tied to EasyGPS anymore, either. The "extras" are only waypoints, right? They don't need to be .gpx files.

 

I now offer to email cachers the .loc files, and do a couple a week. I don't mind, but it might cost a cacher a day or two to get them

 

My 2 cents worth.

Link to comment
Go back to allowing .loc files to be uploaded like a picture. That worked just fine for the extra waypoints.

This only worked prior to Pocket Queries when the only way you could get information about a cache was on the cache listing itself. Additional LOC files would cause the same problems as putting them in GPX files.

 

Really it is sort of the same thing. An uploaded loc file will still need to be returned somehow to the user, and having that as a clickable download on the page will not work.

Link to comment
What do you think about the idea of matching the Urls for the waypoints to the cache?
I could make it work, but it would be ugly. It would involve matching GUIDs, which I hate. :D

 

Go back to allowing .loc files to be uploaded like a picture. That worked just fine for the extra waypoints.
That's unfortunately not an acceptable solution. The idea is to provide the information in the pocket query, not just on the cache page.
Link to comment

I worked on this further today. Here's what I have so far:

 

For Pocket Queries - Extra waypoints have their own GPX file named QueryName-wpts.gpx if you choose the GPX option. Other formats will not have this data. I'm still currently using GCXXX-NAME as the format.

 

For individual GPX Downloads - I stuff the additional waypoints in the single GPX file. The chance of duplicate names is less likely for a cache listing and loading it into software will be less confusing this way.

 

Pocket Queries are running on the test server with the output working. I still need to hook in coordinate-less waypoints back into the cache listings as attached information in the long description. This is to ensure that if someone uses a waypoint to show stages it will show up in GPX files.

 

The optimal solution is to create a new XML structure for the changes (including, for instance, attributes). But this will be a good interim solution, IMO.

 

The jury is still out to add an additional tag that has the linked cache for each waypoint. If someone can help me out and show me what I need to change in the XSD it would help.

 

Onward...

Link to comment
What do you think about the idea of matching the Urls for the waypoints to the cache? Instead of each waypoint having its own page, for example, it would just point back to the cache page.

 

That way Cache A and Waypoint A would have the same Url.

 

I don't really mind adding an additional tag to the namespace, but I don't think it addresses the issue with duplicate waypoint names.

I'm not wild about overloading the URL/GUID as a primary key.

 

Programs that understand GPX but don't "know" Groundspeak GPX (like ExperGPS or Mapsource) won't be able to reassociate them. OTOH, I guess they'd see the duplicate name and just fall into the "oh, dear, this GPX file has multiple wpts with the same name what shall I do?" path and be no worse off. Programs that were devoted to Geocaching.com-isms would have enough bread crumbs to reconstruct the trail. So, my distaste aside, I don't totally hate it.

Link to comment
In retrospect it almost feels like I should provide a second file that contains all the supporting waypoints. I'm wondering how some people will react to these extra waypoints.

I don't understand why supplemental waypoints are treated like first class citizens, instead of being scoped to the containing waypoint. I'd rather see:

 

<wpt ...>

<internalwpts>

<wpt ...> ... </wpt>

<wpt ...> ... </wpt>

</internalwpts>

</wpt>

 

Of course, this would require more tools changes and I don't know what's involved in this type of schema change. But I'm always anal about containment.

Edited by ChileHead
Link to comment
I don't understand why supplemental waypoints are treated like first class citizens, instead of being scoped to the containing waypoint.

This was already discussed in the previous thread. There are significant disadvantages to doing what you suggest.

 

First, it breaks the design of a GPX file, in that it has waypoints contained within other waypoints; that's not how the GPX format is designed.

 

Second, the contained waypoints would not be visible to applications that are not geocaching-aware. That means you couldn't see them with Google Earth or ExpertGPS or any of a host of other programs. All the other proposed solutions allow the waypoints to be visible and parsed by those programs.

 

While from a pure database point of view it makes some sense to encapsulate the waypoints into their geocaching hosts, that is a function best left to third-party applications.

 

From a design point of view, it's important to distinguish the transport mechanism (the GPX file) from the underlying database structure. In my opinion, there are often very good reasons for the two to be very different, and this is one of those cases that proves the point.

Edited by fizzymagic
Link to comment

I think I have a good solution to the uniqueness of waypoint names. Insetad of allowing a user to have a waypoint with 6 characters, restrict them to 4. When I am generating the waypoint file I can prepend additional characters if I run against a problem with similar names.

 

For example, cache A and cache B have PKG1 as a waypoint. When I return the list I prepend numbers to make them 01PKG1 and 02PKG1. I then add the additional extended tag (ugh) that points back to the correct cache.

 

This combines some prior ideas offered in the thread. In most cases Groundspeak still "owns" the first two characters that It does break the idea that Groundspeak "owns" the first two characters but they are often discarded by applications anyway.

 

Thoughts?

Edited by Jeremy
Link to comment

What happens after 99 people each choose PARK as the waypoint name? Would this be generated on the fly so that the universe is limited to 500 caches, thereby minimizing the "99" upper limit problem? If so, then it could be confusing if Tuesday's PQ calls the parking waypoint on Cache X "08PARK" and then Friday's PQ calls the same parking waypoint on Cache X "31PARK."

 

I am not a programmer so if this question is stupid, just laugh and move on.

 

I will say that I don't much care about "GC" being prepended to any waypoint other than the main cache entry. And yes, I always strip out GC so that I can cram more useful info. onto my GPS screen. :antenna:

Link to comment
If so, then it could be confusing if Tuesday's PQ calls the parking waypoint on Cache X "08PARK" and then Friday's PQ calls the same parking waypoint on Cache X "31PARK."

It could be, which is why I suggested we do the GCXXX-PARK concept instead. But since we only have 6 characters to work with in the waypoint name there isn't a whole lot we can do.

 

The tag pointing back to the cache it relates to should fix the issue with changing waypoint names.

Link to comment
I am not a programmer so if this question is stupid, just laugh and move on.

It isn't stupid. They are the same questions I brought up during my decision process. Quoting one post in 3 responses was kind of goofy on my part but I haven't had my coffee yet.

Link to comment
If so, then it could be confusing if Tuesday's PQ calls the parking waypoint on Cache X "08PARK" and then Friday's PQ calls the same parking waypoint on Cache X "31PARK."

It could be, which is why I suggested we do the GCXXX-PARK concept instead. But since we only have 6 characters to work with in the waypoint name there isn't a whole lot we can do.

 

The tag pointing back to the cache it relates to should fix the issue with changing waypoint names.

OK so it is the lesser of two evils. It doesn't bother me so much, because I'm from the school that dumps all the old data and replaces it with fresh data before each caching expedition. But for those who are fond of offline cache databases, having the additional waypoint names changing from one week to the next could pose a problem.

 

Once you've finished your coffee, you could always edit your first reply to include the text of the other two, and then delete the extra posts. Or maybe you're just trying to up your post count.

 

::: dreams wistfully of Whidbey Island coffee and, as a compromise, heads off to take the elevator down to Starbucks in the lobby for cup number two :::

Link to comment

I just want to understand something.

 

One solution that has been suggested by non-staff people is to strip the GC off of the waypoint and append something to the two characters in front. In other words, parking coordinates for GC1234 would be PK1234.

 

The reason (unless I'm missing it) is the Jeremy is unwilling to part with the GC prefix for Geocaching related waypoints. ("Unfortunately the issue for me here is that the prefix should be protected for Groundspeak's use.")

 

Which then means (if we're sticking to the 6 character limitation) that something has to be appended on the back of the existing waypoint (so the parking coordinate is GC1234-PARK) and we'll leave it to third party software like GSAK or GPSBabel to strip off everything after the hyphen and people can do whatever.

 

But the six character limitation is a problem, right?

 

Also - some people don't utilize (or don't know how to utilize) GSAK for stripping characters and/or renaming waypoints.

 

So:

6 character limitation due to some devices

2 front characters are only for Groundspeak Namespace, but they must be included

4 characters already in use for names of caches

 

With those restrictions, I believe you're caught between the proverbial unending game of Rock-Paper-Scissors.

250px-Rock_paper_scissors.jpg

To break the chain, something's got to give.

 

:antenna: Six character limitation on devices won't give until Garmin upgrades every single firmware and display screen on every little yellow etrex out there.

:angry: The system already uses the four characters to the naming convention. Eventually (at some astronomical number that we'll hit much sooner than anything thinks), Geocaching.com will hit GCZZZZ and have to make it 5 characters: GC00001.

 

That leaves the only solution that doesn't involve cachers RELYING on third party software (which GC.com seems reluctant to even have mentioned due to commercial aspects). I believe we'll need to release the reliance on the GC prefix.

 

I still FIRMLY believe that the PK**** solution is a good one and can work well IF we're willing to forego the necessity of GC as a prefix.

 

As part of the ability to upload multiple waypoints, you could let the USER decide what TWO characters they'd like as prefix characters, and keep the same four characters as suffix.

 

Here's what I'm envisioning as an "end user"

2bd7351d-2aa3-4881-b36c-457bf5df9c40.jpg

Click Image to Enlarge

  • As the header of the page, people should have the option if they're entering them in different formats (like on PQs).
  • As a waypoint is added, the hider can determine if the waypoint is public or private (I presume they'll be private ones for final coords for the reviewers).
  • They'll need a "select" button to be able to delete waypoints if necessary.
  • It would be nice to have a pre-select group of standard icons. I used the drop-down for EasyGPS set for my GPS76S, but I'm sure there's a STANDARD set out there somewhere.
  • Latitude and Longitude fields
  • Field to allow the HIDER to determine what two characters would be the prefix, but give them a "suggestion" for a standard for parking ("PK").

If this cache were then GC1234, the additional waypoint would come out as PK1234. But if it were something like GCB660, and I put in "01" "02" '03" "BX", the waypoints would be 01B660, 02B660, 03B660 and BXB660.

 

Of course the other possibility is to strip off the GC and put those two user characters as a suffix. Then the hypothetical cache above would be the waypoints would be B66001, B66002, B66003 and B660BX.

Edited by Markwell
Link to comment

I have to say I REALLY like the "P" idea. It makes sense when looking at it. And the most important thing to think about is that most cachers aren't going to want a confusing jumble of numbers to wonder about.

Step back... look at this from the lowest common demoninator's point of view... if I get a seperate gpx file of subsidiary waypoints, I'll be most likely to understand that waypoint P11234 goes with GC1234. This makes sense to me. For caches with multiple waypoints, it does get a touch more complex- P11234, P21234, etc, but still understandable. Non parking waypoints would get my vote as S0-SZ, with a limitation of 37 S (step/subsidiary/ waypoints allowed- 0-9 + a-z, but I'd recommend removing the 0)

It does set a limit, but at this time, we have limits that we deal with anyway- like the lack of anything like this at all currently. :antenna: It doesn't seem like it would be too hard to change it later. But for ease of use and comprehension, I think a P and S designation for these waypoints would be generally easier for non-programmers to understand.

-Jen

Edited by Jennifer&Dean
Link to comment

Here's what I think might work, I am probably missing something:

 

GC1234 = The published cache coords.

 

GC1234-P1 = Primary parking coords

GC1234-P2 = 2ndary parking coords

 

GC1234-01 = First auxiliary coord.

GC1234-02 = 2nd aux. coord

etc.

 

People can use GSAK to drop the "GC" part before loading into GPS, could strip the hypen also ...

 

Make multiple coords an option on the PQs, people who can't load over 6 chars into GPS could uncheck the box.

Link to comment

Dashes won't work. As noted higher in the topic the dash does not work on some GPS units

 

A generic prefix for type won't work. Your PKPARK and my PKPARK will be the same. We're trying to avoid duplications in the waypoint file.

 

Even if it was GCXXX and PKXXX there will be reused types like stages of a multi that will duplicate on the cache listing itself.

 

I do like the prefix option if every prefix is unique. In a way, Markwell, you are turning the waypoint name into just the two letter prefix which would seem to work ok. So as long as we disregard that the first two digits relate to the type of waypoint (like PK for *all* waypoints) it may work.

 

So, M1, M2, M3 could be prefixes for a multicache, while Q1 Q2 Q3 could be multiple questions. The rest would be the XXXX part of the GC Code.

 

I have a niggling suspicion that something may be Bad with this. We try to make every attempt to make the prefixes unique (and in fact, waypoints unique) so you can always look something up easily by just adding the code. However I expect as the database gets larger than life (read: Waymarking.com) we're going to exceed 6 digits eventually anyway. At some point we'll just have to deal with the fact that a code could return more than one result.

Link to comment

I knew I could kick a hole in the prefix concept (which sucks!). If someone has access to the prefix they could create a GC prefix which would duplicate the parent GCXXXX code.

 

We could check for this but we would have to check for TB codes, WM codes, and whatever new codes we create in the future. I guess I don't expect a whole lot of new ones but I'd hate to lock this down with the possibility that a new one would appear.

 

At this point it seems like the best solution, however.

Edited by Jeremy
Link to comment

What about having the database check for unique-ness prior to adding them?

 

If they put in PK twice on two different waypoints, it kicks back an error indicating that they need to be unique. Reserve out whatever ones you KNOW about.

 

Here's how I see it playing out:

 

On my cache GCB660, I submit the waypoints "PK" "01" "02" "03" "BX" and a secondary parking option ALSO labeled "PK", prior to posting, the database throws back an error indicating that the prefix codes need to be UNIQUE within a cache.

 

As an end user I understand that, and go back and change the second PK to TB to mark where the temporary building was. But then the system kicks back a different warning - indicating that TB is a "reserved" prefix for Travel Bugs (and shows me a list of the reserved prefixes, including GC). I can then make the secondary parking P2. No errors, and the waypoints are submitted.

 

Resulting waypoints:

PKB660

01B660

02B660

03B660

BXB660

P2B660

 

I still know they're associated with the GeoCache GCB660, but I've got an awful lot of combinations from which to choose to make all of the waypoints I would need.

Edited by Markwell
Link to comment
What about having the database check for unique-ness prior to adding them?

This was a given. What I'm saying is that someone could create a GCXXX parking coordinate. You know there's someone out there that will try it. So we'll have to check for users trying to make GC as a prefix. Additionally we'll need to check for TB and WM for Travel Bugs/Geocoins and Waymarks.

Link to comment
So, M1, M2, M3 could be prefixes for a multicache, while Q1 Q2 Q3 could be multiple questions. The rest would be the XXXX part of the GC Code.

This is the solution I favor. The second character of the 2-character prefix is a base-31 digit, so the cache can have up to 31 waypoints of any given type.

 

Thus, for a multicache with 31 stages, they would be named:

M0XXXX

M1XXXX

M2XXXX

...

M9XXXX

MAXXXX

...

MZXXXX

 

Since the last 4 characters of the waypoint are the cache ID, there will be no cross-cache collisions.

 

The prefix can be used to sort the waypoints of each type; the prefix for a given waypoint would only change if the cache owner did something to change that dort order.

 

I'd limit the first character of the prefix to 3 or 4 possibilities: P for parking, M for multicache stage, Q for questions in a puzzle cache, and maybe Z for everything else.

 

I like this solution; it fixes almost every problem people have come up with. Specifically,

  • The waypoint can easily be associated with the correct cache.
  • The waypoints can obey the 6-character limit (for now).
  • There will be no waypoint name collisions for anything coming from geocaching.com.
  • The waypoints will be readable by non-geocaching-aware third-party applications.
  • No additions to the Groundspeak namespace are required.

Link to comment

I suppose you could force it somehow, by having a dropdown list of 0-9 and A-Z to choose from. In essence the user is only able to select one digit per listing.

 

In the database the waypoint would actually be saved as M1XXXX but when edited it would show as M[1]XXXX where [1] is a dropdown box.

 

Just a thought. I actually didn't force the first digit of the waypoint name in my concept. I was merely showing that the user could use P1 and P2 to show two parking coordinates. They could have easily used C1 as a car park.

Link to comment

By the way, the design of the database was intentionally made so in the future a parking waypoint could be shared across two separate cache listings. This kinda breaks the GCXXXX = P1XXXX cache link, though I guess GCYYYY and GCXXXX could have P1YYYY and P1XXXX waypoints that point to the same thing.

Link to comment
By the way, the design of the database was intentionally made so in the future a parking waypoint could be shared across two separate cache listings. This kinda breaks the GCXXXX = P1XXXX cache link, though I guess GCYYYY and GCXXXX could have P1YYYY and P1XXXX waypoints that point to the same thing.

Oooh, I like this. The big park closest to my home has six caches in it, three of which are mine, and all share the same parking coordinates. How would that work? Say I hide another cache in that park. Would there be a way on the cache submission form to tell the database "please repeat the same parking coordinates that got used over on this other cache as additional waypoint XXYYYY?" Same question for retro-editing my existing caches.

Edited by The Leprechauns
Link to comment

I'm envisioning an Enter a waypoint area much like the current one. Except that at the start of every wapoint there is a drop down option box with the options or Parking, Step, Turnpoint, Final, whatever and that you choose one of the 3 or 4 options for this waypoint, then put in your coordinates. At the end of the waypoint entering area have a checkbox that makes it visible to other players or not. That way I can include my Final coordinates for the cache in the system but noone would see or recieve them for download except an approver or other admin.

When the page is generated the system generates the numbers in order, so the first one with Parking chosen becomes P1XXXX and if a few points later the parking option is chosen again, you get P2XXXX for that one.

-J

Edited by Jennifer&Dean
Link to comment
I'm envisioning an Enter a waypoint area much like the current one. Except that at the start of every wapoint there is a drop down option box with the options or Parking, Step, Turnpoint, Final, whatever and that you choose one of the 3 or 4 options for this waypoint, then put in your coordinates. At the end of the waypoint entering area have a checkbox that makes it visible to other players or not. That way I can include my Final coordinates for the cache in the system but noone would see or recieve them for download except an approver or other admin.

It pretty much works this way as designed.

 

When the page is generated the system generates the numbers in order, so the first one with Parking chosen becomes P1XXXX and if a few points later the parking option is chosen again, you get P2XXXX for that one.

 

I expect sort order will be important for stages. Autogenerating the codes wouldn't be flexible enough to support this ability. Good idea though (and a different perspective is great!).

Link to comment

Odd question- what codes are currently in use? I know GC, TB, and probably WP are taken, but what what other options are out?

 

And how would the waypoints be displayed on the listing? When I look at some multisteps that take you on a tour and the waypoints are scattered throughout the writeup, would they be displayed in a list somewhere on the page if this was filled in and made available for downloads?

 

Thanks!

Link to comment
Odd question- what codes are currently in use? I know GC, TB, and probably WP are taken, but what what other options are out?

We are only using GC, TB and WM.

 

And how would the waypoints be displayed on the listing?

 

It will be in a table listing on the page. Waypoints with no coordinates listed will be imbedded in the description of the GPX file, while the ones that do have coordinates will be listed as waypoints. But for display on the listing you'll see them in tables.

Link to comment

First off I'd like to thank Markwell for what he had to say.

 

I am glad to see the idea of GC1234 being linked to PK1234. And I agree with Jennifer&Dean that the Parking Coordinates should be entered just like the Cache Coordinates. That seemed obvious to me.

 

There should only be one PK allowed, but more on that in the example.

 

But I agree with Jeremy's comment of

I knew I could kick a hole in the prefix concept (which sucks!). If someone has access to the prefix they could create a GC prefix which would duplicate the parent GCXXXX code.

 

He brings up two issues that cannot be allowed in my opinion...

 

1... You cannot give control of the Prefix to users. Defaults are the only way this would succeed. People don't get to pick anything other than GC, and the same must be true for PK and any other waypoints people choose to add. If they can pick RE then RF and so on, then someone else uses T1 then T2 for the same idea, everyone gets confused. The safest way is to have the Geocaching.com server assign 6 digit codes based upon a predetermined Groundspeak sanctioned list.

 

2... The problem also exists for the stage codes. There is two issues in that as well. First off, naming stages S1WXYZ, S2WXYZ etc is poor sorting on the GPS Unit when more than one cache exists. But WXYZS1 and WXYZS2 would sort properly. The problem with that is you would be now using a Suffix. That works fine to me for the additional data PQ, but I doubt I'm in the majority. Also, I don't see any reason to need M1 or P1 to match with Multi or Puzzle. S for Stage or Stop is a global solution and reduces coding (I think).

 

It's obvious that for the cache GCWXYZ that GC is GeoCache and WXYZ is a unique code that cannot be duplicated in any other cache. So with that in mind... an example

 

The creation of a new Geocache - Let's say it becomes GCWXYZ (WXYZ will be used for waypoint tag creation)

 

Placer enters the stuff we are all used to, and these additional fields on the Submission Form

 

Suggested Parking Coordinates: they enter them - GC server logs them as PKWXYZ

 

Stage 1 Coordinates: they enter them - GC server logs them as WXYZS1

Stage 2 Coordinates: they enter them - GC server logs them as WXYZS2

Stage 3 Coordinates: they enter them - GC server logs them as WXYZS3

...

Stage 31 Cooridinates: they enter them - GC server logs them as WXYZSZ

 

If people need additional Parking Coordinates, they would be needed during the cache search itself, and entered as Stage data. The seeker would be reading the page anyway if they are doing a puzzle or multi, so they would know what to do next anyway.

 

The advantage of making Stage codes being the Suffix, it makes easy sorting in the field and since the WXYZ is unique to the cache, people would know right away what cache these relate to.

 

The problem is that for the currently existing caches that are GCGC01 to GCGCZZ it would cause duplicity. I have no solution for that problem currently. Maybe someone does.

 

:laughing: The Blue Quasar

Link to comment

Although there are programs out there that can strip the code apart and redress it, like GSAK does, it shouldn't be considered a solution.

 

I love GSAK like the rest of you. But forcing people to have to jump through hoops just to manage the additional data, especially a solution that involves the use of a third party solution that works best when paid for isn't a good idea.

 

GSAK is the only program I use to handle my PQ's and GPS connectivity, but Groundspeak should have a self-contained solution for itself.

 

Also, there would be a flood of people complaining that they had to buy another program to use the new PQ features. It's bad enough people complain that their Premium Membership monies are being used for Waymarking (I don't understand that complaint, but hey, who am I :laughing:?). Now they will complain that they had to pay for another program to handle the data, and learn how to use it....

 

Having a self-contained solution is the best solution in my opinion. Then people can choose to use GSAK or similar for the enhancements that those programs offer.

 

Many people also configure GSAK to do things with the GCWXYZ already... so they will be getting another set of data and have to reconfigure GSAK just to handle that.

 

So this new data may force Cylde to have to make additonal changes to handle the Waypoint names when altered by the %code or %smart and probably others, and he will have to know what to expect since GSAK owners may have to do work arounds in the interim.

 

That's a lot to ask.

 

;) The Blue Quasar

Link to comment

Scary, but how about a hybrid solution, both single-digit prefix and suffix?

 

GC#### stays as is.

P####1 = parking option 1

P####2 = cheater parking

P####3 = winter parking

M####1 = multistage

M####2 = multistage

X####1 = misc view along way

X####1 = neaby benchmark/letterbox/cool tree

etc...

 

Would be a bit more tough for 3rd party apps to parse but sorts nicely in a GPSr natively and no dupes that I see.

 

hth,

 

Randy

Link to comment

Okay, correct me if I am wrong but arent there some letters that are NOT used in current waypoints. Let's say the letter "L" is unused. We can now use "L" in place of my hyphens (see my post above)

 

GC1234 = Posted coords

GC1234LP1 = Parking coords 1

GC1234LM1 = Multi coord 1

 

etc.

 

I still like the idea of the waypoints for a cache being sorted together...

 

I know this goes over the 8 character limit...

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