Michal Migurski's notebook, listening post, and soapbox. Subscribe to this blog. Check out the rest of my site as well.

Sep 27, 2010 1:30am

map sprint

This weekend marked the first global Mapnik Code Sprint. Most attendees converged on Cloudmade's London office, while Nino Walker and I held down the fort in San Francisco and Robert Coup dialed in from New Zealand.

Having just spent about two days thinking deeply about relative path resolution in Mapnik side-car Cascadenik, I'm fairly happy with where the code base has arrived. My goal with all of this stuff - introducing web cartography to CSS, building on Schuyler and Chris's work in tile rendering, and trying to make it easier to run your own map server - has always been to take an activity that's already fun and interesting, and make it easy, fun and interesting. Maps on the internet should not be difficult to publish or overly dependent on single providers like Google, and it's the details in all the bits of glue that make this possible.

For my part, I agreed with Dane to focus on correctness in Cascadenik's output. I put the code away for a while and when I came back a little while ago, it was obvious that a lot of old, bad decisions I had made were in need of some fixing. It's important for good, small tools to behave in predictable ways and I've been taking a lot of cues from what I consider to be prescient, amazing design decisions in HTML and CSS and doing my best to apply them to portable and easy web cartographic stylesheets.

The changes we made fall into three broadish areas:

  • Cascadenik now knows more about paths, so if you ask it to create a stylesheet for Mapnik and put it in some directory, it'll try to be just a little bit smarter about how it names things based on where they are and where they came from.
  • Cascadenik also has a lot less options when compiling, which I think is a good thing. Dane had to update many of my early, now-wrong assumptions with a bunch of patches that added new optional behavior flags, and I used the weekend to change those underlying assumptions so there didn't need to be so many flags.
  • Nino introduced an incredibly cool new way to manage data sources which I think is going to make working with data a lot more palatable.

This isn't quite the place for all the technical details, but I think it's worth repeating that the reason for all this work and effort is to open a certain kind of activity to new groups of people. Dane became an honest-to-god C++ programmer through his exposure to Mapnik and I think that makes him a saint or a hero or both, but it shouldn't be necessary for ordinary users to make this same transition. Rather, it should be normal that people can approach maps and cartography and do interesting things with them, things different from the usual "pizza places in city X" use case offered by the Googles of the world. Like, I've got this wallet that Gem made for me (out of indestructible tyvek!) and these bad-ass shoes that I designed on Zazzle.com:

This is a synthetic preview image that Zazzle showed me when I was posting my renders of the Oakland Assessor's Parcels shapefile:

Pretty close right?

Anyway, most of what I've been doing for the past few years in these occasional experiments and releases has been an attempt to shrink problems, so that activities which might otherwise require substantial effort or time or money or people can require less of all those things, raising the RPE's as Kellan might put it.

I'll see what I can do about making the shoes publicly buyable.

Also, here's that awesome thing Github does where they show you everybody's changes in a long horizontal graph:


Sorry, no new comments on old posts.

May 2017
Su M Tu W Th F Sa

Recent Entries

  1. three open data projects: openstreetmap, openaddresses, and who’s on first
  2. building up redistricting data for North Carolina
  3. district plans by the hundredweight
  4. baby steps towards measuring the efficiency gap
  5. things I’ve recently learned about legislative redistricting
  6. oh no
  7. landsat satellite imagery is easy to use
  8. openstreetmap: robots, crisis, and craft mappers
  9. quoted in the news
  10. dockering address data
  11. blog all dog-eared pages: the best and the brightest
  12. five-minute geocoder for openaddresses
  13. notes on debian packaging for ubuntu
  14. guyana trip report
  15. openaddresses population comparison
  16. blog all oft-played tracks VII
  17. week 1,984: back to the map
  18. bike eleven: trek roadie
  19. code like you don’t have the time
  20. projecting elevation data