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
