QGIS Compositing, credits where due

Credit where credit’s due on the great QGIS Compositing (as well as some stellar forthcoming raster tools):

http://nyalldawson.net/2013/03/coming-soon-in-qgis-2-0-blend-modes-for-layers/

I thought I had seen an unusually large spike in my Aussie traffic… .

QGIS Compositing, more comparisons

QGIS Compositing, more comparisons… .  You guess which is QGIS and which is TileStache… .

QGIS Compositing, more gushing yet…

Ever had a workflow on the web that resulted in stuff so nice, you wanted to replicate on the desktop?  Ya, me neither until recently.  I love the cartography a particular website, know all the bits and pieces of color and effects that go into, but had no desktop application that could do the same.   Until now.  On the left, QGIS, on the right, TileStache (i.e. mapnik).  There were a few practical differences in application which result in most of the differences you do see, but now we can wrap great cartography into all our products, printed or web.  And no, print is not dead yet, whatever the declaration.

Quantum GIS Compositing Continued

QGIS compositing is not limited just to between layers, but also for elements in the Print Composer. How is this useful? Every want a non-rectangular map? With 1.9 alpha, you can use an SVG to affect the elements under it.  On the right, the svg.  On the left, the map element inside the Print Composer.

Overlay the two with “Blending Mode” set to “Normal” and the svg covers the map.

Set the svg blending mode to “Dodge”, and we get an interesting mask, as well as (in this case) some additional affects related to the two different shades in our svg.

The svg shapes can be anything:

But let’s try something more meaningful, for example, using an svg to mask our map of a peninsula:

For your inner cartographer– behold!  A non-rectangular map!  Wrap some text around that puppy and call it art.

BTW, the map itself is a fake summer aerial created with povray, a winter aerial, and a little tinting of the winter aerial using blending mode “multiply” in the map itself.  But that is the topic of another post… .

 

Way beyond red-dot fever– bees hives and overlapping home ranges

Last week, post Boston Code Sprint, I spent a couple of hours playing with bee data, specifically bee keeper data for Norfolk County Massachusetts.

My friend Eric (a bee keeper of 4 hives in said county) says that worker bees can fly as far as 3 miles for nectar, but after that approximate limit, they hit diminishing returns relative to the calories they burn.

Proximity of bee hives is important for reasons of competition (although bees are quite friendly with each other on the flower) but also disease transfer, which in this age of not-so-easy bee keeping, is an important factor.  So we set out to map bees.

With a list of addresses, QGIS, and the mmqgis extension (see Plugins:Fetch Python Plugins)  which uses Google services for address lookup, we get a nice little set of points for beekeepers in Norfolk County.

Having a good context map for any such set of points is important.  This is the part of the project I worried most about.  Fortunately, we also have the OpenLayers Plugin, which allows us to add a number of web maps as background (BTW, when we want print quality maps down the road, this will cause us suffering, but for now it is a nice stand-in for a good base layer).  We decided the colorless Stamen Toner map was perfect for our purposes.

Now, let’s buffer these points– give those bees 1.5 miles of free reign, and see where the overlaps in range are (we could make these 3 mile radii, but you get the point):

The map tells us something of overlapping ranges, etc., but it seems like we could use something like we could do something more sophisticated.  Anyone who has followed my blog for a while will not be surprised by the employment of Voronoi polygons… .

Eric, having suffered an explanation of different ways to calculate Voronoi earlier in the week, remembered the relationship between buffers and Voronoi, and asked if we could combine them.   In this case, picture soap bubbles of your youth.  Blow a soap bubble for each bee point, and the walls of bubbles in between form Voronoi polygons.  In our case, we use cones instead of soap bubbles, but after a couple hours of playing in PovRay, we made some code like this:

#version 3.6;

// Pov Includes
#include “colors.inc”
#include “transforms.inc”
#include “cone_coords.inc”

#declare Camera_Size = 500000; //freekin huge

background {color <0, 0, 0>}

//Set the center of image
#declare scene_center_x=759496;
#declare scene_center_y=2861454;

#declare Camera_Location = <scene_center_x,5,scene_center_y> ;
#declare Camera_Lookat = <scene_center_x,0,scene_center_y> ;

// Use orthographic camera for true plan view
camera {
orthographic
location Camera_Location
look_at Camera_Lookat
right Camera_Size*x
up Camera_Size*y
}

// Union all the cones together into one object

#declare coner = union {
cone { <0,0,0>,15840,<0,5,0>,0

} };

union {

#declare LastIndex = dimension_size(cone_coords, 1)-2;
#declare Index = 0;
#while(Index <= LastIndex)
object {
coner
translate cone_coords[Index]
}
#declare Index = Index + 1;
#end

// Pigment cones according to distance from camera
pigment {
gradient x color_map {
[0 color Blue ] // Blue to orange will help us employ blue as the alpha values later
[1 color Orange ]
}
scale <vlength(Camera_Location-Camera_Lookat),1,1>
Reorient_Trans(x, Camera_Lookat-Camera_Location)
translate Camera_Location
}
finish {ambient 1}
}

We get a funky result (yes, this is the result I hoped for):

A little transparency, alternate QGIS blending mode, and using the blue band as a transparency band give us a nice output:

We’ll add in those Voronoi boundaries to emphasize the edge of these areas:

And since this is really only meant for Norfolk County bee keepers, and doesn’t represent folks outside that area, we’ll use a mask with a blending mode of “Subtract” to really offset this map:

I will be interested to see if this helps them look at disease control and spread.  In case you are wondering, Eric is luck enough to have an almost dedicated area for his bees, which includes a huge wetland complex (think: lots of flowers) that is (in his words) all his own.  Well, all his bees own, anyway.

Compositing lands on the desktop– QGIS

Ok, how come no one told me this?  Blending modes in QGIS?  I’m running the nightly build for 1.9, so I have no idea if this is new or old, but a little compositing in QGIS is very welcome… :

Now, how the heck do I set transparency?

Solarized

I have been intending to use Ethan Schoonover’s Solarized (http://ethanschoonover.com/solarized) colors for vim for development work for a while now, and finally got around to adding it to my profile on my laptop.  What is nice about the colors is they are meant to be distinguishable in the terminal without using excessive contrast– color is the primary distinguishing element.  It makes writing or reading on a computer easy on the eyes, and so once again vim has become my goto for development work (although I don’t recommend it for everyone…).

Boston Code Sprint

I hung out this week at the Boston Code Sprint http://wiki.osgeo.org/wiki/Boston_Code_Sprint_2013, which is a “C-Tribe” code sprint for improving things like PostGIS, MapServer, and other GeoFOSS projects written in C. See Paul Ramsey’s posts on PostGIS and MapServer for more on what everyone was working on.

Being my first time at a code sprint, it’s been very interesting, and it’s a very warm and inviting group. I will have some forthcoming posts on the work I did on skeletonization, and also work on getting it up on GitHub. Toward this end, Voronoi (yipee!) should land in PostGIS in the future via two venues. The first venue to provide Voronoi will be from the recently welcomed SFCGAL (optional) dependency additions to PostGIS coming down the pike from the Oslandia representatives, Olivier Courtin and Hugo Mercier, who were at the sprint. The second venue will be the addition of Voronoi from within GEOS as a port from JTS, since JTS already has it implemented. That may be a few months off, as it is being proposed as a Google Summer of Code (GSoC) project which Sandro Santilli agreed to manage (after hunting me down in IRC for my overly broad GEOS ticket).

For my part, I cleaned up and worked on documenting my existing code base for routing skeletonization, played a bit with some additional filtering techniques appropriate to skeletonization, and ran some performance tests against the skeleton results that Olivier was producing from an ST_StraightSkeleton function leveraging the CGAL computational geometry library. It wasn’t a fair test, as my skeletonization was approximate, and Olivier’s exact, but it did give us the sense that ST_Voronoi from that codebase might be more performant for the skeletonization problem than exact skeletonization as performed by CGAL. As part of the skeletonization problem, I have been tasked by Paul Ramsey to write a C implementation of Dijkstra routing, to remove my pgRouting dependency from my skeletonization code, which I will start in on when I get a moment to breathe.

So, what will skeletonization look like when it’s complete? Nobody knows, but my projection is that we’ll have a few functions, dependent upon the kind of information you have about the geometry you want to skeletonize. So for example, if you had a stream network with known inputs and outputs, the algorithm would take advantage of that a priori knowledge and use it to clean up the final skeleton. Something like:


skeleton_geometry ST_Skeletonize(geometry polygon, geometry multipoint);


This is will create a nearly perfect skeleton for the cases where you have this a priori knowledge.

The tougher problem, of course, is when you have less knowledge about the skeleton. And if you want to encourage PostGIS developers to kibitz about analytical geometry, pose this as a problem– believe me that hours will be spent generating new algorithms for solving it. I arrived with 4 ideas on skeletonization (one of them the above) and left with an additional 3 or 4 great ones from conversations with Stephen Woodbridge, Regina and Leo, Pierre Racine, and Bborie Park (hopefully I haven’t forgotten any). But, regardless of which of these pan out, the idea is simple, instead of two input geometries, these will take an input polygon geometry and one or more tuning parameters. Cheers to Paul too for helping to limit the depth of this rabbit hole for me.


skeleton_geometry ST_Skeletonize(geometry polygon, value double, skeletonType text);


These solutions will likely not be as good as the routing solution above, but will be tunable to a posteriori results. The use case here might be scanned maps of road networks, contours or similar from which we want to extract linear features, or similar. Thus these approaches are an important addition to enhancing conversion from PostGIS Raster data type.

PostGIS Onesie, redux– side-by-side comparison

I thought one more post for procrastination sake. Brother 4 years ago:

and sister today:

PostGIS Onesie Redux

Following in her brother’s (and father’s) footsteps: