Geoprocessing for humans: pygp

I'm not the only one simplifying terrible Python APIs in the geospatial world. Yesterday, I ran across a blog post about software named pygp. Very much about ArcGIS records and fields, it models data differently than Fiona does but similarly eliminates a lot of boilerplate and provides simple access to all coordinates of a record's shape field.

def example_geometry(path):
    Example showing use of Geometry helper class that does the heavy lifting
    on the geometry object and returns something quite similar to WKT/GeoJSON

    Structure is simple, a tuple of tuple of Point objects, very similar to
    Avenue days of geometry and WKT MultiLineString etc.
    (((0, 498266, 6100519, None, None), (0, 499775, 6100281, None, None),
      (0, 500224, 6098694, None, None), (0, 499616, 6097662, None, None),
      (0, 498346, 6096789, None, None)))

    :param path: Workspace Path
    :type path: str
    feature_class = FeatureClass(osjoin(path, POLYGON))
    for srow in
        print srow.get_value(

# End example_geometry function

I don't know whether pygp has eliminated the need to count references to cursors and records or just omitted

del feature_class

from the example. I'd have looked in the code, but I couldn't find a link. I bet a lot of people would love to see it on GitHub.


Re: Geoprocessing for humans: pygp

Author: Pedant

No need to del feature_class - it's a local that will be garbage collected when example_geometry() returns.

Re: Geoprocessing for humans: pygp

Author: Sean

Correct in this case. But what would happen if I created a new FeatureClass instance after the above code in the same function, using the same parameters? Would I encounter locked files? My question isn't hypothetical:

Re: Geoprocessing for humans: pygp

Author: Jason Humber

Backing up a little, in the 9.x world of arcgisscripting there was always an imposed need to delete the row and cursor as a means of closing them and dropping references. This usually looked like del srow, srows statement and was usually placed after the while loop. Being forced to use a while loop and the need to use del always felt odd to us so in the cursor implementation we have in pygp we take care of closing cursors once the loop has exhausted.

So in this case there is no need to del feature_class since the locks on the feature class are dropped when the clean-up/closing is done at the end of the loop.

Re: Geoprocessing for humans: pygp

Author: Jason Humber

Just noticed the last line of your post, drop me an email...