Product(s):	Cube
Version(s):	6.1 to 6.5
Area:	User Programs

For some models, users combine CUBE script language with one or more languages, e.g. Python, etc. Python scripts can be developed from scratch, with a very intuitive scripting language. Moreover, Model Builder in ArcGIS provides a very useful tool to develop geoprocessing scripts, that can be further adapted and easily included in Cube.

Solution

In the example below, in converting some GTFS data to Cube format for the Perth City using Cube Voyager capabilities, we used Python geoprocessing to undertake a Spatial Join between the PT nodes included in the Shape.txt file and the PT stops included in the Stop.txt file.

To show how the process could be built in ArcGIS, we show here how to start using Model Builder, exporting the Python script and adapt it to be used in Cube.

With Model Builder in ArcGIS we can build the model very easily, as shown in the example below.

The model script can be quickly exported to Python script as shown below (Model > Export > To Python Script…).

A Python .PY file is then created, containing the script as it is executed through Model Builder.

The script can be refined if needed, but the only necessary edits are the two steps below:

• Add the import sys statement, to import the sys module
• Change the definition of inputs and outputs using the sys.argv
  function: defining the list of command line arguments passed to the
  Python script

Some further edits have been made in this example:

• The script to allow overwriting of the outputs has been included as
  from arcpy import env
  env.overwriteOutput = True
• The try – except – finally commands have been included as below
  (error handling in Python can be done through the use of exceptions
  that are caught in try blocks and handled in except blocks)
• Run messages are written in the text file “printfile”

To add the new user program (Python in the example) in the Cube environment, follow the simple steps below:

1. First of all, move the python script (StopsNodesJoin.py in the example) to the proper location in your catalog folder (e.g. {Catalog_Dir}/Input/Python).

2. Click on “User Programs > User Programs Settings…” to edit existing programs or add a new program.

3. The User Program Settings window contains the full list of your User Programs, Click “Add…” to add the new User Program.

4. The Python.exe program can be included in Cube directly as an executable (Pythonw.exe if we do not want to pop-up the command prompt when Python is executing). Specify the Program as below, browsing to the Python.exe file location, depending on your installation.

   

   
   As you can observe in the picture, we are going to pass the information needed to Python on the Command Line.

5. Then we need to proceed in defining the remaining components of the Program Interface. We define Input and Output Files as below (with the Script File and allowing 10 inputs and 10 outputs data file, as an example).

   
   

   
   Note that Input files defined as text (rather than binary) can indicate whether they may contain catalog keys.

   
   

   
   

6. Define the Command Line Arguments (sys.argv[#] in the Python script), considering the inputs and outputs, as below

   
   

7. When clicking “OK” and going back to the Application Manager, we can now include Python by selecting “User Programs > PYTHON”, and this will be an empty box, ready for us to fill in with the necessary script file, inputs and outputs. In our example the inputs are the PT nodes and PT stops DBF file (dynamically linked from the outputs from other conversion steps). The outputs are the prn file containing the run report and the stop nodes feature class contained in the GTFS.gdb, with the result of the spatial join.

   
   

The input Script File can be now edited directly within the Cube Text Editor, by double clicking on it within the Application Manager. In our example, the stop nodes are joined to the closest PT node, as it can be observed in the picture below.

The User Program definition made via the wizard is stored in an Application Manager Resource (.RSC) file. Starting from Cube 6.4 (to avoid issues with missing user rights) the file is written to

“C:\Users<username>\AppData\Roaming\Citilabs\Cube\User”

To transfer the program to another machine, the RSC file needs to be copied to the equivalent directory on the target machine. The only settings that you might need to change are the executable name and run path.
It is also possible, through the Pilot program, to copy the necessary RSC file automatically in the right folder, if storing it within the catalog directory.