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.
This thing I've been working on for a month or so here and there, to make maps like this:
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:
. . . with the desired result of shore-flush tract polygons
As with most things in life, this proved harder than it looks. Stuff I learned:
- When using vector tiles for geoprocessing, that
.geojsonendpoint is nice and easy. Mapzen has one, Mapbox does not. - 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
- For both providers, the
waterlayer is not specifically from OSM - it's derived, so not as easy to tinker with the underlying data - Both providers issue some invalid geometries. I encountered self-intersections and side location conflicts
- 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.
- 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.
- 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. - However, the old hacks
turf.buffer(feature,0,'miles')andST_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.