On January 19th, 2013 the California Chapter of the OSGeo is holding a hack-a-thon. I hope the geogeeks present will be interested in hacking on a new toolkit from the SurveyOS Project called SlitherGrid. Here is a description of the toolkit:
SlitherGrid is an open source toolkit for geospatial raster data processing written in the Python Programming Language. Its focus is on non-traditional raster data (LIDAR, elevation rasters, and other “non-optical” raster datasets). The toolkit is currently in a conceptual stage, although there is preliminary source code available on the SurveyOS Project SVN code repository.
The immediate design goals of the SlitherGrid Toolkit are:
- Pure Python implementation with no dependencies on C programming language libraries.
- Ease of use.
- Support for basic raster processing operations on 2D raster data grids.
- Support for basic GIS and land surveying data formats.
- Pluggable software architecture that supports easy customization. This includes (1) the addition of support for additional raster and vector data formats, and (2) the addition of additional raster processing algorithms and tools.
- Built-in geospatial functionality. (The grids aren’t just simple arrays of numeric values. They support geospatial opertaions.)
The long term design goals of Slither Grid Toolkit are:
- Support for multi-threading.
- Support for 3D raster data grids.
Conceptual Toolkit Architecture Summary
The conceptual code of the toolkit is currently organized into four (4) Python modules. Grid.py contains all of the classes for simple 2D raster data grids. (These are called “SlitherGrids”). Geomtry.py contains utility geometry classes used to represent coordinates, angles, and simple vector geometry. GridIO.py contains classes that support basic file input/output, allowing the user to create 2D grids from common raster data formats. GridPainter.py contains classes that can take a 2D raster grid and paint, or render it, to common image file formats for visualization.
The Sunburned Surveyor
I’ve decided to implement an AutoLISP software module manager in Python. (I’d write it in AutoLISP, but the language doesn’t have some of the filesystem API support that I need.) I’m looking for a plug-in framework I can use for the software similar to that found in Eclipse RCP, Netbeans RCP, or OpenJUMP.
After poking around the internet for a while, I managed to find this very helpful blog post from William E Hart with a review of some Python Plug-in Frameworks. The Yapsy Plug-in Framework in his list looks like what I need. I hope to use it in combination with the PyQT GUI toolkit to create a Python pluggable software framework for desktop applications similar to my Simple Pluggable Swing Program.
Yapsy Home Page
Chris Martin and I continue our work on the Python Point Cloud Processing Library. In our last session we loaded the InMemoryPoint class into IDLE and created and tested objects from it. To get this to work we had to add a local folder with the classes from the library to our Python path, reboot the computer, and import the class. We got a little stuck when we just imported the module name and IDLE complained it couldn’t find our class. We needed to import the module and the class name.
We fixed a couple of little bugs in the class we found during our testing. We’ll start building a unit test for the class in our next session so our tests will be automated. I’ve still got to decide on the best way to do unit testing in Python for our library. We then need to figure out how to add an overloaded constructor in Python. Our current constructor for the InMemoryPoint class doesn’t accept any parameters. We want a constructor for this class that we can pass inital northing, easting, elevation values to.
In the meantime, I’ve got some work to do to keep caught up with the training sessions Chris and I are having. This includes writing the start of our API documentation. I’ve got an HTML template set-up, I just need to start fleshing it out. (I decide to code my own Python API documentation for now, instead of using something like Epydoc.)
I also need to create a Point protocol using the SurveyOs protocol mechanism I’ve created for Python and modify our InMemoryPoint class so it implements the protocol.
As part of our last session Chris and I discussed how the Python interpreter is implemented and why Python always passes “self” as the first argument to the method of an object.
I’ll post with another update as soon as Chris and I get some more time to work on the library.
The Sunburned Surveyor
Chris Martin, a coworker from mine at KSN who supervises our laser scanning technology, has joined me to work on an open source library for point cloud processing. The library will be written in Python and will be released under the GNU GPL. We are meeting for an hour every Thursday to work on the library. We’ve uploaded our very first class file today. Things will move slowly at first, as Python isn’t my strongest programming language and Chris is pretty new to programming in a modern object-oriented language. However, I expect things will really pick-up speed as we move forward. Stay tuned to this blog for updates on the project. All the source code will be released through the SurveyOS Project.
The Sunburned Surveyor