I was just asked if I knew of a comprehensive set of openly licensed map symbols:

I have been searching for a set of fairly 'classic' map symbols, that is reasonably complete; classic meaning that the symbols actually convey some meaning, without being overly fuzzy and complex, so it is easy to extend the set without having to imitate somebodies idiosyncratic style.

I'm not aware of such a thing. But it occurs to me that this might be just the job for the OSGeo foundation. High quality free and open source symbols would break down another one of our long-standing barriers to deployment. They might even be able to pay for themselves. OSGeo could relicense them for use with MapGuide Enterprise or other commercial editions of OSGeo products.

Here are the requirements, as I see them:

• Creative Commons license.
• Conform to accessibility guidelines.
• SVG.

The time is now for scalable vector graphics. With the help of several style sheets, we'd have a whole family of symbol sets: greyscale, section 508, or retro web-safe. MapServer can't use them directly (yet) but there are a number of open source tools -- like GIMP -- that can convert SVG to old school pixmaps. It also wouldn't be terribly difficult to convert simple SVG symbols back to MapServer's own symbology language with a little mapscript fu. Future versions of OSGeo software, like a MapServer 5.0, will want to use SVG directly.

I disagree with Adena's take on Planet Geospatial as a group blog. Boing Boing is a group blog. The GeoRSS Blog is a group blog. The Stoa Consortium is a group blog. Planet Geospatial is a feed aggregator. I've worked with James Fee to get markup that is easy to monkey with, but that's as far as I consider it a joint venture. Not that I'd be opposed to participating in a group blog.

Speaking of the blogosphere: I'm looking to blog swap for a week or so with a food or wine blogger that has a equal itch to try writing about the software and data side of viticulture, terroir, geography, and maps. Interested? Send me an email.

Here's a good article by Charlie Savage: A Community for REST. I appreciate the work that the Rails community is doing to push back against WS-*. The other thing I think Rails does exactly right is use of YAML for configuration instead of XML.

Users of GDAL have a couple virtual formats at their service. The Python Cartographic Library is using these for configuration of filesystem-based data stores. The thing is, there are no schemas for these XML languages, there's no way to validate, there are no fancy tools for making virtual files other than your text editor. So why bother with XML? As I see it, here's a great use case for YAML. Instead of:

<OGRVRTDataSource>
  <OGRVRTLayer name="world_borders">
    <SrcDataSource relativeToVRT="0">world_borders.shp</SrcDataSource>
        <SrcLayer>world_borders</SrcLayer>
    <LayerSRS>EPSG:4269</LayerSRS>
  </OGRVRTLayer>
</OGRVRTDataSource>

we could have:

featuretype:
    - name  : world_borders
      path  : /data/world/world_borders.shp
      layer : world_borders
      srs   : EPSG:4326

I feared that it might be too good to be true. Perfect bookend scandals. I sincerely hope that Landis' B sample clears him.

Last week I objected to the OSGeo Foundation overselling the rigorousness of their software incubation process, and challenged the incubation committee to raise their standards. The sitting OSGeo president, Frank Warmerdam, wrote (in comments) to suggest that I could have worked within the committee, using vetos to hold back projects until they'd made serious progress.

I'm a programmer, not a politician, and I've no interest in playing politics like that. I've got many other better things to do with my time. There are tests to write, tickets to be resolved, milestones to be set, and code to be released. And the other folks in the committee wouldn't stand for it. I'd be tarred and feathered. Every project in the incubator has been guaranteed that they'll be promoted. Every member of the committee (except for me, at the time) is also representing an incubating or "on-deck" project, and there is rather high social pressure on committee members to not impede each other's projects.

Does unwillingness to spend a big chunk of free time trying to reform the incubation committee disqualify me from criticising the process? Not in the least. I'm an open source geospatial software developer too, and will be profoundly affected by the actions of OSGeo. Let me try a metaphor on you: I'm not the guy in the back seat of your car second-guessing how you drive, I'm the guy on the bicycle yelling at you to drive carefully.

Ruby is the best thing since sliced bread. It embraces Perl refugees, gurus love it, and you're nothing but a chump if you're using a sucky language like Python or Java. So says the blogosphere. Why then -- with the exception of Charlie Savage's work with GDAL and GEOS -- does it seem that there is nothing significant going on at the intersection of Ruby and Geospatial? There are a few Ruby MapServer users, but no committers. There are a few modules for Google Maps (even I wrote a simple one), but that's just pushpin country. Where are the Ruby modules for cartographic projections? Where are the Ruby W*S clients? Am I missing something right under my nose?

NASA's mission statement has been modified. Look out for the Kiss of Death in a form like this:

President Bush today praised the NASA World Wind project, calling it an "amazing new way of discovering our environment".

It pains me to have to continue to write about what I consider to be faults of the new OSGeo Foundation, but as an unaffiliated developer of open source geospatial software, it's the only influence I have. I want these faults to be addressed. OSGeo must succeed, if only because its failure would wreck the wider open source geospatial domain. I've got friends who are deeply involved, and I'd like success for their sakes. I'm also worried that in this early stage, before it really finds its feet, our gentle OSGeo giant is going to stumble around and break things, or tread on worthy, but less ambitious software projects.