tecznotes

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

Sep 27, 2010 5: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:

March 2024
Su M Tu W Th F Sa
     
      

Recent Entries

  1. Mapping Remote Roads with OpenStreetMap, RapiD, and QGIS
  2. How It’s Made: A PlanScore Predictive Model for Partisan Elections
  3. Micromobility Data Policies: A Survey of City Needs
  4. Open Precinct Data
  5. Scoring Pennsylvania
  6. Coming To A Street Near You: Help Remix Create a New Tool for Street Designers
  7. planscore: a project to score gerrymandered district plans
  8. blog all dog-eared pages: human transit
  9. the levity of serverlessness
  10. three open data projects: openstreetmap, openaddresses, and who’s on first
  11. building up redistricting data for North Carolina
  12. district plans by the hundredweight
  13. baby steps towards measuring the efficiency gap
  14. things I’ve recently learned about legislative redistricting
  15. oh no
  16. landsat satellite imagery is easy to use
  17. openstreetmap: robots, crisis, and craft mappers
  18. quoted in the news
  19. dockering address data
  20. blog all dog-eared pages: the best and the brightest

Archives