Getting OSM data exports is a little tedious. They're available, but it's not so easy to get it since it's always very exhaustive. They should try to review ho

Getting OSM data exports is a little tedious. They're available, but it's not so easy to get it since it's always very exhaustive. They should try to review how they make data available for developers, have different data sets, appropriate file formats, etc. They should offers different level of exhaustiveness and type of maps. The most basic should only contain roads and streets with their names. OSM.org is great as a google maps alternative for users, but the problem lies with how OSM lets it data being available. GIS systems are always sensitive to size and performance, so it's not a simple problem. MapBox seems to be on the rise, but I don't know what they're doing exactly, and what is free or not. I tried using their .mbtiles format once and failed, it is a combination of zlib, sqlite and google protocol buffer. The generated C++ headers were the most horrific thing I saw in my life. There are better alternative to google pbf, I guess flatbuffers for example? I have no idea how one would or should distribute map files properly. XML is not indexed and very very large, mainstream databases are inadequate because indexing geographic data is tricky so you cannot really select a specific zone you want. If I was openstreetmap, I would federate XML exports, and generate country exports automatically, AND generate smaller exports for smaller country regions. I don't know if a good alternative would be to provide slightly overlapping squares, so planet.osm would be divided by 16 (or 32) squares, and then each square 16 (or 32) times again. Open platform only thrive if distribution is smooth, and for maps it's not easy but it could be done. It's only a data problem. EDIT: I'm talking about exports simply because OSM.org servers might never be able to hold XML API calls for every developer who wants to use it in their apps.