[OSM-talk] Wanted: Osm2pgsql.exe developer

[Jon Burgess]

On Sat, 2008-11-15 at 13:06 +0200, Rahkonen Jukka wrote:
> Jon Burgess wrote:
> 
> On Fri, 2008-11-14 at 21:08 +0200, Rahkonen Jukka wrote:
> >> I'd say that the new one has problems at least with multipolygon
> >> relations. For example a multipolygon, relation with OSM_ID 4230, is
> >> imported as separate polygons, outer ring having OSM_ID 12298022.
> >> That's probably why the number of polygons is bigger, there are lots
> >> of lakes with holes in the data. I have not yet isolated any line or
> >> point differencies, I am just learning how to query them visible from
> >> PostGIS. I am sorry I can't give lat/lon coordinates now, I have
> >> reprojected the data into Finnish KKJ system in the database.  I will
> >> reproject it to epsg:4326 before next investigations.
> 
> > Did you import the data with --slim? There is a bug in the current code
> > which which breaks multipolygons unless the slim mode is used.
> 
> > I see relation 4230 appearing as a polygon with lots of holes:
> 
> > foo=> select osm_id,name,"natural",NumInteriorRings(way) from planet_osm_polygon where osm_id in (-4230,12298022);
> >  osm_id |   name    | natural | numinteriorrings
> > --------+-----------+---------+------------------
> >   -4230 | Konnivesi | water   |               67
> > (1 row)
> 
> 
> No, I did not use the --slim switch.  As advertised, it is much slower
> to import with slim mode, but it does import polygons with holes
> correctly. Differencies in feature count was now 97223-96970 for lines
> and 48305-48581 for polygons.
> 
> I created difference layers from tables imported with the old
> osm2pgsql.exe and this new one in slim mode.  Query may be stupid, but
> I think that it selects reliably objects imported with the old one
> (named OSM_) which do not have a pair with same OSM_ID in the other
> table (named GOSM_) SQL is like this
> create table diff2 as (select * from (select osm.*, gosm.osm_id as
> goo, gosm.name as gname from osm_polygon osm LEFT JOIN gosm_polygon
> gosm using(osm_id)) as foo where foo.goo is null);
> 
> Some findings:
> - Old program gave positive OSM_IDs for features created from
> relations while the new seems to give them negative values.  Obviously
> the code has been changed in between.  I guess and hope that this
> change makes OSM_ID as unique identifier so it can be used as a
> primary key in the imported PostGIS tables. Until now I have been
> forced to create a new OID field for primary key.

When we create nodes for parking areas the way ID is used to identify
the new node which could cause a clash. We could make this a negative ID
which would help.

I think there is an edge case in the multipolygon support which can
cause multiple linear ways to be created with the same relation ID if
the rings are not closed. 

In short, I don't think we can give any guarantees about the uniqueness
of the osm_id column.

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

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

	Jon