[OSM-talk] Exceeded API bandwidth limit, now what?

Ævar Arnfjörð Bjarmason avarab at gmail.com
Tue Sep 14 20:17:30 BST 2010


On Tue, Sep 14, 2010 at 19:02, Michal Migurski <mike at stamen.com> wrote:
> On Sep 14, 2010, at 12:06 AM, Frederik Ramm wrote:
>
>> Hi,
>>
>> Michal Migurski wrote:
>>> I'm downloading London, in small sections. I just exceeded my API bandwidth limit.
>>
>> Get
>>
>> http://download.geofabrik.de/osm/europe/great_britain/england.osm.bz2
>>
>> then do
>>
>> bzcat england.osm.bz2 | time osmosis --rx - --bb left=-.6 bottom=51.3 right=.4 top=51.7 --wx london.osm
>>
>> (or whatever "London" is for you).
>
> Thanks guys. I understand about the extracts, I've used them extensively for years.
>
> I'm experimenting with a way to get at smaller areas of OSM data (generally city-sized) for a possible update to http://tiledrawer.com, and I'm hoping to understand how to both work within the API limitations and be able to piecemeal together a town-sized area without requiring end-users to deal with bzip files or osm2pgsql on their own.
>
> The code I'm developing is here:
>        http://github.com/migurski/TileStache/blob/osm-mirror/TileStache/Goodies/Providers/MirrorOSM.py
>
> It's a provider class for Tilestache that mirrors OSM on a tile-by-tile basis.
>
> Is there any interest here in publishing the OSM API via tile-like URLs? For example, being able to make a request like this to pull a chunk of bounded XML cached out of the OSM API:
>        http://tile.openstreetmap.org/14/2627/6331.xml  <---- note "xml" on the end
>
> The advantages with this should be plainly obvious: a source of data that's trivially cacheable, on the order of hours-to-days old, and available for specific areas of the world, without the massive download and parse overhead of OSM extracts.

Have you looked into the TRAPI? It does that on a z12-basis, it could
probably be extended for bigger/smaller requests.

Anyway, the use case for this sort of thing is much smaller than you'd
think, because:

 * Splitting the tiles makes a lot of things like routing / clicking
   on a complete way hard.

 * Applications that used this would need to suck down a lot of XML to
   get the small subset of the data that they want, having a database
   that serves up custom data is much more efficient.

But on the upside it's simple and scalable with proxies.



More information about the talk mailing list