The Mapzen diaspora was active in 2019 with thousands of pull requests. There continues to be a future for the projects incubated at Mapzen and those tools and data continue to be used and updated after our January 2019 transition to the Linux Foundation.

project	2019 closed PRs	stars
Pelias	720	1,799
Valhalla	236	999
Tangram JS/ES	102	1,506/540
Tilezen	143	394
Who’s On First	30	n/a
Who’s On First data	1,554	232

We’ve also been making a few updates to this website like renaming “products” to “projects” to reflect our new status with the Linux Foundation. Also, come by and say hi on Twitter!

Project updates since January 2018:

Map display

Tangram JS

Tangram JS has added several new capabilities over the past two years, along with a new build system to output native ES6 JavaScript modules (since v0.16), syntax refinements to avoid boilerplate code, and performance and memory usage improvements for labels and other areas.

New data source parameters for controlling level-of-detail support cases where tiles may be either too large (in file size) or too detailed (in feature density or coordinate precision) than desirable for the current application, such as generalizing raster data or optimizing for low network bandwidth. The zoom_offset parameter (v0.17) down-samples tile data by one or more zoom levels, while the zooms array (v0.18) provides fine-grained control over which zoom levels will load new tiles.

For example, we can use zoom_offset: 1 to opt for softer and more performant terrain tiles:

Geo-referenced (un-tiled) raster image layers were added in v0.17, useful for ad hoc overlays such as historical images or local aerial imagery; the scene author can apply alpha processing or composite multiple images into a single layer. Together these features extend Tangram’s unique flexibility for real-time raster processing, with the ability to mask, filter, and analyze multiple raster and vector layers simultaneously with custom GLSL shader code.

Agricultural drone imagery filtered by raster-derived values in a Tangram shader:

Or use a slide tool to compare contemporary topographical data (shown here from Nextzen terrain tiles) with contour lines from a USGS historical map:

Significant label improvements arrived in v0.15, with labels now properly colliding across multiple data sources and tile boundaries – enabling more seamless data overlays interleaved with Mapzen basemaps. Label collision is also now re-evaluated in between zoom levels, for increased label density.

Filtering and styling syntax also gained new capabilities with native support for complex JSON objects (v0.19), whether included in GeoJSON properties, or embedded as stringified JSON in MVT as output by Mapbox’s Tippecanoe tiling library. These objects can now be automatically parsed from MVT data sources, accessed in layers with common JS-style “dot notation” syntax, and filtered with new array-to-array set operations (includes_all and includes_any). Tangram’s hierarchical layer structure is powerful, but managing parallel filter sub-trees can be complex; we’ve added new priority and exclusive keywords (v0.18) for more control over the layer matching logic, useful for disambiguating competing sub-layers or short-circuiting filter paths.

Finally, several syntax extensions focus on removing repetitive boilerplate code in scene files. Most notably, the blend_order parameter can now be set within draw groups (v0.18), greatly simplifying complex stacks of label and sprite symbol layers. v0.19 brought built-in rendering styles for all combinations of blend and base, removing another common pain point with blend modes. And the new all_layers data source parameter composites an entire vector source into one scene layer, useful for creating wireframe views or loading MVT tiles with variable or unknown layer names.

Tangram ES

Tangram ES has steadily stabilized and improved its own capabilities with a host of changes over the past two years, all bundled up into our latest release: Tangram ES 0.11.

This release includes an essential change for Android users. Following the guidelines for Google Play, the Tangram Android SDK now includes 64-bit binaries for both the ARM and x86 architectures. If you have an app on Google Play that uses Tangram, you should upgrade to this release!

zoom_offset for data sources, as described in Tangram JS above, is now supported in Tangram ES as well.

Android apps can now render a Tangram map into a TextureView. This lets you embed maps into more complex View hierarchies or apply bitmap effects that aren’t possible with a SurfaceView.

A new JavaScript engine abstraction adds the ability to compile Tangram ES with JSCore, the native JS engine on iOS and macOS, reducing the size of your compiled binary.

Both the iOS and Android Tangram SDKs have a new, much faster interface for adding custom data layers. The scene below used to take 4.5 seconds to load on a phone - now it takes 22 milliseconds!

These are just a few of the changes in Tangram ES since becoming part of the Linux Foundation. We’ve also made loads of bug fixes, performance enhancements, and developer workflow improvements. Head on over to our repository to see all the activity!

Search

The Pelias geocoder has seen many improvements in the last two years. Active development has been continued by the growing Pelias community and by Geocode Earth, who offers a hosted geocoding API and consulting for custom geocoding installation.

Notable developments since joining the Linux Foundation include:

• A major focus on customization including support for importing custom data via CSV, customization of “boost” levels to fine tune results, and display of additional data through the “addendum” feature
• Improved autocomplete through the new Pelias Parser
• Massively improved query performance through multiple optimizations to Elasticsearch queries, use of the libpostal service, and more
• An easy to use Docker framework for quickly getting started with Pelias
• Improved deduplication logic to avoid presenting identical looking (and confusing!) results
• New query parameters such as boundary.gid for filtering by parent administrative area
• Support for importing OpenStreetMap relation records
• A new Transit importer supporting GTFS and other common formats
• Support for Elasticsearch 5, Elasticsearch 6, and soon Elasticsearch 7

Routing

The main themes in the Valhalla project have been centered around maturity and efficiency. The code is easier to build on platforms like Windows, Android and iOS. We’ve added some new features like 2 new costing modes and are working towards a multimodal bike-share routing. V3.0 of the Valhalla tile spec was released about a year ago and allowed us to make some gains in tile sizes where we know the use-case the tiles would be targeted at. The bulk of the rest of the contributions have been largely around maturity of the product adding new features for properly selecting origin and destination edges in the graph or allowing/disallowing routes based on time of day or access restrictions (ie accuracy of the routing). We’ve also generally improved the performance and usability in scenarios where you are disk limited (server-less or mobile).

• Windows build support
• Motorcycle costing
• Experimental nodejs bindings
• Supported for predicted traffic influenced routing
• Reduced boost dependencies to header only for easier crossplatform development
• Time dependent isochrones (isochrones differ depending on predicted traffic)
• Valhalla V3.0
  • Smaller tiles especially when omitting elevation sources
  • Improved performance (~100ms cross country US routing)
  • Support for filtering out parts of the graph based on mode of travel (remove bike-only edges or remove pedestrian-only edges for example)
• Support for polyline5 and geojson geometry output
• Taxi costing
• Preferred side of street (and tolerance) for arrival and departure locations
• Max search radius for locations
• Via and break through location types allowing for u-turns with no separate leg and continuing in the same direction with a separate leg respectively
• Internal API now tracks turn lane information at the nodes along the route
• Improve reachability checks to search in both directions
• Caching improvements for on-the-fly tile fetching (serverless mode)
• Allow time-independent routes to ignore timed restrictions
• Allow u-turns where no other option is possible
• Bike-share multimodal coming very soon!

Vector Tiles

Long term support for free hosted access to vector and terrain Tilezen tiles continue to be supported by generous AWS Research Grants thru April 2020, and global builds sponsored by HERE on Nextzen. Please email if you’re interested in sponsoring a build or access to tiles!

• v1.5 added an inexpensive global tile build, international road shields (img), and many more kinds of points of interest.
• v1.6 significantly reduced file sizes between 23% (p50) and 30% (p90) globally by additional geometry simplification, dropping features, dropping properties, and more aggressive merging to multi-lines and multi-polygons in low- and mid-zooms.
• v1.7 added more green areas, prototyped point-of-view for disputed boundaries, and added collision_rank for more predictable label collisions, and population_rank for sizing place labels, and modeling support for showing traffic flow lines and traffic incidents.
• v1.8 support ~30 points of view for disputed boundaries, country, region, and capitals for high-zooms from OpenStreetMap and low-zooms from Natural Earth, added wikidata_id concordances. The version hosted on Nextzen since July 2019.
• v1.9 (under development) focused on adding more landuse green areas at low- and mid-zooms, contours, and outdoor feature enhancements

(above) Chart shows sizes in bytes (logarithmic scale), based on top 100,000 tiles from openstreetmap.org logs at 512 pixel zoom.

We will continue to host indefinitely the raw metatiles assets in an S3 requester pays bucket. You can now run your own tile server via tapalcatl-py: it’s cheap for low usage and easy to configure as an on-demand Lambda + API Gateway with Zappa. This is the same software and configuration that powers the existing endpoint, but billed to your own AWS account. Setup instructions are in the project README and most users should expect to see AWS bills less than $5 / month.

If you’re running a larger commercial service you’d also want to add CloudFront edge cache and look at running tapalcatl-py via Docker in EKS.

Terrain Tiles

Tilezen terrain tiles are available via Nextzen with an API key, and are still accessible in 256 sized tiles via the existing Amazon public dataset S3 endpoints.

The 512 and buffered 260 and 516 sized terrain tiles on Nextzen are made possible by running Zaloa as a Lambda function.

We did additional work extending Marble Cutter to tile indexed landcover sources into tiles, and prototyped a vector export.

Who’s On First

• On the data side, Who’s On First gained comprehensive worldwide locality coverage by adding over 4 million new locality points from GeoNames. Projects like Pelias can now import Who’s On First alone without having to worry about deduplicating results between the two datasets.
• Added 11.7 million more name translations to 972k places, thanks Wikidata.
• Posting monthly changelogs (1, 2) at whosonfirst.org/blog
• Legal audit of WOF datasources terms and conditions, we’re enterprise ready.
• Expanded and validated Disputed area coverage, including guidance on label hierarchy display
• Split the mono repo into per country repos for the administrative data at the request of Github.
• Alternate geometries are more explicit, easier to index, and include in distributions.
• All features now include mz:min_zoom and point geometries include label bbox
• Easier to work with the data in databases, documenting fields, removing nested : strings in property names, simplify default geometries, resolve geometry self intersections
• Label shortcodes and abbreviations for country and regions
• Capital cities declared with new data properties
• Per country rebuilds, including: Norway, Poland, France, Switzerland, Denmark, Germany, India, Ireland, United Kingdom, Sweden, Finland, Belgium, Australia, Austria, Saudi Arabia, United Arab Emirates, Canada, United States (townships for localadmin, reset geometry of oversized mostly rural neighbourhoods), and Netherlands
• Other small fixes from customer feedback

Pre-GeoNames import locality coverage visualized:

Post-GeoNames import locality coverage visualized:

Transitland

Transitland started in 2014 as a data platform aggregating transit data in the San Francisco and New York metro regions. Today Transitland makes available stop locations, route lines, schedules, and other data from 2,626 transit operators in 59 countries. There’s an API and a range of different user interfaces.

Transitland is managed by Interline Technologies, a mobility and transportation technology firm founded by Mapzen alums. Interline provides custom Transitland integrations and consulting to transit agencies and private mobility providers (think e-scooters and ride-hail cars). Here’s one example of how we’re using Transitland open-source components to support the 30+ transit agencies in the San Francisco Bay Area.

Thanks to generous support from Amazon Web Services, Transitland’s APIs have been free to other startups, advocacy groups, and transit enthusiasts. Learn more about Transitland’s general governance and growth.

Thanks to a grant from the United States’ Transportation Research Board, Interline is currently expanding Transitland to support real-time transit data.

And finally, we’re ending 2019 with major technical changes: Transitland Version 2.0. The new version is faster (to handle an entire country’s worth of transit data in one import!) and distributed (to allow Interline’s client, other organizations, and enthusiasts to run their own deployments of Transitland tooling.

Metro Extracts

Daily OSM extracts are available from Interline, making it easy to get started with Valhalla, Pelias, or Tilezen with a small local area instead of the entire, very large OpenStreetMap planet file. Interline OSM Extracts are powered by the open-source PlanetUtils package, which wraps up a variety of OSM processing toolchains.

header image: Calendar, June; Japan; 1985-44-1-7, Cooper Hewitt, Smithsonian Design Museum