[OSM-dev] dev Digest, Vol 57, Issue 6
Stefan Ziegler
stefan.ziegler_zst at gmx.de
Mon Dec 7 23:30:54 GMT 2009
Hello,
-------- 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.
--
Diplom-Informatiker,
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.!
http://portal.gmx.net/de/go/dsl02
More information about the dev
mailing list