Hi Lennard, Thanks for your comments and please find our feedback below if you could.
> > That relation[2] is only one of the many huge natural=wood areas that were > added to Japan, as part of an import. They are all imported as insanely > large multipolygon relations. For instance, that relation 1337942 was > added 23 December 2010. Others might already have been imported before the > data of your local planet or extract. We tried to delete from planet_osm_polygon where osm_id=-1337942; and the deleted record is 0. > What you could try now is find the rules in the stylesheet that relate to > natural=wood, and disable those. Also find the related SQL queries in the > <Layer> and modify them so they're explicitly *not* fetching natural=wood > from the database. You have to be very sure these large objects are not > fetched from the database[3]. In osm.xml, we deleted the natural=wood and deleted wood in SQL and tried again but the speed didn't change. Now we are trying to do check the bottleneck. Regards, -Jin On Feb 7, 2011, at 6:58 PM, Lennard wrote: >> We are struggling for several month for this rendering but still the >> rendering speed is too slow. We followed several comments from community >> but still not getting better. If you have any suggestion or idea from you >> experience, it will help us. > > You didn't mention your datasource, but from previous messages[1], I > assume you're working with OSM data. You said last time you were operating > with OSM data from December 2010. You also said you didn't have the > relation that was pointed out then. > > That relation[2] is only one of the many huge natural=wood areas that were > added to Japan, as part of an import. They are all imported as insanely > large multipolygon relations. For instance, that relation 1337942 was > added 23 December 2010. Others might already have been imported before the > data of your local planet or extract. > > What you could try now is find the rules in the stylesheet that relate to > natural=wood, and disable those. Also find the related SQL queries in the > <Layer> and modify them so they're explicitly *not* fetching natural=wood > from the database. You have to be very sure these large objects are not > fetched from the database[3]. > > Then try rendering. If your rendering is now fast again, this natural=wood > import for Japan is the culprit. If so, try working with the person(s) > that imported the data, and see if you can get them to clean up and > simplify the data. > > [1] https://lists.berlios.de/pipermail/mapnik-users/2011-February/003959.html > [2] http://api.openstreetmap.org/api/0.6/relation/1337942 > [3] Layers involved: "leisure" and "text"/"text-poly" > > -- > Lennard > _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
