-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Stubbs wrote: | 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 to the data and get the renderers etc to sort it out
You can add option 4 to the wiki if you want, as long as you can propose how the renderers are going to sort it out. :-) Relationships are designed for grouping things together. Doing nothing is really option 2 - Dave Stubbs has proved it's possible to extract the data easily, I'm prepared to write the code to add the relationships if no one else will. I can't see how option 4 could ever be preferable. If a renderer doesn't want to use the relationship, they don't have to. If they need it and it isn't there, we're going to be stuck with double symbols. Robert (Jamie) Munro -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwtmfz+aYVHdncI0RAmxZAKDyiYtcDhrqzFWnxWXDsLjMCI14bACgp1fD O1PWoCBnt5PJctRDPcuV5Po= =w/s+ -----END PGP SIGNATURE----- _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
