Canyon Data Schema - CDS

CDS is an approach to managing canyon information for data exchange over the web.


name type size values mandatory
language list of text 2   n
rivername text 30   n
canyonname text 30   n
aliasname text 30   n
uci text 10   y
country text 2   y
province text 30   n
region text 30   n
ncity text 30   n
ctype text 10 integral,section n
investigated short   0,1 n
introduction text 500   n
advice text 200   n
techratingsystem text 20 FFME,ACA n
techrating text 20   n
belay short   0,1,2,3,4 n
maxrapel short     n
subrating short     n
equipment text 200   n
altitude and time
entryheight short     n
exitheight short     n
approachtime short     n
descenttime short     n
returntime short     n
avenue text 500   n
approach text 500   n
descentdetails text 500   n
return text 500   n
firstdescent text 100   n
weblinks text 300   n
imagelinks text 300   n
videolinks text 300   n
literature text 200   n
entrycoordinate WKT     n
exitcoordinate WKT     n
dataquality short   1,2,3 n
printedmaps text 100   n



The language the description is written in. This can be a single, or a list of values



Name of the river that floats through canyon. The name should preferably be derived from an official data source.


Name of the canyon. The name should preferably be derived from an official data source.


Alias name of the canyon


Unique Canyon Identifier (UCI) is the attempt to create a unique ID for each canyon. It consists of

  • the ISO country code
  • a five-place, arbitrary code
  • a double figure


GerbachCanyon has UCI atgerba01

ISO Code arbitrary code number
at gerba 01




Arbitrary name for a region e.g. alpes maritimes, Karnische Alpen, Salzkammergut, ...


Nearest village or city


A canyon can consist of multiple sections. The ctype attribute indicates whether the description relates to the whole canyon (integral) or to a section (section). The corresponding integral canyon description has to contain links to it´s sections.


  • 0 - indicates that the canyon has yet not been investigated by the author or any other person
  • 1 - indicates that the canyon has already been investigated



Should be a brief summary of the main characteristics of the canyon


If there are special issues to obey, e.g. restrictions, add them here



Technical rating system. Permitted values:


Rating corresponding to the system above, e.g. v3a4II


Quality of the belay:

  • 0: not specified
  • 4: Not or only partially equipped. A canyoneer brings adequate anchoring material.
  • 3: Compelling rope technical sections are equipped with at least one fixed point. Often outdated and inconvenient placed anchors.
  • 2: High and dangerous places are equipped with 2 anchorage points or 1 glued anchor, isolated inconveniently located. While lugs have large safety margins, but only limited intervention possibilities. Small climbing sites are not set up.
  • 1: Use status leaves no wish unfulfilled.


Maximum rapel height in meters.


Canyons are often rated by subjective criteria like landscape, water and rock quality, variety, ... The scale reaches from 1 (uninteresting) to 7 (highlight)


Coordinate System: WGS 84, see

how to resolve data errors

  • How do we resolve different spelling on river names, regions, towns... also sama data but in a different language
    • idea: create manually a mapping table to convert river, region.. names in the official local language of this country
  • How to report back if data is bad, completely wrong or missleading
    • idea: we should have something like a data quality indicator and a feedback link on the data, if the feedback is rated bad the quality indicator gets bad too means data from different sources is displayed preferred and also we could use this to give a potential warning in the apps etc


  • how should we handle the fact that a canyon can have multiple sections? Is the idea with the ctype attribute satisfiying?
    • Answer max: In the data model we should put all information for all sections of one canyon (from one source) together. The reason is, if I want to go for canyon X you dont want to look up 5 different data sources for the five different sections usually. You wanna have all section to choose from. Then in the App it is handles to display this in different per section. The more tricky question is when we get data from multiple sources and some describe the same canyon part as one section and some as two, how do we mix this information up or otherwise should we mix informations from different sources anyway, see also major decitions.
  • I have put a new idea of the CDS in the attachment, please have a look at it
  • Before defining which IDs we need we should define what do we need them for, right now I can identify the following potential IDs
    • FID - each Canyon dataset from an external source should have a unique foreign key, usually a DB key from the other DB plus a prefix identifying the other system, potential usage for:
      • Data and ID manipulation only for one specific FID
      • Send Feedback or Changes back (future use)
      • Unique identifier of source data
    • River ID (or maybe Canyon ID) - each River should have an ID derived from official standard sources, used for:
      • Find all potential same canyon infos for one Canyon
      • example: country_state_rivername (state and river in local language, if river exists multiple add next town to it manually)
      • This is only an idea, better approaches welcome ...
    • UID - each Canyon given out by the web service should have an unique ID
      • If we take source system + river ID + section we should have our UID, but it's likely that the riverid needs change
      • we could use the FID, but what if we combine multiple sources (do we want to do that anyway?)
    • Any other IDs?

Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpg CDS_ideas_v1.jpg r1 manage 236.5 K 2016-03-11 - 22:55 UnknownUser A first draft how the CDS could look like
Topic revision: r11 - 2016-03-16 - MaxHehenwarter