How I Build Geoprocessing Tools: #9 Pseudo Code

The Value of Pseudo Coding

I love to sketch. Some people read books or watch TV to unwind. I like to draw things, inventions, home improvement designs, etc... The act of drawing forces me to see how things fit together and exposes flaws in my idea when I see it come to life on paper. I sketch with general shapes then add details. I might create a breakout of a detail to visualize a connection or create a small section to scale, on graph or line paper, to get a better concept of form. Creating an outline for a document or pseudo code for a computer application is very similar.

The scripting environment gives me access to all GP tools and allows me to programmaticly assign the parameters of a tool. In that way I can dynamically control all the tool parameters and vary those parameters based on various conditional statements I code in the scripting language. I can call GP tools within a conditional loop or logical branch with more control than currently available in ModelBuilder.

However, the real reason I have chosen to venture into the world of scripting for the creation of this MOVE tool is because I want access to the coordinates of the vertices of features. I am scanning the geoprocessor object model and I see that the coordinates are accessible in the model. Of particular interest is this section that deals with a cursor and geometry.

I'll come back to this diagram often when I need help seeing how things fit together. I will also learn much from how others have assembled solutions before I'm done. Next I like to pseudo code my solution. Pseudo coding is what I call the process of simply writing the comments for functional sections of my code without the actual scripting code. I like to write in outline form what my thought for the flow of the script might be. I then read the comments/code and see if it looks like it will work. I can reorganize the statements and then I just fill in the blanks.

The process of pseudo coding performs two very important functions. First it helps me organize the solution into logical steps and second it acts as the foundation for the scripts comments that are required if anyone else needs to fix or modify my code. I may be very brief with the first draft of my pseudo code and I will add more and more detail as time goes along.

Here is my first draft...

# Create the Geoprocessor

# Get the Inputs

# Create a Cursor

# Get the Geometry

# Modify the Geometry

# Write the Output

My second Draft...

# Create the Geoprocessor

# Get the Inputs

# Create a Cursor

# For Each Feature

# Get the Geometry

# Get Each Vertex

# Calculate the New Coordinates

#Get the next Vertex

# Modify the Geometry

# Write the Output

# Get the next feature

...I continue modifying and adding detail until I'm confident I know how to solve the problem with the tools I have. I will continue to add new sections of detail indenting as I go; first pseudo coding with comments and then filling in the blanks with actual code...