Apex carnivores are wide-ranging, low-density, hard to detect, and declining throughout most of their range, making population monitoring both critical and challenging. Rapid and inexpensive index calibration survey (ICS) methods have been developed to monitor large African carnivores. ICS methods assume constant detection probability and a predictable relationship between the index and the actual population of interest. The precision and utility of the resulting estimates from ICS methods have been questioned. We assessed the performance of one ICS method for large carnivores - track counts - with data from two long-term studies of African lion populations. We conducted Monte Carlo simulation of intersections between transects (road segments) and lion movement paths (from GPS collar data) at varying survey intensities. Then, using the track count method we estimated population size and its confidence limits.

We found that estimates either overstate precision or are too imprecise to be meaningful. Overstated precision stemmed from discarding the variance from population estimates when developing the method, and from treating the conversion from tracks counts to population density as a back-transformation, rather than applying the equation for the variance of a linear function.

To effectively assess the status of species, the IUCN has set guidelines, and these should be integrated in survey designs. We propose reporting the Half Relative Confidence Interval Width (HRCIW) as an easily calculable and interpretable measure of precision. We show that track counts do not adhere to IUCN criteria, and we argue that ICS methods for wide-ranging low-density species are unlikely to meet those criteria. Established, intensive methods lead to precise estimates, but some new approaches, like short, intensive, (spatial) capture-mark-recapture (CMR/SECR) studies, aided by camera trapping and/or genetic identification of individuals, hold promise. A handbook of best practices in monitoring populations of apex carnivores is strongly recommended.

The dataset covers data from two distinct areas: Kafue National Park in Zambia and Hwange National Park in Zimbabwe. The dataset consists of shapefiles of the road network, the minimum convex polygons of lion movements (see below) and movement trajectories of GPS collared lions in each area. The GPS collar data has been processed to present daily movements where each line in the shapefile represents the 24-hour movement (from 6AM to 6AM) of a lion from a pride of a known size. Only lines are included for which Day Of Year (DOY) there was movement data for all collared lion prides within each area. The road network shapefiles are clipped to the 100% minimum convex polygon of lion locations used. The shapefiles with 'I100' in their name created in QGIS 3.2 with v.split with segments of max 10,000m, these are only used for simulations where 100% of the road network is used. 

The R code randomly generates a chosen number of sets of transects of given length (in meters) and given intensity (as a percentage of the length of the total road network) and then intersects the the randomly generate transects with the lion movements to generate track count data as the number of tracks of carnivores observed per 100 km driven as the length of transects is known, the number of crossings, and pride size is lion trajectories crossing transects is known.

Within the R code a user has to set the following parameters:

The chosen site (either "Hwhange" or "Kafue"),

The survey intensity, which is the percentage of road network included in transects, in the manuscript we use 20, 40, 60, 80 and 100.

The length of transects (in meters), in the manuscript we use 10,000 (for the first half of transects per set) and 5,000 (for the second half of transects per set).

The coordinate reference system (crs), both our study area were '32735'

The spacing of points. This determines how the road network will be broken up. The number entered represents the number of meters between each point. We used 50, which means that for the whole road network (which are lines) a point is created every 50m. A smaller number would mean more precision, but also (much) more time needed to create transects.

The combination of intensity, lengths of transects and spacing of points determines how many transects will be generated per transect set and how many points there are per transect. I advise to start with a low intensity and short transects to get an idea how fast (or slow) things go. During transect creations the code will print every 10th point of a transect to show how it's progressing. One could consider overriding the calculating of number of needed transects by adding setting 'transectNR' manually.

The minimal distance, in meters. This determines the distance which is used as a treshold if crossing points should be kept or not. If points are less distance from each other than specified only one will be kept. The default value we used is 1,000 meters.

Road buffer distance, this places a small buffer around the roads to ensure that no crossings are missed because of accuracy issues in the location of roads or locations of lions. The default value is set to 25 meters.

The first and last transect sets. These are used to keep track of the number of transect sets created. Creating random transect sets can take considerable time, thus generated transects are saved as shapefiles so they can be re-used later. I advise with only generating a few transect sets first to determine how fast things go on your machine.

The user will also have to create a folder called 'results' within their working directory. This folder will be used to store the output (shapefiles and image files of transects, image files of examples of crossings, csv files with transect set, transect number and transect lengths (in meters) and csv files with the coordinates of an intersection between transect and lion trajectory, DOY, pride, pride size, date, transect set, transect number, length of transect, id and simulation number ('run'). Separate shapefile for surveys with 100% intensity are used, these are the same road networks, but pre-processed in QGIS (see above).