From the manual:
osm2pgsql relies much on its node cache during import. If the nodes do
not fit into the cache it needs to do database lookups which slow down
the process. Use enough cache so all nodes are cached. -C 12000 seems
to do the job, even if that means you have to configure more swap
space.
Try to use -C 'somethingbig'
See the wiki
If you want to try and build this executable yourself, just clone the github code and check the README file, it states somewhere:
On most Unix-like systems the program can be compiled by
running './autogen.sh && ./configure && make'.
So if you have all the libs/reqs fulfilled you'll be building an executable that works.
To search for points around that location in London, you'd want a query like this
SELECT *
FROM planet_osm_polygon
WHERE ST_Intersects(way, ST_Buffer(ST_Transform(ST_SetSRID(ST_Point(-0.12,51.5),4326), 3857), 500);
This will take the point, transform it into the web mercator projection (EPSG 3857) used by default in osm2pgsql, buffer it by 500 mercator meters, and find points that lie within that polygon.
A more accurate way to do this would be
SELECT *
FROM planet_osm_polygon
WHERE ST_Intersects(way,
ST_Transform(ST_Buffer(
ST_SetSRID(ST_Point(-0.12,51.5),4326)::geography,500)::geometry,
3857)
);
This converts to geography so you can expand the point by 500 true meters.
A third, and probably quickest way, is
SELECT *
FROM planet_osm_polygon
WHERE ST_DWithin(way, ST_Transform(ST_SetSRID(ST_Point(-0.12,51.5),4326), 3857), 500);
Of course in practice you'll have some other WHERE conditions to apply, and be using a more complicated real-world geometry to search against.
Some common mistakes are
- Trying to compare geometries of different projections
- Reprojecting the geometry in the
planet_osm_point
table, preventing index usage
- Mixing up latitude and longitude.
It's worth noting that PostGIS geometries are completely distinct from PostgreSQL geometric types. The appropriate page to see available functions is Chapter 8 of the PostGIS reference.
Best Answer
osm2pgsql
creates the tables and indexes in the user default schema, i.e. the first one found in its search path, which is usuallypublic
. By changing this setting, in PostgreSql, one can load the data to a custom schema. It is important to keep thepublic
schema in the path, as it is required for getting thehstore
type.and you can then launch the osm2pgsql tool with the new user
Alternatively, you could change the search path of the user you are currently using. Make sure to change it back once the data is loaded.