Survex-204 | Survex | All Survex | Scans | Upload Scans | Drawings | Upload Drawings | 290 (FGH) | 204 (Steinbrücken) |
Data Issues | tasks to do | caves | ents | expoers | survey lengths | statistics | Expo2018 | Expo2019 | import/export | Django admin

Wookey : 2014

175.8 m surveyed this year.

Other years: | 1988 | 1989 | 1990 | 1991 | 1992 | 1993 | 1995 | 1996 | 1998 | 1999 | 2000 | 2002 | 2005 | 2007 | 2009 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2018

Table of all trips and surveys aligned by date

DateTripsSurveys
July 23, 2014 Find 107, Start rigging in UNKNOWN
July 24, 2014 More rigging in 107 UNKNOWN
July 25, 2014 3rd Rigging in Trip (107) UNKNOWN
July 26, 2014 3rd Rigging in Trip (107) UNKNOWN
July 29, 2014 107 - Gemshohle - Finalising Nipped Down rigging + Pushing lead in Southern China - "The Last TSA" 107 1 39.9 m
July 30, 2014 107 - Gemshohle - The Last TSA, Climb N end of China 107 2 136.0 m

Horrible bug here but only when there is more than one survex block per day, e.g. see Wookey 1999 where there are 3 eiscream survex blocks on 5th August. it duplicates the entry but gets it wrong. The length from the first block is displayed twice but there should be 3 rows: eiscream, eiscream2, eiscream3.

Fortunately it is just this display on this page which is wrong: no bad calculations get into the database.

The interaction of django database query idioms with django HTML templating language is a bit impenetrable here. I blame Aaron Curtis who was too fond of being clever with the Django templating system instead or writing it in python anyone could understand.
- The template is in troggle/templates/personexpedition.html
- The code is in function personexpedition() which calls get_person_chronology() in troggle/core/views/logbooks.py
- the connection between the two is made in the URL resolver in troggle/urls.py

To be fixed!