Geeked About Cycling

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.

Geographic Literacy

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.

Open Source Myth Busting

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.


Re: Open Source Myth Busting

Author: Martin Daly

Sean, I've already commented on Ed's blog about the slight misrepresentation of my words. What I would like to note here is that although I obviously am employed by a nasty closed source vendor, I was presenting in my capacity as a member of the AGI Technical SIG committee, and thus from a neutral point-of-view. I hope that I explained, rather than supported or opposed, open source. You'd have to ask the audience about that though. I do admit that I have "a thing" about many-eyes-make-all-bugs-shallow, which I think can be the case, but is often an over simplification given the complexity of some software. The bit about who developers are was part of the more general explanation of open source, rather than the open source GIS bit, and I agree comes across as a somewhat misleading out of the context of the presentation. Having said that, open source GIS would not be where it is today without the likes of DMSG and Refractions, etc. The question of support was raised during the day, and the Q and A session. It was pointed out that while mailing lists, newsgroups, IRC, etc., are the main conduits for support, companies like DMSG are starting to offer "commercial" support, for commercial rates of course. There was a feeling at the meeting that the organisations that were presenting case studies were cash poor but time rich, and that the support cost was "hidden" as man hours. More expensive? No idea. I would guess that it is very project/case/accounting-dependent. Martin P.S. I have read the "fearsome" GPL.

Re: Open Source Myth Busting

Author: Ed Parsons

Sean, I agree this could be open to misinterpretation, I think Martin has done a good job to clarify.. I'm still undecided about the support issue, I think at this point the perception about "support costs" is on balance valid, until there are more DMSG like companies offering support, "community" support is not an option for many organisations. ed

Re: Open Source Myth Busting

Author: Rob

Just some links to authoritative info on free *and* open source... ...if you prefer information in a blog like format, loaded with opinion and personality, consider starting with Stallman's personal home page...

Re: Open Source Myth Busting

Author: Paul

Ref: Martin's quote on open source related costs: ..."There was a feeling at the meeting that the organisations that were presenting case studies were cash poor but time rich, and that the support cost was "hidden" as man hours. More expensive? No idea. I would guess that it is very project/case/accounting-dependent." "Man Hours" are a cost-item to be sure; but it's what you do with your man hours and how fast you bring something to market. You are going to spend those hours doing SOMETHING; Thanks to DM Solutions and MS4W and the other tools at, I had a simple OS web application up and running in an hour. I could have done it all from scratch and spent two weeks trying to get Apache and MapServer et. al. all working on windows xp - but I didn't. I see no problem with open source support vendors charging market rates - especially when they give back to "the community" like DMSG has. I wish I had a dollar for every hour I've spent digesting the ESRI Support site; and I pay an annual extortion fee on top of the many man hours to troubleshoot their commercial software.

Re: Open Source Myth Busting

Author: Martin Daly

Sheesh. This could run and run... Rob, I read those and more in the (much too long) time I spent preparing my presentation. Paul, you quote me but then seem to miss my explicit reference to *the organisations that were presenting case studies*. It was not the case that anyone at the meeting stated that *all* projects using FOSS were like this or that you *had* to have lots of time to spare in order to use FOSS, nor did I intend to report it as such. As for your experience with ESRI: they are big enough and ugly enough to stick up for themselves. I would also trust that you do not imagine that this applies to all commercial companies, hint, hint.

Re: Open Source Myth Busting

Author: Eamonn Doyle

This is an interesting thread and I would agree that it could run and run. My experience is that in a complex GIS project the initial costs and ongoing licencing of commercial off the shelf software is insignificant compared to the professional services costs of project management, development and support. In all but the smallest projects, wehether you choose COTS or Open Source, the professional services costs are likely to be the similar. Everybody needs to make a living and there are no free lunches. In the past couple of months I've had exposure to two projects that selected open source software, in this small sample the total costs of implementation of both projects were far in excess of the COTS equivalent. Eamonn

Re: Open Source Myth Busting

Author: Sean

Indeed, Eamonn. That's why I suggested that we not make too much of the "free" aspect of open source. Can you provide any more detail about the two expensive projects? In your company or outside? GIS or not? It's hard to give them credence without any context.

Re: Open Source Myth Busting

Author: Eamonn Doyle

There are some commercial sensitivities here but without giving too much away... One was a spatial metadata/web services project in which some partners were using COTS and one was using Open Source. The COTS partners contracted us to develop, they got a working prototype within 12 weeks at a pretty reasonable cost. The Open Source partner had to recruit and employ a developer and did not deliver until about 4 months after us. Put an economic cost on all that and my guess it was more expensive. The second was a project on which we bid unsucessfully and subsequently discovered a Open Source solution was adopted at twice our bid price from a systems integrator with no GIS track record - so that's unlikely to come in on budget. In both cases my assessment was COTS was cheaper and less riskey. Opinions my own of course!

Re: Open Source Myth Busting

Author: Sean

Eamonn, Since you don't mention any specific shortcomings of open source, your first example seems like it could be a simple case of management failure. It could happen to any project where you bring in contractors, no? I happily grant your point about the relatively small cost of software in relation to the budget of a large project. Cost is mostly a red herring: The freedom of open source remains its most important aspect. At this point I must disclose that I am part of the team that won the second project you mention. I assure you the customer's situation is not nearly so dire as you make it out to be.

Re: Open Source Myth Busting

Author: Eamonn Doyle

Isn’t the web a small place! It wasn't my intention to criticize but I did want to contrast the approaches and outcomes. My experience is that open source software may not be ideal for all projects precisely because of the level of freedom you mention. When one is under contract to deliver to specification, timescale and budget it's useful to have both a well defined set of tools and a well defined set of responsibilities. As a systems integrator my company assumes risk on behalf of the customer, that’s what we get paid for. We share that risk with our partners, including the technology supplier. In a solution involving open source software it’s not clear to me exactly who is prepared to accept technical risk. As I see it this is a fundamental flaw in applying open source software in deploying mission critical systems. Once a partner who is prepared to accept this risk enters the value chain my guess is they will want a reward. The corollary is that when the customer themselves understands and is prepared to accept the development risk then open source software may be attractive.

Create a PostGIS DB with Make

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

    dropdb $(DBNAME)

    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.


Re: Create a PostGIS DB with Make

Author: Mateusz Loskot

Oh, Irony! It's such obvious to use Make to almost every repetitive task, however I've never bethought about it :-) Sean, I think this could be a very nice improvement to PostGIS makefiles to automation final tasks: createlang plpgsql yourtestdatabase psql -d yourtestdatabase -f lwpostgis.sql psql -d yourtestdatabase -f spatial_ref_sys.sql what do you think?

Bivariate Cartographic Style

Orion constellation thumbnail

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]))

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.

Community MapBuilder 1.0

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.

New MapServer Steering Committee Member

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.

LoB News

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?

Calling All Lobbyists?

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.


Re: Calling All Lobbyists?

Author: Brian Flood

hi Sean assuming you're comments above are not completely tongue-in-cheek :) mandating Open Standards makes complete sense but why would you mandate Open Source? It's an option just like commercial software but I'm not sure why you would exclude one over the other (what ever happened in the MA state govt anyway?) on another note, Mapnik's use of the AGG library is quite nice. Excellent quality maps. Do you know why MGOS didn't use this library? Seems like they missed a good oportunity there... cheers brian

Re: Calling All Lobbyists?

Author: Sean

On mandating open source: I have to take a pretty hard line initially to give myself room to bargain, right? Others are just as free to insist (with far too much success) that the federal government be COTS only. I think most people are comfortable somewhere in between. Why didn't Autodesk go with Anti-Grain? Maybe it's that the license isn't OSI approved, or maybe Autodesk wanted to save sexier graphics for their commercial version. When I take off my hacker hat and start to think like a product manager, I can think of a bunch of plausible explanations.

Re: Calling All Lobbyists?

Author: GeoMullah

Say, that picture looks vaguely familiar? Say, is that my office? Wait. That is my office!

Re: Calling All Lobbyists?

Author: Chris Holmes

As part of OSGeo I'm looking to put together a response to this (unfortunately I couldn't go to the practitioner day thing). In true open source fashion, all our welcome to contribute (and I'm looking to be a lot more swamped than I thought I would be). See the page at the OSGeo wiki.