We're talking about several different things here<br><br>* An 'plug-n-play' OSM server. This is a good idea, which is partially why I wrote OSM2Go. But, distributing a database with the server as well would make the download (IMO) intractable at over 1Gb. I could ship it with 
planet.osm.bz2 instead, and have a 'please wait for 2-3 hrs' when you start. NB: The majority of the time is spent in the database doing bulk upload, <span style="font-weight: bold;">not </span>parsing the source data.<br>
<br>* Cutting down datasets to alleviate the above. IMO also good idea, as day to day I'm unlikely to start needing data from other continents.<br><br>* Generating a binary data format. Not sure about this - parsing of the XML isn't particularly slow, bz2 does a fairly substantial job of removing redundancy, and you still have to put it into some kind of database. Unless you're writing your own, but that's a different kettle of fish - storage for the nodes alone is ~144Mb, and that's before you add any kind of indexing.
<br><br><div><span class="gmail_quote">On 06/09/06, <b class="gmail_sendername">Nicola Ranaldo</b> <<a href="mailto:ranaldo@unina.it">ranaldo@unina.it</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wednesday 06 September 2006 22:30, Nigel Magnay wrote:<br>> The binary distribution though is *huge* - planet.osm unpacks to about 3Gb<br>> of text, which is around 6Gb by the time it gets into database page tables.
<br>> Osm2Go can create a db directly from planet.osm.bz2 in about 2-3hrs, which<br>> I thought was better than trying to distribute a zipped database (~1Gb for<br>> derby) along with it...<br>><br>> Might be nice to have dumps of (say) 
uk.planet.osm, europe.planet.osm, etc<br>> to cut some of that down.<br><br>I think general pourpose users needs a plug an play data set, they have just<br>to download somefile.xxx and use it in their browsing/routeplanning
<br>application. Splitting data access in server, client and network localhost<br>overhead will only slow the entire process. This is good for development,<br>testing and server solutions but not for a simple client.<br>About archive size, i can see a lot of commercial tools with a dvd containing
<br>a good and detailed set of all european maps very far from actual osm<br>coverage. If this result is achieved by a custom data backend better than<br>free available solutions we should think to start a project to achieve
<br>similiar results.<br><br>        Niko<br><br><br></blockquote></div><br>