[OSM-talk] Exceeded API bandwidth limit, now what?
Michal Migurski
mike at stamen.com
Tue Sep 14 20:41:57 BST 2010
On Sep 14, 2010, at 12:17 PM, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Sep 14, 2010 at 19:02, Michal Migurski <mike at stamen.com> wrote:
>>
>
>> 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.
No, I hadn't heard of it - based on a quick reading, it sounds completely perfect for what I'm interested in!
>
> 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.
Does this mean that ways are cut off at tile boundaries? I've not found this to be the case with the normal API, which returns complete ways.
I'll experiment with TRAPI, it's very much in-line with what I was imagining with Z/X/Y.xml requests.
-mike.
----------------------------------------------------------------
michal migurski- mike at stamen.com
415.558.1610
More information about the talk
mailing list