AGCommons Roads Data Development in Ethiopia

Final Report

12-Feb-10

Executive Summary 

This  summary addresses  the purpose, accomplishments, and  lessons  learned  from  the overall project, and not solely the aspects covered in the third and final report which follows. The focus of this project was the development of roads data for Ethiopia using a customized Global Roads Open Access Data Set (gROADS) PDA‐based data gathering tool. This gROADS interface, built on the  freeware  Cybertracker  and  compatible with  the UN  Spatial Data  Infrastructure‐Transport data model, uses  icons  to  record  road  conditions, barriers, bridges,  and other  transportation features as well as agricultural features of interest.  

To  collect  the  data,  the  project  employed  an  “incidental  data  collection” methodology  that made use of field sorties by World Food Program (WFP) field teams. One day workshops were conducted to train the teams in the use of the PDAs. Staff from the Regional Centre for Mapping of Resources  for Development  (RCMRD)  in Nairobi, a project partner, also received  training  in the  use  of  the  gROADS  enabled  PDAs,  and  are  in  a  position  to  deploy  the  technology more widely in East Africa. 

The WFP teams collected data in the field from June‐November 2009. An IMMAP staff member on secondment  to WFP periodically data downloaded  tracks  from  the PDAs and sent  them  to CIESIN  for  conversion  to  ArcGIS  geodatabase  format.  CIESIN  compiled  a  python  script  that converted “events” along each track into changes in road conditions based on directionality, and which  also  converted  the  agricultural  features  (markets,  grain  storage  facilities)  into  points. Substantial manual editing (totaling 8 person days)  in ArcGIS was required for most tracks, since the raw data tended to be messy. 

The project produced about 5,200 kilometers of  improved roads data  for Ethiopia. These data were  integrated  into a WFP base map along with data from a separately funded NASA project that pilot  tested  the ability to derive road data  from ASTER satellite  imagery. The data will be disseminated via an OGC‐compatible map client and will also be available for download without restrictions (dedicated to the commons under Creative Commons 0). 

A number of lessons were learned from this project:  

The  time  required  to  learn  to  collect  data  using  the  PDAs  depended  heavily  on  the number  of  people  in  the  group  and  the  conditions  for  the  training.  For  one  on  one training, 1 hour was generally sufficient, but for larger groups, and given limited number of units and  logistical difficulties,  it was  found  that a day or more was  required.    It  is recommended  in  the  future  to  conduct  training  of  trainers  so  as  to  maximize  the number of competent trainers and allow for more one‐on‐one instruction. 

Field staff needed to be given a clear mandate from managers that data collection was not optional, since there was some passive resistance to additional responsibilities be added. In terms of active data collection, the project was never able to deploy teams specifically for data collection. The possibility of employing private truck drivers in data collection was considered, but most of these individuals lacked interest in the project as well as the literacy and technical skills to be able to operate the units successfully.

Units with integrated car chargers and window mounts proved important, since those units with more pieces tended to have a greater rate of malfunction and required more 

2

staff time to operate. The focus needs to be on easing the burden of data collection for the incidental data collectors, since they have multiple responsibilities. 

There are recommendations for changes in the UNSDI‐T data model that would make selection easier and more consistent, especially for non‐native English speakers. There are also changes that will need to be made in the gROADS software and data storage that will facilitate post‐processing. 

It is hoped that the updated/revised gROADS tool will be available to the African Soil mapping teams under AGCommons, so that they can contribute to the development of improved roads data for Africa. There was also an expression of interest in the tool from the National University of Rwanda, but there was insufficient timing for a training workshop in late 2009 before the IMMAP staff member left Addis Ababa. It is hoped that RCMRD staff may be able to conduct trainings there and in other countries.   The tool explicitly requires users to dedicate their data to the public domain, though it will obviously be difficult to enforce “requirement”. 

Overall, many valuable lessons were learned in this short pilot program that can improve the quality and effectiveness of roads and agricultural feature data collection in Africa and in other developing regions. Were the approach to be institutionalized and the PDAs to be deployed over longer time frames (in combination with active data collection), one could envisage a process whereby roads data are collected for an entire country over the course of a year and then updated periodically as new roads are built. 

3

‐ Possibilities for completing or expanding the work in Africa  

 

   

 

‐  Lessons  or  recommendations  related  to  the  project    from  the  outset  of  the  idea,  to  its development,  to  its  selection  for  funding,  to  its  implementation,  including  administrative aspects.  

 

   

 

‐ With hindsight, what would you do differently in this project?  

 

 

 

Finally,  I'd  suggest  you  include,  if  available,  some  analytical  information  to  support  the conclusions  of  the  final  report  regarding  the  methodology  of  data  collection.  I  mean,  for instance,  the number of collectors  for each method,  the % of assertive  (if any) and  incidental data collected..    

 

 

 

I hope you can see the advantages of doing such an executive summary.  

 

 

 

Thank you in advance for addressing these issues. 

The  following  report  summarizes work  carried  out  for  the AGCommons  Ethiopia  Roads Data Development project and  is submitted as the deliverable for Phases 3 to 4 (Data assembly and reporting). 

 

Phase 3 ‐ Task 4: Remaining Data Collection 

IMMAP will continue collection of data as defined by the plan developed  in Task 1 until all required  roads  have  been  collected.  RCMRD  representatives  will  be  introduced  to  the software and the methodology, for further replication in East Africa. 

Deliverables: None – data to be packaged and delivered as defined by Task 5. 

1. Field allocation of PDA units 

4

PDA  units  were  deployed  to  the  field  immediately  following  the  completion  of  the  data collection tool in late May. Given the priority placed on improving data availability for the Somali region of Ethiopia, the original 10 PDA units (model ASUS A696) purchased for the project were allocated to the region. 10 additional units (PHAROS 535v) were purchased over the summer in order to increase the rate of data collection and allow for concurrent missions in other regions of Ethiopia. After clearing customs and being configured to run the CyberTracker data collection tool, these were distributed throughout northern and western Ethiopia to cover the remaining areas of interest in the country.  

2. Transfer of Knowledge and RCMRD  

RCMRD (Regional Centre for Mapping of Resources for Development) staff from Nairobi, Kenya, Catherine Kunyiha  (Remote Sensing Expert) and  Julie Maingi (GIS Expert), travelled to Ethiopia for  the week of September 28th  to  collaborate on  the gROADS  tool and  training with  iMMAP staff  Anna  Schemper.  This  training  of  trainers,  ensures  that  RCMRD will  be  in  a  position  to deploy the methodology to other countries in Africa in the future.  After  a  day  in Addis  planning  and  preparing  for  the  training,  Catherine  and  Julie  traveled  to Dessie,  Ethiopia  where  they  spent  two  days  training  WFP  field  staff  on  the  gROADS  data collection tool. Approximately 15 participants attended with additional training provided for the Dessie WFP suboffice ICT focal points.  In  total,  throughout  Ethiopia  approximately  100  personnel, mainly  from WFP  but  also  from other organizations, were trained in the use of the CyberTracker roads data collection tool.  Data  collection  from  incidental data  collectors  in Somali Region  sub‐offices  (Dire Dawa,  Jijiga, Gode, and Kebridehar suboffices)  increased considerably  in the  last few months of the project, following  renewed  directives  by  the  WFP  Country  Office  to  its  field  staff  concerning  the importance  of  this  task.  Collection  started  out  of  Dessie  Suboffice  in  northern  Ethiopia immediately following the training conducted by RCMRD staff, from where WFP FMAs monitor all of Amhara and Afar Regions to Food Delivery Point level. 

5

3. Data Collection Data collected against requirements is summarized as follows: 

Region  Existing Roads Data (km) Estimated  Additional (km)* 

Collected 

Km  % 

Afar  5262  3508  330  9.4 

Gambella  875  437  121  27.7 

SNNP  1984  1323  0  0.0 

Somali  16922  11282  4767  42.3 

Grand Total  25044  16551  5218  31.5 

*These  figures  represent an estimated proportion of mapped  to unmapped roads  in each region based on local knowledge and comparison with similar but well‐mapped regions 

  Additionally, data for logistically important areas as dictated by the head of WFP Logistics were collected for the following regions: 

Region  Collected Roads (km) 

Oromiya  1367 

Tigray  227 

 It  should be noted  that estimated additional  roads data were  just  that—an estimate. Bearing this  in mind,  there  is unfortunately  is no  sure way of  knowing our exact  success  in  this data collection exercise.  An assessment of data collection performance is provided in Phase 4 below.   

6

  Phase 3 Task 5: Data Assembly 

IMMAP and CIESIN will assemble a complete dataset of  roads covering all‐season and major  dry‐season  transport  routes  in  Ethiopia.    This  dataset  should  meet  all  major standards  established  by  the  AGCommons  program  and  be  published  to  a  reliable metadata node (eg: GeoNetwork) at CIESIN and/or RCMRD as well as other appropriate portals. 

Deliverables: Complete Dataset as defined above. 

1. Data Processing  Beyond  helping  to  conceptualize  the  data  collection  strategy,  CIESIN’s  primary  role  in  this project was to process the Cybertracker output files (CTX files) and to compile them into a roads database  that  is  compliant with  the UN  Spatial Data  Infrastructure‐Transport  (UNSDI‐T)  data model, to merge those data with the World Food Program base map, and to serve the data on the web using an web map service. As of 6 January 2010 the first step has been completed, but neither merging  nor  data  serving  have  been  started.  All  steps will  be  completed  in  by mid‐January.  Based  on  preliminary  data  received  from  Ethiopia  in  July,  CIESIN  developed  a  set  of  python scripts  to  process  the  CTX  files.  The  first  script  accepts  as  input  CTX  files  exported  from Cybertracker as shapefiles. The data are separated by device ID, date, and time, and  lines with directionality are created based on the time stamp associated with each way point. The output is an ArcGIS  file geodatabase with  two  feature data sets: mass points  (points along  the  track) and tracks (line features derived from the mass points).    In addition, the attribute  information 

7

collected by the field teams is converted to two additional feature data sets: events (change in road  conditions)  and  points  of  interest  (agricultural  markets,  grain  silos,  check  points, warehouses, obstacles, road damage, culverts, fords, riverbeds, and bridges).   The second script takes the tracks and events and, based on the time stamps of events (which indicate the direction of travel), it creates line segments with attributes.  This is accomplished by using Network  Analyst  to  build  routes  for  lines with  attributes.  The  routes  are  then  split  at events and assigned the observed changes in road conditions. The result is a set of line features for areas where attributes exist (i.e., field teams recorded road conditions). Both scripts can be reused  for  future  data  collection  efforts  that  use  CyberTracker  and  the UNSDI‐T model  (see Appendix 1 for the scripts).   Once  these  scripts have been  run,  there  is  still a manual process  required  to  further edit  the roads data and to establish connectivity between tracks. For the most part this went smoothly, but there were a number of factors that slowed the job down. For example, for cases where the same road was driven by multiple teams, often the events would not be fully consistent across the  tracks, which meant  that  the  editors  needed  to make  a  judgment  call  concerning which attributes to assign to a given road segment.  In other cases, tracks had no corresponding events data (e.g., where the device was left on but no one was actually entering data), which rendered it  impossible  to  run  the second script or  to generate useful data  from  the  tracks.    In  the case where  single  tracks were produced without events, CIESIN  included  the  track  in  the data  set using  Google  Earth  as  a  validation  tool  to  the  extent  possible,  but  the  lack  of  attribute information made  the  resulting data  less useful.   Appendix 2 has  illustrated editing  rules  that were followed in order to ensure consistency across editors and editing sessions.  Not all tracks were connected to the main network. In at  least three cases tracks were  located about 1km from the network, which is too far to be able to connect them without ancillary data such as high resolution imagery.   For future deployment of the PDAs, it will be important during the  training  sessions  to  emphasize  to  field  teams  that  editors  do  not  have  any  ancillary information easily at their disposal and therefore are unable to complete the network if the field teams forget to collect data for a certain period.     Once  the  individual  tracks were  edited  and  attributes  assigned,  they were  considered  to  be completed  “roads”  and  they were  combined with other  roads  to  form  a  complete  roads  file geodatabase.    The  final  step was  to  convert  the data  to  the UNSDI‐T model, which  involved assigning  a  new  source  ID  and  separating  the  combined  road  attributes  into  surface  type (1=Paved,  2=Gravel,  3=Dirt/Sand,  4=Steel,  5=Wood,  6=Grass,  0=Unspecified)  and  surface condition  (1=Rough  (<40kph),  2=Smooth  (>40kph),  3=Snow/Ice,  4=Mud,  0=Unspecified) according  to  the  UNSDI‐T  model  criteria.  A  separate  Source_ID  table  with  the  source information was also created.  

Phase 4 

  Task 6: Reporting IMMAP, CIESIN and RCMRD will develop a report analyzing the lessons learned from the project.   The report should serve as a guide to future efforts to replicate the project for other geographies or remaining roads of interest.  Key analysis that must be included in the report include:  

8

An assessment of the  ideal way to balance  incidental with assertive data collection techniques,  including  an  assessment  of  specific  challenges  encountered  in  this collection effort and the lessons learned from it. 

An  assessment  of  the  usability  of  the  data  collection  tool  and  recommended improvements for future efforts 

An analysis of  the  challenges  faced  in obtaining quality data  from both  incidental collection partners as well as various  types of paid data collectors and approaches taken to identify and engage. 

Deliverables: Final Report as defined above.  

1. An assessment of  the  ideal way  to balance  incidental with assertive data  collection techniques,  including  an  assessment  of  specific  challenges  encountered  in  this collection effort and the lessons learned from it.  

The roads data collection project  in Ethiopia sought to combine two broad approaches to data collection  previously  employed  separately  by  humanitarian  organizations  in  other  regions  of Africa.  Assertive  data  collection,  which  involves  dedicating  resources  to  the  sole  task  of surveying roads, tends to be used during operations where the resulting data support a specific operational requirement and the  immediate benefits (better data reliability and completeness) justify  heavier  project  costs.  Incidental  data  collection  takes  a  ‘wiki’  approach  such  as  that developed  by  Open  Street  Map  and  Google  Map  Maker,  making  maximum  use  of  field personnel’s spare  time while  travelling between project sites and equipping  them with simple data loggers.  A  number  of  lessons  learned  from  both  approaches were  derived  from  this  project  and  are summarized here. 

Incidental data collection 

The main conclusion regarding incidental data collection is that incentives should be put in place from  the  outset.  This  should  be  a model  that  is  followed  in  all  future  projects. Although  an organisation’s management  team  sees  the  importance of  road data  collection  for operatons, those employees who actually do the work often do not. This provision was lacking in the initial data  concept  and  was  corrected  mid‐course  by  having  the  data  collection  sanctioned  as mandatory  by managers  (Head  of WFP  Logistics,  heads  of  suboffices  etc.).  This worked  to  a certain extent but other incentives might also be considered, such as the regular publication of updated maps and atlases; due to resource and time constraints, an updated road atlas will only be  available  after  the project  end.  In  longer  running projects  ‘rolling’ updates  should have  a notable impact on staff motivation. 

Assertive data collection 

Unfortunately, assertive data collection was not  successfully  implemented during  this project. Suitable  surveyor  staff was  not  readily  available. An  alternative  approach  considered was  to equip commercial transporters with the CyberTracker units and the additional work  integrated into their fee, however it soon became clear that drivers did not have the necessary literacy and technical skills to operate the units and had in fact little interest in participating. 

9

2. An  assessment  of  the  usability  of  the  data  collection  tool  and  recommended improvements for future efforts 

Overall the tool was found to be very effective. A number of considerations for future projects are suggested here. 

Training 

In one‐on‐one training, trainees were able to master its functionalities in about a half hour to an hour depending on  language abilities. However, trainings for groups of 20+ people (sometimes the minimum possible due  to  the need  to consolidate  sessions) could  take up  to a day and a half.  This  was  often  attributed  to  a  poor  training  environment—power  cuts,  no  overhead projector, only a few devices to train on, etc. A suggestion for improvement may be to organize a training of trainers, so that smaller groups can be trained in succession without relying on the availability of the project coordinator. The experience with RCMRD trainers proved this to be an effective approach. 

Hardware integration 

At  the hardware  level,  the more  integrated  the equipment,  the better. Half  the units had an integrated car charge unit; half had a combination of wall charger/cigarette lighter inverter. The latter  were  reported  to  have  trouble  maintaining  connection  to  power  supply.    Generally speaking, more pieces of equipment  to manipulate mean more work  for  the  field  staff and a greater risk of device failure. 

Accessories 

Accessories for the data collection unit (window mounts and car charge setup) are a crucial part of the project as without them the task is impractical. The RAM window mounts purchased for the second batch of PDAs proved particularly effective. 

Suggested amendments to attribute structure 

A number of additional attributes useful for road data collection are listed in italics below. These will be forwarded to the custodians of the UNSDI‐T road data model for consideration. 

1. Roads data a. Type (road, off road, detour)  b. Surface condition (smooth, rough, mud) (REMOVE MUD) c. Seasonality (wet/mud, dry) 

  

2. Road obstacle data a. Water 

1. Ferry 2. Flood 3. Wet riverbed (ford) replace with “wet river crossing” 

10

4. Dry riverbed 

c. Other 1. Checkpoint 

1. Type (temporary, permanent) 2. Mine/UXO area 3. Other  

3. Transport related points a. Aerodromes 

1. Type  (airport,  airfield,  airstrip,  helicopter  landing  zone)  Replace AIRPORT/AIRFIELD/AIRSTRIP and simplify to ‘Airfield’ and infer size from other attributes 

2. Surface type (paved, gravel, grass, dirt) 

b. Bridges 1. Bridge type (span, culvert, floating) NOTE: many problems with floating 

bridge type—few trainees understood this even with explanation and in the field this compromised data collection.  

c. Agricultural points 

1. Warehouse 1. Compound  size  (small,  medium,  large)  REMOVE—too 

qualitative 2. Status (commercial, private, gov’t, closed) 

1. Market 1. Type (commodity, livestock, mixed) 2. Status (temporary, permanent) 

Data transfer 

The way in which MS ActiveSync transfers data from PDA devices to the PC should be reviewed. There was a considerable amount of data  loss and confusion reported from  ICT focal points  in the field due to the fact that data on the PDA are automatically erased when transferred from PDA  to  PC  (and  deposited  in  CT  database).  It might  be  preferable  to  provide  the  option  of actively erasing data from PDA once the transfer is complete. 

Overall however, the model of establishing an  ICT focal person to manage the process of data upload/ submission to the project manager worked very well; training all PDA users for this job would have proved impractical. 

3. Challenges faced in obtaining quality data from both incidental and assertive data collection partners. 

11

As noted above, assertive data collection was unsuccessful. Initially, this approach was pursued by floating a tender to commercial transport companies used by WFP for its food aid delivery. It quickly  became  apparent  that  the  tool’s  requirements  were  too  advanced  due  to  illiteracy among drivers. Following this, WFP sought surveyors in Addis Ababa interested in the work, but that did not work out. Future projects should rely on the network or consultants developed by RCMRD, however since these are often sourced from abroad, additional resources would need to be budgeted. 

The main challenge  in  incidental data collection originated  from  the perception by some  field personnel  of  extra  work  that  they  were  required  to  do.  These  data  collectors  were  not volunteers;  they were  required  to collect  the data alongside  their normal duties as WFP  field staff. Once again, more effort to demonstrate the eventual benefits to them of this extra work should be carried out in the future.  A  second  challenge  arises  from  the  fact  that  once  routes  to  regular  project  sites  have  been covered,  there  is no  incentive  to adopt alternative,  longer and  less  secure  routes  in order  to cover additional roads. This  leads to redundancy  in data collection as some roads are covered multiple  times, while  some  areas  are  left  untouched.  The  project manager  has  only  limited authority to assign new routes as this is subject first and foremost to operational requirements. However, should this method be mainstreamed into agencies’ operational practices, and should the  method  be  disseminated  among  a  larger  group  of  agencies,  in  time  even  the  least frequented roads would eventually be recorded. 

12

Appendix 1. Python Scripts for Processing Shapefile Output from Cybertracker 

 

Note: the scripts require an ArcEditor or ArcInfo ArcGIS license, version 9.2 or later, to run. 

 

# --------------------------------------------------------------------------- # gps_point_conversion.py # G. Yetman # 20 July 2009 # Description: # Converts GPS points to line features (roads) by device ID and date. Separates # events from mass GPS points and outputs them to individual feature classes. # NOTE: # Output location should be a feature dataset inside a file geodatabase. The # feature dataset should have an appropriate coordinate system (WGS84) and high # resolution/cluster tolerance defined. Using the root of a file geodatabase # will result in generalization of the output road tracks due to default # tolerances. Shapefiles would presumably work (double precision) but this has # not been tested. # --------------------------------------------------------------------------- # TODO: # -clean up: accept input/output parameters as arguments so we can attach this to a model or # call it from a wrapper script # -add the field name to find POI records as a parameter # -validate fields in input shapefile # -do nothing for null sets! # Import system modules import sys, string, os, arcgisscripting # Create the Geoprocessor object. Using older-style for users in Africa who are still running 9.2. gp = arcgisscripting.create() # Allow overwriting of files gp.OverWriteOutput = 1 # Set the necessary product code. If we can get away with just ArcEditor it will be good for those # with the node-locked license. gp.SetProduct("ArcEditor") # set the cluster tolerance so the output tracks are not generalized # here, we are setting it to be arbitrarily high. gp.ClusterTolerance = "0.000000008983153" # Script arguments... #Input_GPS_Point_Shapefile = sys.argv[1] #if Input_GPS_Point_Shapefile == '#': #nooutlier8july09.shp testdata.shp

13

Input_GPS_Point_Shapefile = "D:\\GlobalRoads\\CyberTracker\\Nov242009\\Jijiga_11_20_09\\Jijiga_11_20_09.shp" # provide a default value if unspecified #Output_File_Geodatabase = sys.argv[2] #if Output_File_Geodatabase == '#': Output_File_Geodatabase = "D:\\GlobalRoads\\CyberTracker\\Nov242009\\Jijiga_11_20_09\\November242009_Jijiga112009.gdb\\Events" # provide a default value if unspecified # Local variables... temporary_feature_class = Output_File_Geodatabase + "\\tmp" Unique_GPS_Devices_by_Date = os.getcwd() + "\\tmp_freq.dbf" # Load features into geodatabase print "Loading GPS points to file geodatabase." gp.FeatureClassToFeatureClass_conversion(Input_GPS_Point_Shapefile, Output_File_Geodatabase, "tmp", "", "", "") # Add date field to combine data and time (separate in shapefile) print "Adding new date/time field." gp.AddField_management(temporary_feature_class, "DATETIME", "DATE", "", "", "", "", "NULLABLE", "NON_REQUIRED", "") # Concatenate date and time fields print "Updating new date/time field." gp.CalculateField_management(temporary_feature_class, "DATETIME", "[DATE_] & \" \" & [TIME]", "VB", "") # Create a table of unique device records by date print "Calculating unique device-date records" gp.Frequency_analysis(temporary_feature_class, Unique_GPS_Devices_by_Date, "DEVICEID;DATE_", "") # array to hold output feature class names splittracks = [] # output a point line feature class for each unique device ID/date combination try: # Open the table and output a new point fc for each unique device-date record # keep track of the number of new feature classes and their names rowcount = 0 rows = gp.searchcursor(Unique_GPS_Devices_by_Date) row = rows.next() while row: splittracks.append("masspoints" + str(rowcount)) selectString = "\"DEVICEID\" = " + "'" + row.DEVICEID + "'" + " AND DATE_ = date " + "'" + row.DATE_ + " 00:00:00" + "'" gp.select_analysis(temporary_feature_class, Output_File_Geodatabase + "\\" + splittracks[rowcount], selectString) row = rows.next()

14

rowcount = rowcount + 1 except: print gp.GetMessages() del row del rows # construct lines from the segments based on time stamps. # first, create empty line feature classes to hold the output try: print "" for track in splittracks: print "Processing " + track + " to create track feature classes." gp.createfeatureclass(Output_File_Geodatabase, track + "_track", "POLYLINE") # can use PLTS Points to Line or Polygon tool to do this...but it would be a manual process, shoot. # instead, get a search cursor for the output line featureclass then add a vertex to the line. Create spaghetti data, # we will add attributes using events later. Hopefully we don't hit memory limits here! except: print gp.getmessages() # copy events (where data collection recorded change in road state) to a separate # feature class by device ID and date. Remove these records from the separated point feature classes # so they are not used in the track construction (they tend to be out of synch in time!). try: print "" selectString = "\"POINTTYPE\" = \'Change road condition\'" for track in splittracks: print "Processing " + track + " to create separate events." gp.select_analysis(Output_File_Geodatabase + "\\" + track, Output_File_Geodatabase + "\\" + track + "_events", selectString) # if the output event feature class is empty, delete it. Otherwise, # delete the event features from the point feature class rows = gp.searchcursor(Output_File_Geodatabase + "\\" + track + "_events") row = rows.next() if row is None: gp.delete(Output_File_Geodatabase + "\\" + track + "_events") else: gp.makefeaturelayer(Output_File_Geodatabase + "\\" + track, "temp_points_lyr") gp.selectlayerbyattribute("temp_points_lyr", "NEW_SELECTION", selectString) gp.deletefeatures("temp_points_lyr") except: print "Error in creating event feature classes." print gp.getmessages() del row del rows # copy events (where data collection recorded a feature of intest) to a separate

15

# feature class by device ID and date. Remove these records from the separated point feature classes # so they are not used in the track construction. As we have already removed change in road condition # events from the mass points above, this block removes any points that have a non-null DATA_RECOR value. try: print "" selectString = "\"DATA_RECORDC\" <> \'\'" for track in splittracks: print "Processing " + track + " to create separate point of interest feature classes." gp.select_analysis(Output_File_Geodatabase + "\\" + track, Output_File_Geodatabase + "\\" + track + "_poi", selectString) # if the output event feature class is empty, delete it. Otherwise, # delete the event features from the point feature class rows = gp.searchcursor(Output_File_Geodatabase + "\\" + track + "_poi") row = rows.next() if row is None: gp.delete(Output_File_Geodatabase + "\\" + track + "_poi") else: gp.makefeaturelayer(Output_File_Geodatabase + "\\" + track, "temp_points_lyr") gp.selectlayerbyattribute("temp_points_lyr", "NEW_SELECTION", selectString) gp.deletefeatures("temp_points_lyr") except: print "Error in creating event feature classes." print gp.getmessages() del row del rows # copy the points from each point file to the corresponding track file in order by date/time try: print "" for track in splittracks: print "Processing " + track + " to get points for road tracks." pointfc = Output_File_Geodatabase + "\\" + track # array to hold track points pointarray = [] lines = pointfc + "_track" # get the shape field name desc = gp.describe(pointfc) shapeFName = desc.ShapeFieldName rows = gp.searchcursor(pointfc,"","","","DATETIME A") row = rows.next() # check that it's not an empty set if row is not None: while row: feat = row.GetValue(shapeFName) pnt = feat.GetPart() pointarray.append(str(pnt.x) + "," + str(pnt.y)) row = rows.next()

16

# write out the line array cur = gp.InsertCursor(lines) pnt = gp.CreateObject("Point") lineArray = gp.CreateObject("Array") for point in pointarray: x, y = point.split(",") pnt.x = x pnt.y = y lineArray.add(pnt) feat = cur.NewRow() feat.Shape = lineArray try: cur.InsertRow(feat) except: print gp.getmessages() print "Can't insert feature." del feat del lineArray del point del cur del row del rows except: print "Error in writing out split tracks." print "Make sure to close ArcCatalog and ArcMap before running this script." print sys.exc_info()[0] #print gp.getmessages() # add device ID and date to tracks try: print "" for track in splittracks: print "Adding device ID and date of collection to " + track pointfc = Output_File_Geodatabase + "\\" + track trackfc = Output_File_Geodatabase + "\\" + track + "_track" desc = gp.describe(pointfc) shapeFName = desc.ShapeFieldName # add fields gp.addfield(trackfc,"DEVICEID","TEXT","","","39") gp.addfield(trackfc,"DATE_","DATE") rows = gp.searchcursor(pointfc) row = rows.next() if row is not None: # update values, same for all rows gp.calculatefield_management(trackfc,"DATE_","\"" + row.DATE_ + " 00:00:00\"") gp.calculatefield_management(trackfc,"DEVICEID","\"" + row.DEVICEID + "\"") except:

17

print "error adding attributes to track." print gp.getmessages() # clean up try: gp.delete(temporary_feature_class) gp.delete(Unique_GPS_Devices_by_Date) except: print gp.getmessasges() print ""

print "Processed GPS points to make " + str(rowcount) + " new feature classes."

# --------------------------------------------------------------------------- # split_route_events.py # G. Yetman # 20 July 2009 # Description: # Split output events into two feature classes: one with changes in road type # conditions and a second for all event types. # Modify output event (change in road type) table to have a from-to structure. # Use output events (change in road type) to create routes with tracks and # output a shapefile that is split appropriately. # Notes: # uses the output of gps_point_conversion.py, which are line feature classes # and point (event) feature classes based on GPS points collected in the field. # --------------------------------------------------------------------------- # Import system modules import sys, string, os, arcgisscripting # Create the Geoprocessor object. Using older-style for users in Africa who are still running 9.2. gp = arcgisscripting.create() # Allow overwriting of files gp.OverWriteOutput = 1 # Set the necessary product code. If we can get away with just ArcEditor it will be good for those # with the node-locked license. gp.SetProduct("ArcEditor") # get the toolbox gp.addtoolbox("C:\Program Files\ArcGIS\ArcToolbox\Toolboxes\Linear Referencing Tools.tbx") # set the cluster tolerance so the output tracks are not generalized # here, we are setting it to be arbitrarily high. gp.ClusterTolerance = "0.000000008983153" # script arguments

18

input_geodatabase = r"D:\GlobalRoads\CyberTracker\Nov242009\Jijiga_11_20_09\November242009_Jijiga112009.gdb" input_workspace = r"D:\GlobalRoads\CyberTracker\Nov242009\Jijiga_11_20_09\November242009_Jijiga112009.gdb\Events" output_location = r"D:\GlobalRoads\CyberTracker\Nov242009\Jijiga_11_20_09\November242009_Jijiga112009.gdb\Tracks" # route event field rfield = "DEVICEID" # missing data flag missing_data = 0 gp.workspace = input_workspace # subroutine to update the event table with a to measure, create the dynamic layer, # and export it to a new feature class. It requires two inputs: table of route events # with a measure field "MEAS", and a route feature class to intersect the table with. def updateEvents(table, roads): if gp.exists(table): # add the measure field gp.addfield(table,"TOMEAS","DOUBLE") rowcount = 0 meas = "" print "Processing", table, "event table to contain to measures" # get a cursor on the table to edit it. Reverse sort by time # so we can use the next row as the updated to measure location # for the previous row. The last row has no to measure, other rows # are given the next row's measure value as the to measure value. rows = gp.updatecursor(table, "", "", "", "DATETIME D") row = rows.next() while row: # if we are at the last row (first in the reverse sorted table), # just get the measure value. Otherwise update with the value from # the next row (previous in the loop) if rowcount == 0: # get the measure value meas = row.getValue("MEAS") else: # update with previous value row.TOMEAS = meas rows.updaterow(row) # get value for next update meas = row.getValue("MEAS") row = rows.next() rowcount = rowcount + 1 # release the locks

19

del row del rows # create the dynamically segmented layer based on the row events table # and route feature. Then export it to a new feature class. lyr = "road_events" params = "RID LINE MEAS TOMEAS" gp.makerouteeventlayer_lr(roads,rfield,table,params,lyr) gp.copyfeatures(lyr,route + "_split") else: print "Table", table, "missing! There was a problem in creating the route events." missing_data = missing_data + 1 # get a list of event point feature classes. We are assuming that the output from the previous # script has not been modified! Note that we are only processing those tracks with point events, # others are ignored. fcs = gp.listfeatureclasses("*_events","POINT") fcs.reset() fc = fcs.next() while fc: track = fc[0:fc.find("events")] + "track" if gp.exists(track): print "Processing", fc, "to create tracks split at point events" # create the output route feature class route = output_location + "\\" + track + "_route" gp.createroutes(track, rfield, route) # locate features along routes event_table = input_geodatabase + "\\" + track + "_eventtbl" event_params = "RID POINT MEAS" gp.LocateFeaturesAlongRoutes_lr(fc, route, rfield, "0", event_table, event_params) # optional params: "FIRST","NO_DISTANCE","ZERO","FIELDS" # edit the table output from the locate tool to have a to measure. updateEvents(event_table, route) else: print "Tracks to match", fc, "events not found!" missing_data = missing_data + 1 fc = fcs.next() if missing_data > 0:

print missing_data, "Missing data for part of the process! Check input feature dataset and for output table of route events."

  

20

Appendix 2.  Illustrated Editing Rules  The  following  are  a  few  examples  of  editing  rules  that  were  followed  in  order  to  ensure consistency across editors and editing sessions.  

1. Where there were two tracks for the same road, editors chose one based on the quality 

of  the  attributes  (frequency  of  events  and  points  of  interest)  or  the  relative 

completeness  in  terms of  length of  the  tracks. Figure 1 shows  two possible scenarios. 

Whenever both roads had the same attributes, the blue road because it is longer. If red 

had more attributes, then the overlapping blue segment was cut and edited to connect 

with the red road. Figure 2, shows a loop track. Traveling south the frequency of events 

recorded was less (points 23‐27) than the ones recorded when traveling north (points 1‐

7). Although the differences may be solely attributable to differences  in  interpretation 

of road conditions by different field collectors, for the purpose of editing it was assumed 

that the field collector on the track with more events was more attentive and therefore 

better captured changes in road quality. 

 Figure 1: Example of road completeness 

21

 Figure 2: Example of events frequency 

 2. Where  the  teams  back  tracked  over  the  same  road  and  assigned  the  same  segment 

different road qualities, the worse condition was chosen. In the example below (Figure 

3), the  lower segment had been driven going to and returning from a certain  location. 

On  the way  to  the  location  (driving  south),  the  road was  assigned  the  class  “Paved, 

Smooth  (>40 kph)”. On  the way back  the  segment was assigned  two classes: “Gravel, 

Smooth  (>40  kph)”  and  “Paved,  Smooth  (>40  kph)”.  The  latter was  assumed  to have 

worse road conditions and therefore it was chosen.   

 Figure 3: Example of worse road condition chosen 

22

 3. It was necessary  to  simplify  geometry  in many  cases by  removing  extraneous  tracks, 

especially  in  towns.  In  the  first  case below  (Figure 4),  the  reddish  line  represents  the 

simplified road data  from  the more complex black  track.  In  the other cases  (Figure 5), 

the before (left) and after (right) is presented. 

 Figure 4: Example of road simplification 

 

 

 Figure 5: Examples of road’s geometry simplification (before and after) 

23

 4. Editors  removed  tracks  entirely  that  had  insufficient  way  points,  such  as  the  track 

below. 

 Figure 6: Example of deleted track