[{"data":1,"prerenderedAt":197},["ShallowReactive",2],{"blog-\u002Fblog\u002Ffixing-missing-water-interactive-basemaps\u002F":3,"related-blog-\u002Fblog\u002Ffixing-missing-water-interactive-basemaps\u002F":161},{"id":4,"title":5,"abstract":6,"author":7,"body":15,"description":143,"excerpt":6,"extension":144,"head":6,"image":145,"imageAlt":146,"keywords":147,"meta":152,"modified":6,"navigation":153,"path":154,"proficiencyLevel":6,"published":155,"rawbody":156,"schemaOrg":6,"schemaType":6,"section":148,"seo":157,"stem":159,"__hash__":160},"blog\u002Fblog\u002Ffixing-missing-water-interactive-basemaps.md","How We Fixed Water Feature Rendering Across All Zoom Levels in Our Basemaps",null,{"name":8,"slug":9,"jobTitle":10,"bio":11,"twitterCreator":12,"sameAs":13},"Ian Wagner","ian-wagner","Founder & President \u002F COO","Ian is co-founder of Stadia Maps and leads engineering and operations. He works on routing, navigation, and the technical foundations that keep customer applications reliable at scale.","@ianthetechie",[14],"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fian-w-wagner\u002F",{"type":16,"value":17,"toc":135},"minimark",[18,22,43,46,51,54,62,67,71,78,81,84,91,95,98,127],[19,20,5],"h1",{"id":21},"how-we-fixed-water-feature-rendering-across-all-zoom-levels-in-our-basemaps",[23,24,25],"blockquote",{},[26,27,28,29,34,35,42],"p",{},"We just shipped a significant update to the data pipeline behind our ",[30,31,33],"a",{"href":32},"\u002Fproducts\u002Fmaps\u002Finteractive-basemaps\u002F","Interactive Basemaps",". The change fixes a class of visual inconsistencies at low- and mid-zoom levels, such as missing rivers, shifting coastlines, islands that suddenly appear, and major water features that pop into detail abruptly rather than transitioning smoothly. The root cause was mixing two different data sources at different zoom levels. The fix is a unified OSM-derived dataset across all zoom levels, sourced from ",[30,36,41],{"href":37,"rel":38,"target":40},"https:\u002F\u002Foverturemaps.org\u002F",[39],"external","_blank","Overture Maps",".",[26,44,45],{},"Here's what was happening and what we changed.",[47,48,50],"h2",{"id":49},"why-water-features-were-disappearing-at-mid-zoom-levels","Why Water Features Were Disappearing at Mid-Zoom Levels",[26,52,53],{},"Our basemaps were pulling from two different datasets, depending on the zoom level. At lower zooms, we used Natural Earth, a well-known dataset that efficiently represents the most important details for broad-scale cartography. At higher zooms, we switched to OSM-derived data. These two datasets don't agree on everything: coastlines have vastly different levels of detail and features that exist in one don't always have equivalents in the other at the same zoom thresholds.",[26,55,56,57,61],{},"The handoff point between them was the source of most of the visual inconsistencies. A customer noticed a clear example: The St. Lawrence River disappeared entirely between zooms 6 and 8. OSM represents it as a ",[58,59,60],"code",{},"water"," polygon, while the way we processed Natural Earth's simplified data at those zoom levels didn't carry the equivalent coverage. The result is a river-shaped hole filled with land. But that was one symptom of a broader pattern. Coastlines were shifting shape mid-zoom, small islands were appearing or vanishing, and water features were popping in suddenly rather than transitioning smoothly.",[63,64],"content-twenty-twenty",{"afterSrc":65,"beforeSrc":66},"\u002Fassets\u002Ficeland-new.png","\u002Fassets\u002Ficeland-old.png",[47,68,70],{"id":69},"what-changed-a-single-data-source-across-all-zoom-levels","What Changed: A Single Data Source Across All Zoom Levels",[26,72,73,74,77],{},"We've unified our basemaps around a single OSM-derived dataset across all zoom levels. Specifically, we're using releases from ",[30,75,41],{"href":37,"rel":76,"target":40},[39],", which apply additional QA on top of OSM to ensure major water bodies are complete and consistent, something we had occasionally struggled with when building directly from raw OSM data.",[26,79,80],{},"Using the same source throughout eliminates the cross-dataset seam. No more coastline jumps. No more islands appearing from nowhere. No more rivers losing their shape at mid-zoom. It also means features that were simply absent at lower zoom levels. Rivers, estuaries, and reservoirs are now present and correct from the moment they're geographically relevant, rather than popping in abruptly as you zoom past the old data handoff point.",[26,82,83],{},"We also updated our geometry simplification algorithm and parameters. The new approach carries more detail through mid-zoom levels and produces smoother transitions as you zoom in and out with less of the sudden snap from one level of detail to the next.",[26,85,86,87,42],{},"The St. Lawrence is back where it belongs: ",[30,88,90],{"href":89},"\u002Fexplore-the-map\u002F#map=8.86\u002F44.5347\u002F-75.4982","see it here",[47,92,94],{"id":93},"what-this-means-for-your-application","What This Means for Your Application",[26,96,97],{},"If your application renders maps at mid-zoom levels, your users are now seeing more accurate, more consistent water rendering. Specifically:",[99,100,101,109,115,121],"ul",{},[102,103,104,108],"li",{},[105,106,107],"strong",{},"Rivers, estuaries, and reservoirs"," now appear at the zoom levels where they're geographically relevant",[102,110,111,114],{},[105,112,113],{},"Coastlines"," have smoother transitions, with more detail present at low and mid zoom levels",[102,116,117,120],{},[105,118,119],{},"Islands and water bodies"," render consistently from zoom to zoom",[102,122,123,126],{},[105,124,125],{},"Transitions between zoom levels"," are smoother across all water features",[26,128,129,130,134],{},"These are the kinds of artifacts that are easy to miss in development and easy to notice in production. If you ever spot anything on the map that still looks off, let us know at ",[30,131,133],{"href":132},"mailto:support@stadiamaps.com","support@stadiamaps.com",". Reports like these are how this fix started.",{"title":136,"searchDepth":137,"depth":137,"links":138},"",4,[139,141,142],{"id":49,"depth":140,"text":50},2,{"id":69,"depth":140,"text":70},{"id":93,"depth":140,"text":94},"Mixing Natural Earth and OSM data at different zoom levels caused rivers to vanish, coastlines to shift, and islands to flicker. Here's how we unified our basemaps around a single Overture Maps dataset to fix it.","md","\u002Fimages\u002Fog\u002Fwater-basemap-og.png","How We Fixed Water Feature Rendering Across All Zoom Levels in Our Basemaps — Stadia Maps",[148,33,149,41,150,151],"Maps","OpenStreetMap","Cartography","Vector Tiles",{},true,"\u002Fblog\u002Ffixing-missing-water-interactive-basemaps","2026-06-04","---\ndescription: >-\n  Mixing Natural Earth and OSM data at different zoom levels caused rivers to\n  vanish, coastlines to shift, and islands to flicker. Here's how we unified our\n  basemaps around a single Overture Maps dataset to fix it.\nexcerpt: >-\n  Mixing two datasets made rivers vanish and coastlines shift at mid-zoom.\n  Here's how a single Overture Maps dataset fixed water rendering across all\n  zoom levels.\nseo:\n  title: \"How We Fixed Water Feature Rendering on Our Basemaps\"\n  ogTitle: \"How We Fixed Water Feature Rendering Across All Zoom Levels in Our Basemaps\"\npublished: \"2026-06-04\"\nimage: \u002Fimages\u002Fog\u002Fwater-basemap-og.png\nimageAlt: \"How We Fixed Water Feature Rendering Across All Zoom Levels in Our Basemaps — Stadia Maps\"\nsection: \"Maps\"\nkeywords:\n  - Maps\n  - Interactive Basemaps\n  - OpenStreetMap\n  - Overture Maps\n  - Cartography\n  - Vector Tiles\nauthor:\n  name: \"Ian Wagner\"\n  slug: \"ian-wagner\"\n  jobTitle: \"Founder & President \u002F COO\"\n  bio: \"Ian is co-founder of Stadia Maps and leads engineering and operations. He works on routing, navigation, and the technical foundations that keep customer applications reliable at scale.\"\n  twitterCreator: \"@ianthetechie\"\n  sameAs:\n    - \"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fian-w-wagner\u002F\"\n---\n\n# How We Fixed Water Feature Rendering Across All Zoom Levels in Our Basemaps\n\n> We just shipped a significant update to the data pipeline behind our [Interactive Basemaps](\u002Fproducts\u002Fmaps\u002Finteractive-basemaps\u002F). The change fixes a class of visual inconsistencies at low- and mid-zoom levels, such as missing rivers, shifting coastlines, islands that suddenly appear, and major water features that pop into detail abruptly rather than transitioning smoothly. The root cause was mixing two different data sources at different zoom levels. The fix is a unified OSM-derived dataset across all zoom levels, sourced from [Overture Maps](https:\u002F\u002Foverturemaps.org\u002F).\n\nHere's what was happening and what we changed.\n\n## Why Water Features Were Disappearing at Mid-Zoom Levels\n\nOur basemaps were pulling from two different datasets, depending on the zoom level. At lower zooms, we used Natural Earth, a well-known dataset that efficiently represents the most important details for broad-scale cartography. At higher zooms, we switched to OSM-derived data. These two datasets don't agree on everything: coastlines have vastly different levels of detail and features that exist in one don't always have equivalents in the other at the same zoom thresholds.\n\nThe handoff point between them was the source of most of the visual inconsistencies. A customer noticed a clear example: The St. Lawrence River disappeared entirely between zooms 6 and 8. OSM represents it as a `water` polygon, while the way we processed Natural Earth's simplified data at those zoom levels didn't carry the equivalent coverage. The result is a river-shaped hole filled with land. But that was one symptom of a broader pattern. Coastlines were shifting shape mid-zoom, small islands were appearing or vanishing, and water features were popping in suddenly rather than transitioning smoothly.\n\n::content-twenty-twenty\n---\nafterSrc: \"\u002Fassets\u002Ficeland-new.png\"\nbeforeSrc: \"\u002Fassets\u002Ficeland-old.png\"\n---\n::\n\n## What Changed: A Single Data Source Across All Zoom Levels\n\nWe've unified our basemaps around a single OSM-derived dataset across all zoom levels. Specifically, we're using releases from [Overture Maps](https:\u002F\u002Foverturemaps.org\u002F), which apply additional QA on top of OSM to ensure major water bodies are complete and consistent, something we had occasionally struggled with when building directly from raw OSM data.\n\nUsing the same source throughout eliminates the cross-dataset seam. No more coastline jumps. No more islands appearing from nowhere. No more rivers losing their shape at mid-zoom. It also means features that were simply absent at lower zoom levels. Rivers, estuaries, and reservoirs are now present and correct from the moment they're geographically relevant, rather than popping in abruptly as you zoom past the old data handoff point.\n\nWe also updated our geometry simplification algorithm and parameters. The new approach carries more detail through mid-zoom levels and produces smoother transitions as you zoom in and out with less of the sudden snap from one level of detail to the next.\n\nThe St. Lawrence is back where it belongs: [see it here](\u002Fexplore-the-map\u002F#map=8.86\u002F44.5347\u002F-75.4982).\n\n## What This Means for Your Application\n\nIf your application renders maps at mid-zoom levels, your users are now seeing more accurate, more consistent water rendering. Specifically:\n\n- **Rivers, estuaries, and reservoirs** now appear at the zoom levels where they're geographically relevant\n- **Coastlines** have smoother transitions, with more detail present at low and mid zoom levels\n- **Islands and water bodies** render consistently from zoom to zoom\n- **Transitions between zoom levels** are smoother across all water features\n\nThese are the kinds of artifacts that are easy to miss in development and easy to notice in production. If you ever spot anything on the map that still looks off, let us know at [support@stadiamaps.com](mailto:support@stadiamaps.com). Reports like these are how this fix started.\n",{"title":158,"ogTitle":5,"description":143},"How We Fixed Water Feature Rendering on Our Basemaps","blog\u002Ffixing-missing-water-interactive-basemaps","hk8SC0ro149jGalZqFUHjk8Saxpqvy5drzw0vWAYWx0",[162,175,186],{"title":163,"description":164,"path":165,"published":166,"keywords":167,"rawbody":174},"Beyond the Car: Routing for the Other 90% of Transport","Car-first routing APIs fail trucks, e-bikes, and LSVs. See how Stadia Maps uses Valhalla and OpenStreetMap to deliver modal-specific routing that respects each vehicle's physical and legal constraints.","\u002Fblog\u002Fbeyond-the-car-routing-for-specialized-fleets","2026-05-26",[168,169,170,149,171,172,173],"Routing","Navigation","Valhalla","Fleet Routing","Micromobility","Low-Speed Vehicles","---\ndescription: >-\n  Car-first routing APIs fail trucks, e-bikes, and LSVs. See how Stadia Maps\n  uses Valhalla and OpenStreetMap to deliver modal-specific routing that\n  respects each vehicle's physical and legal constraints.\npublished: \"2026-05-26\"\nimage: \u002Fimages\u002Fog\u002Fspecialized-routing-og.png\nimageAlt: \"Beyond the Car: Routing for the Other 90% of Transport — Stadia Maps\"\nsection: \"Routing\"\nkeywords:\n  - Routing\n  - Navigation\n  - Valhalla\n  - OpenStreetMap\n  - Fleet Routing\n  - Micromobility\n  - Low-Speed Vehicles\nauthor:\n  name: \"Ian Wagner\"\n  slug: \"ian-wagner\"\n  jobTitle: \"Founder & President \u002F COO\"\n  bio: \"Ian is co-founder of Stadia Maps and leads engineering and operations. He works on routing, navigation, and the technical foundations that keep customer applications reliable at scale.\"\n  twitterCreator: \"@ianthetechie\"\n  sameAs:\n    - \"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fian-w-wagner\u002F\"\n---\n\n# Beyond the Car: Routing for the Other 90% of Transport\n\n> Standard \"car-first\" routing APIs often fail to account for the unique legal and physical constraints of specialized fleets. Stadia Maps bridges this gap by leveraging the Valhalla routing engine and OpenStreetMap data to provide granular, modal-specific routing for everything from 10-ton trucks and e-bikes to low-speed vehicles (LSVs).\n\n## The Problem\n\nStandard consumer mapping apps are excellent at getting a passenger car from point A to point B, but the \"car-first\" default is a significant limitation for professional use cases. The moment a business needs to route a 10-ton truck, a delivery e-bike, or a neighborhood electric vehicle, most [Directions APIs](\u002Fblog\u002Fwhy-osm-routing-needs-real-time-traffic\u002F) fall apart. Such platforms often lack the flexibility required for specialized fleets and fail to account for the unique legal and physical constraints these vehicles face.\n\n## The Logic Gap\n\nGeneric routing engines often treat a 10-ton semi-truck the same as an e-bike, leading to dangerous route suggestions or illegal maneuvers. Developers shouldn't have to build custom logic layers just to ensure a vehicle stays on a legal road.\n\nStadia Maps solves this by processing [OpenStreetMap (OSM) data](https:\u002F\u002Fwiki.openstreetmap.org\u002Fwiki\u002FRouting_profiles) into a specialized routing graph. Our engine extracts both implicit and explicit vehicle access rules, bridging the gap between raw map data and safe navigation.\n\nBy providing tailored routing profiles for diverse vehicle archetypes, we ensure that every calculation respects the physical and legal constraints of each asset. We leverage the open-source [Valhalla routing engine](https:\u002F\u002Fvalhalla.github.io\u002Fvalhalla\u002F), which allows you to customize desirability factors when you make an API request.\n\nSpecialized profiles for the 10-ton truck and the e-bike enable logistics platforms to automate fleet dispatch and [micromobility](https:\u002F\u002Fwww.mckinsey.com\u002Ffeatured-insights\u002Fmckinsey-explainers\u002Fwhat-is-micromobility) startups to provide riders with reliable, safe navigation.\n\n## The Stadia Maps Difference\n\n[Dynamic costing](https:\u002F\u002Fdocs.stadiamaps.com\u002Frouting\u002Fstandard-routing\u002F) gives you control over dozens of parameters on the fly, ensuring fleets navigate complex environments efficiently. Key capabilities include:\n\n- **Vehicle Subtypes:** Distinguish between mountain bikes and road bikes, or golf carts and other Low-Speed Vehicles (LSVs).\n- **Physical Preferences:** Configure the engine to avoid hills for scooters, disallow U-turns for long trucks, or avoid toll roads entirely.\n- **Precision Waypoints:** Specify that a waypoint must be visited from a particular side of the road, a critical feature for curb-side delivery and waste management.\n- **Direct Map Edits:** Map errors shouldn't take months to fix. Make your own edits directly. Updates can be live in our [routing engine](https:\u002F\u002Fdocs.stadiamaps.com\u002Frouting\u002Fvalhalla\u002F) within days.\n\n## Specialized Mobility Solutions\n\nFlexibility enables business models that standard providers simply cannot support. A prime example is our work with municipalities such as [Peachtree City, GA](https:\u002F\u002Fpeachtree-city.org\u002F216\u002FPaths-Golf-Carts), and [The Villages, FL](https:\u002F\u002Fwww.districtgov.org\u002Frecreation\u002Ftrails.aspx).\n\nThese communities have extensive, legally regulated networks for golf carts and LSVs. Stadia Maps provided the only routing profile customizable enough to fit their local ordinances, such as prohibiting LSVs on roads with speed limits over 35 mph.\n\nWe support almost a dozen routing profiles out of the box, including bus, motorcycle, and pedestrian, with [matrix routing limits](https:\u002F\u002Fdocs.stadiamaps.com\u002Frouting\u002Ftime-distance-matrix\u002F) that are often orders of magnitude higher than those of our competitors. Whether you are optimizing a transit authority's bus training or dispatching a fleet of e-bikes, your routing engine should adapt to your vehicle, not the other way around.\n\n---\n\n[Create a free account](https:\u002F\u002Fclient.stadiamaps.com\u002Fsignup\u002F) to explore our specialized routing profiles, or [contact our team](mailto:support@stadiamaps.com) to discuss a custom solution tailored to your unique vehicle constraints.\n",{"title":176,"description":177,"path":178,"published":179,"keywords":180,"rawbody":185},"Why Basic OpenStreetMap Routing Needs Real-Time Traffic","OpenStreetMap is a world-class road network, but without real-time traffic it's a static dataset. Here's why algorithmic ETAs fall apart in production logistics and how Stadia Maps closes the gap with TomTom-powered routing.","\u002Fblog\u002Fwhy-osm-routing-needs-real-time-traffic","2026-05-12",[168,169,149,181,182,183,184],"Traffic Data","Matrix Routing","Logistics","TomTom","---\ndescription: >-\n  OpenStreetMap is a world-class road network, but without real-time traffic\n  it's a static dataset. Here's why algorithmic ETAs fall apart in production\n  logistics and how Stadia Maps closes the gap with TomTom-powered routing.\nexcerpt: >-\n  OpenStreetMap is great geography, but without real-time traffic it falls\n  short on ETAs. Stadia Maps closes the gap with TomTom-powered routing.\npublished: \"2026-05-12\"\nmodified: \"2026-05-27\"\nimage: \u002Fimages\u002Fog\u002Fosm-traffic-og.png\nsection: \"Routing\"\nkeywords:\n  - Routing\n  - Navigation\n  - OpenStreetMap\n  - Traffic Data\n  - Matrix Routing\n  - Logistics\n  - TomTom\nauthor:\n  name: \"Ian Wagner\"\n  slug: \"ian-wagner\"\n  jobTitle: \"Founder & President \u002F COO\"\n  bio: \"Ian is co-founder of Stadia Maps and leads engineering and operations. He works on routing, navigation, and the technical foundations that keep customer applications reliable at scale.\"\n  twitterCreator: \"@ianthetechie\"\n  sameAs:\n    - \"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fian-w-wagner\u002F\"\n---\n\n# Why Basic OpenStreetMap Routing Needs Real-Time Traffic\n\n> OpenStreetMap (OSM) provides a world-class geographic foundation, but it remains a static dataset. Without real-time traffic integration, routing engines must rely on algorithmic proxies—like road class and legal speed limits—which often lead to unreliable ETAs and logistics bottlenecks.\n\n## The Problem\n\n[OpenStreetMap (OSM)](https:\u002F\u002Fwww.openstreetmap.org\u002Fabout) is one of the world's leading road maps, but a persistent gap remains between fixed geographic data and a [live navigation experience](\u002Fproducts\u002Frouting-navigation\u002F). Without dedicated traffic data, Estimated Times of Arrival (ETAs) are essentially educated guesses. While OSM is excellent at mapping the world's road network, a static dataset cannot capture the actual driving conditions at this exact moment. In [enterprise-grade logistics](\u002Fblog\u002Fbeyond-the-car-routing-for-specialized-fleets\u002F), the lack of live data is often the first significant technical hurdle.\n\n## The Limits of Algorithmic Guesswork\n\nIn the absence of real-time data, a routing engine must estimate travel speeds based on tags and a few common proxies:\n\n- **Road Class:** Assuming a motorway is always faster than a residential street.\n- **Tagged Speed Limits:** Using the legal maximum as the baseline (when the tag even exists).\n- **Network Density:** Adjusting for urban vs. rural environments.\n- **Time of Day:** Using low-granularity buckets like \"daytime\" and \"nighttime.\"\n\nReal-world data show wild variances compared to these static estimates. Road class is a blunt instrument for predicting speed. Missing speed limit tags in open datasets force routing engines to rely on broad averages, resulting in unreliable ETAs and logistics delays. Rule-based algorithms are also notoriously bad at predicting choke points because open datasets don't account for traffic light timings, congestion near specific exits, or the \"invisible\" friction of a busy intersection.\n\n## The Stadia Maps Difference\n\nTo move from guesswork to precision, we integrated [TomTom's global traffic data](https:\u002F\u002Fwww.tomtom.com\u002Fproducts\u002Ftraffic-apis\u002F) directly into the [Stadia Maps routing engine](https:\u002F\u002Fdocs.stadiamaps.com\u002Frouting\u002F). High-resolution historical profiles and live feeds allow for accurate, real-time routing. We provide this through three key technical pillars:\n\n1. **Global Coverage:** Access to consistent data across more countries than almost any other vendor.\n2. **Rapid Updates:** A traffic latency of approximately two minutes allows our API to suggest alternate routes almost as soon as a wreck occurs.\n3. **Historical Profiles:** Deep granularity forms the backbone of predictive routing. High-resolution historical data enables accurate, time-dependent routing in advance, allowing you to plan a route for Tuesday at 8:00 AM based on what might happen on Tuesdays at 8:00 AM.\n\n## Fleet Intelligence at Scale\n\nFor dispatch, optimization, and fleet operations, [matrix routing](https:\u002F\u002Fdocs.stadiamaps.com\u002Frouting\u002Ftime-distance-matrix\u002F) (calculating the time and distance between many origins and destinations) is the engine's most critical function.\n\nThe Stadia Maps infrastructure supports matrix requests that are significantly larger than most competitors allow on standard plans. By integrating traffic data directly into these large-scale requests, we eliminate the need for developers to split requests into smaller chunks, reducing unnecessary complexity and latency.\n\nDevelopers maintain full agency over their implementation. We provide the fastest route based on live conditions, but the frequency of re-routing remains entirely in your control. Choice of revalidation frequency puts you in charge of the trade-off between real-time accuracy and [scaling costs](\u002Fpricing\u002F), ensuring your bills remain as predictable as your ETAs.\n\n---\n\n[Create a free account](https:\u002F\u002Fclient.stadiamaps.com\u002Fsignup\u002F) to start building with real-time traffic and high-performance routing today. Our [documentation](https:\u002F\u002Fdocs.stadiamaps.com\u002Frouting\u002F) provides everything you need to integrate TomTom-powered precision into your existing OSM workflow.\n",{"title":187,"description":188,"path":189,"published":190,"keywords":191,"rawbody":196},"Sponsorship of Two Open Data Projects","We continue our support of the open-source community by sponsoring two organizations: The OpenStreetMap Foundation and OpenAddresses.","\u002Fblog\u002Fsponsorships-osmf-openaddresses","2023-09-04",[192,149,193,194,195],"Open Source","OpenAddresses","Sponsorship","Community","---\ndescription: \"We continue our support of the open-source community by sponsoring two organizations: The OpenStreetMap Foundation and OpenAddresses.\"\npublished: \"2023-09-04\"\nkeywords:\n  - Open Source\n  - OpenStreetMap\n  - OpenAddresses\n  - Sponsorship\n  - Community\n---\n\n# Sponsorship of Two Open Data Projects\n\nStadia Maps leverages open-source mapping technologies and datasets.  Since our inception, we have continually\ncontributed our technical expertise back to several projects, including [Valhalla](https:\u002F\u002Fvalhalla.github.io\u002Fvalhalla\u002F)\nand [MapLibre](https:\u002F\u002Fmaplibre.org), as well as open-sourcing some [projects of our own](https:\u002F\u002Fgithub.com\u002Fstadiamaps).\n\nWe are happy to announce our financial support for two organizations, whose work we both rely on and contribute back to: the \n[OpenStreetMap Foundation](https:\u002F\u002Fosmfoundation.org\u002F) (Bronze level) and [OpenAddresses](https:\u002F\u002Fopenaddresses.io).\n\nWe take pride in contributing monetarily to these organizations, playing our role in helping secure their future.\n\n## Learn More About Stadia Maps\n\n- Read more about the [products we offer at Stadia Maps](https:\u002F\u002Fstadiamaps.com\u002Fproducts\u002F).\n- [Create an account](https:\u002F\u002Fclient.stadiamaps.com\u002Fsignup\u002F?utm_source=marketing_site&utm_medium=blog&utm_campaign=sponsor_organizations&utm_content=sponsorship_osfm_openaddresses) to start building today!\n- Join our community on [Slack](https:\u002F\u002Fslack.openstreetmap.us\u002F) or [Discord](https:\u002F\u002Fdiscord.gg\u002FqRBy6qqtdT), follow us\non [Mastodon](https:\u002F\u002Fen.osm.town\u002F@stadiamaps), [Twitter](https:\u002F\u002Ftwitter.com\u002F@stadiamaps), or\n[LinkedIn](https:\u002F\u002Fwww.linkedin.com\u002Fcompany\u002Fstadia-maps\u002F), or sign-up for our [mailing list](https:\u002F\u002Feepurl.com\u002Fgs51fD)!\n",1780547077541]