Is that even true? And is number of companies even a good metric? Based on revenue/market cap, the bulk of companies use OSM directly.
The world's biggest company (Apple) uses OSM directly. Telenav uses it directly. Don't Tesla and Uber use OSM directly too? And we use Mapbox at Gaia GPS, but we also use OSM data directly.
> How about letting users experiment and seeing what cool stuff they can come up with?
In my experience building a company, if you focus on too many things, you get everything wrong. This smells to me of being not on target for making OSM as strong as possible, even though it has alluring upside.
https://electrek.co/2017/07/03/tesla-map-navigation-open-sou...
Actually it does. Especially since you can have 1 billion in revenue by selling $10 dollar bills at $1 dollar.
>b) having the biggest market cap is something thats good for their shareholder, and terrible for anyone else
Whatever.
>But yeah, do continue to praise your beloved highness.
Irrational argument ad hominem.
It's an awful measure for "biggest company", since private companies have no market cap. This was discussed a while ago in relation to Saudi Aramco's potential partial IPO. Saudi Aramco is huge, much bigger than Apple, with no market cap.
They absolutely do. They're just updated less frequently and called "valuations". Closely-held private companies also have valuations, they're just even less frequently made visible.
In the way the Fahrenheit and Celsius scales "are entirely different things." Both "valuation" and "market cap" are measures on the aggregated estimated present value of future cash flows, i.e. net asset value, from/of a security.
can't there be an open source set of service
APIs that's self hosted
Unfortunately, the developer experience is much more painful than using Google Maps.
With Google Maps, if you can add Javascript to a web page you're basically good to go. Data updates, software updates, server redundancy, server support and security, all taken care of. Even if you're exclusively a front-end dev, you're making a static site, and you've never heard of Linux.
Compared to that, self-hosting OSM tile generation requires a bunch of extra knowledge, equipment and maintenance.
With image tiles it's a hurdle. You have to build 18 zoom levels of tiles. The most detailed layers have an astronomic number if tiles. You also need a huge amount if storage.
http://tools.geofabrik.de/calc/#type=geofabrik_standard&bbox...
Did I mention the data being huge? What's the point of having 15Tb container, which takes forever to deploy? You can certainly containerize the services, but there's no benefit containerizing the data, since you have to replace it all at once rather than synchronizing the differences.
Even if you could make the general setup and maintenance incredibly easy somehow, just syncing the map data from osm regularly would require decent hardware: the extra cost of each dev doing this themselves just doesn't compare to using a central tile host.
On top of that, if every dev was regularly updating their own OSM data, OSM would have a lot of extra strain on their data download servers to deal with. Not sure if this could be comparable to the hardware overhead of providing a tile hosting service though.
We need servers with at least 24 CPU threads and 256 GB RAM and moving the data into PostGIS, region by region takes a week or two. Plus you manually have to fix the process when it just spits out an error and aborts after 15 hours of churning.
You can get country level extracts, which can be updated every day. Nearly any server which can import OSM data is able to keep it up to date.
The problem is that most companies using OSM are using Mapbox. This leads to a few problems, including attribution, which I decided not to touch on, but is a serious problem that Mapbox doesn't address sufficiently.
If they could use OSM directly, they'd be engaged with OSM directly. They'd care about OSM. Right now OSM shoves these users away and makes them into customers of some third party (maybe Mapbox, maybe someone else) instead of caring about OSM itself.
> Expanding the scope of OpenStreetMap to include transient data. Too much other work to do, maybe later for this.
How about letting users experiment and seeing what cool stuff they can come up with?