tecznotes

If you need to make a bag of polygons from a selection of OpenStreetMap data, you would think that simply running shapely.ops.polygonize on the selection of linestrings is enough. In fact, polygonize needs for the line endings to coincide, and may not work as you would expect with OSM data. I scratched my head over this a bit after successfully using polygonize to handle TIGER data, until it occurred to me that TIGER is built to have lots and lot of little lines.

The trick is to split each linestring input to polygonize() into all its constituent segments, and then let the function do the reassembly work for you. Creating the polygons of Amsterdam above from metropolitan extract roads took just a few seconds. Here’s the polygonize.py script that does it, expecting GeoJSON input and producing GeoJSON output.

Hachures are an old way of representing relief on a map. They usually look a bit like this, and they’re usually hand-drawn:

I’ve been playing some some simple algorithmic ways to generate hachure patterns with input elevation data.

They’re rather New Aesthetic, with the regular-spaced grid based this pattern that encodes slope and aspect together:

You can align the marks with the slope, or across it (as with contour lines). The latter results in some pretty blocky-looking hills; my feelings about these are mixed:

I especially enjoy the smooth appearance of hills in San Francisco using the orientation along the slope. Things get even more interesting when minimal labels are added on top:

Also, good things happen at relative-low zoom levels, where the relative size of hills and marks gives everything a spiny, written-on appearance:

Have a look through a collection of renders for more examples.

Next weekend, I’m heading to Chicago to spend a week volunteering for the Obama 2012 campaign’s tech team. I’m very excited; it should be a fairly high pressure environment and I hope to have a number of opportunities to bring a bit of API design and basemap cartography love from San Francisco.

This election feels intuitively like the one that matters, the one where we prove that the past four years weren’t just a reactionary fluke. We had a round of flowers and sunshine last time around, but the President wasn’t running on much of a record. In 2012, he’s been in office for a full term, and a lot of people who were hoping to see a 180° turnaround from the Bush years were disappointed to discover that ours is a rough political landscape to navigate. Given the circumstances, I think Obama’s done a great job. Given the risk that supporters from 2008 might not be so excited this time around, I’m putting in extra energy to help assure that we can push this not-at-all-guaranteed election over the hump.

If you’re local to San Francisco and want to help, Catherine and Angus at the SF technology field office in SOMA are looking for your help.

We launched a thing last week. It was fairly well-received by people on the internet. A few people at Stamen who don’t normally write on the company blog wrote on the company blog: Zach talked about the blur/noise process behind the watercolor tiles, Geraldine explained all the work that went into the textures, and Jeff showed off some of his work logging tile usage on the site. I recapped a lot of my background work on Terrain, and then Cups And Cakes Bakery went and made it into cupcakes.

Paul Smith, who taught me how to install Mapnik a long time ago, did an interview with me about maps while slacking off from his day job. In it, I wrote a bunch of things that I think are interesting about online maps, which is a good thing because today I didn’t feel well and bailed on my Where 2.0 talk. Sorry about that—you didn’t miss anything, I was really unhappy with the talk I had prepared, which probably contributed to my morning.

Here are pictures:

With some help from Ryan and Tom, I’ve been wrapping my pea-sized brain around WebGL. I’m doing my usual start-from-the-bottom thing so it’s been a great exercise in understanding a programming paradigm built around static lists and buffers. I’ve worked like this before, but not extensively and not with a render output this smoking fast.

It’s all simple stuff so far, but I’m chasing two ideas: using WebGL for simple 2D output with an added speed bump, and driving it from SVG or the HTML DOM. None of the examples below will work unless you’re using a current WebGL-compliant browser, which for me was Chrome 17.

The elephant is me figuring out the basics of viewport transformations that match pixel positions, image textures, and simple animation passed via vertex buffers:

The monkey is a test to see how many things I can throw around on a screen without sacrificing framerate, as well as some sanity checks on coding style. Turns out, the answer is “lots”. Interesting things happen with this one when you switch to and from its tab; I’m using a basic timeout-based mechanism for the little face particles, and it clearly falls into a regular rhythm.

The unicode patterns (borrowed from Sarah Nahm) are governed by an invisible D3 force layout, and are a test of synchronization between multiple “programs” and driving a visual effect from a geometric layout. Also additive blending for punchiness. Try dragging the boxes:

These are some of the resources I’ve been using to get up to speed:

• Learning WebGL
• OpenGL Shading Language wiki
• CAAT implementation notes
• Mozilla Developer Network (with best practices)
• Raw WebGL from Opera

I’m still not totally comfortable with the programming approach of maintaining collections of static lists in preference to objects and other data structures, and I’ve been avoiding three.js until I can get comfortable with how WebGL works for simple, two-dimensional graphics. No lighting effects or spinny statues quite yet.