[OSM-talk] Wanted: Osm2pgsql.exe developer

[Rahkonen Jukka]

Jon Burgess wrote:

On Fri, 2008-11-14 at 21:08 +0200, Rahkonen Jukka wrote:

>> 2008/11/14 Rahkonen Jukka <Jukka.Rahkonen at mmmtike.fi>:
>> >> This version imports Finland.osm dataset OK.  There are slight differencies in the number of features imported by this and Artem's version:
>> >>
>> >> Old
>> >> points: 24578
>> >> lines: 97223
>> >> polygons: 48305
>>> >>
>> >> New
>> >> points: 23680
>> >> lines: 96889
>> >> polygons: 50316
>> >>
>> >> I will do cross check later by selecting features imported by the old but not with the new and vice versa.
>> >>
>> >> -Jukka-
>> 
>> > I'd guess that its just a change in the osm2pgsql style definition,
>> > which determines which features are interesting, and whether those
>> > features should be treated as polygons or as linestrings.
>> 
>> 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.
- 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.
- 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.

For me it looks like it is safe to use the new osm2pgsql.exe, but only in slim mode.

-Jukka Rahkonen-