Tag Info

Hot answers tagged

6

Magnus, What are you intending to do with the OSM data once in a postgis table ? Depending on what you intend on doing with the data (Are you looking to do spatial analysis of highways ? Make a map of a complete city including restaurants and other POIs (points of interests) ? ), your osm2pgsql style files will be a little different. First, osm2pgsql's ...


6

I think you must (in addition to other scripts you've run) also run legacy.sql file which you can find next to postgis.sql and spatial_ref_sys.sql on whatever platform you are. This will add function aliases for old names because in Postgis 2.0, all functions have a 'ST_' prefix.. so AsText is now named ST_AsTexT(). Hope this helps!


5

You are not using geodesic functions to calculate the length, which means that for a point there is an error factor of: cos( LATITUDE * pi() / 180 ) If you then multiply the calculated lenght by the error factor you should obtain a value pretty close to the actual trail length. For instance the Old Beechy Rail Trail is close to Melbourne, which has a ...


5

Introduction This will likely require significant amount of manually work to detect and remove the duplicated data. When you're detecting and resolving the duplicate data; you'll want both sources to be in the same geo format: shapefile, PostGIS DBs, or as OSM data. Workflow The following workflow is based on having both sources of data as OSM before ...


5

Replacing st_length with st_transform(way,4326)::geography solves the geodetic distance problem - thanks unicoletti!. Old Beechy Rail Trail | 47.2km Great Southern Rail Trail | 53.5km Ballarat-Skipton Rail Trail | 57.2km High Country Rail Trail | 63.7km East Gippsland Rail Trail | 97.6km ...


5

You will have to create a new one. Nominatim requires a different database scheme than your rendering stack because it needs to perform really different queries. Using the same database for rendering and geocoding would be very inefficient, if possible at all.


4

You have to set up the database in the form osm2pgsql expects it. I have written a detailed Howto here (you might use google to translate): http://wiki.openstreetmap.org/wiki/User:Ajoessen/Postgis


4

You can find the source code of osm2pgsql here: https://github.com/openstreetmap/osm2pgsql/blob/master/reprojection.c and you will find this note in line 67: /* hard-code the source projection to be lat/lon, since OSM XML always * has coordinates in degrees. */ pj_source = pj_init_plus("+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs"); /* ...


4

ST_AsLatLonText documentation says: It is assumed the point is in a lat/lon projection. The X (lon) and Y (lat) coordinates are normalized in the output to the "normal" range (-180 to +180 for lon, -90 to +90 for lat). So you are seeing your point (in 900913) "wrapped" around until it eventually gets into the normal range. To see your ...


4

The difference is in the names: planet_osm_point contains point features from OSM, that is, nodes that have tags on them. Columns in both tables are tags, plus way for geometry. Planet_osm_polygon contains polygons and processed multipolygons (so you don't need to collect multipolygons yourself). So, for example, building contours would be included in ...


4

Your computer should be fine for importing Europe. Given your dataset size and computer, I'd recommend something like this osm2pgsql -c -S /usr/share/osm2pgsql/default.style --slim -d osm-europe --flat-nodes flat-nodes.bin --number-processes 8 -C 20000 europe-latest.osm.pbf I'm assuming that you have an 8 thread CPU, if not, adjust --number-processes. ...


4

I found the solution here: http://postgis.net/docs/UpdateGeometrySRID.html --This will change the srid of the roads table to 3857 from whatever it was before UpdateGeometrySRID(varchar table_name, varchar column_name, integer srid); So for my database the table name was 'planet_osm_line' and the column that contains the srid and geometry is 'way'. the ...


3

Maybe user is reserved keyword. You may try to put username value to semicolons. Something like: psql -d mydb -c "ALTER TABLE geometry_columns OWNER TO \"user\";"


3

I ended not being able to have OpenGeo suite installed. There was a conflict with the libdal packages between OpenGeo suite, and the libgdal packages of postGIS and QGIS.


3

Just done the process for Cambridge. [This is the fastest method] Using PostGIS 2.0 (pgAdmin postgres SQL Tools 1.14) Downloaded the Cambridge OpenStreetMap data from here: http://download.geofabrik.de/osm/europe/great_britain/england/ selected Cambridge note the cambridgeshire.shp.zip 01-May-2012 06:08 11M ESRI Shapefile (EPSG:4326), zipped Loaded ...


3

The file seems to have moved. Have a look here: https://raw.github.com/openstreetmap/osm2pgsql/master/default.style


3

I had the same problem, and here is how I solved it: The problem lies in PolygonBuilder.cpp within the libgeos library. The line causing the problem has actually been fixed already, but the fix is not in the current ubuntu/debian repository that is installed via apt-get. Details of the change can be found here. I downloaded the libgeos from github and ...


3

I imported a Planet File on a 24Gb Machine (Ubuntu Trusty) with the following .. bzcat planet-latest.osm.bz2 | osm2pgsql --verbose -U YourUser --flat-nodes flat-nodes --keep-coastlines --cache 24000 --hstore --hstore-add-index --tablespace-index pg_default --exclude-invalid-polygon --number-processes 6 --unlogged --cache-strategy dense --extra-attributes ...


3

I just found a solution. There is also an active psycop2 connection. When I commit it or close the connection before osm2pgsql runs and open it afterwards again it works. Probably osm2pgsql can't access to the database if this connection is open.


3

I ran into the same problem and I ended up using adopted way_area size clauses. By default they seemed to be too small for me. So when zooming out it would fetch so many very small polygons that that was too much data to transfer. So basically you don't display too small polygons when being zoomed out. You have to try and error until you have the best ...


3

One way of doing this, is to use a window function and partition by geometry, so that each repeated geometry gets an id: 1, 2, 3, etc (or 1, 2) in your case, and then you just select from the table where the id = 1, to get a unique set of values (attributes and geometry) back, eg, WITH unique_geoms (id, geom) as (SELECT row_number() OVER (PARTITION BY ...


2

are you mentioning about nodes, ways and rels tables. osm2pgsql should be used with many options avalaible. You can find them when you type --help command. Like the one example here: osm2pgsql -U postgres -d postgis -S "C:\Program Files\HOTOSM\share\default.style" -k -l -v -c -s -m -E "C:\Program Files\HOTOSM\share\900913.sql" "C:\path\map.osm" This ...


2

Use only the -l parameter and drop -m in your command. From the osm2pgsql help: -l|--latlong Store data in degrees of latitude & longitude. -m|--merc Store data in proper spherical mercator (default)


2

An edge contains a source and target, which describes your route-able network. For Dijkstra algorithm this is sufficient. A-Star and Shooting Star algorithm have a heuristic component and make use of the geometry of source and target (x1,y1 and x2,y2). Source and target coordinates are pre-calculated for better performance. The geometry (ie. ...


2

I ended up using imposm due to crashes with osm2pgsql. There's a pretty good step by step guide here for importing an osm data set. Hope this helps out


2

planet_osm_roads contains only ways that are used for rendering low zoom levels, such as motorsways, rivers, etc. It does not contain details like residential roads, streams and various other features normally rendered only at high zoom. The default c-based definitions of what to add to the roads table are tagtransform.c If you want to customize this, ...


2

planet_osm_line: contains all imported ways planet_osm_point: contains all imported nodes with tags planet_osm_polygon: contains all imported polygons. Relations seem to be resolved for that. planet_osm_roads: contains a subset of planet_osm_line suitable for rendering at low zoom levels. planet_osm_line contains too many elements to render on ...


2

I am not aware that you have a converter from Mapnik to Mapserver mapfile styles. You will really need a lot of tools for what you expect. OSM world has his own set of tools because of their DB complexity and storage (XML) I don't recommend to use Shapefile for rendering OSM data. If you need lot of custom styles, the shp don't give you all the attributes ...


2

I switched to imposm http://imposm.org/docs/imposm/latest/ for the same reason and everything worked out great. I was trying to install osm-bright for mapbox https://github.com/mapbox/osm-bright/ as all of the desired styling was present. Hope this helps out.


2

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



Only top voted, non community-wiki answers of a minimum length are eligible