[OSM-dev] dev Digest, Vol 57, Issue 6

Stefan Ziegler stefan.ziegler_zst at gmx.de
Mon Dec 7 23:30:54 GMT 2009


-------- Original-Nachricht --------
> From: "Bruce Skingle" <Bruce.Skingle at immutify.com>
> Subject: [OSM-dev] OSM Map Browser Application

> I've been working on a map browser project, and I have some code I'm
> ready to think about releasing (free, with source, under the Eclipse
> Public Licence).  
> It can call the OSM API to download the XML data for the viewable
> portion of a raster map and display the OSM data as an overlay, which
> seems fine.
> My main issue is with the interactive map which renders on the fly from
> the XML API. It requests "tiles" of XML data, equivalent to Slippy map
> tiles at zoom level 12 (in terms of area covered). The calls to the API
> are rather slow, which suggests to me that the server is working hard
> to answer the queries, and I want to get some people who understand
> what's happening on the server to look at it before I release to a
> wider audience, hence this email. 
> The program caches all data and never re-requests anything it has cached

Caching is very useful to save download time and especially server load.

> OSM provides ready cut "tiles" of XML data, this seems like a sensible
> approach to me, but I might be alone. I've heard about something called
> TRAPI but haven't seen much information about it.

TRAPI would be the answer to get osm data without server load on the main osm server. 
For implementations look at: http://wiki.openstreetmap.org/wiki/Tile_data_server

If one user make a higher load on the main osm server, it will be banned.
> I take the planet file and produce these tiles.
> I take the planet file and produce Eclipse plugins so users can
> download, say, a countries worth of data. This makes it more useful
> as an offline tool.

Maybe it's better to produce tile data files in osm-Format - the same as the input. Then it is useful for more applications - like my osm3d.
The idea is really simple: just parse the XML planet file with a SAX parser (you can't load Gigabytes of XML data into memory), save the node id's for nodes with lat/lon inside your tile, and find all ways and relations using these nodes and all relations using the ways selected before.
That is faster than loading the planet to a database and using sql to select the ways/node/relation. But if you want to produce tile data files for the whole planet - then a database may be faster (just parsing one time and the rest is done by the database).
A server, where you can download tile data files will always be faster than TRAPI , but not so flexible.

Maybe you can provide such tool as a jar file usable without Eclipse?
> Regards,
> Bruce Skingle.

Stefan Ziegler.
Homepage: http://www.stefanziegler-online.de/
Wir alle wissen mehr als das, wovon wir wissen, dass wir es wissen. (Thornton Wilder)

Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!

More information about the dev mailing list