On Fri, Oct 17, 2008 at 08:58:00PM +0200, Stefan de Konink wrote:
Example (excerpt from db.NodeName.txt => content of name=... tags on nodes):Node/way/relation name/ref/is_in:- text files sorted by id (intended for namefinder - could be changedinto "proper" database entries similar to the way tags are handled)What do you actually implement here?
39: Kaiserdamm 46: Spandauer Damm 54: Siemensdamm 59: Dreieck Funkturm 86: Saatwinkler DammIt's meant to be parsed and put into RAM, not accessed randomly inside the file. For non-namefinder applications, this has to be replaced (the text files are rather large). For tags, I do store a \0-terminated block per element, separating key and value by = and k/v pairs by \n, with proper escaping. There's an index from element id -> start of tags block, but nothing else. Feature type recognition (implemented in the bulk importer) and extraction of other information relevant to the given application is expected to be a preparation / precalculation step, not a runtime one. Of course there might be applications that need efficient access via tag name or tag value even at runtime, so a generic "OSM binary database" implementation could also provide those indices.
CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/
signature.asc
Description: Digital signature
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
