opencaching.com

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

We'll use this thread to propose elements to be included in the standard. If you're going to debate an element we can break it off into another thread to give it the attention needed.

(The "..." denotes the yet to be determined namespace.)

<...:cache id="(MD5 hash of coords, name, and date placed)" active="true/false" retired="true/false" xmlns:...="yada">: defines the ID of the cache, basic status and references namespace.

<...:name>: name of the cache

<...:placed_by>: name of the team or persons which placed the cache. Free from name.

<...:lastmod>: Last time the cache record, not including logs, had been modified. Suggested by Oli.

<...:owner id="(scheme yet to be determined)">: owner of the cache. This element can be present present multiple times to allow co-ownership of caches. So, if accounts "Joe Cacher" and "Bill Wanderer" put out a cache together, there would be two owner elements and one placed-by element with whatever team name they want.

<...:type>: type of cache. this can be a freeform using loose definitions. Just about anything can be put in there. Can have multiple entries. Will need to establish some standards but can have "multi, virt" for multiple stage virtual cache or "trad, physical" for what most people think of as a traditional, or even "photo" for photo opportunity or "moving" for a moving cache. No need to limit ourselves to a hard coded set of rules. The individual hosting sites or search sites can determine what they will and will not allow.

<...:size>: size of cache. This can be "regular," "large," "micro," "mini" or whatever. Not only that, it could be "ammo," "filmcan," or "bucket" This allows for not only general sizes, but also actual container type.

<...:difficulty>: established rating system for difficulty.

<...:terrain>: estblished rating system for terrain.

<...:country>: The country the cache is in

<...:state>: State or providence the cache is in.

<...:county>: Whatever sub-division or state or providence the cache is in. (Optional)

The above three element can have "mystery" as a value is the cache type is a mystery. While on this subject, a standard for bogus coords needs to be established.

<...:blurb>: Short description of the cache. This is a very short descrition of the cache that can be optionally included in the seach results. This is used to "sell" the cache to a person looking at the results of a search they'ver made. Only limited HTML allowed.

<...:description>: Full description of the cache. This may or may not be a complete mirror of the cache page. This will allow for a much more decsriptive cache page while this section is what will be loaded onto a PDA. The reason the two could be different is many times people like to put a lot of information on the cache page that is not relevant to the hunt. This will also allow for extremely complex cache pages online while giving bare minimum cache info on a PDA.

<...:logs>: Logs to be discussed in a different thread as they will be much more complicated.

<...:hints>
<...:hint>: allows for multiple hints. This would be useful if the hider gives multiple hints and because most PDA-based decoders are/can be automatic, only portions of the hint is revealed at a time.

Information that is included in the standard GPX definition:

<wpt lat="xx.xxx" lon="xx.xxxx">: Position of the cache (and the start of the waypoint description in the GPX file.

<name>: Waypoint name. Could be anything. If I had a private hosting script running I might start with SNCR01. It will be up to the hosting sites to avoid collision. However, with a good many GPS units wtill only displaying 6 characters, it is advisable to only use up to 6 to name the waypoint.

<time>: Date and time the cache was originally placed.

<desc>: (Title) by (owner), (cache) (diff/terr) i.e. "Sissy's Snarky Walk #1 by Sissy-n-CR, Multicache (5/5)"

<cmt>: Shortened description designed to fit within the GPS's comment field.

<url>: URL of cache page.

<urlname>: title given to the URL. i.e. "Sissy's Snarky Walk #1 by Sissy-n-CR" Test to display on the <url> hyperlink.

<src>: The source of the data. The name of the hosting site.

<symbol>: Symbol to be displayed in the user's GPS. The GPX query sites can use custom symbols per user much like GPXspinner.

<type>: Type of waypoint.

That's all for now. The basic description of the cache.

Open for debate.

CR
_________________
"...been know to miss the finer points."

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

Hi CR,

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

Sounds like a good idea.

CR
_________________
"...been know to miss the finer points."

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

Hi,

one tag to add to the list:

<lastmodify>

so a every program can decide if the listed cache is older or newer than the one in his database with the same id (in my backmind is the syndication/replication) ...

and of corse

<dateplaced>

I think we should find an Internet-RFC which defines how the date-string has to look like ... so all will be compatible ...

... Oli

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

<longitude> and <latitude> should be added too Wink

---
lat: Decimal number of the cache latitude with 5 decimals. 5 decimals are enough to computeing the cache-position exactly to S/N DD°nn.nnn'. Range from -90.00000 to +90.00000.

long: Decimal number of the cache longatude with 5 decimals. 5 decimals are enough to computeing the cache-position exactly to E/W DDD°nn.nnn'. Range from -180.00000 to +179.99999.
---

... Oli

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

Opps!

While Lat and Long are handled in the core GPX standard, I probably should have mentioned that!

See the GPX developer's Manual for elements that have already been defined.

CR
_________________
"...been know to miss the finer points."

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

Hi,

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

What do you think about including some elements to inform about the version and selected attributes (or search-options) ? My dream is that a program accessing the GPX-interface can choose which TAGs are responded and which not - for example the long-description, logs, hints and pics arent every time needed ... or if you want only logs ...

... Oli

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

Would there need to be an element that said which of the elements are included?

If I'm following you correctly, you asking for a something that will tell us which of the elements were in included in the query.

I'm not sure if that is needed. If a human is requesting the file, they would get the whole file. If, say, a search engine is only requesting minimal information, then it would already know it's getting an abreviated version. ( A search engine wouldn't need cache decription or logs. A stats site would only need cache id and logs elements of logtype, finder id, and date. ...and so forth)

CR
_________________
"...been know to miss the finer points."

Guest · Posted: Sat Jan 17, 2004 8:42 am Post subject:

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

Oh.

But couldn't that be handled by a naming scheme for the .xsd file? Like ocgpx10.xsd, ocgpx11.xsd, and so on?

CR
_________________
"...been know to miss the finer points."

Team BMW-Biker · Joined: 01 Oct 2003 Posts: 209

Renegade Knight · Joined: 15 Sep 2003 Posts: 151

Do you guys have anyone who writes the apps who read the Groundspeak extensions on board for a universal GPX system?

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

No, but I've PM'ed a couple who are generally friendly to the cause. There are others, but think I already know the answer.

I'd love to have somebody who knows what they're doing onboard and at least give us some guidance.

CR
_________________
"...been know to miss the finer points."