Add LabelCenterline function

[quincylvania]

Closes #354. The goal is to replace acalcutt/osm-lakelines with a faster SQL function. I've never written anything this complex in SQL before, so any help with efficiency and best practices is appreciated. I'm also new to this project, so I'm not sure about where to hook this in.

The logic:

1. Get the exterior polygon (ignoring islands) and use a convex hull if for some reason there's more than one exterior polygon
2. Use ST_LineInterpolatePoints to evenly distribute vertices around the polygon
3. Get ST_VoronoiLines from the interpolated vertices and covert to edges
4. Filter to only edges within the polygon
5. Recursively clip the shortest branch edges until only a single line is left
6. Simplify, smooth, and return

SFCGAL is not required for this method.

It takes about 40 seconds to calculate lines for the 395 largest lakes of Michigan, which I think is already a big improvement over osm-lakelines. The recursion takes about 75% of this time and can probably be made vastly more efficient.

The results are relatively consistent with osm-lakelines and I think look pretty good, except when there are large islands or bays.

[nvkelso]

Rad!

[nyurik]

this is really impressive! The sql style is a bit different from other files (e.g. using ', etc), but no biggie. I will be studying it for a bit for sure

[pnorman]

I'll try to give this a detailed review, as it's something I've been interested in.

[nyurik]

Among the above examples, I think only this one seems a bit incorrect:

[quincylvania]

The sql style is a bit different from other files (e.g. using ', etc), but no biggie.

I converted these to PL/pgSQL functions to avoid the block string, but I see that this also enables some language features we might be able to use to speed up the code. I'll look into it at some point.

Among the above examples, I think only this one seems a bit incorrect:

Yes, the more circular the feature, the harder it is to determine a sensical centerline. We might try baking in a threshold where circular stuff just defaults to a horizontal line.

We could also achieve better results by allowing multiple lines in the output to account for islands and bays, perhaps based on the zoom. Lots of of shapes just really aren't modeled sufficiently by a single line. Ex: Manicouagan Reservoir.

[quincylvania]

Okay, I added a number of enhancements to get nicer results in a reasonably fast timeframe. It now takes just 15 seconds to calculate the basic centerlines for the 395 largest lakes of Michigan, down from 40 seconds. Smoothing is now done proportionally to the size of the feature.

Multiple lines over a given length threshold can be included in the output. This allows more accurate labeling at higher zooms.

Holes over a given size can be included in the calculation as well. This takes a little longer to calculate, 22 seconds for these lakes.

More examples:

There as six parameters to customize these behaviors.