Google really has a comprehensive set of APIs. For my site, I used their mapping, routing, elevation, charts, and geocoding services. I won't go into details on how those work, if you use them then you already know, but the point here is that when you leave Google, you are leaving a very comfortable environment whereby everything is under one roof, and going out into what is initially a very confusing world of different libraries and services. Seeing how they all fit together exactly can be daunting at first. I'll try to save you some time in sketching an outline of what I found out. Remember that I'm not an expert on all of this; I am just speaking here as someone who recently had to go through a painful transition from one API environment to a completely different set of APIs. There is, as always, more than one way to do it. All I want to do is try to give you some hints and clues to make it easier and perhaps bring it all together in a way that makes sense, specifically for someone coming from an exclusively Google environment.

Maps: OpenStreetMap and Stadia Maps

First of all, the maps themselves. I really never had to think about this much at all with Google, it "just worked" and I followed their recipes and made their magic incantations, and hey presto, maps on my website. But once you leave Google, where are you going to get your maps from?

The main actor here is a crowdsourced effort called OpenStreetMap. Think of this as a Wikipedia for map data. It isn't quite as smooth or complete as Google's maps, but it is the solution you'll most likely end up using, unless you have a lot of money.

OpenStreetMap (or OSM) has a service which you can use to put maps on your website, but mainly what they do is provide the DATA, not the actual service itself. Then other companies take that data and package it up and sell the service of actually giving you the maps that go on your site. There are useful guides that talk about switching, but it's still a pretty big list of possibilities, and I'm going to try to cut to the chase here for you.

When you start poking around looking for mapping providers, you'll quickly come across vendors like TomTom, or Mapbox, or Bing, or other big companies. I looked at their fee structure, and all of them seemed quite pricey. I am a small, one-man shop, and not used to having to pay out each month just to have maps on my site. So anything at all seems like a drag, to be honest.

In the end I saw some mention of a company called Stadia Maps. They caught my attention for a couple of reasons. First of all, their fees were very reasonable, and they are tier-based, rather than "pay as you go". This is quite important, because pay-as-you-go means that if you use a certain number of map views, then you pay for them - simple, right? But what if, say, one of your pages suddenly gets linked one day from a popular news site like reddit? Your map views could explode through the roof, and your credit card bill will explode with it. Soft tiers, on the other hand, means that you just pay for a nominal level of activity per month - they average it out, and if you seem to be consistently using more than your quota, then you might get a call from them eventually asking if you would like to move up to the next tier. But one bad day won't kill you, because they recognize that's how the internet works sometimes. In other words, they are trying to be nice about it, a bit more relaxed than this "pay for every single hit" model.

Also, Stadia Maps talked about how they were not backed by venture capital, unlike companies like Mapbox. I think this is very important, because in my experience companies that are venture-backed tend to behave very differently from companies that are self funded, or based on angel investors. Venture-backed companies tend to want to grow much more aggressively, and as such the user can often take a back seat to other ambitions. I know this isn't always true, but it is a risk when a company is trying to grow really fast. Often the founders are more focused on their exit strategy, getting bought, going public etc than they are on just making a great company that does one job really well. Having been burned by Google, I wanted to go with a company that was at least trying to do the right thing and be around for the duration, just being happy with providing a good service for a reasonable price, rather than striving to become the next Google. I communicated with the guys who run Stadia, and felt comfortable with the noises they were making. I felt like I was on the same page as them, so I settled on that company. I should add that I have no connection with them apart from what I'm recounting here; I'm not being paid to say this, and I'm not doing stealth marketing or anything like that. This is just an honest account of what I found by looking around for a mapping provider, and it's just my opinions, that's all.

Mapping API: Leaflet.js

Next up, how to display the maps and do stuff like drawing lines and markers.

What Stadia Maps told me was that I should probably look at using the Mapbox GL JS API to display my maps, which somewhat surprised me, since Mapbox is a competitor to Stadia. However they filled me in that this library is Open Source, and safe to use, not really dependent on Mapbox as a vendor.

So I investigated this library, and to cut a long story short, I hated it. I just couldn't get into it, and there were multiple things that bugged me. Like, for example, lat/lngs were reversed everywhere in the code (with respect to how Google's API does it), which would mean a lot of potential for bugs as I transitioned my (quite large) codebase. If in your existing code you have lat,lng everywhere, and your stored data is formatted like that too, and in the new one it's lng,lat, i.e. reversed, that's a bit of a hassle! Also, it just seemed harder than it should be to do some simple things, like drawing a polyline for example. I looked for a function or class called something like, oh I dunno, "polyline", like Google has, and couldn't find it. Eventually I found out that in order to draw a polyline, you have to use something called GeoJSONSource. And this is a mess of nested curly brackets, with each level of nesting just begging the question "Ok, so what exactly are the OTHER options at this level?". The examples boggled my mind because they begged more questions than they answered, and finding out how it all fit together was frustrating.

Eventually I threw up my hands in disgust and went looking for some alternative. Luckily I had heard about a library called Leaflet.js, so I took a look at it, and I was immediately struck by how... familiar it looked. There are straightforward functions for polyline, circle, rectangle, polygon, and they work pretty much the same way as Google's API. And there are markers, and popups. Ok, so the names are different for some things, but overall I just got the sense that this was the way to go, especially coming from Google.

So that's what I would suggest to anybody coming from Google's Maps API: Go with Leaflet.js, and use raster maps. The Mapbox GL JS library is much newer than Leaflet, and uses vector maps intead of raster. What's the difference? Basically maps online are composed of tiles. The tiles cover the world, and as you zoom and pan around, you are requesting different tiles. Raster tiles are just good old images, so as you zoom in and out you see some pixelation as the old tile is magnified or zoomed before the next level of tile is loaded. With vector maps, the "new and improved" way of doing maps, it's all done using drawing rather than images. So things are theoretically a lot smoother, since it's all vectors rather than bits. The downside is that it works quite differently at the API level, and while it theoretically entails less data being downloaded, it's also much more CPU intensive on the client side. Trust me, if you're coming from Google's Maps API, then you will be a lot more comfortable with Leaflet.js and raster maps, than going all gee-whiz with Mapbox GL JS. I mean, you can if you want, but that's my advice. Maybe you're smarter than I am. All I know is that my main priority was simply to get my maps working again as they did before, just using some platform other than Google. So I only wanted to change one variable at a time; I wasn't trying to move to the next level in technology, I was just trying to get the maps working as they did before. That's all. So I was extremely happy to find Leaflet.js.

Routing: Stadia Maps (Valhalla)

Ok, so what Stadia Maps + Leaflet.js does for you is allow you to display maps on your site, draw lines (routes) and markers, and popups. All that good stuff. Stadia also has a routing service, which is based on the Open Source Valhalla routing engine. So you can get routes too, which checks off another box on what you need to replace from Google.

Geocoding: OpenCage Geocoder

Next up there's geocoding, or taking a place name and getting back a lat/lng, or vice versa. Stadia doesn't do this themselves, apparently it's another type of service altogether which they just aren't doing yet, but they recommended another company that is at a very similar level to them, called OpenCage. They have a very reasonable fee structure, including a free tier, and they even have a geocoding plugin for Leaflet.js, which puts a search box on your map with minimal effort. Very nice.

Other Useful Leaflet.js Plugins

That reminds me: Leaflet.js has a lot of third party plugins. These are mini Javascript libraries which add functionality to Leaflet. For example, there is one that makes shapes (circles, rectangles, polygons) editable, like what you could do with Google. You can find a lot of these just by doing some judicious Google searching, usually putting Leaflet.js at the start and then keywords, e.g. "leaflet.js shape editing". The shape editing module is here:

https://github.com/Leaflet/Leaflet.Editable

There are other libraries, one useful one was to decode the paths that came back from Valhalla's routing engine - they were encoded in a way that I hadn't seen before for some reason, which was strange given that the method was apparently developed by Google. Maybe I've been using this encoding all the time under the covers of the Google API, I really don't know. All I know is that I now needed to explicitly decode these weird strings that I got back from Stadia's routing engine, and this allowed me to do that:

https://github.com/jieter/Leaflet.encoded

Another one gives you a "fullscreen" button on the map:

https://github.com/Leaflet/Leaflet.fullscreen

Charts: Plot.ly

Then there's charts. You may not be affected by this, but I show elevation charts on my maps, so Google's Visualization library was something I used quite heavily. It's nice. I initially tried using the main Open Source Javascript library that seemed to always come up at the top of searches, namely Chart.js. It looks very snappy and smooth, and I just assumed it would be able to do whatever I needed. And maybe it could, but damned if I could work out how. The documentation is atrocious, extremely frustrating if you want to try to do anything that goes far outside of the default options. The way it is structured makes it extremely difficult to figure out where options actually go, or how to use them. All the tutorials are the same, going into excruciating detail about the really simple stuff (like how to create a chart) but then totally ignoring what you really need - how to customize to make the charts do things outside the defaults. I couldn't figure out how to make the x axis on my elevation chart display reasonably tidy and well-spaced ticks, for example. I wanted the ticks to go up in intervals like "0 10 20 30 40" miles, but instead the automatic ticks come out as some weird intervals like "0 11 15 23" or whatever. Really odd numbers. And I couldn't make the chart change it. When I changed the type of the axis to something other than the default, then the chart line disappeared. The docs tell you to ask questions on stackoverflow using the tag chart.js, so I did that, but never got an answer:

https://stackoverflow.com/questions/51688322/setting-custom-x-axis-ticks-on-chart-js-line-chart-for-distance-vs-elevation

In the end I was so frustrated with the stupid documentation and apparent total lack of community support, that I gave up on Chart.js and went looking desperately for some alternative. Initially all I found were strange libraries that were either commercial (i.e. fee based, no thanks) or else with some weird dependency on some other library (I like no dependencies, just basic raw javascript).

Eventually I stumbled upon Plot.ly. I downloaded it, and in short order I had very nice looking elevation charts with reasonable looking axes. What a breath of fresh air! It just worked, and I could change the options easily. It's true that their documentation page kind of sucks, for some reason they decided to put everything on one page and it makes my browser freeze for a while while it tries to sort it all out every time I load it. But the library itself works fine, and it's intuitive and easy to use.

Elevation Data

It would be remiss of me if I did not mention how I get my elevation data. This is one area where I actually already transitioned away from Google some time ago, due to the restrictions they place on the use of their services. I announced this on the crazyguyonabike forums back in 2014:

New elevation data for maps, improved elevation profile charts, and fullscreen mode posted by Neil Gunton on Mon 8 Sep 2014

Basically I had to do this because Google was being too restrictive, in terms of how many requests you could make per second or something like that. I wanted to allow my users to re-calculate the elevation profiles for complex routes on-the-fly, and Google wouldn't let me do that in the way I wanted, so I "rolled my own" solution by downloading all the elevation data for the entire world, storing it on my server, and figuring out how to access it by lat/lng. It's a strictly amateur effort on my part, but it gets the job done and allows me a lot more freedom as to how I generate my elevation profiles. Also, as you will see if you read through the linked forum thread above, it quickly became apparent to me that generating elevation profiles is not as simple as it would first appear. The data is anything but "clean", which results in odd spikes and troughs in the profiles which make no sense in the real world. So you have to have algorithms for "smoothing" out these wrinkles, but you can't smooth too much, otherwise you lose real detail. So with a little assistance from one or two users on my site, I came up with some equations to help me be like Goldilocks and have "just the right" amount of smoothing. Again, it ain't perfect, but it gets the job done.

Conclusion

So there you have it, a rough road map of services and libraries that should enable you to replicate whatever you were doing with Google maps, using largely Open Source tools. I say "largely" because while the tools themselves can be Open Source, generally anything that involves calling a server somewhere will require paying the person who runs that server, since running servers obviously takes money. So Leaflet.js is free and Open Source, but getting map tiles to use with Leaflet.js will likely involve paying someone (unless your website or app is so small that you can use OSM's free server without causing them any load problems). Ditto geocoding - this sort of service takes a lot of server resources, so expect to pay someone for that (but even OpenCage has a free starter tier, so you only have to pay once you start using a certain level of resources - they have a pretty generous starter tier of 2,500 requests per day).

On the upside, once you are transitioned into the world of Leaflet.js, it will be much, much easier switching to some other mapping provider down the line. Heck, if you wanted to, you could even run your own map tile servers. For now, though, I can actually give my users the option of which provider to use - Stadia, who I pay for, or OSM's mapping server, which is free but not supposed to be used too heavily for commercial sites. But I give it as an option, because I figure not too many will actually do that (users don't generally change options) and so the number of people who do switch will be small.

As an aside, I can use OSM's mapping server for the journal downloads. I give my users the option to download their journals from my site, whereby I run an offline script that goes through all the database records etc and generates a set of static html files which are zipped together so the user can have their journal for offline use. If they have maps in the journal then this presents a bit of an issue, since Stadia Maps has a restriction that requests have to come from your registered domains. If someone is browsing via a file rather than a website, then there's no domain and the maps will not work. So for the downloads, I simply point to the free OSM server instead. It's a very nice, flexible system, and not likely to be an issue for OSM since the downloaded journals are mainly for backups. They are generally stored on a person's local hard drive or burned to DVD-ROM, and used by one person at a time. So I don't see the load being any issue for OSM.

This is an example of why switching to OSM is actually a Good Thing - it gives you far more control than you had with Google.

I hope this was useful, it gives you a roadmap at least. In the next section I'll try to give some notes that I jotted down while going through my transition, that might be useful as specific gotchas and things to look out for.