Oh I'm so sad for them. Mapzen has a bunch of really great products and services, they are some of the top experts in open source mapping. It's a shame the business hasn't worked out.
They have a good companion post on alternative services for folks needing to migrate. It doubles as a survey of the best in open source mapping tools out there right now. https://mapzen.com/blog/migration/
> They have a good companion post on alternative services for folks needing to migrate. It doubles as a survey of the best in open source mapping tools out there right now. https://mapzen.com/blog/migration/
That post needs to be archived somewhere before the shutdown.
5 downvotes and counting. Why is that? Isn't it remarkable that we're relying on another startup, one who may not even be revenue positive, to archive the output of another failed startup? Is this not an interesting thing?
Plenty of startups fail and write massive articles about how everything they did was amazing, they were going to cure cancer and all the world's ailments, but something fell through and now they're dead and how it's mostly everyone else's fault. I've seen far more spin around shutdown than acquisitions.
Haha, that announcement became quite the running joke inside of Google, with people generating "advancing our amazing bet" memes whenever a project it tech was deprecated.
Is that a requirement? Let say a big startup announces to cease operation with hundreds of paid customers. I think it is totally acceptable for a short announcement like Mapzen’s, but with a seperate page about migration and refund. Then the next is making sure everyone in the company will help taking customer calls.
Unless stated otherwise, I think we can assume whenever a company goes out of business, the reason has to be $$. There are special cases like political pressure etc.
Really sad to see. I've been very happy with Mapzen for the past year or so.
Their open source stuff is really good, and the service itself is excellent as well. Not quite as polished as Google/Mapbox, but absolutely usable in production apps.
Would be very interested to read a post mortem. Did they simply struggle to find users, was their pricing strategy wrong, was quality an issue?
If anyone at Mapzen is reading these comments, thank you for all the work you've done. I'll miss you guys.
I know a bunch of the team there but don't know all the inside scoop.
They were trying freemium with the hosted services but not many people were paying.
One of the issues (imo) is that there really isn't open traffic data (but there should be).
This really hampers some of the more interesting routing things and they were focused on a
lot of the more multi-modal and pulling in elevation data for biking, etc. Some people were
doing some pretty cool stuff with their tools but I think in the end Google gives away enough
API transactions for most people and the quality is good enough.
From what I understand of real time traffic data, most of it is generated from mobile users themselves. That means for the most part it'll be Google, and to a lesser extent Apple.
If Google thinks it's in its advantage to keep that data closed to benefit their business model, then no one else has access to it.
I doubt that traffic data was their main issue ... but anyway ... yes, traffic data is a difficult topic. And yes, the state of open traffic data is bad:
But no, although Google and Apple (and also Mapbox!) do not give a away their traffic data, there are still three sources for world wide traffic data:
TomTom, HERE and inrix. All acquire their data via external software companies or automotive companies (or whatever) including their measurement units into their products.
Mapzen was starting their open traffic data project and so we at Graphhopper were hoping they would solve this issue in the next years, but now, obviously they won't:
>Robust, high quality data
INRIX gathers real-time, predictive and historical data from more than 300 million sources, including commercial fleets, GPS, cell towers, mobile devices and cameras.
>Calculating traffic at a 100m granularity, we use advanced algorithms and heuristics to ensure data is intelligently fused to true traffic conditions for 8 million kilometers of roads in more than 47 countries, making every trip safer and more efficient.
Kinda like it says, they get it from fleets, app makers, etc. For example, you might put an OBD2 device like Automatic in your car to lower your insurance - the company making the OBD2 device might be selling location data of that OBD2 device. Commercial fleets have those as well, and that data is also sold. Same for mobile apps - a lot of them collect user location data, especially anything related to motion/navigation.
One example - http://www.coyotesystems.eu/ but there are dozens, if not hundreds, more companies selling this kind of data on their users, and companies like Inrix aggregate it.
As said Waze, Google, etc. can generate their own. There are also lots of companies that have paid to put sensors on public roads but retain all the rights for the traffic data. I think anything older than 1 day should be released into open data.
The second option can be hosted at ArcGIS Online without you doing anything (i.e. loading anything). It is a REST API. Yes, it is hidden in their stupid docs.
The third option is faster than anything else, but would require you to load planet-osm.
Mapnificent [0] seems to do something similar and I had some fun playing around with it for my city. It doesn't seem to go into as much detail as Mapzen and doesn't have an API, but it's open source.
It is a great shame to see them go, was always impressed with the quality of their products and ecosystem built around it.
If there are any Mapzeners here looking for something new, please consider taking a look at www.procedural.eu - we also make a WebGL mapping engine based on OSM data, but our focus is more using procedural generation to augment the data, to generate immersive 3D natural environments for visualizing ski resorts, hiking routes etc.
That’s sad news. I was planning to use them for my programming class. The Geocoding and other APIs, besides being free and generous, were easy to learn and very useful. The technical blog posts were also enlightening.
> Have you considered teaching your journalism students Docker first?
I agree. This would be a great prank. As a bonus, it'd help solidify their disinterest in everything computer-ish, making them more motivated journalism students. Do it OP!
Do you need geocoding? I ask because I am one of the makers of the OpenCage geocoder. We offer forward and reverse geocoding from open data (primarily OpenStreetMap, but also others). We're listed in the migration guide, and we'll be offering 20% off our pricing for all former Mapzen customers. Blog post about that is coming shortly.
I'm sorry, but the last time I tried OpenCage it was terrible. And by terrible, I mean in line with everything else that uses OSM-based data. Geocoding is hard and I wish you luck, but you've got a long way to go.
I've never come across a geocoder better or cheaper than Google, unfortunately. They all claim accuracy but fail in trivial cases, or interpolate to the wrong part of the street where Google is spot on (though Google has its occasional flaws). I'd love to see competition but it's probably not coming any time soon.
A comparison is challenging in that in our experience there are many different use cases. It all depends on which geographies you are interested in, and what level of accuracy, speed, data freedom, and cost you are willing to accept. I mean of course we can do query X on different services and say service A returns answer 1, service B returns answer 2, etc. But that's only useful if your queries look like X, and very often they don't. So it's difficult to say "service A is better". Much more relevant is which is better for your specific needs (and budget).
The only guaranteed way to know if a service will meet your needs is to test, hence why we offer 2,500 free queries per day for as long as you like.
sorry you had a bad experience. Feel free to contact me if you want me to take a closer look. "Geocoding" is a very broad term, it really depends if you need reverse, forward, what level of specificity, which region of the world, the quality of your queries, etc. I'm happy to concede we're not perfect for every use case, but we are definitely more than good enough for many (as proven by our many long-term clients). Thanks for trying us out, and as said happy to have a look at your needs specifically if you contact me.
I can't speak for the commenter above, but as someone who runs a paid service built on open geodata I can tell you our best customers are those who first try to self host and then realize what a pain that is. The challenge is not just keeping the software up to date, but that you also need to keep the data fresh. How fresh of course depends on your exact use case, of course, but for perspective OpenStreetMap has 3-4 million edits per day. It's totally doable - and is technically very interesting, but in much the same way that fixing your own car or baking your own bread is doable and fun. It's more cost-effective to hand it off to a reliable expert.
Building/installing is (relatively) easy. Maintaining is hard.
Even without a requirement to stay particularly up to date, the size of the datasets makes working with OpenStreetMap reasonably complicated.
I needed tiles in non-web-standard projections: equirectangular and polar (EPSG:4326, 3575 and 3031). ESRI used to provide equirectangular tiles[0], but have deprecated the service. Polarmap have an Arctic map, but only at standard resolution [1]. I couldn't find an Antarctic map.
With a fair amount of fiddling, and building on the work OpenMapTiles.org have done, it was possible to generate the tiles, but I now realise why few people have attempted this: it requires a lot of processing power, technical ability to get everything working properly, and cartography to have a map that looks good (not just the final styling, but the choice of what data is present in each layer of vector tiles).
I met the minimum of what we needed [2], but I need to find more time to do the rest -- like contours.
Anybody know if there is a hosted libpostal service? I didn't notice in the migration document. It's easy to include in our application if we need to but it's used infrequently and consumes a couple of gigabytes of memory so we've found it useful to call as a service when needed.
Such sad news. Mapzen has been a core component of many projects that I've worked with. They have created and supported many great products that will be missed.
They also have been a big part of supporting the GeoNYC group and helping to organize the OpenStreetMap US conferences.
Am I the only one who constantly discovers cool services during their shutdown notices? It feels like half of them can start to make it after the press they get during shutdown.
I'm going to guess: not enough customers to get them to a point where the business is sustainable and not being able to find inverstors that are willing to invest in something like this.
They have a very nice product but competing with the likes of Google is hard.
People don't realize how onerous and expensive it is to run a mapping service (even if you use OSM data). For example, the Google Maps API and the Bing Maps APIs are most likely totally subsidized services. Google/MSFT are able to justify the cost because the mapping tools are used in so many other products. And since the cost of development is spread over multiple places, the true cost of the geo services are not reflected in the prices of the services. Whereas someone like Mapzen has to recoup all of their costs on just the services.
Additionally, companies like Mapzen make this mistake in believing that because Google (and a few others) have this massive Maps API ecosystem that there's a ton of money in this market. I've seen similar investment slides and their argument boils down to something like, "well Google/msft is aggressively going after this market so that means there MUST be money here" and that's the bulk of the justification. Honestly, I don't even think Google/MSFT know why they have been going after the Maps API market so aggressively. For one, Google has completely and utterly failed to leverage the Maps API to transition or segue customers onto Google Cloud Platform where there is obviously a lot of money to be made. So like what else is there? There's no way the geo services business matches the cloud, ads, youtube, or chrome/android business. Not to mention all the other shit going on.
In conclusion, I feel like we will see other services fail as well. I would be SHOCKED to see MapBox continue on or even IPO. They will most likely be sold once investors realize what I've just discussed or shut down. I also predict that Google / MSFT will just limit their interest in this product unless they can find a way to help it drive GCP/Azure business.
Mapbox have products that people want to use. Mapbox GL is an astonishing product almost entirely without competition, and their routing is also top-notch.
It remains to be seen whether 200+ employees and sunk costs is a sustainable business; it's an audacious bet on their part that it is. But Mapbox without doubt has the foundations of a very sustainable business within it.
Mapzen never had the revenue, and never looked like it was trying very hard to get it, presumably betting that its Samsung parent would keep the tap running (and, to their credit, being aggressively open-source so that their work wasn't wasted when the day came that the tap was turned off). A bunch of the stuff they did was technologically really fascinating and valuable, such as Who's On First (their geocoder), but never got to saleable product stage. Commercially Mapzen hobbled themselves for geocoding by their laudable insistence on being a 100% open solution: you simply can't do worldwide, reliable, saleable address-level geocoding with open data yet.
Note too that there are a bunch of less noisy players within the OSM ecosystem - Geofabrik, Thunderforest, Graphhopper - who do work which is often as interesting and performant as the Silicon Valley companies, yet with a much lower profile. If you're looking for alternatives following the Mapzen shutdown, I'd commend all three.
I totally agree that Mapbox has great products. There's no doubt there. My doubt is whether or not the market is big enough to support the development of such products.
My thesis is that "geo services" ventures need to be subsidized or else they can't sustainably exist at prices that developers are today accustomed to pay for.
>But Mapbox without doubt has the foundations of a very sustainable business within it.
Are you sure about that? The world is littered with failed companies with amazing products that couldn't find enough people to sell them to. Just because you have a lot of people who want to buy your $100 bills for $50 doesn't mean you have a strong business.
Google is playing the long game. They want to digitize as much information about the world as possible. Autonomous cars, location recognition from arbitrary photos, location-based marketing, etc. As computing becomes more intertwined with our physical world, there will probably be many new markets where having the best maps is a competitive advantage.
This is most likely the case. Which is why companies like Mapzen and Mapbox will go out of business or sell for cheap in the near future. There is no long game for them to play.
>People don't realize how onerous and expensive it is to run a mapping service (even if you use OSM data).
Yes. Apple learned this with their disastrous rollout of their custom mapping solution a few years back. Mapping/geographic projects are nothing to sneeze at, even for the big guys. There's just so well-integrated and useful that we hardly think about the complication involved.
I was talking only about geo services (aka the APIs), you're talking about the consumer products (the app and the site).
But more to my point Google and MSFT have a "multi-faceted" geo business so they can make money in many different places. Whereas someone like Mapzen or Mapbox ONLY has the geo services/APIs end. So where can the go to subsidize the cost of the services? The answer is they cant so the revenue from the services to carry the entire cost of their efforts.
Sure, we're on the same page. For Google, building out a Maps service is a way to increase inventory for an ad platform. They can accept much lower margins on the geo services business, since they have high margin ads efforts.
Theoretically, if Mapbox could get enough views, they could also enter the advertising market. But from my understanding of their company and business model, that would be a really tough sell.
The first Maps API dropped in 2008. No one company has figured out ads on geo APIS. Not Google. Not FB, MSFT, or anyone else has figured out how to put ads on geo apis. I think its safe to say its never going to happen.
Ha, I did not know that. I knew it came out of the Samsung accelerator, didn't know they were actually owned by Samsung. My guess is probably wrong in that case. However, from all that I can find it states they're supported by Samsung Research, to me that's not the same thing as 'part of' Samsung, which would imply ownership.
> However, from all that I can find it states they're supported by Samsung Research, to me that's not the same thing as 'part of' Samsung, which would imply ownership.
You are correct. They are not owned by Samsung, they were simply part of the accelerator.
Actually, as someone else pointed out, in Mapzen's terms of service:
> These Terms of Service (“Terms”) govern the terms by which you (if registering on behalf of yourself) or the entity you represent (if registering as a business) (“Customer,” “you” or “your”) may utilize the mapping tools and services made available by Samsung Research America, Inc. on behalf of its Mapzen business unit (“Mapzen˝ or ˝we˝ or ˝us˝ or “our”).
Seems they were actually part of Samsung. Makes me wonder why they shuttered Mapzen. I can see this being useful to them for Tizen amongst other things.
I remember reading it takes several days on super beefy hardware just to import all of the data from openstreetmap and openaddresses they they use to run mapzen.
I don't think this is a thing where you just whip up a docker-compose file and spin up a Heroku dyno.
I don't know about mapzen, never used their tools. But a common first way to use OSM data is to use osm2pgsql to import the data into PostgreSQL. Yes, on beefy hardware, it can take ~24 hours to import the whole OSM database file for the whole world.
One beauty of OSM is that lots of the software can, and does, work for region based extracts, and doesn't require the whole world. You can render tiles, do geocoding, or routing on a per country, or continent basis, depending on what you want. Mapzen provided "metroextract", but Geofabrik (my employer) provides continent/country/state extracts on https://download.geofabrik.de You can also cut out your own extracts with osmosis, or osmium-tool, based on the planet/continent/country/state region covering your area of interest.
Sad to see this. I've been using Mapbox for my projects, if only because their documentation was pretty good for a beginner like me- but Mapzen seemed like an excellent service, and I hate to see that competition die.
If you need an alternative, please also keep an eye on MAPCAT. Our OSM-based public map portal is already live (www.mapcat.com), and the map API is just about to be launched. More info at http://try.mapcat.com/
I've made quite a bit of use of Tangram JS (which I was very impressed by), and also of Mapzen's Open Street Map metro extracts and the IMPOSM project. Both very useful - thanks Mapzen.
Hope everyone involved manages to find new work swiftly.
Are you using Mapzen's vector tiles with Tangram? If so have you decided on a replacement? Mapzen pricing was good, too good it seems. I require access to global tiles but very low amount of requests with a custom Tangram JS yaml.
Sorry to hear that. Is openaddresses.io, one of their backed projects dying too? I've been using their data on geocode.xyz, but it seems like there has not been any new data in the past 6 months.
If you need an alternative, please consider MAPCAT. Our OSM-based public map portal is already live, and the map API is just about to be launched. For more info please check http://www.mapcat.com and http://try.mapcat.com
For example, while Mapbox use open source (OSM) tiles, other services - e.g. their search API - aren't open, as Mapzen's is(/was). Yet they are listed on that page by Mapzen as an alternative for Search.
I'm an engineer on Mapbox's search (geocoding) team, and our geocoding engine is actually open source: https://github.com/mapbox/carmen
Our data isn't, but as other commenters here have said, it's not currently possible to build a good geocoder with the open data available. We're constantly working to support open data efforts, but it's not there yet.
> For example, while Mapbox use open source (OSM) tiles, other services - e.g. their search API - aren't open, as Mapzen's is(/was).
The geocoding engine[1] powering the Mapbox Search API is open source, and has been since its inception in 2012. The same is true of the routing engine[2] powering the Mapbox Directions API (OSRM), and the engine used to create Vector Tiles[3] for the Mapbox Maps API, along with the engines powering most Mapbox APIs.
Non-open code at Mapbox is usually tightly coupled to our infrastructure or data processing pipelines, which would not be generally useful to the community at large. The useful bits of even this infrastructure code is also typically abstracted into generally useful libraries for community use, such as earcut[4], rasterio[5], tile-cover[6], and hundreds of other modules of all varieties.
It depends what you need. If you need an outdated, highly filtered dataset, sure. But no need for IPFS, just grab the tiles from https://openmaptiles.com/ where you also find the appropriate license (which this demo does not seem to include...)
Hey there all! I work for Boundless Geo. This sucks. But thankfully we and many like us will be able to help pick up the Geo Spatial slack as it were.
Boundless helps reduce the cost and time of deploying and managing geospatial software with a scalable, open GIS platform – including Server, Exchange, Desktop and Connect – and a powerful ecosystem of geospatial knowledge, tools and resources.
They have a good companion post on alternative services for folks needing to migrate. It doubles as a survey of the best in open source mapping tools out there right now. https://mapzen.com/blog/migration/
Edit also a post specific to the Who's On First project: https://www.whosonfirst.org/blog/2018/01/02/chapter-two/