<div class="gmail_quote">On Mon, Jun 22, 2009 at 2:29 AM, Brett Henderson <span dir="ltr"><<a href="mailto:brett@bretth.com">brett@bretth.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Graham Jones wrote:<br>
> Brett,<br>
><br>
> I'll have a look at --write-pgsql-dump and add some words about that<br>
> too.  Then I'll have a go at MySQL...<br>
><br>
> The other thing I would like to add is a write-up on choosing a<br>
> database to use, because it is not obvious to me which would be the<br>
> best, but I suspect this has been looked at a lot before now.  I think<br>
> the choices are:<br>
</div>I'm not aware of a page summarising this, so it sounds very useful.<br>
Lots of people ask about it.<br>
><br>
>     * PostgreSQL/PostGIS - Can handle big datasets, and has geographic<br>
<div class="im">>       extensions.  What I do not know is whether these extensions are<br>
>       fast or not, or if for simple things like selecting for a<br>
>       bounding box it would be quicker to just select on lat/lon<br>
>       directly.   Mapnik uses this database, but the schema is<br>
>       optimised for rendering.<br>
><br>
</div>There's actually 3 PostgreSQL schemas which causes much confusion:<br>
1. The API database.  This is the database behind the main OSM<br>
ruby-based API.  This is supported by the osmosis "apidb" tasks.  The<br>
only db capable of holding full history.<br>
2. The Mapnik database.  Used by the mapnik renderer.  Loaded using<br>
osm2pgsql.  Not supported by osmosis.  Uses PostGIS extensions.  Holds a<br>
filtered subset of data appropriate for rendering.<br>
3. The pgsql "simple" schema.  Badly named, but this is a schema I<br>
created for holding OSM snapshots (ie. doesn't maintain history).  It<br>
does support replication for keeping it up to date.  Uses PostGIS<br>
extensions.  Used by ROMA servers.<br>
<br>
All three schemas above can support minutely updates, 1 and 3 by<br>
osmosis, 2 by osm2pgsql.<br>
><br>
>    *<br>
><br>
><br>
>     * MySQL - Can handle big datasets, but does not have geographic<br>
>       estensions.<br>
><br>
This is the same schema as the PostgreSQL API schema, but implemented in<br>
MySQL.  Provides identical features, but no longer the preferred<br>
database of choice.  It's being maintained in the short term, but I<br>
suspect it will get dropped over time if PostgreSQL continues to work well.<br>
><br>
>     * Sqlite - I have seen a discussion about this and I think there<br>
<div class="im">>       are doubts over how well it works for big datasets?<br>
><br>
</div>No idea on this one, but yes I'd be dubious about its use for large<br>
databases.  Not supported by osmosis.<br>
<br>
On this note, I've also messed about with the Berkeley DB Java Edition<br>
which didn't work well on large datasets.  I've long since deleted the<br>
osmosis tasks that used it.<br>
><br>
>     * GT.M - I know nothing about this, but the xapi servers seem to<br>
>       use it?<br>
><br>
I don't know anything about this either.<br>
<div class="im"></div></blockquote><div><br>GT.M is a high performance schemaless datastore.  A bit like CouchDB.<br><br>Probably not what you are looking for.<br><br>80n<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">><br>
>    *<br>
><br>
><br>
> I would also like to include some example SQL queries to deal with<br>
> selecting nodes / ways etc. in a given bounding box, or searching for<br>
> points of interest.   These are not too difficult to do, but I suspect<br>
> that some ways are more efficient than others, so it would be nice to<br>
> include 'optimum' examples.<br>
</div>Sounds reasonable.  You may wish to check out the osmosis "pgsql"<br>
queries in this space, it uses true geo-spatial queries if the optional<br>
way "linestring" and "bbox" columns are available.<br>
<div class="im">><br>
> Do you know if this has already been done and written up somewhere?<br>
> If not I will set up a template and ask for help filling it in!<br>
</div>I haven't seen it before (not that I've looked ...).  Sounds great to me!<br>
<br>
A couple of other db mechanisms are available, details are on the wiki.<br>
TRAPI - Stores data using a tile-based mechanism.<br>
<a href="http://wiki.openstreetmap.org/wiki/TRAPI" target="_blank">http://wiki.openstreetmap.org/wiki/TRAPI</a><br>
osmbin - A compact custom storage mechanism.  Supported by osmosis via a<br>
plugin.<br>
<a href="http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--write-osmbin-0.6" target="_blank">http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--write-osmbin-0.6</a><br>
<div><div></div><div class="h5"><br>
Brett<br>
<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
</div></div></blockquote></div><br>