The biggest cycling stage races of the year are upon us, and that means that the TDF Blog bumps Planet Geospatial from the top of my blogpile. Last year I reviewed the official 89th Giro and 93rd Tour maps, but there's no significant changes this year: the Giro map is a little more brown, the Tour map remains the same gold.

The TDF Blog points out that the Tour route is emerging on Google Earth Hacks. By next year, the designers of the race websites will have realized that they need to supplement their drab itineraries and profiles with KML files.

Gabbo-like buzz for ArcGIS Explorer is building again (here for great picture). Does ESRI really need such an application to stay competitive, or is it more of a vanity project? I'll be an ArcGIS user again, but only on the desktop, and for selfish reasons I'd like to see the company not expend resources building a geospatial cathedral. On the other hand, an ArcGIS Explorer that is a viable alternative to Google Earth and WorldWind could help convince people that ESRI really gets the modern web platform.

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.

MapBuilder 1.0 has arrived. Congratulations to Cameron Shorter, Mike Adair, and the rest of the gang. I've been following development of MapBuilder since just before version 0.4, and admire how the project has grown and progressed. The MapBuilder developers love their cutting-edge Javascript and XSLT web platform, and their discussions have a great energy. There's no shortage of ideas in this community. Most of all, I'm very happy that XHTML 1.0 compatibility is a feature in this release. It's the squeaky wheel that gets the grease, after all.

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.

Dave Smith, at Surveying, Mapping and GIS has an interesting geospatial LoB debriefing. It all still seems pretty murky to me (no fault of Dave's). Were there any journalists present to get interviews or comments from the participants?

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.