On Sun, 2008-02-24 at 12:19 +0000, Tom Hughes wrote: > In message <[EMAIL PROTECTED]> > David Earl <[EMAIL PROTECTED]> wrote: > > > On 24/02/2008 10:53, J.D. Schmidt wrote: > > > So IMHO it's up to the rendering engines to render the data smartly. > > > It's not the rendering engines that decide what should be put into the DB. > > > > I'm on both sides here: I agree that it would be better not to have both > > a node and an area; OTOH, there's already lots and lots of these, so it > > is shooting ourselves in the foot not to clear up the mess in one way or > > another. > > > > And I'm confused about what Mapnik is actually doing to get this right > > (if indeed it is always getting it right). > > Well mapnik actually fakes up nodes during the import into postgis > in this case, so I guess it is doing something clever to avoid faking > up the node if one already exists - it may well be doing a bbox query > against postgis to see if there is already a node within the area.
Right now it does not do this. As I think Richard mentioned before, the reason you generally do not see the second node is that the rendering collision detection algorithm removes one of the icons. If you go to say zoom 18 then you might see 2 icons, but only on large car parks where the node is not near the centre of the area. I can not find any examples myself. I've been tempted to add the intelligent algorithm you describe into osm2pgsql for a while now but it has yet to reach the top of my todo list. Unfortunately we don't build the spatial indexes on the data until the import is complete so we might have to delay this duplicate detection until the end of the processing (or maybe the points table is small enough to be scanned sequentially without too much of a hit). Jon _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk