I'm a bit late in pointing out this story on the National Geographic site concerning the geographic literacy of young (US) American adults. The story is cleverly illustrated with an image of the globe showing only the United States. A slightly more nuanced map of the world from the perspective of the average US citizen went around the blogosphere in 2004, before geospatial blogging caught on.

I tested myself (18 for 20), and made the common mistakes explained at the bottoms of pages 31 and 34 (see the report). There are some interesting results in there that didn't make the headlines. A majority grossly overestimate the population of the US, with 29% guessing that there are more than a billion of us! Less than 1 in 5 know that Mandarin is the most used natural language. Only 11% correspond regularly with anyone outside the US.

Ed Parsons' entry about perceptions of open source leaves me scratching my head. I'm pretty sure the intention was to inform about the reality of open source GIS as well as the perceptions, but his readership could come away a bit confused.

He writes:

The day started with Martin Daly of Cadcorp debunking some of the myths of open source software, including

• Open source does not mean free !!
• Open source means I can get access to the source code, different to "freeware"
• Open source developers are not cola fueled communists operating from their bedrooms, but mostly professional programmers employed by commercial companies to contribute to open source projects.
• In many ways open source licensing is as complex as commercial closed source licensing !!

I've never met Martin Daly, but know of him through the postgis-users list. I'm sure he'd do a great job debunking myths. Is the list in the excerpt above intended to be a list of myths, or a list of truths? To me it seems a bit of each, so I'll address them as they are.

Sometimes I find myself cycling through databases when developing with PostGIS. To reduce the amount of typing I've written a simple makefile. It's cleaner than a shell script:

POSTGIS = /usr/local/share/postgresql/contrib
DBNAME = new_db

all: db

clean:
    dropdb $(DBNAME)

db:
    createdb $(DBNAME)
    createlang plpgsql $(DBNAME)
    psql -d $(DBNAME) -c "CREATE SCHEMA postgis"
    psql -d $(DBNAME) -f $(POSTGIS)/lwpostgis.sql
    psql -d $(DBNAME) -f $(POSTGIS)/spatial_ref_sys.sql

The command below creates a fresh database:

$ PGUSER=postgres make -f makefile_postgis

and the following drops it:

$ PGUSER=postgres make -f makefile_postgis clean

You can easily add other targets that use shp2pgsql and psql to load shapefiles into the new database. See the PCL makefile_postgis for example.

In a previous post I wrote about using the Python Cartographic Library for charting the bright stars. Now I'm revisiting this script while working on a generalized bivariate cartographic style for PCL. Style generator, more precisely, in which one feature property parameterizes M point symbolizer sizes and another parameterizes N colors. From these we generate M x N rules for symbolizing features.

In this example, symbolizer size in pixels is determined by the visible magnitude of a star, and color is determined by spectral type. The coolest M type stars are shown in red, the hottest B type stars in purple. If you're fortunate enough to be somewhere with an optically thin night sky and and few city lights, you can actually see the color difference between the two brightest stars in Orion with an unaided eye. Betelguese (alpha Ori) is the red star at the upper left of Orion, and Rigel (beta Ori) is at the lower right.

The symbolization rules are parameterized by the following mappings of magnitude ranges to pixel sizes, and a function of the spectral type string to a hex color:

mags = [
    ['f.MAGNITUDE <= 0',       13],
    ['0 < f.MAGNITUDE <= 1',   11],
    ['1 < f.MAGNITUDE <= 2',    9],
    ['2 < f.MAGNITUDE <= 3',    7],
    ['3 < f.MAGNITUDE <= 4',    5],
    ['4 < f.MAGNITUDE <= 5',    3]
]

colors = [
    ['f.SPECTRAL_TYPE.startswith("O")', '#FF99FF'],
    ['f.SPECTRAL_TYPE.startswith("B")', '#CC99FF'],
    ['f.SPECTRAL_TYPE.startswith("A")', '#9999FF'],
    ['f.SPECTRAL_TYPE.startswith("F")', '#99FF99'],
    ['f.SPECTRAL_TYPE.startswith("G")', '#FFFF99'],
    ['f.SPECTRAL_TYPE.startswith("K")', '#FF6633'],
    ['f.SPECTRAL_TYPE.startswith("M")', '#FF3300'],
    [True, '#CCCCCC'],
]

The rules are a product of these two lists, and in this case the filter expressions are simply and-ed:

star_style = Style()
for m in mags:
    for c in colors:
        g = Graphic(mark=Mark('circle', fill=Fill(c[1], opacity=1.0),
            stroke=None), size=m[1])
        symb = PointSymbolizer(graphic=g)
        rule = Rule(m[0], [symb], "%s and %s" % (m[0], c[0]))
        star_style.rules.append(rule)

You could accomplish this in MapServer too, but it would require 48 class definitions and at least 500 lines of configuration. In my mind, the code above is a big improvement.

Last week MapServer's technical steering committee voted to make Steve Woodbridge a member. Steve is the first person we've added since the committee was formed. He's one of the most well-known, knowledgeable, and friendly voices on the mapserver-users list, a presenter at the annual conferences, and probably the foremost user of the Perl mapscript bindings. When I asked Steve if he was interested, he eagerly said yes. I probably should have proposed his membership earlier, as we've always intended to bring on more of the MapServer power users.

One current member expressed some concern that we risk making the committee too large and watering down the power of individual members. As I see it, membership is more about responsibility than power, and I'm happy to have Steve Woodbridge share this responsibility with me.

In the discussion around the vote, we also started to deal with the fact that MapServer hasn't yet formed the project steering committee required to get through the OSGeo incubation process. I expect to see some action there soon, and am counting on some of the MapServer TSC folks who also wear OSGeo hats to carry that ball.

Via All Points Blog, I read this article concerning the geospatial Line of Business in the federal government, and found an interesting invitation:

"Think big, propose big ideas," Young said. "Let's hear where you failed so we don't replicate that going forward."

I'll leave it to other visionary lobbyists to propose sole-sourcing the federal geospatial enterprise, or converting our surging prison population (we're #1) into map digitization chain-gangs. If you want to pitch one of these ideas, you're welcome, but please do throw me a small bone. We'll go for lunch and a brace of martinis at whatever Washington restaurant is filling the void left by the closure of Signatures.

I have bolder ideas yet. The GSA wants big? I can go big:

Open Source: mandate the use of open source software in the geospatial LoB.

Open Standards: this is what allows a diversity of applications to work together, and prevents vendor lock-in.

Open Systems: the internet, from which we can not separate geospatial interests, is supposed to be distributed, decentralized, and even a bit anarchic. Consolidation is counter-productive. If anything, we need more participants in the geospatial community, and federal funding should go towards increasing the diversity of connections between agencies (government or civic) and citizens. More mash-ups, more peer-to-peer; fewer repositories, fewer one-stops.

[PCL-MapServer output (full size, 145kb)]

I've been thinking a bit more about PCL and mapnik and their separate implementations of SLD. Compatibility would be great, but it might be easier said than done. The problem with sharing an SLD implementation is that mapnik is a C++ framework with Python bindings, while PCL is a Python framework with some C extensions.

Mapnik uses Boost.Python, which makes it very easy to access C++ code from Python. Going the other way is not nearly as easy. I can't tell yet if Boost's support for execution of Python is as good as what SWIG provides through directors. At any rate, to use the PCL styling classes, mapnik developers would have to get very intimate with the Python C API: PyObject_GetAttr() and friends. I assume the mapnik renderer has code that pivots on the C++ type of symbolizers, and some kind of adapter would have to be written. This isn't hard, but it's not trivial either.

body_html_template