This will be a quick post. I just looked at how ST_Buffer is written in the PostGIS codebase, and I thought this was interesting. When you use ST_Buffer and specify geometry, buffer distance, and an integer value, this gets converted in the overloaded function into a quad_segs version. P.S. I would have written more, but Sherlock just started. Continue reading ST_Buffer diving under the covers part 1
My previous post on improving buffering geography in PostGIS has three disadvantages: It doesn’t do this at a low enough level to automatically use the best available local coordinate system. This leaves it to the user to choose the best available local coordinate system. I should fix this (but I probably won’t just now…). It uses a different function name than you otherwise use for buffering. … Continue reading ST_Buffer for those who want really want all buffer features in geography
A little functionality request from @antoniolocandro on twitter: ST_buffer for geography has no option for quad_segs, alternative so buffer looks nice not jagged? cc @smathermather — Antonio Locandro (@antoniolocandro) January 8, 2016 Ask and ye might receive. Let’s build a function that will take your input geography, how far you want to buffer (in local coordinates) number of segments you want in a quarter, and … Continue reading ST_Buffer for those who want really round geographic circles
Trying out PostGIS 2.2’s ST_ApproximateMedialAxis capabilities today. I’m going to use it to label parcels. So here is my parcel fabric: And here’s what the skeleton of that fabric looks like: It get’s pretty interesting where the parcels are more complicated: more: Oh, the code you say? Well, it couldn’t be much easier: SELECT gid, ST_ApproximateMedialAxis(geom) AS geom FROM cuy_parcel_2015; Or the full version for … Continue reading ST_ApproximateMedialAxis(geom)
Two posts precede this one, ODM — the future that awaits, and ODM — the future that awaits (part 이) Ben Discoe has a good point on the first post, specifically: As I see it, the biggest gap is not in smoother uploading or cloud processing in the cloud. The biggest gap is Ground Control Points. Until there’s a way to capture those accurately at a … Continue reading OpenDroneMap — the future that awaits (part 삼)
In my previous post, ODM — the future that awaits, I start to chart out OpenDroneMap beyond the toolchain. Here’s a bit more, in outline form. More narrative and breakdown to come. (this is the gist) Objectives: Take OpenDroneMap from simple toolchain to an online processing tool + open aerial dataset. This would be distinct from and complementary to OpenAerialMap: Explicitly engage and provide a … Continue reading OpenDroneMap — the future that awaits (part 이)
OpenDroneMap could piece together from disparate parts all the pixels for the world:
At a high resolution (spatial and temporal)
For everywhere we can fly
One drone, balloon, and kite flight at a time
And all to be pushed into common and public dataset, built on open source software commonly shared and developed. Continue reading OpenDroneMap — the future that awaits
I have been reading a bit about drone remote sensing of agriculture fields. On one hand, it’s amazing, world changing technology. On the other hand, some part of all of it is bunk. What do I mean? Well, applying techniques created for continent size analyses may not scale down well. Why? Well for one, all those clever techniques (like Normalized Difference Vegetation Index, as well as its non-normalized siblings) rely heavily on two things: 1– being on average right over a large area; 2 — painting with such a broad brush as to be difficult to confirm or refute. Continue reading Reflections on Goldilocks, Structure from Motion, near scale remote sensing, and the special problems therein
Talking about the future sometimes requires critiquing the present. The wonderful thing about an open source project is we can be quite open about limitations, and discuss ways forward. OpenDroneMap is a really interesting and captivating project… and there’s more work to do. To understand what work needs done, we need to understand OpenDroneMap / structure from motion in general. Some of the limitations endemic … Continue reading OpenDroneMap — Improvements Needed
There are many automated solutions that solve really interesting problems, but at this point in time, it is the semi-automated solutions that really fascinate me. These are solutions that combine the subtlety and intelligence of the human mind with the scale of automation. In this context, I have been thinking a lot about OpenDroneMap — what are the parts of the toolchain which should be … Continue reading Geocoding from Structure from Motion — Integrating MicroMappers and OpenDroneMap
Smathermather's Weblog 