Hobu, Inc.

… we’re making excellent, industrial software too. Jeff seems to dismiss the notion that self-organized software development can provide the same level of quality or standing that closed-source, cathedral-style software can. Readers of my weblog should be able to fill in my arguments against this idea without me even having to write them

Speaking of beer and pizza, if ESRI ever wants developers to go out and sell their products for them, they need to quit charging for EDN. As ESRI moves to selling server-focussed software, they need to realize that *developers* are the people they should be marketing to. Yes, the developers don’t hold the purse strings, but if you give the developers the ability to build out a one-off that demonstrates specific organizational functionality, your sales job is done. As it stands now, I think developers are one-off’ing in OpenLayers, MapServer, FeatureServer, GeoServer, and PostGIS. My evidence is completely anecdotal, but I’ve noticed a continuing stream of curious developers showing up and asking very basic questions how to get going. ESRI’s missing these folks, and in my opinion should be taking the same tact with developers that Oracle does. Otherwise, a day or two of fiddling with OpenLayers doesn’t cost $1500 like an EDN seat does…

Even having EDN doesn’t get you much. One fairly serious security-related bug has been stuck in my craw for over a year, and even though I have an EDN seat, I don’t have “support” and I’m not allowed to file bugs. This is completely ridiculous. I wasn’t asking to have my hand held through installing ArcGIS Server. Instead, I was filing a very clear and easy to demonstrate bug. Had this been an Open Source project, I would have filed the bug *with* the patch to fix it as well. Currently, my only hope is to make enough noise on places like this weblog in the hopes of guilting or shaming someone to notice and fix it

OSGeo is a member supported organization, and its entire operating budget comes from sponsorship. One thing that I think is critically important to ensuring continuing sponsorship is to report back to them annually with a “here’s what we did because of your support” report.

We’ve had an Executive Director for over a year, and we’ve been in operation for almost two, but we’ve yet to have an annual report of OSGeo’s activities. I think an annual report is extremely important to help reduce the opacity of OSGeo, show sponsors how their support has actually helped, and give potential volunteers a window into the organization so they can see where to start. Without it, the whole thing’s just a giant black box. In this case, we do need to know how the sausage is made…

The OpenLayers developers and project are probably such rock stars that this fact has little consequence for them, but under my limited tutelage as their incubation mentor, OpenLayers recently graduated the OSGeo incubation process, and it was approved by the board.

Congrats guys!
Update: I see Slashgeo picked up the news.

I do most of my development on OS X, but I do have parallels instances for both Ubuntu and Windows. One thing I really miss on OS X and Windows is valgrind. It is the savior of dumb C/C++ programmers like myself everywhere. Apple ships a couple of tools that are close to approaching the utility of valgrind.

• Chris Hanson’s nice description of how to use the leaks command on OS X.
• ‘man malloc’ on OS X describes a number of environment variables you can use for malloc tracing on OS X.

Still not as good as valgrind, but close enough for a lot of cases…

Hello again. My Plone site got trashed by the spammers, and I’m so sick of Plone that I just grabbed an RSS feed of my posts and plopped them into this Wordpress site. Yes, I know this is PHP. Weblogging in Python sucks.

Everyone’s reimplementing Python bindings to GDAL these days. Sean’s got one or two attempts, and the GeoDjango wrote ctypes bindings for OGR and GEOS. Neither of these efforts are as complete as gdal.py/ogr.py in the standard GDAL distribution, but they are going off and writing new stuff anyway. Why?

GDAL’s Python bindings are really C/C++ in Python form

The API in GDAL’s Python bindings is not at all pleasant to program with if you are a true blue Python coder. There are some gotchas because resource management is foisted on the Python developer who is not used to it, TheNamesOfThingsAreHardToReadSometimes, and the APIs don’t map to other standard Python ways of doing things.

I have been reacting to this by adding more sugar to GDAL’s bindings. Specifically, you will be able to call feature.items() and feature.keys() instead of manually fetching them in the upcoming GDAL 1.5 release. You can also do for ‘feature in layer’ and it will iterate for you. These minor improvements should make things a little better. If anyone has more suggestions for sugar that won’t impact backwards compatibility, let me know.

GDAL’s Python bindings are hard to deploy

GDAL’s deployment story in the past was miserable. Most people depended on pre-packaged Python binaries because it was so difficult to get them built, they didn’t install in a standard (setup.py/disutils) way, depended on external data (the GDAL_DATA directory), and polluted your site-packages. For GDAL 1.5, this story will be improved significantly:

• Setuptools/distutils is now used by default to build and deploy the bindings. I will be registering the GDAL bindings with the CheeseShop, and once available, you should be able to easily build your own bindings if you have the GDAL base library (and headers) installed.
• I am expecting to include the scripts/utilities and GDAL_DATA files *with* the Python package for distributions such as the CheeseShop one and the download.osgeo.org Windows binaries.
• The bindings are now in the ‘osgeo’ namespace, so you can do ‘from osgeo import ogr’ instead of just ‘import ogr’. Note that the old method will continue to work for a while as we deprecate things, but we’re moving in the right direction.

The reimplementers hate SWIG.

SWIG sucks. “Simplified” my ass. SWIG is a complex ball of stuff. If you only have one language to support, SWIG is the worst possible way you could choose to write bindings. If you have five or six languages to support, SWIG is the *only* way you can choose to write bindings and hope to not have to manually maintain thousands and thousands of lines of native interface code. SWIG does indeed suck, but without it GDAL would likely only have Python bindings… not Python, Java, C#, and Perl.

My interest in flying came from exposure to my neighbor’s radio-controlled model flying and working as a line boy filling the local cropduster up with chemicals and fuel. I had an interest in taking lessons near the end of high school, but I didn’t have the resources to undertake the effort. I wasn’t looking toward being a career aviator, which made going in debt to obtain a license impractical. This past year I decided I had the resources to do the training, and after a discovery ride at Hap’s Air Service in Ames, I was hooked.

I completed my ticket (pilot-speak for a license) in the venerable Cessna 172, which is a mainstay of general aviation. Not too fast, not too slow, enough hauling capacity for pasty computer geeks, and docile and forgiving in the air, it makes for an excellent training aircraft. Actual operation of the aircraft is more akin to operating heavy machinery than driving a car, and one of the most challenging aspects of learning to fly comes up very early in training — landing. After getting over the landing hump, I solo’d, and it was then on to doing cross-country flights and building up my experience in preparation for my practical test.

For me, the most enjoyable part of flying is going on cross-country flights. Cross-country flying is defined as flying more than 50 nautical miles, and it doesn’t usually entail going from New York to Los Angeles During training, navigation is usually done through raw pilotage or radio navigation — no fancy GPS. Pilotage involves taking a map and figuring out where you are and where you are going The perfect task for a map geek smashing bugs at 100 mph one mile up …

I am now off into the uncharted (for me) waters of independent contract consulting, and I’m currently looking for jobs. Here’s a list of stuff I’d love to find funding to implement:

• Oracle GeoRaster support for GDAL
• ArcSDE raster write support for GDAL
• ArcSDE vector write support for OGR
• Finish implementing and rolling out the next-gen Python bindings for GDAL 1.5
• External RTree support for OGR drivers that would benefit from it.
• QueryByShape support for ArcSDE in MapServer
• PySDE development
• General MapServer and GDAL development

Contact me at hobu@hobu.net if you are interested in working with me.

The GDAL project has historically been very branch-averse, and this has meant that all releases were a combination of new features and bug fixes. Another immediate benefit to the GDAL project of the move to subversion
is that branching and tagging is simple… it’s just another copy, and it’s allowed us to maintain a “stable” branch and selectively backport bug fixes. MapServer has followed this release pattern for quite a while, and I’m sure GDAL users will appreciate not having the ground shift underneath them just for a bug fix.

For more details on the release, read Frank’s release message http://lists.maptools.org/pipermail/gdal-dev/2007-April/012533.html

Trac is the best thing since sliced bread. Er, ok, maybe not *that* great, but if there’s any software product out there that embodies that gross word called synergy, Trac is it. It brings the source, bugs, and documentation (wiki) together into a lean, mean, software production machine (again, more hyperbole, but damn I like Trac).

GDAL previously existed on infrastructure spread across at least three different servers. We had CVS hosted at MapTools, Bugzilla hosted at remotesensing.org, and documentation hosted on Frank’s personal server. Having things spread around so much meant that once it was working, it was pretty much left alone, which was ok until stuff broke (thanks MySQL). Our project’s infrastructure made it very difficult for non-developer types to participate other than through maillist interaction.

In January, after approval from the project steering committee, we migrated from our CVS server to Subversion at http://svn.osgeo.org/gdal. This first step allowed us to easily move stuff around in our repository and has given us tons of flexibility. Last weekend, I migrated our Bugzilla to Trac at http://trac.osgeo.org/gdal. The final step of our infrastructure migration gave us stuff we’ve always wanted like a wiki, usable milestones and development roadmaps, and a great source code browser. I’m excited and hopeful that Trac will help the GDAL project scale as it continues to attract more contributors, code, and bug reports

BTW, a member of the ANSI C committee once told me that the only thing rand is used for in C code is to decide whether to pick up the axe or throw the dwarf, and if that’s true I guess “the typical libc rand” is adequate for all but the most fanatic of gamers . _{Tim Peters. 21 June 1997}

import ogr
import osr
import random

ds = ogr.Open(r'c:\hobu\shapefiles\data.shp', 1)

layer = ds.GetLayer(0)
count = layer.GetFeatureCount()
for i in range(count):
    feature = layer.GetFeature(i)
    fudge = random.randint(0,10000)
    geometry = feature.GetGeometryRef()
    gcount = geometry.GetGeometryCount()

    for j in range(gcount):
        g = geometry.GetGeometryRef(j)
        pcount = g.GetPointCount()

        for p in range(pcount):
            x,y = g.GetX(p), g.GetY(p)
            g.SetPoint(p,x+fudge,y+fudge,0)

    layer.SetFeature(feature)

ds.Destroy()