[OSM-talk] Wanted: Osm2pgsql.exe developer

[Jon Burgess]

On Sat, 2008-11-15 at 14:25 +0200, Rahkonen Jukka wrote:
> Jon Burgess wrote:
> 
> On Sat, 2008-11-15 at 13:06 +0200, Rahkonen Jukka wrote:
> 
> > In short, I don't think we can give any guarantees about the uniqueness
> > of the osm_id column.
> 
> Good to know.  I am playing with Finnish and Scandinavian data only and I set keep PostGIS using WITH_OIDS as default and thus I get primary keys automatically.  Not really a problem for me, but those who are playing with more data and perhaps have a remote database without db-admin rights need to create the primary key field themselves.  Primary key is compulsory for many uses.  But knowing the situation helps. 
> 
> >> - There are some features that are not imported at all by the new
> >> version. At least areas with tag shop=supermarket and no other tags
> >> except name (way 4881398). It does not appear on Mapnik map either, so
> >> the program works for me in the similar way than in Mapnik slippy map
> >> production.
> 
> > I don't think the 'shop' tag has ever been included in the list of
> > imported tags. It is definitely not being rendered by the current
> > osm.xml file.
> 
> Right, did not remember that shop wan one of those extra tags that was added to osm2pgsql.exe. It is possible to read map features page so that giving shop=supermarket as an area is supported, but not all shop=something.  Osmarender seems to render it. For on-demand rendering it would be more simple to keep all shops as points and perhaps colour the building according to building=shop or building=commercial or the like. But I have understood that now I can just edit the default.style file for having some own tags, for example max_speed if I'd like to colour highways according to that.

Mapnik does not render everything listed in Map_Features but building=*
will render. The default.style will let you customise this quite easily
which is a nice new feature for the Windows version.

Good luck with max_speed. I believe there are lots of variations in the
way the data has been entered which will probably cause issues.

> >> - Combination highway=[any type], area=yes comes now correctly as
> >> polygon, while they used to be lines. 
> >> - Major part of differencies in number of line features are due to
> >> riverbanks and highways marked with area=yes tag.  They get now
> >> correctly converted into polygons and can be found there.
> 
> > This is one of several new features introduced since the last time the
> > Windows version was built. Another big feature is the support for diff
> > imports.
> 
> >> For me it looks like it is safe to use the new osm2pgsql.exe, but only
> >> in slim mode.
> 
> > Thanks for doing the testing.
> 
> Thanks for compiling.  By the way, the final report is missing now, that used to look like this
> 
> 
> Node stats: total(2658737), max(312060206)
> Way stats: total(175231), max(28408381)
> Relation stats: total(836), max(51578)
>      
> 

I see these in the output when I run the program as below:

$ ./osm2pgsql.exe -W --slim  -U foo -d foo cyprus.osm.bz2
osm2pgsql SVN version 0.55-20081113 $Rev: 10464 $

Password:foo

Using projection SRS 900913 (Spherical Mercator)
Setting up table: planet_osm_point
Setting up table: planet_osm_line
Setting up table: planet_osm_polygon
Setting up table: planet_osm_roads
Mid: pgsql, scale=100, cache=800MB, maxblocks=102401*zd
Setting up table: planet_osm_nodes
*** WARNING: intarray contrib module not installed
*** The resulting database will not be usable for applying diffs.
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_nodes_pkey" for table "planet_osm_nodes"
Setting up table: planet_osm_ways
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_ways_pkey" for table "planet_osm_ways"
Setting up table: planet_osm_rels
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_rels_pkey" for table "planet_osm_rels"

Reading in file: cyprus.osm.bz2
Processing: Node(213k) Way(20k) Relation(0k)
Node stats: total(213472), max(312053827)
Way stats: total(20617), max(28408030)
Relation stats: total(3), max(48708)

Going over pending ways
processing way (1k)

Going over pending relations

node cache: stored: 213472(100.00%), storage efficiency: 2.78%, hit rate: 100.00%


	Jon