Canyon Data Schema - CDS

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

Schema

metadata

language

The language the description is written in. This can be a single, or a list of https://en.wikipedia.org/wiki/ISO_3166-1 values

identification

rivername

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

canyonname

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

aliasname

Alias name of the canyon

uci

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

example

GerbachCanyon has UCI atgerba01

country

https://en.wikipedia.org/wiki/ISO_3166-1

province

https://en.wikipedia.org/wiki/ISO_3166-2

region

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

ncity

Nearest village or city

ctype

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.

investigated

• 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

characteristics

introduction

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

advice

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

rating

techratingsystem

Technical rating system. Permitted values:

• FFME (mainly used in Europe)
  • fr: http://www.ffme.fr/uploads/federation/documents/reglements/canyonisme/canyonisme-classement.pdf
  • fr: http://www.canyoning.com/documents/cotation.pdf
  • de: http://www.canyoning.it/verstedesco/standards/schwierigkeit.pdf
  • it: http://www.aic-canyoning.it/images/doc/procanyon/aic_norme_classificazione_tecnica-2003-2.pdf
• ACA (USA)
  • http://www.canyoneering.net/docs/ratings.pdf

techrating

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

belay

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.

maxrapel

Maximum rapel height in meters.

subrating

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

coordinates

Coordinate System: WGS 84, see http://spatialreference.org/ref/epsg/wgs-84/

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

discussion

• 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?