Skip to content

Instantly share code, notes, and snippets.

@wboykinm
Last active April 15, 2024 14:57
Show Gist options
  • Save wboykinm/8a606185e69d470134064ec3210f0de5 to your computer and use it in GitHub Desktop.
Save wboykinm/8a606185e69d470134064ec3210f0de5 to your computer and use it in GitHub Desktop.
Learnings while geoprocessing vector tiles with turf.js

In case anyone is interested, I've been trying to use turf.js on both Mapbox and Mapzen vector tiles, and I've learned a few things I wish I'd known going in.

Background

This thing I've been working on for a month or so here and there, to make maps like this:

main

Purpose

The specific geoprocess I was aiming for was a tile-by-tile turf.erase of OSM-derived water polygons from TIGER-derived census tract polygons, like these:

tract

. . . with the desired result of shore-flush tract polygons

Breadcrumbs

As with most things in life, this proved harder than it looks. Stuff I learned:

  1. When using vector tiles for geoprocessing, that .geojson endpoint is nice and easy. Mapzen has one, Mapbox does not.
  2. Getting GeoJSON out of Mapbox's vector tiles was harder than it looked, but with some super help not impossible - here's a thing that'll do it for you
  3. For both providers, the water layer is not specifically from OSM - it's derived, so not as easy to tinker with the underlying data
  4. Both providers issue some invalid geometries. I encountered self-intersections and side location conflicts
  5. These specific bad geometry types aren't the end of the world. Pretty much any engine (Tangram, Mapbox GL, D3js) will still be able to render them.
  6. These geometry errors do however blow up turf-based geoprocessing. With proper error handling (lots of try/catch) and some looping, the best case scenario is a discarded feature. Worst case scenario is an entire tile where the geoprocess fails. Even the best case isn't awesome.
  7. PostGIS (the place I flee when the big bad JS monsters are after me) also has some trouble with processing these features, but ST_Makevalid() was useful in recovering some of the bad geometries.
  8. However, the old hacks turf.buffer(feature,0,'miles') and ST_Buffer(the_geom,0) both failed to repair any of them.

So I'm leaving off a bit discouraged about this, though there's an open ticket with Mapbox (internal) and another one with Mapzen. Thought I'd leave these notes here in case anyone can commiserate or be warned ahead of time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment