Site navigation

Section navigation

App Case Study: Country guide to climbing areas

Intro ↑ Back to contents

This case study covers third party organisations wanting to provide high level climbing area information via a mobile app where the organisation wants to leverage information already in theCrag.

High level information includes:

  • Climbing areas
  • Geo locations
  • Area descriptions
  • Various area stats

If your organisation wants to include high level climbing information in a country adventure app then you should contact theCrag. It will save you a lot of time and money collating this information as well as keeping it up-to-date.

Type of agreement ↑ Back to contents

The nature of the agreement for this type of arrangement will be an ongoing monthly fee which includes:

  • API key to access theCrag data programatically
  • Commercial license to use the data in the app

You will have to negotiate a commecial agreement with us.

Access to data ↑ Back to contents

Access to the data is via our API. You will require a valid API key and we will have to document all the endpoints you require. You will need somebody technical on your end.

The API returns JSON formatted data.

API calls ↑ Back to contents

All theCrag API end points are documented in:

https://www.thecrag.com/article/API

What follows are the end points that are required for this case study.

Getting high level climbing area information can be achieved with a single API call.

  • index/detail/{nodeid}

For example (using curl) we can get this info for, say Australia, with the API key in the header:

curl -H "X-CData-Key:key=API_KEY;" "https://www.thecrag.com/api/index/detail/11737699?pretty=1&abbr=0&withdata=NodeID,ParentID,LastUpdated,NodeType,AreaType,Name,TLC,NumberRoutes,NumberAscents,Popularity,Kudos,Point,Tag,Description&to=arealeaf"

Or we can get this info for, say New Zealand, with the API key in the url arguments:

curl "https://www.thecrag.com/api/index/detail/11737723?key=API_KEY&pretty=1&abbr=0&withdata=NodeID,ParentID,LastUpdated,NodeType,AreaType,Name,TLC,NumberRoutes,NumberAscents,Popularity,Kudos,Point,Tag,Description&to=arealeaf"

Note that the nodeid for Australia is 11737699 and New Zealand is 11737723. While it may be more convienent to use the API key in the url arguments it is more secure to use it in the header.

The result of this api call will look something like:

{
   "data" : [
      [
         11737699,
         7546063,
         1476584303,
         "area",
         "Region",
         "Australia",
         null,
         60535,
         545823,
         [
            19.8,
            100
         ],
         1029723,
         "137.2016923,-27.10729777",
         null,
         [
            [
               {
                  "Description" : "I love a sunburnt country, A land of sweeping plains,\r\n\r\nOf ragged mountain ranges, Of droughts and flooding rains.\r\n\r\nI love her far horizons, I love her jewel-sea,\r\n\r\nHer beauty and her terror – The wide brown land for me!"
               },
               11183449
            ]
         ]
      ],
      [
         11738035,
         11737699,
         1476583903,
         "area",
         "Region",
         "Victoria",
         null,
         16136,
         124500,
         [
            18.4,
            100
         ],
         281879,
         "144.38412486,-36.97375357"
      ],
      ... more
}

In otherwords a JSON array of arrays is returned. The fields of the inner array correspond to the arguments provided by the url parameters.

The returned index is a heirachy down to the lowest area level. You are most likely interested in the top level crags, which are the first non-region climbing areas. Below that only areas of area type 'Crag' are probably of interest at a high level.

Most of the fields are fairly self explainatory. Note that TLC stands for Top Level Crag. Also Kudos is an internal measure of the total utility of a crag (how much joy the are brings to the climbing community).

Caching the result ↑ Back to contents

The information returned by this end point is fairly long lasting. Imagine there are 100,000 app installs all quering this end point continuously. theCrag service is currently not dimensioned to hanlded this kind of traffic. Traffic overload from one particular api key would mean that we would have to disable this key.

It is therefore important to cache the result and then decide when to get new data. Eg user triggered request, or monthly for example.

While caching and serving data on a third party server is generally not permitted for various reasons, it is ok to cache on a particular app install.

End point failure ↑ Back to contents

It is the Internet, so occasionally the end points fail for various reasons. We also do not guarentee theCrag server is 100% available. There are times where we take it down for maintenance. Your app must be able to deal with this

Attribution and branding ↑ Back to contents

It is important that you make mention that the data is sourced from theCrag. This is part of the terms of use of the data. Please do not make your app look like it is a theCrag app though. The data being sourced from theCrag is different from a theCrag app.