Hi, 2011/5/30 Frederik Ramm <frede...@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 polygon). 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 _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
