There are quite a few open source icon libraries out there, but they all have compromises. Some are too detailed and don’t look good at the small sizes required by maps. Some come with license contraints or partial paywalls. Some are too limited in scope or too hard to use. So short of drawing their own, most open source cartographers have to settle with cobbling together free icons from different sources that don’t really go together. Not ideal.

One library, all the icons

In 2026 I started the Pinhead icon library to serve as a centralized, public domain, collaborative repository of map icons. The goal is nothing less than creating the best and biggest set of open source map icons on the web.

I seeded Pinhead with icons from popular public domain icons sources, including Maki, Temaki, NPS, and OpenStreetMap Carto. I gave every icon a descriptive name, conflated duplicates, scaled them to the same size and orientation, and cleaned up their SVGs. Work to improve legiblity and standardize design elements has also been underway. You can browse the coverage page to see how Pinhead compares to other icon sets.

Accessing Pinhead

I aim for Pinhead to be the easiest-to-access icon library. The icons are distributed in two main formats: as SVG files and as a compiled font file. I’ve built a few different distribution methods, each of which is updated upon release, so whenever an icon is added to Pinhead it will appear across the ecosystem automatically.

Web distribution

I built a preview website, pinhead.ink, where users can search and download individual Pinhead icons, copy their SVG codes, or get all the icon files in one download.

All version of all the icon files, metadata files, and font files are hosted at stable endpoints on the web server. This lets users reference remote resources in their apps like <img src="https://pinhead.ink/v21/windmill.svg" width="15px" height="15px"/> or <link href="https://pinhead.ink/v21/pinhead.css" rel="stylesheet"/>.

Wikimedia Commons distribution

All Pinhead icons are synced to Wikimedia Commons, making them compatible to use within Wikipedia, Wikidata, the OpenStreetMap Wiki, and similar projects.

QGIS distribution

Pinhead is bundled by default within the Resource Sharing plugin in QGIS, making it straightforward for GIS pros to use and style Pinhead icons within QGIS projects.

Node distribution

Node developers have their choice of two versioned packages for integrating Pinhead icons into their projects: @waysidemapping/pinhead (for SVG files) and @waysidemapping/pinhead-font (for the webfont).

Streamgages (or stream gauges if you prefer) are devices that measure the surface level of a body of water. Gage height is a simple measurement that tells hydrologists a great deal about the state of a watershed, marking both floods and droughts. It’s also of deep interest to boaters, who know that certain streams can only be navigated at certain water levels.

The U.S. Geological Survey maintains an extensive network of streamgages across the United States. Each has a webpage providing the public with valuable real-time waterway data. However, I found the experience a bit siloed. As part of my canoe and kayak trail project, I realized that if the USGS streamgages were included in OpenStreetMap, then apps could link users to current stream conditions. Time to get mapping!

Engaging the gages

I knew it would be infeasible to map all 10,000+ USGS monitoring stations one-by-one, so a data import was in order. It turns out that there is a lot of churn with gages coming online and offline all the time. So instead of doing a one-time import of data that would instantly become stale, I wrote a series of scripts that compare the latest offical data with OSM and generate OsmChange files with updates. This way we can keep the map fresh going forward.

USGS to OSM import flow

1. Getting source data

The first step in our process is getting the source data. As the product of a federal agency, USGS data is in the public domain and thus license-compatible with OSM. Alas, USGS doesn’t distribute anything like a single GIS file of the gages. Rather, there is an old school API that returns CSV tables of stations actively recording given metrics. Not ideal, but workable.

2. Crosswalking the source data

Next we have to translate, or “crosswalk” the source data into the OpenStreetMap format using standard tags. Regrettably, I find the USGS station names to be poorly formatted for OSM, with many having abbreviations and unexpected capitalization. But after a mix of automated and manual editing, we get objects with tags like this:

man_made=monitoring_station
name=McKenzie River near Vida
official_name=MCKENZIE RIVER NEAR VIDA, OR
ref=14162500
website=https://waterdata.usgs.gov/monitoring-location/14162500
operator=United States Geological Survey
operator:short=USGS
operator:type=government
operator:wikidata=Q193755
ele=260.82
monitoring:water_level=yes
monitoring:flow_rate=yes
monitoring:water_temperature=yes

3. Fetching existing OSM data

It’s a common mistake in OSM to import duplicate features atop existing data. To avoid this, we need to be mindful of whatever gage data lives in OSM already. Luckily, since all USGS stations have unique identifiers, we can simply compare ref tags to avoid creating redundant features.

Before starting this import, I manually went through and added any missing ref and operator tags to USGS stations previously mapped in OSM. This done, we can fetch the latest OSM data with a short Overpass query.

4. Diffing the two datasets

At this stage we have two datasets: the official USGS data with OSM tags, and the downloaded OSM data. Their formats being the same, we can compare them directly and create three types of changes: additions, updates, and deletions. When updating, we don’t want to override everything from OSM, just values where USGS is the source of truth.

5. Uploading to OSM

Our OsmChange files in hand, all we need to do is boot up JOSM, drag in the files, and upload. We can do this in small batches to avoid irking changeset reviewers with massive bounding boxes. For deletions, there are cases when stations haven’t been removed but are temporarily down, so I prefer to review each one manually.

With that, OSM is up-to-date with USGS. We can re-run the scripts anytime we like.

Follow-up work

After completing the initial import, I decided to see how else I could take streamgage mapping even further.

Tagging even more data

USGS monitors a lot more than just water levels, so I expanded the script to support forty-some environmental qualities such as salinity, soil moisture, air pressure, and groundwater discharge. A lot of the sites have webcams, so I added links to those. Most have external identifiers that allow interfacing with providers like NOAA, so I added those through a third-party dataset.

Upgrading USGS geometry

You can do a lot with automated edits, but editing by hand has its own advantages. It turns out that the gage coordinates given by USGS aren’t terribly accurate, erring by as much as a few hundred yards. This may be okay for 1:24,000 scale topo maps, but is wildly substandard for OpenStreetMap.

Since the import, mapper including myself have been improving gage locations in OSM based on aerial imagery, ground-level imagery, and surveys. In effect, this means that OpenStreetMap now has better geometry for USGS monitoring sites than does USGS. Go figure.

Tagging gagehouses

A gagehouse is a special little building that shelters gaging equipment. OpenStreetMap didn’t have a tag specifically for this, so I started using building=gauge_house (the British spelling), drawn as an area around the monitoring station node. I wrote up documentation for this tag so other mappers can discover it.

Visualizing gages

Having already developed the Canoe & Kayak Trails view for OpenTrailMap, it was a natural fit to include streamgages. For the icon, I directly copied the pinwheel that has been used to mark gages on USGS topographic maps for decades. Users can easily view each station’s OSM tags and check its current conditions through external links.

Reflections and future directions

In the end, I imported more than 16,000 USGS features into OSM that monitor surface water, groundwater, weather, soil, and snowpack.

Unusually for OSM imports, I did this without raising red flags from other mappers. The work was highly technical and time-intensive, involving a number of custom scripts and a fair amount of gruntwork. Most people do not have this level of expertise when trying to get their data into OSM. But the result was an accurate, comprehensive merging of data that would have taken over a thousand hours if completed manually.

I published my work as open source in the hope that other people could adapt it to their own use cases. I myself have already adapted it to import NOAA’s tide gagues and Philadelphia’s bikeshare stations. Eventually I’d like to build out a reusable framework and library of third-party datasets to keep in sync with OSM.

Don’t hestitate to reach out if you have questions or need help with your own import.

While I was a full-time maintainer of iD (the default editor at osm.org/edit), I designed over 270 preset icons. Presets are the default feature types such as “Coffeehouse” or “Foot Path” that people can add to OpenStreetMap using iD. Good preset icons keep the app approachable for new mappers while helping power-mappers sift through data. Plus I think bespoke icons make the map look pretty sharp.

My icons live in the Temaki icon library, which is licensed in the public domain and can be used by anyone. My contributions represent more than half of this library.

Some of my favorites

Cultivating a design language

A consistent design language helps users to make inferences and catch distinctions between icons. When possible, I designed related icons as a series to highlight commonalities.

Mountain landforms

Water infrastructure

Railroad tracks

Transit boarding

Gathering inspiration

Temaki is part of a rich history of freely licensed map iconography. Some of my designs didn’t start from scratch, but were inspired by elements from the likes of National Park Service, OSM Carto, Maki, and other Temaki contributors (shoutout to Bryan Housel!)

Combining existing icons

Representing map features

Since iD supports a vast number of feature types, I often ended up using literal representations of objects rather than abstraction or analogy.

For example, the default barrier icon in iD is a plain ⛔︎ no entry symbol. This is highly abstract and doesn’t tell you much about the real-world nature of the barrier. So, I designed a slew of descriptive icons that show each type of barrier as if you’re viewing it at ground level.

Barriers depicted literally

Distinguishing similar features

iD has a lot of similar-sounding presets that trip up new mappers. What’s the difference between an island and an islet? I created unique icons for confusingly similar features to help mappers decide which one is a better match.

Small vs. large

Natural vs. landscaped

Horizontal vs. vertical

Illustrating jargon

Detailed mapping requires a lot of specialized knowledge about what things are and what they’re called. I drew illustrative icons for niche feature types to help new mappers tag them correctly even if they’ve never heard the word “cairn” or “gantry”. These icons are especially helpful for non-English speakers since the preset labels in iD may not be fully translated.

Niche map features

Achieving legibility

The primary design constraint of map icons is legiblilty at small display sizes. The smaller your icons can be, the higher density of information you can convey.

Temaki icons are designed to be displayed at a minimum of 15x15 pixels. To achieve readable icons at this size, I aligned icon elements to a pixel grid and rarely used shapes smaller than one pixel in size.

My icons @ 15px

Browsing the library

In addition to contributing icons, I also built a preview webpage for the Temaki library. Users can filter icons by category and search them by name.

OSM 411 is a website that makes it easy to browse different OSM tools while maintaining context. Basically it’s a big list of links that will all open to the same location. Users can customize the settings and then create a single link to save or share, while developers can configure the page with URL parameters.

I invite you to try it out or learn more on GitHub.

When not at my desk, I spend as much time as I can taking the scenic route to the next spot on the map. How you get somewhere can be just as important as where you’re going, if not more so.

I desired to preserve a piece of the places I passed through, some of them rather fragile to change, so I tried mounting a GoPro to the hood and pressing record. The resulting videos became Wayside Surveys (formerly Wayside Geographic).

Now expanded to train trips, boat trips, and more, the channel is a high-resolution record of special places at specific points in time, documented for the benefit of mappers and future generations alike.

Sample video

This relatively short drive in rural Arizona gives a taste for the channel (my longest video is over six hours.) I recommend pumping the video quality up as high as you can to avoid compression artifacts.

So you could spend months reading the OSM Wiki trying to figure out how to map something—or you could just learn by watching.

With the Wayside Mapping channels on Twitch and YouTube, I provide mapping livestreams and videos intended to demo the intricacies of OpenStreetMap editing. I always felt OSM was a little bit like a video game, so why not stream it like one? Come join the chat and let me know what you want to see mapped 🤙

I’ve been paddling my whole life, but I didn’t think much about canoe and kayak mapping until I stumbled across the Northern Forest Canoe Trail. It opened my eyes to the idea that the world’s waterways form an interconnected paddle network similar to a road or trail network. Naturally I wanted to see how this could be modelled in OpenStreetMap.

Unfortunately, I found the existing OSM tagging to be lacking. While route=canoe relations were in use, as was the canoe=* access tag, there was no consistent, expressive way to tag things like portages, whitewater rapids, open water, unimproved access points, or links between land and water.

Modern tagging for water trails

Over months of mapping the NFCT and similar water trails in the Northeast US, along with some community input, I developed an OSM data model that treats waterways as a routable paddle network. All the details needed for trip planning are represented. To help other mappers understand and use the model, I wrote extensive documentation on the OSM Wiki, including a comprehensive water trail mapping guide.

Some of the waterway tags I created or popularized, and have documented:

• rapids=* – the presence and grade of rapids
• portage=* – access for a person carrying a small boat on foot
• open_water=* – how exposed is a waterway
• oneway:canoe=* – is it possible to paddle upstream
• waterway=flowline – a slow-moving flow through a large body of water
• waterway=access_point – a place where a path meets the water
• waterway=link – a topological connection between an access point and a waterway
• waterway=confluence – a notable junction between two waterways
• route=portage – a route taken to carry boats over land
• waterway:name=* – the name of the waterway contained in a water area
• waterbody:name=* – the name of the water area surrounding a waterway

Visualizing water trails

With the tagging squared away, the next step was to visualize the newly-mapped OSM data.

Coincidentally I had been working on OpenTrailMap for OpenStreetMap US, and was able to add a Canoe & Kayak Trails view with relative ease. The resulting map highlights things like access points, barriers, water locks, and canoeability. Mappers can also focus on specific attributes to expose missing data.

I also added portage=* support to the WaterwayMap canoe view, allowing mappers to account for overland connections when identifying gaps in the paddle network. Thanks to @amandasaurus for maintaining this great tool!

State of the Map US talk

For a quick overview of my paddle tagging schema and its origins, check out my talk from State of the Map US 2024 in Salt Lake City. The information described in the recording is still relevant as of 2025.

“Virginia Is For Lovers”, one of the more famous tourism slogans, can be found on welcome signs all over the state. Ahead of State of the Map US 2023 in Richmond, I adapted the design for the love of mappers, taking special care to place the ❤️ at the approximate location of RVA.

A sticker with this graphic was a freebie for conference attendees.

In 2023 I was lucky enough to lead the logo design for the best party in mapping: State of the Map US. The result, in the words of one RVA local, is “just so Richmond”.

In a departure from most prior State of the Map US logos, the conference team opted for a monochrome design. The intent was to have something versatile that operated well in different contexts and different colors, and would look sleak on a shirt without using as much plastic ink.

Richmond is one of the most-tattooed cities in the US, so we decided to draw inspiration from classic tattoo art with an incised blackletter font. The raven nods to the classic work of onetime Richmond resident Edgar Allen Poe and adds to the gothic feel.

The logo is framed by the iconic A-Line Bridge and its reflection in the James River. Dogwoods, the state flower of Virginia, give a springtime flourish.

And of course our logo wouldn’t be complete without a map element, so we have the outline of Virginia (including the Eastern Shore!) with the capital star over Richmond.

Photo gallery

Photos by Parker Michels-Boyce for OpenStreetMap US.

As part of re-launching the OpenStreetMap US swag store, I created a design referencing the checkbox that OSM mappers see when uploading a changeset in iD or JOSM. Selecting this option adds a review_requested=yes tag to the changeset, hence the name of the product series.

This graphic was intended primarily for baby onesies and toddler shirts, a rarity for tech-themed merchandise. By popular demand, the design was expanded to adult-sized t-shirts and other items.

Nova Scotia is “Canada’s Ocean Playground”, at least according to its license plates. The province has an extensive network of well-signed scenic routes inviting tourists to follow backroads while on their maritime adventures. The routes commemorate Nova Scotia’s history and culture, from the famed Cabot Trail to the Acadian Evangeline Trail and beyond.

After a summer road trip winding my way through the rugged beauty of Nova Scotia’s byways, I tasked myself with getting the province’s scenic routes “on the map”. To me, this meant mapping the routes in OpenStreetMap and then adding their shields to OSM Americana, a road-focused map style.

To my knowledge, this was the first time a state-level scenic route network has been comprehensive supported in an OSM-based map.

Shield icons by Quincy Morgan

Mapping

When I investigated the data, I found that a few of the scenic routes had already been mapped in OpenStreetMap, though without a unified tagging scheme. I cleaned up and standardized these routes, added the remainder, and collected them all with a unique network tag. Now the full slate of routes could be fetched with one simple query.

Shield icons

To represent the routes in Americana, I drew a complete set of highway shield vector icons. These are inspired by their corresponding roadside route signs, but are not exact replicas. Instead, the graphics are simplified and pixel-aligned in order to be legible at the very small sizes required by digital road maps.

As with all Americana icons, these graphics are licensed CC0, meaning you (and anyone!) can freely use them in your own projects.

Display size

Simplified for legibility

Americana support

OpenStreetMap Americana is working to recreate the look and feel of North American paper highways maps using OSM data. Rendering highway shield icons along road routes is central to the cartography.

While numbered routes have extensive coverage in OSM, scenic routes tend to be undermapped. In fact, at the time of this work, Americana could only differentiate routes based on their ref tags, meaning unnumbered routes were not supported. Spurred in part by this Nova Scotia scenic route case, the Americana team built name selection into the shield rendering stack. This feature unlocked support for all kinds of niche, unnumbered road routes.

You can check out the live results over on americanamap.org.

Following up on my Beach Camping logo for Mapping USA 2022 & 2024, I wanted to whip up something new for 2025 that still felt consistent with the graphic history of this virtual conference series. I took a new look at Holly Moore’s delightful surfboard camperbus logo from MUSA 2021 and decided to give it an update.

Since this event would be in January, the laws of nature require we switch from beach bum to ski bum. We’ve traded in our VW bus for an Airstream trailer, our surfboards and ocean teals for snowboards and icy blues. Someone even drew “2025” on the frosty back windshield. Of course we have to register our rig in California, the rare place you can enjoy the beach and the slopes in the same day.

Mapping USA is the annual virtual conference series hosted by OpenStreetMap US. The first event under this name occurred in late spring 2021 and was themed around a surfing road trip. Since the 2022 conference took place in the fall, the OSM US team decided to go with a cozy fall camping theme while still nodding toward the beach.

Components

My logo meshes the natural and human landscape into the folds of a paper map. The consistent angles of the mountains, evergreens, cabin, tent, and campfire all work together to create the illusion of dimensionality while conveying a scene. The dotted line introduces a typical map element and hints at the growing OSM US Trails Stewardship Initiative.

I love a logo that, like a good map, tells a story (or invites the viewer to tell their own.) Is my campsite by a river or a lake? Maybe the coast? How far to visit my friend in the cabin? Could I hike there? What might I find along the way?

Accessory graphics

Mapping USA is all about sharing OpenStreetMap knowledge and connecting with the community. My logo invites people to gather around the digital campfire to teach, learn, and grow.

2024 version

Mapping USA 2024 took place in January. Since the 2022 logo proved popular, I simply updated the colors for a winter landscape. (No conference occurred in 2023.)

Montana is a waterway wonderland, home to thousands of river miles that play host to world-class paddle trips. Much of these flow through private lands, but the state has nonetheless ensured public access though a “best in the west” Stream Access Law.

But the access law only applies to certain waterways, and has two different classifications, each with different restrictions. Some rivers allow overnight camping while others don’t. It’s a bit complicated… maybe OpenStreetMap can help!

I created a tag to encode Montana stream access classes and then tagged every Class I river mile in the state. As a result, data users can easily tell where certain recreational activities are protected when planning their next epic adventure on the water.

This swag design for OpenStreetMap US draws on a timeless question from new mappers and longtime mappers alike: how long must I wait to see the results of my efforts? Thankfully, few mappers have gone to greater lengths to redraw the map than Napoleon.

This boxy, oversize tee fits a modern streetwear aesthetic, suitable for everything from house parties to beach picnics to marching across Europe.