[OSM-dev] Lite OSM backend

Nigel Magnay nigel.magnay at gmail.com
Thu Sep 7 09:04:46 BST 2006


We're talking about several different things here

* 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, not
parsing the source data.

* 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.

* 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.

On 06/09/06, Nicola Ranaldo <ranaldo at unina.it> wrote:
>
> On Wednesday 06 September 2006 22:30, Nigel Magnay wrote:
> > The binary distribution though is *huge* - planet.osm unpacks to about
> 3Gb
> > of text, which is around 6Gb by the time it gets into database page
> tables.
> > Osm2Go can create a db directly from planet.osm.bz2 in about 2-3hrs,
> which
> > I thought was better than trying to distribute a zipped database (~1Gb
> for
> > derby) along with it...
> >
> > Might be nice to have dumps of (say) uk.planet.osm, europe.planet.osm,
> etc
> > to cut some of that down.
>
> I think general pourpose users needs a plug an play data set, they have
> just
> to download somefile.xxx and use it in their browsing/routeplanning
> application. Splitting data access in server, client and network localhost
> overhead will only slow the entire process. This is good for development,
> testing and server solutions but not for a simple client.
> About archive size, i can see a lot of commercial tools with a dvd
> containing
> a good and detailed set of all european maps very far from actual osm
> coverage. If this result is achieved by a custom data backend better than
> free available solutions we should think to start a project to achieve
> similiar results.
>
>         Niko
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20060907/41aca45f/attachment.html>


More information about the dev mailing list