Thoughts 21009

Block Focus

I’m fascinated with the idea of editing OpenStreetMap (OSM) by focusing on one US census block at a time. It’s easy to get lost in the infinite pan of satellite imagery web maps sometimes. But there’s something about framing one’s attention to a small geographic boundary (like a census block) that seems to help focus attention.

A simple example of this idea is the Twitter bot @everytract which posts tiny maps of US census tracts.

When looking at satellite imagery in web maps, we’re used to either inferring boundaries from what’s visible (roadways, treelines, water sources, etc) or being explicitly told what’s what via map labels. But there’s something about cutting out anything outside a boundary of focus that stops you for a second and forces you to consider a particular space.

With this idea in mind, I built a prototype map called Block Focus.

It shows only a single census geometry at a time and encourages you to look at that particular space in an OpenStreetMap editor, either the standard one or Facebook’s RapiD editor. Refreshing the page highlights a different area of focus each time.

Right now, the prototype page is focused on Seattle and only shows census block groups (mostly due to data availability). But I’ve found the effect to be far more pronounced when looking at census blocks, and specifically those outside of urban centers.

Perseverance TRN

I watched the Mars 2020 Perseverance rover landing a few weeks ago, with a similar mix of anticipation, joy and pride that I felt watching the Curiosity landing back in August 2012. If you haven’t had a chance to watch the video of the Perseverance landing, it’s well worth it.

Leading up to the Curiosity landing years ago, I remember pouring through NASA webpages, conference papers and journal articles learning about the engineering wonder of the rover’s Entry, Descent and Landing (EDL) system. That EDL system was by and large reused for Perseverance’s landing with a notable exception: the new Terrain-Relative Navigation (TRN) system.

Perseverance’s landing location at Jezero crater was considered so tricky that NASA needed a new way to avoid hazardous areas (rocks and craters) and identify a safe landing location in real time. Think Neil Armstrong scanning the Moon’s surface while landing the Apollo 13 lunar module, only in a robot.

To do that, they built the TRN which is a combination of a Lander Vision System (LVS) and a pair of onboard digital maps. The LVS takes images of the Martian surface during descent and compares them to the digital maps carried onboard to accurately determine the landers position and select an optimal landing site on-the-fly. The digital maps were created by the USGS and consist of a high resolution 25-cm map and a lower resolution 6-meter map, both of which were created using imagery from the Mars Reconnaissance Orbiter’s HiRISE imager. NASA even tested the system on Earth to make sure it would work, flying a helicopter through Death Valley National Park with a prototype version of TRN installed.

TRN is another evolution in technology (like the Skycrane) that has helped NASA land rovers on Mars with increasing degrees of accuracy, as seen in this comparison of landing ellipses of different rover landings.

Better accuracy in landing means they can land rovers in more complex terrain, and more complex terrain usually means more interesting science to be done.

Planeta

Go has been my programming language of choice lately, but I’ve been somewhat frustrated with its geospatial offerings, at least in comparison to what’s available in JavaScript and Python.

I’d been using the excellent paulmach/orb library, although it doesn’t seem to be under much active development these days and it lacks the ubiqitous bindings to GEOS that opens up a lot of functionality. I’m also a huge fan of the work by tidwall, like the Tile38 and BuntDB libraries. BuntDB is an in-memory key-value store that offers spatial indexing (via R-trees) which I’ve been using to develop a small web service called rtyq.

But these options lack the general purpose utility offered by other libraries, like Python’s Shapely or JavaScript’s Turf.js. I’d been researching the landscape of geospatial tooling in various languages when I stumbled upon news of CockroachDB’s 20.2 release supporting spatial data types.

The geo package they added to their open-source cockroach library to support these data types seems like it has everything geospatial: GEOS bindings, PROJ bindings, both geometric and geographic methods, and even S2 indexing. They even built it all on top of an existing open-source library that implements a variety of geometry types, twpayne/go-geom. Overall, it’s an incredibly impressive package of geospatial functionality in Go.

I’m considering it an experiment at the moment, but I’ve pulled out their geo package into a stand-alone library I’m calling planeta. At the moment, it’s mostly intended to see if Cockroach’s geo package could stand on its own as a general purpose geospatial library for Go.