On Mon, Feb 25, 2008 at 2:24 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Dave Stubbs wrote: > | On Sun, Feb 24, 2008 at 11:14 PM, Robert (Jamie) Munro > | <[EMAIL PROTECTED]> wrote: > |> -----BEGIN PGP SIGNED MESSAGE----- > |> Hash: SHA1 > |> > |> > |> Tom Hughes wrote: > |> | In message <[EMAIL PROTECTED]> > |> | David Earl <[EMAIL PROTECTED]> wrote: > |> | > |> |> Unfortunately removing the related node isn't going to work, because > |> |> Mapnik won't then render parking symbols. And it is a lot of work > to do > |> |> that. > |> | > |> | I believe it will - as far as I know mapnik has rendered those > |> | symbols for parking areas for some time. > |> | > |> |> Since we have contradictory behaviour in the two renderers we can't > |> |> resolve this automatically unless osmarender can look and see on > the fly > |> |> if there is a P node inside the area it is trying to do one for > |> |> automatically. > |> | > |> | I believe it is fundamentally wrong to add nodes which duplicate > |> | areas, although I know it is quite common. > |> > |> I agree with this wholeheartedly. 1 item on the ground should be 1 item > |> in the database. What no one else has suggested is that if you really > |> need to put something in the DB twice, then at least use a relationship > |> to link the DB objects together. > |> > |> I expect that someone with PostGIS knowledge can construct a query to > |> quickly identify all the parking nodes inside parking areas and produce > |> a list. I'm sure that many of us could write a perl or python script to > |> take this list and delete or relate the nodes. > |> > | > | As of the last planet there are 5881 such nodes. Interestingly there > | are one or two car parks with two or three nodes in them. > | My hugely overcomplicated postgis query could delete these for mapnik > | in about 30 seconds if it was important to do so. > > Can we have a vote on what to do next? > > Options: > 1. Delete the nodes inside areas, make sure the areas are set > access=public and any tagging (e.g. car park name) is copied across. > 2. Add a relationship between car park nodes and the area they are in > and do nothing else. > 3. Add a relationship between car park nodes and the area they are in > and change the tagging of the node somehow. > > On that list, my vote would be, in order of preference, 1,3,2 >
You missed option 4: - do nothing and option 5: - do nothing to the data and get the renderers etc to sort it out they're actually effectively the same option. _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
