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
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
