[OSM-dev] osm2pgsql output possible to work with Java XAPI?

Stefan Keller sfkeller at gmail.com
Mon May 30 22:22:31 BST 2011


2011/5/30 Frederik Ramm <frederik at remote.org> wrote:
> Hi,
> On 05/30/11 17:19, Peter Körner wrote:
>> Wouldn't it be more logical to trick the rendering system to use the
>> pgsnapshot tables?
> I think that all depends on what you want to do with your system. A
> rendering system that uses pgsnapshot tables will almost certainly be slower
> than one that uses the osm2pgsql schema, and likely unsuitable for live
> rendering; but if you only need it for batch processing then that's
> certainly an option.
> Another possibility would be modifying the JXAPI code to work on
> osm2pgsql-style slim mode tables, with the limitations that entails. Thing
> is that the slim mode tables don't normally have geo indexes which would
> have to change then.

We're not targeting a rendering system but OSM web services which
deliver OSM data in geospatial formats (incl. point, linestring and

We're using heavily the hstore option and recently tried the slim mode
(with varying success) because of out-of-memory problems:

osm2pgsql --create --slim --database gisdb --prefix osm --style
/usr/local/share/osm2pgsql/default.style --username ifs
--hstore-all switerland.osm.bz2

I think that the resulting tables could serve both worlds: the spatial
(osm_line,osm_point,osm_polygon,osm_roads,osm_ways) and the osm world
(osm_nodes,osm_rels,osm_ways). But I'm still open to any solutions
based other tools as long as they output e.g. polygons. :->

That's why I thought that by configuring default.style one could
"tweak" the output so that it could serve the JXAPI (perhaps with some
additional views)?

Yours, Stefan

More information about the dev mailing list