Groundspeak GPX

[+Clan Masters]

Hi can anyone point me in the right direction for a description of the Groundspeak GPX Schema, I know most of it is pretty straight forward, I am interested in the data that is stored in the log and logs tags and would like to know what for example the log id is and also what the finder id is and what the encoded does?

 

<Groundspeak:logs>

Groundspeak:log id="-3">

<Groundspeak:finder id="0"></Groundspeak:finder>

<Groundspeak:text encoded="False"><br /><br />

 

thanks

 

colin

[+fizzymagic]

Hi can anyone point me in the right direction for a description of the Groundspeak GPX Schema, I know most of it is pretty straight forward,

I don't believe there is any complete reference for the schema. In particular, I know of no complete listing anywhere of the cache types or attribute values. But I would be happy to be shown wrong.

 

I am interested in the data that is stored in the log and logs tags and would like to know what for example the log id is and also what the finder id is and what the encoded does?

 

<Groundspeak:logs>

Groundspeak:log id="-3">

<Groundspeak:finder id="0"></Groundspeak:finder>

<Groundspeak:text encoded="False"><br /><br />

 

Log ID is the numerical ID for the log. It started at 1 for the first log ever and is up to over 100 million now. You can order logs by the time they were created using this attribute.

 

Finder ID is the numerical ID of the user who found the cache. Like the log ID, it is simply the user number by order of registration. My user ID is very low; about 41000, because I started in 2002. User IDs are over 2 million now.

 

Cache ID is the numerical ID of the cache, also starting from one. You can get the waypoint (GC number) from the cache ID and vice-versa.

 

Encoded is simply whether the log is ROT13 "encrypted" or not.

[+Clan Masters]

Hi can anyone point me in the right direction for a description of the Groundspeak GPX Schema, I know most of it is pretty straight forward,

I don't believe there is any complete reference for the schema. In particular, I know of no complete listing anywhere of the cache types or attribute values. But I would be happy to be shown wrong.

 

I am interested in the data that is stored in the log and logs tags and would like to know what for example the log id is and also what the finder id is and what the encoded does?

 

<Groundspeak:logs>

Groundspeak:log id="-3">

<Groundspeak:finder id="0"></Groundspeak:finder>

<Groundspeak:text encoded="False"><br /><br />

 

Log ID is the numerical ID for the log. It started at 1 for the first log ever and is up to over 100 million now. You can order logs by the time they were created using this attribute.

 

Finder ID is the numerical ID of the user who found the cache. Like the log ID, it is simply the user number by order of registration. My user ID is very low; about 41000, because I started in 2002. User IDs are over 2 million now.

 

Cache ID is the numerical ID of the cache, also starting from one. You can get the waypoint (GC number) from the cache ID and vice-versa.

 

Encoded is simply whether the log is ROT13 "encrypted" or not.

 

Thanks very much for the info, does each cache have its own log ID? if so why is it not the same as the cache ID?

 

thanks

 

colin

[robertlipe]

Fizzymagic's answer is, as usual, spot on. The only minor nit that I'd have is that I'd still sort by Groundspeak:date in the log and not the log id. There may be an appreciable delay between the time someone actually found the cache (and thus, hopefully, the date entered in their log) and the time they actually enter it. For example, if I were to log finds from two months ago today - with the correct date - and you sorted by log ID, they'd display after anybody that logged it in the recent two months.

 

Colin, you can answer your last question by actually looking at a PQ. Each log has its own log id and uses the cache id as a foreign key that's joined.

 

Its pretty safe to assume that anything ID is a plain ole auto increment field that's the primary key in that table in the Groundspeak database. If you look at the structure of a PQ, the layout and relationship of the tables and relationships needed is pretty easy to work out.

[+mpilchfamily]

It will be hard to look at a PQ unless you get a Premium Membership.

[+thebruce0]

The 1.01 GPX schema can be found at http://www.Groundspeak.com/cache/1/0/1/cache.xsd

And the older 1.0 GPX scheme is at http://www.Groundspeak.com/cache/1/0/cache.xsd

 

That should lay out the XML content for the GPX files in use by Groundspeak

 

[+fizzymagic]

The 1.01 GPX schema can be found at http://www.Groundspeak.com/cache/1/0/1/cache.xsd

And the older 1.0 GPX scheme is at http://www.Groundspeak.com/cache/1/0/cache.xsd

 

That should lay out the XML content for the GPX files in use by Groundspeak

 

Yes, but the problem with those schemas is that they do not enumerate the allowed values for those fields that have constrained values. As a result, the schema is of limited use in writing an application that deals with the files.

 

For example, in the schema, the difficulty has type xs:string, while in the real world the difficulty is a real number with possible values of 1, 1.5, 2, 2.5,... 5

 

The schema does not give you that kind of information.

[+ecanderson]

The schema does not give you that kind of information.

The good news is that although the bounds and allowed values aren't enumerated, much of it can be determined without a huge amount of work by reviewing the XML of caches that contain representative strings. For example, one can do a PQ that includes only certain of the attributes, and quickly discern which attributes are which.

[robertlipe]

I'm with you that it's probably "enough" for most cases. But if you're developing software, it's nice to know the rules of the game. Just because the pocket queries YOU looked at didn't have a Mega Event or a Wherigo or a log type that you hadn't seen before doesn't mean your users will. Sometimes you can pass along the tag without *really* understanding it, but if you're displaying, say, icons for cache types, you have choices to make (or an untested code path...) and users will be confused when they see:

A) A new icon type.

The same icon you used for Mystery since you don't know this thing is. That confuses users.

C) A crash.

 

Still, with enough diligence, you can figure out the huge majority just by looking at it, but an actual formal spec would be nice for developers. Hopefully we'll see one.

[+fizzymagic]

Does anybody actually have a complete listing of attributes, along with their indices? Everything else I can do, but that one is tedious.

[+Don_J]

Does anybody actually have a complete listing of attributes, along with their indices? Everything else I can do, but that one is tedious.

 

 

Attribute ID #

 

Abandoned mines 20

Abandoned Structure 54

Access or parking fee 2

Available at all times 13

Available during winter 15

Bicycles 32

Boat 4

Campfires 38

Camping available 31

Cliff / falling rocks 21

Climbing gear 3

Cross Country Skis 50

Dangerous Animals 18

Dangerous area 23

Difficult climbing 10

Dogs allowed 1

Drinking water nearby 27

Field Puzzle 47

Flashlight required 44

Food Nearby 59

Front Yard (Private Residence) 65

Fuel Nearby 58

Horses 37

Hunting 22

Long Hike (+10km) 57

Lost And Found Tour 45

May require swimming 12

May require wading 11

Medium hike (1km-10km) 56

Motorcycles 33

Needs maintenance 42

Night Cache 52

Off-road vehicles 35

Park and Grab 53

Parking available 25

Partnership cache 61

Picnic tables nearby 30

Poison plants 17

Public restrooms nearby 28

Public transportation 26

Quads 34

Recommended at night 14

Recommended for kids 6

Scenic view 8

Scuba gear 5

Seasonal Access 62

Short hike (less than 1km) 55

Significant hike 9

Snowmobiles 36

Snowshoes 49

Special Tool Required 51

Stealth required 40

Stroller accessible 41

Takes less than an hour 7

Teamwork Required 66

Telephone nearby 29

Thorns 39

Ticks 19

Tourist Friendly 63

Tree Climbing 64

Truck Driver/RV 46

UV Light Required 48

Watch for livestock 43

Wheelchair accessible 24

Wireless Beacon 60

Edited October 1, 2011 by Don_J

[+fizzymagic]

Thanks, Don_J!