For me, PostGIS using osm2pgsql import and TileMill did not work both in Mac OS X and Ubuntu. I could not get the geometry to render but the attributes tables works fine.
Hope to see Mapnik working with osm2pgsql imports. Thanks, Noli On 11/9/11, Dane Springmeyer <[email protected]> wrote: > Jaak, > > I just requested you post back the result of explain analyze, but actually I > think this is better as a github issue. > > Can you create an issue at https://github.com/mapnik/mapnik/issues? > Also when you create the issue can you paste the result of: > > select * from geometry_columns; > > Thanks, > > Dane > > > On Nov 8, 2011, at 1:58 PM, Jaak Laineste wrote: > >> Hi, >> I'm trying to run latest Mapnik with planet data. I use converted "OSM >> Mapnik" style XML, imported database with osm2pgsql and installed mod_tile >> and stuff. I tried to use now the latest stuff: PostgreSQL 9.1 with >> PostGIS 2.0 trunk and Mapnik2 (trunk, seems to be rev 3379). I use Amazon >> medium server for it (it has worked fine before for me). The issue is that >> the rendering does not start, and it seems to be suck forever (I mean for >> days) to following query: >> >> SELECT ST_SRID("way") AS srid FROM >> >> (select >> way,aeroway,amenity,landuse,leisure,man_made,military,"natural",power,tourism,name,highway, >> >> case when religion in ('christian','jewish') then religion else >> 'INT-generic'::text end as religion >> from planet_osm_polygon >> >> where landuse is not null >> >> or leisure is not null >> >> or aeroway in ('apron','aerodrome') >> >> or amenity in >> ('parking','university','college','school','hospital','kindergarten','grave_yard') >> or military in ('barracks','danger_area') >> >> or "natural" in >> ('field','beach','desert','heath','mud','wood','sand','scrub') >> >> or power in ('station','sub_station','generator') >> >> or tourism in >> ('attraction','camp_site','caravan_site','picnic_site','zoo') >> >> or highway in ('services','rest_area') >> >> order by z_order,way_area desc >> >> ) as leisure >> >> WHERE "way" IS NOT NULL LIMIT 1; >> >> It does not surprise that the inner query, without bounding box limit, no >> indexes to each column and applied to OSM planet, creates full scan and is >> slow. So my question is: why it makes this kind of queries, can it be >> avoided somehow? >> >> Jaak >> _______________________________________________ >> Mapnik-users mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/mapnik-users > > _______________________________________________ > Mapnik-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/mapnik-users > _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
