Re: [OSM-talk] Parking symbols: YUCK!
Gervase Markham schrieb: > Why wait so long to define best practice? We're just storing up work for > ourselves later. When you map an area, it's just as much effort to use > system A as system B; but if 50% of mappers are using system A and 50% > are using system B, then you've just created a lot of unnecessary work > which could have been reduced by better communication. Thanks Gerv, you made my point - better than I could've done. Guidelines of good practice should be so versatile that they apply to every situation. I'll try to correlate those with "editing conventions and standards" in a way that "Good Practice" is just about a few short and simple statements that define how all this should happen. While the other page contains technical details how to put these guidelines into action. Bye, Sven http://wiki.openstreetmap.org/index.php/Good_practice ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Andy Robinson (blackadder) wrote: > Gervase Markham wrote: >> Sent: 28 February 2008 3:53 PM >> To: talk@openstreetmap.org >> Subject: Re: [OSM-talk] Parking symbols: YUCK! >> >> Andy Robinson (blackadder) wrote: >>> That's the point I'm trying to make really. We need to learn to live with >>> all the potential duplication and less than perfect tag data simply >> because >>> that's what OSM is. >> But surely the point is that we don't have to "learn to live" with >> anything less than perfect, because we can just fix it. _That's_ what >> OSM is. > > I totally agree. In the longer term that's what I would expect. But there is > a potentially long interim that is a dataset that is a made up of all sorts. I have no doubt there will be a lot of data that does not fall into areas that many of us will ever use, but there is a need to prevent unnecessary duplication of information and then work to get around the problems caused by it, when a simple guide line removes any ambiguity on ANY mapping element! >> All Lester is asking for is an unambiguous definition of what best >> practice is, so that people can know what to do and renderers know what >> they _have_ to support. He's not suggesting we send the heavies round to >> the house of anyone who doesn't follow it. > > Also agreed A best practice is a good thing provided its really straight > forward and simple and doesn't become a barrier in itself. There are only three 'guides' in the current best practice. I don't see that is a barrier. But a simple "Don't create new elements when one already exists" is not a problem. If two village elements exist for a location then they need merging? If one is a node and the other an area then obviously the area one is maintained? But there should perhaps be a barrier to creating new nodes where more comprehensive area elements ALREADY exist? >>> Anything otherwise just places restrictions on >>> contributors and potentially turns people away from contributing data. When >>> the world is effectively complete we may be turning our discussions more to >>> making the data set conform somewhat better because that will help users of >>> the data. But we have a very long way to go before we reach that point. >> Why wait so long to define best practice? We're just storing up work for >> ourselves later. When you map an area, it's just as much effort to use >> system A as system B; but if 50% of mappers are using system A and 50% >> are using system B, then you've just created a lot of unnecessary work >> which could have been reduced by better communication. > > We each map in different ways and have a different focus and interests. I > don't think there is one solution to fit all, so easier to work around the > limitations than to try to be too heavy handed. On fine detail then no argument, but we are already getting problems where different factions have their own views and try to force changes based on political views ( i.e. Cyprus ) so on some occasions a heavy handed approach IS needed. Tidying up a few general points of agreement now will remove the need for trying to sort things out later when we have hundreds of thousands of elements across several different ways of working? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Gervase Markham wrote: >Sent: 28 February 2008 3:53 PM >To: talk@openstreetmap.org >Subject: Re: [OSM-talk] Parking symbols: YUCK! > >Andy Robinson (blackadder) wrote: >> That's the point I'm trying to make really. We need to learn to live with >> all the potential duplication and less than perfect tag data simply >because >> that's what OSM is. > >But surely the point is that we don't have to "learn to live" with >anything less than perfect, because we can just fix it. _That's_ what >OSM is. I totally agree. In the longer term that's what I would expect. But there is a potentially long interim that is a dataset that is a made up of all sorts. > >All Lester is asking for is an unambiguous definition of what best >practice is, so that people can know what to do and renderers know what >they _have_ to support. He's not suggesting we send the heavies round to >the house of anyone who doesn't follow it. > Also agreed A best practice is a good thing provided its really straight forward and simple and doesn't become a barrier in itself. >> Anything otherwise just places restrictions on >> contributors and potentially turns people away from contributing data. >When >> the world is effectively complete we may be turning our discussions more >to >> making the data set conform somewhat better because that will help users >of >> the data. But we have a very long way to go before we reach that point. > >Why wait so long to define best practice? We're just storing up work for >ourselves later. When you map an area, it's just as much effort to use >system A as system B; but if 50% of mappers are using system A and 50% >are using system B, then you've just created a lot of unnecessary work >which could have been reduced by better communication. We each map in different ways and have a different focus and interests. I don't think there is one solution to fit all, so easier to work around the limitations than to try to be too heavy handed. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Andy Robinson (blackadder) wrote: > That's the point I'm trying to make really. We need to learn to live with > all the potential duplication and less than perfect tag data simply because > that's what OSM is. But surely the point is that we don't have to "learn to live" with anything less than perfect, because we can just fix it. _That's_ what OSM is. All Lester is asking for is an unambiguous definition of what best practice is, so that people can know what to do and renderers know what they _have_ to support. He's not suggesting we send the heavies round to the house of anyone who doesn't follow it. > Anything otherwise just places restrictions on > contributors and potentially turns people away from contributing data. When > the world is effectively complete we may be turning our discussions more to > making the data set conform somewhat better because that will help users of > the data. But we have a very long way to go before we reach that point. Why wait so long to define best practice? We're just storing up work for ourselves later. When you map an area, it's just as much effort to use system A as system B; but if 50% of mappers are using system A and 50% are using system B, then you've just created a lot of unnecessary work which could have been reduced by better communication. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Wed, Feb 27, 2008 at 4:41 PM, Lester Caine <[EMAIL PROTECTED]> wrote: > > Robert (Jamie) Munro wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Lester Caine wrote: > > | Mark Williams wrote: > > |> -BEGIN PGP SIGNED MESSAGE- > > |> Hash: SHA1 > > |> > > |> Lester Caine wrote: > > |>> J.D. Schmidt wrote: > > |>>> Lester Caine skrev: > > |> [big snip] > > |> > > |>> LOGICALLY - there should never have been a problem created. A POI > > element > > |>> should consist of a single entity which may have additional area > > information. > > |>> Even those tags that are currently only defined as 'node' in many > > cases WILL > > |>> be expanded to include area information at some point. So PLEASE can > > we have > > |>> some sensible method of identifying PAIRS of tags so we can THEN > > decide what > > |>> to do with them !!! > > |>> > > |> Is this not a job for relations? If the pair were related, then we have > > |> no problem? > > | > > | Correct - but how do you identify elements uniquely so you can create the > > | relation? > > > > I'm not quite sure what you mean, but to try to bring this back onto > > topic, if you mean "How do we find amenity=parking nodes that are > > duplicates of areas?" the answer is that we find all the nodes inside > > areas. If there are any that are just outside, we will miss them, whici > > is annoying, but not the end of the world. In order to find them, we can > > use a Simple postGIS query as suggested by Dave Stubbs (which I have > > attempted to reformat a bit): > > > > select p.osm_id > > ~ from planet_osm_point as p, > > ~ planet_osm_polygon as a > > where a.osm_id!=p.osm_id > > ~ and a.osm_id in ( > > ~select a.osm_id from planet_osm_point as p, planet_osm_polygon as a > > ~where a.amenity='parking' > > ~ and p.amenity='parking' > > ~ and a.way && p.way > > ~ and intersects(a.way, p.way) > > ~group by a.osm_id > > ~having count(p.osm_id) > 1 > > ~ ) > > ~ and p.amenity='parking' > > ~ and a.way && p.way > > ~ and intersects(a.way,p.way); > > This will only work for the specific case where there is a single matching > node that goes with the area, and I believe it will be time intensive when > processing a large area. I don't believe there is any mechanism to create > a.osm_id = p.osm_id - these will always have different id's? If they HAD > matching id's them there would not be a problem. You're failing to understand the database contents. This query is designed to act on the data output from osm2pgsql. osm2pgsql automatically inserts a node into the database for every parking area (and doesn't check to see if there is one already) with the osm_id of the parking area way. So what this query does is find all the parking areas with more than 1 node (ie: it has non-autogenerated ones), then extracts the nodes which are in those areas and aren't the autogenerated ones (osm_id's are different). Obviously it fails in the unlikely event that a node does actually have the same ID as the area it's contained in but I really don't care about that case. So the query does work. And matches in excess of 5000 nodes. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Wed, Feb 27, 2008 at 4:41 PM, Lester Caine <[EMAIL PROTECTED]> wrote: > > Robert (Jamie) Munro wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Lester Caine wrote: > > | Mark Williams wrote: > > |> -BEGIN PGP SIGNED MESSAGE- > > |> Hash: SHA1 > > |> > > |> Lester Caine wrote: > > |>> J.D. Schmidt wrote: > > |>>> Lester Caine skrev: > > |> [big snip] > > |> > > |>> LOGICALLY - there should never have been a problem created. A POI > > element > > |>> should consist of a single entity which may have additional area > > information. > > |>> Even those tags that are currently only defined as 'node' in many > > cases WILL > > |>> be expanded to include area information at some point. So PLEASE can > > we have > > |>> some sensible method of identifying PAIRS of tags so we can THEN > > decide what > > |>> to do with them !!! > > |>> > > |> Is this not a job for relations? If the pair were related, then we have > > |> no problem? > > | > > | Correct - but how do you identify elements uniquely so you can create the > > | relation? > > > > I'm not quite sure what you mean, but to try to bring this back onto > > topic, if you mean "How do we find amenity=parking nodes that are > > duplicates of areas?" the answer is that we find all the nodes inside > > areas. If there are any that are just outside, we will miss them, whici > > is annoying, but not the end of the world. In order to find them, we can > > use a Simple postGIS query as suggested by Dave Stubbs (which I have > > attempted to reformat a bit): > > > > select p.osm_id > > ~ from planet_osm_point as p, > > ~ planet_osm_polygon as a > > where a.osm_id!=p.osm_id > > ~ and a.osm_id in ( > > ~select a.osm_id from planet_osm_point as p, planet_osm_polygon as a > > ~where a.amenity='parking' > > ~ and p.amenity='parking' > > ~ and a.way && p.way > > ~ and intersects(a.way, p.way) > > ~group by a.osm_id > > ~having count(p.osm_id) > 1 > > ~ ) > > ~ and p.amenity='parking' > > ~ and a.way && p.way > > ~ and intersects(a.way,p.way); > > This will only work for the specific case where there is a single matching > node that goes with the area, and I believe it will be time intensive when > processing a large area. I don't believe there is any mechanism to create > a.osm_id = p.osm_id - these will always have different id's? If they HAD > matching id's them there would not be a problem. > Oh, and it takes about 30 seconds for the entire imported planet. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Robert (Jamie) Munro wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lester Caine wrote: > | Mark Williams wrote: > |> -BEGIN PGP SIGNED MESSAGE- > |> Hash: SHA1 > |> > |> Lester Caine wrote: > |>> J.D. Schmidt wrote: > |>>> Lester Caine skrev: > |> [big snip] > |> > |>> LOGICALLY - there should never have been a problem created. A POI > element > |>> should consist of a single entity which may have additional area > information. > |>> Even those tags that are currently only defined as 'node' in many > cases WILL > |>> be expanded to include area information at some point. So PLEASE can > we have > |>> some sensible method of identifying PAIRS of tags so we can THEN > decide what > |>> to do with them !!! > |>> > |> Is this not a job for relations? If the pair were related, then we have > |> no problem? > | > | Correct - but how do you identify elements uniquely so you can create the > | relation? > > I'm not quite sure what you mean, but to try to bring this back onto > topic, if you mean "How do we find amenity=parking nodes that are > duplicates of areas?" the answer is that we find all the nodes inside > areas. If there are any that are just outside, we will miss them, whici > is annoying, but not the end of the world. In order to find them, we can > use a Simple postGIS query as suggested by Dave Stubbs (which I have > attempted to reformat a bit): > > select p.osm_id > ~ from planet_osm_point as p, > ~ planet_osm_polygon as a > where a.osm_id!=p.osm_id > ~ and a.osm_id in ( > ~select a.osm_id from planet_osm_point as p, planet_osm_polygon as a > ~where a.amenity='parking' > ~ and p.amenity='parking' > ~ and a.way && p.way > ~ and intersects(a.way, p.way) > ~group by a.osm_id > ~having count(p.osm_id) > 1 > ~ ) > ~ and p.amenity='parking' > ~ and a.way && p.way > ~ and intersects(a.way,p.way); This will only work for the specific case where there is a single matching node that goes with the area, and I believe it will be time intensive when processing a large area. I don't believe there is any mechanism to create a.osm_id = p.osm_id - these will always have different id's? If they HAD matching id's them there would not be a problem. See proposed good practice ideas for fast consistent solution. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lester Caine wrote: | Mark Williams wrote: |> -BEGIN PGP SIGNED MESSAGE- |> Hash: SHA1 |> |> Lester Caine wrote: |>> J.D. Schmidt wrote: |>>> Lester Caine skrev: |> [big snip] |> |>> LOGICALLY - there should never have been a problem created. A POI element |>> should consist of a single entity which may have additional area information. |>> Even those tags that are currently only defined as 'node' in many cases WILL |>> be expanded to include area information at some point. So PLEASE can we have |>> some sensible method of identifying PAIRS of tags so we can THEN decide what |>> to do with them !!! |>> |> Is this not a job for relations? If the pair were related, then we have |> no problem? | | Correct - but how do you identify elements uniquely so you can create the | relation? I'm not quite sure what you mean, but to try to bring this back onto topic, if you mean "How do we find amenity=parking nodes that are duplicates of areas?" the answer is that we find all the nodes inside areas. If there are any that are just outside, we will miss them, whici is annoying, but not the end of the world. In order to find them, we can use a Simple postGIS query as suggested by Dave Stubbs (which I have attempted to reformat a bit): select p.osm_id ~ from planet_osm_point as p, ~ planet_osm_polygon as a where a.osm_id!=p.osm_id ~ and a.osm_id in ( ~select a.osm_id from planet_osm_point as p, planet_osm_polygon as a ~where a.amenity='parking' ~ and p.amenity='parking' ~ and a.way && p.way ~ and intersects(a.way, p.way) ~group by a.osm_id ~having count(p.osm_id) > 1 ~ ) ~ and p.amenity='parking' ~ and a.way && p.way ~ and intersects(a.way,p.way); Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxF6/z+aYVHdncI0RAh6PAKCtfn/vsqSso7HUrD/3csG2prh5WACeMmZn Y8CEJCVGmItUyvNr7qx0azw= =srxW -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lester Caine wrote: > Mark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Lester Caine wrote: >>> J.D. Schmidt wrote: Lester Caine skrev: >> [big snip] >> >>> LOGICALLY - there should never have been a problem created. A POI element >>> should consist of a single entity which may have additional area >>> information. >>> Even those tags that are currently only defined as 'node' in many cases >>> WILL >>> be expanded to include area information at some point. So PLEASE can we >>> have >>> some sensible method of identifying PAIRS of tags so we can THEN decide >>> what >>> to do with them !!! >>> >> Is this not a job for relations? If the pair were related, then we have >> no problem? > > Correct - but how do you identify elements uniquely so you can create the > relation? > I would assume a) manually or b) As per the prior discussion on generating the Mapnik duplicate points & eliminating clashes, by algorithm. Manually would give better data, but I have a lot of parking marked up by me - and it seems I'm not alone :) - so perhaps (b) should be done as a one-off, after a consensus has been gained? A bit of manual clean-up after a mass conversion would be OK, and as it's a relation it's not adding new nodes where there's only an area, nor vice-versa, and it lets any interested renderers do it properly. It wouldn't do anything nasty with the underlying data that I can see. I see I'm not the only one to suggest it... Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHxFnRJfMmcSPNh94RAishAJ0VwGm2EDqng66Za1mRhnxgQ9XfWQCffjJC 6Bhf5s99t7wqYo0/QStvw2I= =1r0F -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Mark Williams wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lester Caine wrote: >> J.D. Schmidt wrote: >>> Lester Caine skrev: > > [big snip] > >> LOGICALLY - there should never have been a problem created. A POI element >> should consist of a single entity which may have additional area >> information. >> Even those tags that are currently only defined as 'node' in many cases WILL >> be expanded to include area information at some point. So PLEASE can we have >> some sensible method of identifying PAIRS of tags so we can THEN decide what >> to do with them !!! >> > > Is this not a job for relations? If the pair were related, then we have > no problem? Correct - but how do you identify elements uniquely so you can create the relation? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 26/02/2008 16:53, Lester Caine wrote:
> This is exactly where agreement on just which tags mean what is essential. If
> we are looking for all schools in a town we want a list of single entries! We
> don't want to be guessing if two entries with similar names are actually the
> same school :( Or if a town has 10 or 20 schools based on the returned data.
That wouldn't apply to the ones I've done because the name is only on
the node.
And as others have pointed out, anarchy rules in OSM: just because you
prefer to map one way doesn't mean I have to. We only do things at least
moderately alike because the renderers set certain rules implicitly that
we follow if we want the pleasure of seeing our work as an end result.
Map_features may be an attempt at some rules, but in practice it is
Artem and 80n and others who get people to follow the rules by what they
do in the renderings.
But in any case, you're always going to duplicate names of things: for
example when two or more adjacent buildings make up the same
institution, or most commonly, many highways are split into multiple
ways, each with the name.
You can cull a lot of these highways if you're clever because they are
joined, but sometimes even they are disjoint, and in any case for a long
road you don't necessarily want to identify it purely by a single
location ("M11, Cambridge" gives a different result in name finder to
"M11, Bishop's Stortford" even though it is the same road, but equally
it doesn't give 20 similar results for "Hills Road, Cambridge" just
because the road goes across some bridges and has some side spurs).
You could argue that disjoint references to the same thing should be
linked with relations (when there is a good reason to jkeep them
separate) would be solved by linking, but this is such a big job - would
need to be applied to many, many highways and is hard to automate; and
it makes editing an order of magnitude more complicated.
David
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
David Earl wrote: > On 26/02/2008 15:43, David Earl wrote: >> On 26/02/2008 14:45, Robert (Jamie) Munro wrote: >>> Lester Caine wrote: >>> | ANY POI that is changed from node to area will potentially have the same >>> | problem, and we should be fixing the general rule not starting to build >>> | another set of pages for voting on every POI node/area conflict debate? >> I strongly disagree with doing this generally, and will get very upset >> if you start deleting my carefully surveyed school nodes for example. >> The positions where I've put of these is significant within quite >> extensive school grounds. > > I should say, I'd have no strong objection in this case to changing > these amenity=school nodes to building=school NODES, but that's a very > different prospect from deleting them. This is exactly where agreement on just which tags mean what is essential. If we are looking for all schools in a town we want a list of single entries! We don't want to be guessing if two entries with similar names are actually the same school :( Or if a town has 10 or 20 schools based on the returned data. > Ideally I'd have building=school areas, but it is rarely possible to get > the shapes on the ground, and Yahoo satellite imagery is a luxury > reserved for particular urban areas (someone has carefully done this for > the Cambridge colleges, which looks great). And as far as I can see data wise we get a list of collages with single entries for each. But starting from a single node POI and then changing to an area is a logical progression. If the original node is supplying some information missing from the area then THAT needs to be addressed, but if the new area is just enhancing the information, loosing the node should not be a problem? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 26/02/2008 14:45, Robert (Jamie) Munro wrote: > Lester Caine wrote: > | ANY POI that is changed from node to area will potentially have the same > | problem, and we should be fixing the general rule not starting to build > | another set of pages for voting on every POI node/area conflict debate? I strongly disagree with doing this generally, and will get very upset if you start deleting my carefully surveyed school nodes for example. The positions where I've put of these is significant within quite extensive school grounds. And secondly, I see no reason to change anything until it causes a problem. The Parking nodes are an issue now because of the rendering. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 26/02/2008 15:43, David Earl wrote: > On 26/02/2008 14:45, Robert (Jamie) Munro wrote: >> Lester Caine wrote: >> | ANY POI that is changed from node to area will potentially have the same >> | problem, and we should be fixing the general rule not starting to build >> | another set of pages for voting on every POI node/area conflict debate? > > I strongly disagree with doing this generally, and will get very upset > if you start deleting my carefully surveyed school nodes for example. > The positions where I've put of these is significant within quite > extensive school grounds. I should say, I'd have no strong objection in this case to changing these amenity=school nodes to building=school NODES, but that's a very different prospect from deleting them. Ideally I'd have building=school areas, but it is rarely possible to get the shapes on the ground, and Yahoo satellite imagery is a luxury reserved for particular urban areas (someone has carefully done this for the Cambridge colleges, which looks great). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lester Caine wrote: | Robert (Jamie) Munro wrote: | |> On that list, my vote would be, in order of preference, 1,3,2 |> |> I've made a wiki page to collect votes, if people think that's a good idea. |> |> http://wiki.openstreetmap.org/index.php/Car_park | | Robert you are missing the whole point here. | | While the access=public applies to car parks - this would be preserved by the | general rule of copying the node tags to the area. | ANY POI that is changed from node to area will potentially have the same | problem, and we should be fixing the general rule not starting to build | another set of pages for voting on every POI node/area conflict debate? I don't want people to say "Well, delete the ones for car park, but nodes for shopping centre should be something else". We'll deal with shopping centres or whatever else there is on the horizon later, and we will be able to refer back to the car park vote as a strong precedent. I was just trying to stop this stupid thread going around and around getting nowhere, and get the car park situation fixed by means of a vote ASAP. We could then use it as a precedent when it comes to other cases. Maybe I should have made the vote general, I probably should have used a better wikiname than Car_Park, but I didn't - I was in a hurry :-) Robert (Jamie) Munro Ps. Please can someone who thinks we shouldn't delete them please go and vote. It's looking rather one-sided at the moment. http://wiki.openstreetmap.org/index.php/Car_park Also it would be interesting to see someone elses second choice. Pps. Fröstel: I've rewritten your comment as a 4th vote option and signed you up for it - please can you check you are happy with that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxCYVz+aYVHdncI0RAkJ3AJ9qUoz/z4iw9BBYJKdOlA1DGY9jSQCfXtns rBv//v2eILXWCRvlirBI8Ro= =mYga -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine wrote: >Sent: 26 February 2008 9:10 AM >To: OSM Talk >Subject: Re: [OSM-talk] Parking symbols: YUCK! > >Andy Robinson (blackadder) wrote: >>> While the access=public applies to car parks - this would be preserved >by >>> the >>> general rule of copying the node tags to the area. >>> ANY POI that is changed from node to area will potentially have the same >>> problem, and we should be fixing the general rule not starting to build >>> another set of pages for voting on every POI node/area conflict debate? >> >> Both nodes and areas carrying the same data in OSM are perfectly valid >just >> as a unified approach is perfectly valid if the object is drawn as an >area. >> The point is that anything in OSM is allowable and there will be no rule >> enforcement so spending hours debating possible rule ideas is all a waste >of >> effort. > >And a simple definition of good practice will remove the need for any >discussion when we start getting similar conflicts with church icons, or >any >other POI. > >> Now that doesn't mean to say we shouldn't put ideas up on good practice, >> that's perfectly valid. But don't expect everyone to adhere to it. > >And good practice is not to create duplicate references to a single POI. It >may be appropriate to have SEVERAL POI's that are linked to the one >physical >location, and currently there is no agreement on how that should be >handled, >but there should be some agreement on how we handle the case where >duplicates >exist? > >> What we do know is that the renderers will get smatter with time and the >> dataset will become richer. Whether we like it or not, many objects may >have >> a degree of duplication whatever guidance is given. > >Accidental duplication perhaps - and that can be corrected just as *IS* >necessary currently if a node and area give conflicting information. But >the >main problem seems to be the insistence that we have to look at area >information to resolve these conflicts, and always 'render' something and >fix >the overlaps. The DATA is becoming richer and it does not take much in the >way >of good practice ( Recommendations - Rules ) to ensure that ALL uses of >that >data can be managed without having to resort to additional bodges to >untangle >unnecessary conflicts? >Or perhaps we just have to live with some duplicate results in a search >telling us different things about the same place? > That's the point I'm trying to make really. We need to learn to live with all the potential duplication and less than perfect tag data simply because that's what OSM is. Anything otherwise just places restrictions on contributors and potentially turns people away from contributing data. When the world is effectively complete we may be turning our discussions more to making the data set conform somewhat better because that will help users of the data. But we have a very long way to go before we reach that point. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Andy Robinson (blackadder) wrote: >> While the access=public applies to car parks - this would be preserved by >> the >> general rule of copying the node tags to the area. >> ANY POI that is changed from node to area will potentially have the same >> problem, and we should be fixing the general rule not starting to build >> another set of pages for voting on every POI node/area conflict debate? > > Both nodes and areas carrying the same data in OSM are perfectly valid just > as a unified approach is perfectly valid if the object is drawn as an area. > The point is that anything in OSM is allowable and there will be no rule > enforcement so spending hours debating possible rule ideas is all a waste of > effort. And a simple definition of good practice will remove the need for any discussion when we start getting similar conflicts with church icons, or any other POI. > Now that doesn't mean to say we shouldn't put ideas up on good practice, > that's perfectly valid. But don't expect everyone to adhere to it. And good practice is not to create duplicate references to a single POI. It may be appropriate to have SEVERAL POI's that are linked to the one physical location, and currently there is no agreement on how that should be handled, but there should be some agreement on how we handle the case where duplicates exist? > What we do know is that the renderers will get smatter with time and the > dataset will become richer. Whether we like it or not, many objects may have > a degree of duplication whatever guidance is given. Accidental duplication perhaps - and that can be corrected just as *IS* necessary currently if a node and area give conflicting information. But the main problem seems to be the insistence that we have to look at area information to resolve these conflicts, and always 'render' something and fix the overlaps. The DATA is becoming richer and it does not take much in the way of good practice ( Recommendations - Rules ) to ensure that ALL uses of that data can be managed without having to resort to additional bodges to untangle unnecessary conflicts? Or perhaps we just have to live with some duplicate results in a search telling us different things about the same place? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine wrote: >Sent: 26 February 2008 8:12 AM >To: OSM Talk >Subject: Re: [OSM-talk] Parking symbols: YUCK! > >Robert (Jamie) Munro wrote: > >> On that list, my vote would be, in order of preference, 1,3,2 >> >> I've made a wiki page to collect votes, if people think that's a good >idea. >> >> http://wiki.openstreetmap.org/index.php/Car_park > >Robert you are missing the whole point here. > >While the access=public applies to car parks - this would be preserved by >the >general rule of copying the node tags to the area. >ANY POI that is changed from node to area will potentially have the same >problem, and we should be fixing the general rule not starting to build >another set of pages for voting on every POI node/area conflict debate? > Both nodes and areas carrying the same data in OSM are perfectly valid just as a unified approach is perfectly valid if the object is drawn as an area. The point is that anything in OSM is allowable and there will be no rule enforcement so spending hours debating possible rule ideas is all a waste of effort. Now that doesn't mean to say we shouldn't put ideas up on good practice, that's perfectly valid. But don't expect everyone to adhere to it. What we do know is that the renderers will get smatter with time and the dataset will become richer. Whether we like it or not, many objects may have a degree of duplication whatever guidance is given. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Robert (Jamie) Munro wrote: > On that list, my vote would be, in order of preference, 1,3,2 > > I've made a wiki page to collect votes, if people think that's a good idea. > > http://wiki.openstreetmap.org/index.php/Car_park Robert you are missing the whole point here. While the access=public applies to car parks - this would be preserved by the general rule of copying the node tags to the area. ANY POI that is changed from node to area will potentially have the same problem, and we should be fixing the general rule not starting to build another set of pages for voting on every POI node/area conflict debate? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Doru-Julian Bugariu wrote: > Robert (Jamie) Munro schrieb: > >> 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. > > Please, please use relations for it and don't delete data entered by > people. Maybe there is a reason why the node is exactly on that position. Since there is nothing to stop people MOVING a node later, that argument fails. The more I think about it, a SIMPLE rule that any uniquely identifiable POI on the ground should only have one set of tags becomes more attractive. As long as information contained within previous copies of that POI, be they nodes or previous instances of the area are maintained, then nothing need be lost. Any tool that ONLY looks at nodes and ignores areas has a problem anyway, since some POI's WILL only be areas? >> 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. > > I think using relations is the right way to solve this problem. And of > course all cases where something can be expressed by a node and an area > at the same time: if there is a display_hint node (or howerver it will > be called in the relation) a renderer can use it directly, else it can > decide itself where to put the icon. THAT was the way I was thinking originally, but in the general rule - since most POI type data can be defined as node or area - then requiring a second node entry for every area is wrong, so providing a fix INCASE an area also has a node is also wrong. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Robert (Jamie) Munro schrieb: 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. Please, please use relations for it and don't delete data entered by people. Maybe there is a reason why the node is exactly on that position. 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. I think using relations is the right way to solve this problem. And of course all cases where something can be expressed by a node and an area at the same time: if there is a display_hint node (or howerver it will be called in the relation) a renderer can use it directly, else it can decide itself where to put the icon. Julian signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-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
Re: [OSM-talk] Parking symbols: YUCK!
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 talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-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 I've made a wiki page to collect votes, if people think that's a good idea. http://wiki.openstreetmap.org/index.php/Car_park Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHws+Az+aYVHdncI0RAi3yAKDiRd9b+E4eoL98IiStYDER/Y9ZoQCg52LT nNIAMwX8fhKXELyek30PIvU= =qZVA -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
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. You can get a list with the following (there's probably a nicer SQL query than this, but this pretty much represents the way I first thought it through, and it seems to work): select p.osm_id from planet_osm_point as p, planet_osm_polygon as a where a.osm_id!=p.osm_id and a.osm_id in (select a.osm_id from planet_osm_point as p, planet_osm_polygon as a where a.amenity='parking' and p.amenity='parking' and a.way && p.way and intersects(a.way, p.way) group by a.osm_id having count(p.osm_id) > 1) and p.amenity='parking' and a.way && p.way and intersects(a.way, p.way); (osm2pgsql creates 1 point for each parking area and gives it the osm_id of the area, so every area has at least 1 point already in the postgis db) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
At 10:19 AM 2/25/2008, graham wrote: >Robert (Jamie) Munro wrote: > > > 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. > > > >If anyone does this, it would be helpful to add access=public to all >parking areas which have a node before deleting the node. I guess that >would be ok for everyone else's too? > >Graham Yes, that would work for me - I followed a suggested convention of only placing a node when it was public. I have probably several hundred scattered throughout the world so it is not practical to manually edit. Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Robert (Jamie) Munro wrote: > 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. > If anyone does this, it would be helpful to add access=public to all parking areas which have a node before deleting the node. I guess that would be ok for everyone else's too? Graham ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: > Again, look at the visualization of the data as a seperate entity - > related to, and an important part of OSM, but not the defining measure > of OSM. > > An example (graphic to fit my reputation ofcourse.. You have been duly > warned ;) ) : > If I decided to map all the trees I have taking a leak up at on the way > home from drinking bouts the last couple of years, I can do so. I'll > just tag it with > v="200 ml used and processed beer"/>. > > I could even tag the same tree multiple times, depending on whether I > took the piss at the north, east, west, or south side of the tree. And I > could even use a different tagname such as > without any problems. > > This points out the wiki-like outlook on our DB. The tag and data has > only mildly interest for anybody else, but it might have real value for > me. I could be the type that tends to loose my keys everytime I take a > leak in toxicated condition, and now I have the possibilty to see where > I have been, and go look for them. Or maybe I'm making a map showing > which trees not to sit under during summer. > > Whatever the reason, it's geodata, and valid to go into the DB or the > 80GB of cryptic XML as you called it. It might be useless for anybody > else, but it wouldn't be to me. AND it could become usefull for someone > else later on (urologists researching maximum distance intoxicated > people can go between leaks, city planners looking for information on > best placement of public restrooms, etc, etc). That would be a statistically very poor sample to base conclusions on, if you would be the only one doing that. If you want others to also start tagging trees that way, you're going to have to find some kind of agreement -> that's where map features comes in... Polyglot ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-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. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHwfo4z+aYVHdncI0RAiLwAKDknPqP+m3PP6okGzOsJl8r4g5LnwCg+iZv CZ/eiOlZbSRqpDOW0QDId4A= =hEE3 -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
David Earl <[EMAIL PROTECTED]> writes: > I see that someone has gone ahead and put automatic parking symbols at > the middle of amenity=parking areas in osmarender. This means nearly all > parking is getting two symbols now and it looks AWFUL. (The good news, > though is that the symbol is nearly always close to where I chose to put > a node manually). > > 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. Part of the reason I added areaSymbol to parking areas is that mapnik _does_ render icons on parking areas. After reading some of this thread I see it has a collision detection system which is the reason you haven't seen duplicate icons there (as long as you placed the node close enough to where mapnik placed the automatic one). > And by the way, even if Mapnik does eventually do this, don't be tempted > to remove P nodes automatically, as some of them have names. The names > would need to be transferred to the area, with all the issues of > conflicts that might throw up. If I were working on an area and saw a parking node inside a parking area I'd definitely remove the node, moving tags as needed. If anybody decides to automatically clean up all the data they'll of course have to handle those cases. -- Knut Arne Bjørndal aka Bob Kåre [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
graham <[EMAIL PROTECTED]> writes: > In my case I have mapped many private parking areas (inside schools, > industrial estates, or explicitly marked 'private') as 'parking'. I > really don't want a parking sign to show on them as it makes them look > available to the public, rather than just a use of land. I realise I > should have marked them 'access restricted', but I didn't - and even if > I do now they will still be rendered with a parking sign... Wrong, if you tag them access= they will not get automatic symbols in osmarender. -- Knut Arne Bjørndal aka Bob Kåre [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: > So as I said before, its not the rendering mechanism that should define > what goes into the OSM DB. At the most basic level, if it is geodata, > and can be described within the scope of it IS valid > for inclusion in the OSM database, no matter how "useless" it would > appear to other users. I have no problem with additional useless information, except where it is the sort of mindless vandalism perpetrated by spammers and hackers who should be hounded out of existence. If someone starts adding links to porn sites and other irrelevant crap, then THAT has to be policed, and personally I think that some stuff which has been added in the past was at the edge of that policing! Where there is useful data then there is not a problem! The problem comes when there is no way of managing the interrelations between that data. If I follow the rules - yes they ARE rules - then I can trace all of the churches in Worcestershire. Tabulate their religions and give distance information from Broadway to each of them. Except at present I can't do that because Worcestershire does not exist in the data. So it needs to be added? Perhaps if we had freely available data for the outline we could add an area/boundary for Worcestershire, but at present that information is not available. So we need some other way WHICH WE CAN ALL AGREE ON to identify a county in England. Evesham is a town IN Worcestershire which as several car parks. Again we do not have a boundary for Evesham, but we DO know what car parks are in Evesham. So we identify them as is_in Evesham. These car parks are currently nodes, but the area information is available and could be added. At that point how do I modify things so that I can get a SINGLE list of car parks in Evesham? From what is being said at the moment I simply ignore anybody else and do what *I* want to do for these car parks. Supply them as areas - kill the nodes - and hope that perhaps one of the rendering options will actually display them when I jump to that location on a map that the customer has selected. If people are not prepared to agree a set of basic rules that produce the same results every time then there is little point even bothering to try and fill in the gaps in the current data and we may as well all just do our own thing and sod everyone else! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt schrieb: >> True. >> I don't understand why it's so fashionable on this list to play down the >> importance of "Map features". Without that page all those "80GB of >> cryptic XML would be pretty useless. > > Thats again because you look at the DB and the usage of the data > contained therein as one entity that defines OSM. > > If you on the other hand look at the DB and the data contained therein > as one entity and the USAGE of the data in the DB as a seperate entity, > you get a more correct view of the state of our wonderfull hutsputz of > geodata and geodata usage. I'm not talking about certain uses, I'm talking about encoding and decoding of information using certain keys. That applies to all kind of geodata whether it's stored in a papermap, a database or a GPX-file. We encode the geodata we survey on the street when entering it into the DB and we decode it again when we use it, regardless for what we use it. The data stored in the osm-DB isn't self-explaining when it says . It would be self-explaining if we would tag things like That would make something like map-features obsolete (sure, an extreme example but highway=residential could also be a street where people live on the street, ie. the homeless or a road *leading* to a residential area (since it's a HIGHway)) > But that's nothing bad or something >> we should encounter, that just the nature of any map, whether it's >> stored in a DB or printed on colorful paper. > > We (OSM) do not store a map in a DB. We store geodata. Sorry, I used the wrong term. In my terms a map stores geodata, ie. is geodata. Whether that geodata is in a strict GIS-sheme on a HD or colorful lines on some paper doesn't make a difference in the first place. When I know which tranformation/encoding was used for reality->geodata I can read both. > Again, look at the visualization of the data as a seperate entity - > related to, and an important part of OSM, but not the defining measure > of OSM. I'm trying to. But rendering a map is just another way of bringing the data in a different shape, which still is encoded. Stylesheets are patient, you can draw every highway=primary with red lines. But when you don't know what highway=primary means you aren't any smarter with those red lines. At least here in Germany they are (like most roads) not red but grey-black (because of the tarmac), neither do they have big labels everywhere saying *primary*. Ie. that tag doesn't describe the road, it's explanation on map features does. > An example (graphic to fit my reputation ofcourse.. You have been duly > warned ;) ) : > If I decided to map all the trees I have taking a leak up at on the way > home from drinking bouts the last couple of years, I can do so. I'll > just tag it with > v="200 ml used and processed beer"/>. That's actually pretty close to my example above and pretty far apart form what the DB looks like. Still might someone reading it expect a tree that's urinating because of some disease which also colors it's leaves yellow/brown. Maybe that tree secretes 200ml of beer each day ;-) > This points out the wiki-like outlook on our DB. The tag and data has > only mildly interest for anybody else, but it might have real value for > me. I could be the type that tends to loose my keys everytime I take a > leak in toxicated condition, and now I have the possibilty to see where > I have been, and go look for them. Or maybe I'm making a map showing > which trees not to sit under during summer. Sure, you can use the DB to store whatever geodata you like and I'm fine with it. You can use it just like a scrap of paper on your desk. But that's nothing this community will bother about or what we run a wiki for. That happens because we want to create geodata that's valuable to everybody and not only to the mapper himself. > Whatever the reason, it's geodata, and valid to go into the DB or the > 80GB of cryptic XML as you called it. It might be useless for anybody > else, but it wouldn't be to me. AND it could become usefull for someone > else later on (urologists researching maximum distance intoxicated > people can go between leaks, city planners looking for information on > best placement of public restrooms, etc, etc). But those city planners would have much less scope of interpretation if you described your tag on something like map features. > So as I said before, its not the rendering mechanism that should define > what goes into the OSM DB. At the most basic level, if it is geodata, > and can be described within the scope of it IS valid > for inclusion in the OSM database, no matter how "useless" it would > appear to other users. And that's not what we're doing, describing geodata within that scope. Instead we're using keywords to label things and those keywords are described in map features. > The Mapfeatures page on the wiki is an important part, but only for "the > second entity" - the visualization of the data. Thats why it is called > "MAP feat
Re: [OSM-talk] Parking symbols: YUCK!
Sven Grüner skrev:
> J.D. Schmidt schrieb:
>>> TAGGING as laid out in the wiki are all rules for content but as yet they
>>> do
>>> not provide a consistent USABLE base once one moves away from the basic
>>> road
>>> stuff. And even the base road stuff people are trying to change the rules!
>> Correction: Tagging as laid out in the wiki is NOT rules for content IN
>> THE DB. Let me just repeat that: Tagging as laid out on the wiki in the
>> "Mapfeatures" page is NOT rules governing the content in the DB.
>>
>>
>> They are recommendations, to be used if you'd like to see your content
>> rendered by the current default rendering engines used on the OSM site.
>> Nothing more, nothing less.
>
> True.
> I don't understand why it's so fashionable on this list to play down the
> importance of "Map features". Without that page all those "80GB of
> cryptic XML would be pretty useless.
Thats again because you look at the DB and the usage of the data
contained therein as one entity that defines OSM.
If you on the other hand look at the DB and the data contained therein
as one entity and the USAGE of the data in the DB as a seperate entity,
you get a more correct view of the state of our wonderfull hutsputz of
geodata and geodata usage.
But that's nothing bad or something
> we should encounter, that just the nature of any map, whether it's
> stored in a DB or printed on colorful paper.
We (OSM) do not store a map in a DB. We store geodata.
>
> A map is an abstract description of the landscape, that's what makes it
> different from an aerial or plat. Someone making that description uses
> certain symbols or certain code for certain features. Someone who uses
> that description needs to know what every symbol/code resembles. On a
> paper map that's done by the map keys which tell you whether those blue
> lines are motorways, railways or maybe rivers, for OSM-data "Map
> features" tell you.
>
> Anybody can enter anything into the DB, we can't change that, we don't
> want to change that and we are all aware of that. But when I (and most
> other mappers as well) enter something in the DB I want other people to
> know what it stands for in reality. I could use some crude tags only I
> know, but what's then the point in making it accessible for the whole world.
Again, look at the visualization of the data as a seperate entity -
related to, and an important part of OSM, but not the defining measure
of OSM.
An example (graphic to fit my reputation ofcourse.. You have been duly
warned ;) ) :
If I decided to map all the trees I have taking a leak up at on the way
home from drinking bouts the last couple of years, I can do so. I'll
just tag it with
.
I could even tag the same tree multiple times, depending on whether I
took the piss at the north, east, west, or south side of the tree. And I
could even use a different tagname such as
without any problems.
This points out the wiki-like outlook on our DB. The tag and data has
only mildly interest for anybody else, but it might have real value for
me. I could be the type that tends to loose my keys everytime I take a
leak in toxicated condition, and now I have the possibilty to see where
I have been, and go look for them. Or maybe I'm making a map showing
which trees not to sit under during summer.
Whatever the reason, it's geodata, and valid to go into the DB or the
80GB of cryptic XML as you called it. It might be useless for anybody
else, but it wouldn't be to me. AND it could become usefull for someone
else later on (urologists researching maximum distance intoxicated
people can go between leaks, city planners looking for information on
best placement of public restrooms, etc, etc).
The other entity - visualization of the data in the OSM DB, takes a
subset of the data in the DB, and masssages it into a format that the
rendering mechanism can utilize. I.E. Mapnik imports the OSM data into a
postgres DB according to the rules it needs, and then renders the
imported data from that mapnik specific DB.
Osmarender downloads the data and post-process it into SVG compliant XML
according to the rules it needs, then renders it via Batik/Inkscape.
Kosmos and all the other rendering mechanisms utilizing OSM data at the
moment, does similar things with the extracted OSM data for the areas
the user wants visualized - extract an area from the DB, massage it
(postprocess, import to own formatted DB, etc, etc), then visualize it
from the postprocessed data.
So as I said before, its not the rendering mechanism that should define
what goes into the OSM DB. At the most basic level, if it is geodata,
and can be described within the scope of it IS valid
for inclusion in the OSM database, no matter how "useless" it would
appear to other users.
>
> And things like the cycle map would definitely not exist without some
> kind of explanation of the relevant tage in the wiki. Without this
> translation/documentation ("ncn=xyz means this way is
Re: [OSM-talk] Parking symbols: YUCK!
Andy Allan wrote: > Now I say this as an illustration of what each renderer does - they > make their own decisions as to what to do. I don't even understand why > you want consistency in the outputs - the main osmarender and mapnik > layers are different, and much of it just comes down to cartographic > style. And there is nothing to distinguish between duplicate items contained in the underlying data. RENDERING is not the only use for the data but the problem of duplicate icons highlights the underlying problem - AND IT IS A PROBLEM !!! > As to the specifics of how mapnik works, see osm2pgsql's > "add_parking_node()" at > http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/output-pgsql.c#L362 > for the code to auto-add a parking node. On the main map it has > parking as non-overlapping as per > http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml#L154 > so the duplicate icon issue is "solved" by this overlap avoidance. BUT that only works for 'parking' - add every other node/area duplicate problem! Add situations where there is no overlap avoidance such as actually processing the data someone is going to code each case individually? > And if you think this is particularly onerous for the renderers to > deal with, then you're probably unaware of how much other stuff needs > to be taken care of too! I KNOW the problem of dealing with the CURRENT data - in many cases it is unusable for anything OTHER than rendering and needs the sort of bodge being discussed to sort out the mess. Some people not be bothered by that problem, because they only want a simple map output, but 90% of the tagging information will allow us to search for WHICH area of the map to display. Having in essence to 'render' areas to find out if nodes are contained in them and then guess if a node IS a duplicate is not practical as the size of the DATA grows. I'm looking at some 50 other tags that may have node/area duplicates - personally how they are rendered does not bother me at all - I want to be able to navigate the data and produce CONSISTENT search results - which are then used to DISPLAY the correct area of a map or simply offer alternatives to select from. A very simple fix for this problem is to display everything on the basis that the node IS different to the area. The renderers can worry about icons on top of one another - be they duplicate parking icons or school, public building or whatever. We then TIDY things up by the convention that there is only one entry for a tagged POI and if an existing node is upgraded to an area, then the node information becomes part of the area tags, and the node is deleted. No need for reams of processing and new bodge code for every node/area tag conflict? We then don't have to worry about duplicates - they don't exist. If they do, then one or other needs to be merged to leave a single distinct entry? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt schrieb:
>> TAGGING as laid out in the wiki are all rules for content but as yet they do
>> not provide a consistent USABLE base once one moves away from the basic road
>> stuff. And even the base road stuff people are trying to change the rules!
>
> Correction: Tagging as laid out in the wiki is NOT rules for content IN
> THE DB. Let me just repeat that: Tagging as laid out on the wiki in the
> "Mapfeatures" page is NOT rules governing the content in the DB.
>
>
> They are recommendations, to be used if you'd like to see your content
> rendered by the current default rendering engines used on the OSM site.
> Nothing more, nothing less.
True.
I don't understand why it's so fashionable on this list to play down the
importance of "Map features". Without that page all those 80GB of
cryptic XML would be pretty useless. But that's nothing bad or something
we should encounter, that just the nature of any map, whether it's
stored in a DB or printed on colorful paper.
A map is an abstract description of the landscape, that's what makes it
different from an aerial or plat. Someone making that description uses
certain symbols or certain code for certain features. Someone who uses
that description needs to know what every symbol/code resembles. On a
paper map that's done by the map keys which tell you whether those blue
lines are motorways, railways or maybe rivers, for OSM-data "Map
features" tell you.
Anybody can enter anything into the DB, we can't change that, we don't
want to change that and we are all aware of that. But when I (and most
other mappers as well) enter something in the DB I want other people to
know what it stands for in reality. I could use some crude tags only I
know, but what's then the point in making it accessible for the whole world.
And things like the cycle map would definitely not exist without some
kind of explanation of the relevant tage in the wiki. Without this
translation/documentation ("ncn=xyz means this way is part of a route
that...") there wouldn't be all those tags in the DB. I'm sure Andy
didn't think, well today I'm gonna render abc=xyz, maybe there are some
mappers who describe their cycleroutes just that way.
Without "Map features" OSM is like an undocumented command-line
programm: To be certain about all it's capabilities you'd need to read
every single line of code. And reading planet.osm might take a while...
regards, Sven
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Sun, 2008-02-24 at 09:28 +0100, Christoph Eckert wrote: > not really. When passing a parking lot, I still want to be able to place a > node and tag it accordingly, without the need to make it an area. The area > may be added later, and then the node should be deleted. This is also my opinion on the matter (not that it counts). -- Bruce Cowan <[EMAIL PROTECTED]> ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine skrev: > J.D. Schmidt wrote: >> Lester Caine skrev: >> >>> Do you have to re-write the renderer every time someone comes up with >>> a new conflict? >> Short answer : Yes. >> >> Long answer : The renderer operates on a subset of the data contained in >> the DB. It is up to the operator of the renderer to extract and >> possibly massage that data into a format that the renderer can utilize. >> It is not the place of the renderer to impose limitiations or rules into >> what is in the DB, since the the DB is/might/will be used for other >> tasks than just rendering maps. >> >> This is similar to the previous discussion this month, where someone >> wanted to impose limitations on what charactersets could be used for >> tagnames. > > Should never have been discussed - Unicode has to be used even if there is an > arbitrary limit of English tag names - the content has to be unicode and > mixing that with anything else is simply crass. > >> All together now, repeat this months mantra after me : "Implementing >> non-DB technical limitations and rules for content in the DB is bad, >> recommendations and smarter algorithms in renderers are good." > > Bullshit. > TAGGING as laid out in the wiki are all rules for content but as yet they do > not provide a consistent USABLE base once one moves away from the basic road > stuff. And even the base road stuff people are trying to change the rules! Correction: Tagging as laid out in the wiki is NOT rules for content IN THE DB. Let me just repeat that: Tagging as laid out on the wiki in the "Mapfeatures" page is NOT rules governing the content in the DB. They are recommendations, to be used if you'd like to see your content rendered by the current default rendering engines used on the OSM site. Nothing more, nothing less. > > See my other message about the area/node conflict. This problem arises > everywhere that node and area options exist for a tag and there needs to be > AGREEMENT on how the conflict is handled. Some people using different methods > of handling it for different tags is no use to anybody so lets decide ONE way > of handling the conflict and stick to it. Personally I have no particular > feeling anyway, but a logical means if identifying a SINGLE list of parking > places ( for example - but any node/area rag! ) is just common sense. > > This is just a simple case of how do you identify a set of tags UNLESS there > is agreement about how a tag is used. *IF* we are going to allow both node > and > area tags for the same item then we need to ensure that they ARE returning > the > same data but some logical method of ensuring that the node and area returns > a > CONSISTENT set of answers is essential otherwise we have anarchy. There is NO agreement on tags used, and should NOT be any such agreement on tags used, since the DB is more akin to a wiki - if you can describe it within the framework of then it can go into the DB for storage. There IS an agreement on RECOMMENDATIONS of tags to be used IN THE SCOPE of rendering maps with the default rendering engines currently used by OSM. Its then up to the rendering engines to visualize those tags according to whatever rules they use in their visualization attempts. > > LOGICALLY - there should never have been a problem created. A POI element > should consist of a single entity which may have additional area information. > Even those tags that are currently only defined as 'node' in many cases WILL > be expanded to include area information at some point. So PLEASE can we have > some sensible method of identifying PAIRS of tags so we can THEN decide what > to do with them !!! > It's still not a OSM DB problem. It's a problem to be solved by the rendering engines. Imposing non-DB technical limitations and rules to the data put into the DB, in order to please the rendering mechanism is fundamentally wrong. Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Sun, 2008-02-24 at 12:19 +, 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
Re: [OSM-talk] Parking symbols: YUCK!
On Sun, Feb 24, 2008 at 12:35 PM, Lester Caine <[EMAIL PROTECTED]> wrote: > Richard Fairhurst wrote: > > Lester Caine wrote: > > > >> We need ONE set of rendering rules that will produce consistent > >> results > > > > No we don't - that's half the point of OSM. If we had ONE set of > > rendering RULES then we wouldn't have a CYCLE map. > > I'm not talking about STYLE - I'm talking base data! > > ANY map can display what it wants, how it wants, but they will all have the > same problem where there are conflicts between area and node data. NOTHING > precludes rendering what ever we want, but how does the cycle map solve this > conflict? However I see fit. It's my map, and I can quite literally do whatever I want. I take the data from the database, do some "magic", and out comes a map. If I choose to do things differently than whatever osmarender or the main mapnik map does, then so bit it. I might render just parking areas. I might put in some nodes. I might do both, or do neither. Now I say this as an illustration of what each renderer does - they make their own decisions as to what to do. I don't even understand why you want consistency in the outputs - the main osmarender and mapnik layers are different, and much of it just comes down to cartographic style. As to the specifics of how mapnik works, see osm2pgsql's "add_parking_node()" at http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/output-pgsql.c#L362 for the code to auto-add a parking node. On the main map it has parking as non-overlapping as per http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml#L154 so the duplicate icon issue is "solved" by this overlap avoidance. And if you think this is particularly onerous for the renderers to deal with, then you're probably unaware of how much other stuff needs to be taken care of too! Cheers, Andy > Just ignore 'parking' and this particular problem goes away, but if > someone decides parking needs to be on the cycle map which area/node data > should it work with? Do you have to re-write the renderer every time someone > comes up with a new conflict? > > > -- > Lester Caine - G8HFL > - > Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact > L.S.Caine Electronic Services - http://home.lsces.co.uk > MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ > Firebird - http://www.firebirdsql.org/index.php > > ___ > > > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: > Lester Caine skrev: > >> Do you have to re-write the renderer every time someone comes up with >> a new conflict? > > Short answer : Yes. > > Long answer : The renderer operates on a subset of the data contained in > the DB. It is up to the operator of the renderer to extract and > possibly massage that data into a format that the renderer can utilize. > It is not the place of the renderer to impose limitiations or rules into > what is in the DB, since the the DB is/might/will be used for other > tasks than just rendering maps. > > This is similar to the previous discussion this month, where someone > wanted to impose limitations on what charactersets could be used for > tagnames. Should never have been discussed - Unicode has to be used even if there is an arbitrary limit of English tag names - the content has to be unicode and mixing that with anything else is simply crass. > All together now, repeat this months mantra after me : "Implementing > non-DB technical limitations and rules for content in the DB is bad, > recommendations and smarter algorithms in renderers are good." Bullshit. TAGGING as laid out in the wiki are all rules for content but as yet they do not provide a consistent USABLE base once one moves away from the basic road stuff. And even the base road stuff people are trying to change the rules! See my other message about the area/node conflict. This problem arises everywhere that node and area options exist for a tag and there needs to be AGREEMENT on how the conflict is handled. Some people using different methods of handling it for different tags is no use to anybody so lets decide ONE way of handling the conflict and stick to it. Personally I have no particular feeling anyway, but a logical means if identifying a SINGLE list of parking places ( for example - but any node/area rag! ) is just common sense. This is just a simple case of how do you identify a set of tags UNLESS there is agreement about how a tag is used. *IF* we are going to allow both node and area tags for the same item then we need to ensure that they ARE returning the same data but some logical method of ensuring that the node and area returns a CONSISTENT set of answers is essential otherwise we have anarchy. LOGICALLY - there should never have been a problem created. A POI element should consist of a single entity which may have additional area information. Even those tags that are currently only defined as 'node' in many cases WILL be expanded to include area information at some point. So PLEASE can we have some sensible method of identifying PAIRS of tags so we can THEN decide what to do with them !!! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine skrev: >Do you have to re-write the renderer every time someone > comes up with a new conflict? > Short answer : Yes. Long answer : The renderer operates on a subset of the data contained in the DB. It is up to the operator of the renderer to extract and possibly massage that data into a format that the renderer can utilize. It is not the place of the renderer to impose limitiations or rules into what is in the DB, since the the DB is/might/will be used for other tasks than just rendering maps. This is similar to the previous discussion this month, where someone wanted to impose limitations on what charactersets could be used for tagnames. All together now, repeat this months mantra after me : "Implementing non-DB technical limitations and rules for content in the DB is bad, recommendations and smarter algorithms in renderers are good." Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Richard Fairhurst wrote: > Lester Caine wrote: > >> We need ONE set of rendering rules that will produce consistent >> results > > No we don't - that's half the point of OSM. If we had ONE set of > rendering RULES then we wouldn't have a CYCLE map. I'm not talking about STYLE - I'm talking base data! ANY map can display what it wants, how it wants, but they will all have the same problem where there are conflicts between area and node data. NOTHING precludes rendering what ever we want, but how does the cycle map solve this conflict? Just ignore 'parking' and this particular problem goes away, but if someone decides parking needs to be on the cycle map which area/node data should it work with? Do you have to re-write the renderer every time someone comes up with a new conflict? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
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. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine wrote: > We need ONE set of rendering rules that will produce consistent > results No we don't - that's half the point of OSM. If we had ONE set of rendering RULES then we wouldn't have a CYCLE map. CHEERS Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Christoph Eckert wrote: >> Maybe that person is using the data >> from the DB to keep a POI record of parking lots. > > I do POIs and my tool currently only can do nodes. If parking lots are > replaced by areas, I need to fix my tool. This is the point I am at as well! We need to be consistent in the way POI's, what ever they are, are identified, and a node is currently easier to tabulate than an area. So perhaps we REQUIRE a node attached to every area which has the tag information. Ignoring the rendering inconsistencies and just looking at the raw data, how do we produce a list of 'parking lots' or any other area/node defined data. In order to fix POI type tools we end up having to process graphical data when a simple set of rules could remove the problem? I keep coming back to the is_in problem and this is just another example of it. WHEN an area is created and the original node is_in it then an automatic is_in with a unique identifier could be created which flags that there is an area that superceds the node. We can then simply read the data and when we find nodes with area is_in tags we can simply ignore them if appropriate leaving just the area POI tags. PERSONALLY I would like to be able to process the raw data without having to ALSO carry out complex area checks every time I find an 'area'. If we need to maintain matching nodes to go with that area, then there should be some flagging to at least indicate that there is an alternative. David's 'parking:redundant' could better be tagged 'parking:see_area' although I will keep hammering the simple concept of a unique is_in identifier so we get 'parking:is_in:'. A concept that will tidy ALL of the area/data information tree. I know this is not liked by the XML purists, but being able to jump directly to related data will always speed up data mapping? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: > Lester Caine skrev: >> >> Again - the fact that people are giving time to enter data is >> precisely why we need to be producing a guide to how to do things that >> is consistent. If people are going to tidy up these 'couple of >> problems' then we don't want one person deleting a node and another >> adding it back because they are looking at different views of the same >> data :( >> *ALSO* we also don't need people wasting time making the renderers >> play silly tricks to make things look right. Lets just be consistent >> in how things are handled. What ever the inconsistency! > > You need to look at it differently. From the view you are putting forth > above, you seem to equalize the rendered output in the form of Mapnik > and Osmarender maps to Openstreetmap. And I can see why, since those two > items produce the currently most visible part of OSM. > > BUT remember, the DB is one thing, the rendering of data from the db is > another thing altogether. Look at the db as a big sea of data, where it > is your (the rendering engine) task to harvest the data that you want to > render. Not to impose rules and limitations on what form the data in the > DB is entered in. > > IMHO one of the reasons why OSM has gained such "notoriety" and > following among neogeographers, established carthographers, and > joe-public alike, is the fact that it is not a mapproducing framework > bound by strict and defined ISO-like rules, but a framework that is more > akin to social networking for the map-inflicted. > > If the two rendering engines used currently differ in the way they > render said data, then its the rendering rules used in those engines > that need to be put into sync. Its not done by imposing limitations or > strict rules on what can/should be put into the DB. THAT is all I am saying. EXCEPT that tagging should be consistent, something which does not happen currently. > If one person observed a parking lot, but didn't have time to log the > boundaries of the lot, and just placed a node with the corresponding > tag, then later another person comes along and logs the boundary of the > parking lot, and puts an area out of that data into the DB, he shouldn't > delete the node another person made. Maybe that person is using the data > from the DB to keep a POI record of parking lots. He might be the only > one doing so, but thats still one of the forces of the OSM project - Log > it, tag it, put it into the DB - even if you are the only person ever > going to use that data. We will have to differ there. Although I suspect that we are actually saying the same thing - just differently. There is a lot of tagging that is not rendered. That is fine, and while it would be nice to be consistent, deleting it is a matter of agreement. *IF* the tagging is being done properly, then both parking:area and parking:node should produce the same basic set of tags, so that upgrading a parking:node to a parking:area would retain all of the core information. If we are going to maintain two different sets of parking data nodes and areas then BOTH should be supplied. > 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 see a major processing hit if every time you find an area you then have to process every node inside that area to see if it is ( whether parking, place or any other node/area conflict ) a duplicate of the area data. You then also have to decide if the node or area data takes priority? If one says private and the other public which should take priority. *I* am looking at the data here, and the problems I have with making the same decisions when two conflicting sets of tag information arises! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, > If one person observed a parking lot, but didn't have time to log the > boundaries of the lot, and just placed a node with the corresponding > tag, then later another person comes along and logs the boundary of the > parking lot, and puts an area out of that data into the DB, he shouldn't > delete the node another person made. I'm not sure. Currently I would delete it. Not to please the renderers, but as I see it as redundant data. > Maybe that person is using the data > from the DB to keep a POI record of parking lots. I do POIs and my tool currently only can do nodes. If parking lots are replaced by areas, I need to fix my tool. > He might be the only > one doing so, but thats still one of the forces of the OSM project - Log > it, tag it, put it into the DB - even if you are the only person ever > going to use that data. OSM is wiki style. If someone comes along and refines an area, it may simply happen that the node disappears as soon the area is created. I agree that anyone can put data into the db, but it's not there for eternity but to be modified. And modification also means deletion. > 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. Seconded. Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
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). There's two ways to do it: either (1) we pass over the data (ideally automatically) and check for parking node within parking polygon, delete the node (or maybe just change its tag, to say parking:redundant, so we don't lose anything accidentally), and transfer any name tag to the area, providing there is no clash,. i.e. the area doesn't already have a (different) name or (2) we change osmrender so it only puts the icon in when there isn't already a relevant node. This would require osmarender to (a) maintain some state: keep a list of parking nodes or areas, and (b) to do the artificial icon after all the nodes (in the layer presumably). Can XSLT do this? In both cases, I think a bounding box test would be sufficient rather than a general point in polygon test, but that's a pretty minor detail. (2) has the advantage that the mapper can override a naive rendering algorithm, and copes with the existing data, but I suspect not knowing much about XSLT that this would be rather hard to do, but it does mean the existing "bad practice" (in quotes because not everyone is of that opinion) is propagated. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine skrev: > > Again - the fact that people are giving time to enter data is precisely why > we > need to be producing a guide to how to do things that is consistent. If > people > are going to tidy up these 'couple of problems' then we don't want one person > deleting a node and another adding it back because they are looking at > different views of the same data :( > *ALSO* we also don't need people wasting time making the renderers play silly > tricks to make things look right. Lets just be consistent in how things are > handled. What ever the inconsistency! > You need to look at it differently. From the view you are putting forth above, you seem to equalize the rendered output in the form of Mapnik and Osmarender maps to Openstreetmap. And I can see why, since those two items produce the currently most visible part of OSM. BUT remember, the DB is one thing, the rendering of data from the db is another thing altogether. Look at the db as a big sea of data, where it is your (the rendering engine) task to harvest the data that you want to render. Not to impose rules and limitations on what form the data in the DB is entered in. IMHO one of the reasons why OSM has gained such "notoriety" and following among neogeographers, established carthographers, and joe-public alike, is the fact that it is not a mapproducing framework bound by strict and defined ISO-like rules, but a framework that is more akin to social networking for the map-inflicted. If the two rendering engines used currently differ in the way they render said data, then its the rendering rules used in those engines that need to be put into sync. Its not done by imposing limitations or strict rules on what can/should be put into the DB. If one person observed a parking lot, but didn't have time to log the boundaries of the lot, and just placed a node with the corresponding tag, then later another person comes along and logs the boundary of the parking lot, and puts an area out of that data into the DB, he shouldn't delete the node another person made. Maybe that person is using the data from the DB to keep a POI record of parking lots. He might be the only one doing so, but thats still one of the forces of the OSM project - Log it, tag it, put it into the DB - even if you are the only person ever going to use that data. 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. Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Christoph Eckert wrote: > Hi, > >> We need RULES that are consistent and that everyone follows to produce >> consistent results. > > we have to cope with the fact that this is a volunteer project. People will > always tag differently. IMO it's not a severe problem if there are a couple > of parking lots which are mapped both as an area and a node. We do the same > for several other areas as well, including nodes for places which are > surrounded by a landuse=residential name=foo polygon. Again - the fact that people are giving time to enter data is precisely why we need to be producing a guide to how to do things that is consistent. If people are going to tidy up these 'couple of problems' then we don't want one person deleting a node and another adding it back because they are looking at different views of the same data :( *ALSO* we also don't need people wasting time making the renderers play silly tricks to make things look right. Lets just be consistent in how things are handled. What ever the inconsistency! -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, > We need RULES that are consistent and that everyone follows to produce > consistent results. we have to cope with the fact that this is a volunteer project. People will always tag differently. IMO it's not a severe problem if there are a couple of parking lots which are mapped both as an area and a node. We do the same for several other areas as well, including nodes for places which are surrounded by a landuse=residential name=foo polygon. Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
In message <[EMAIL PROTECTED]> "J.D. Schmidt" <[EMAIL PROTECTED]> wrote: > Tom Hughes skrev: > > >> 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. > > Let me just remind you all, that there are no "rules". There are only > recommendations. When you all come to realize that, you will find that > it is not a question of whether someone has put a node within an area in > the database, but a question of whether the rendering engine in question > can figure out not to render the node if it has the same icon as an > renderengine-placed icon for the area containing that node. I said "I believe". In other words it was my personal opinion of the best way to tag such things. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Christoph Eckert wrote: > Hi, > >> NOW that areas are ( in some cases ) being rendered and annotated >> the additional nodes may well be unnecessary. > > not really. When passing a parking lot, I still want to be able to place a > node and tag it accordingly, without the need to make it an area. The area > may be added later, and then the node should be deleted. EXACTLY my point - You are working THAT recommendation! and even with the new 'recommendation' removing the node may not be the right answer CURRENTLY! Mapnik currently will not render your parking space if you do that? Osmarender is following a different recommendation. Asking the RENDERERS to sort out the mess is wrong - even thought it is the renderers that have created the problem! *IF* the current recommendation is as you have written, then both renders need to follow it. The recommendation makes sense, but currently it is possibly only right for Osmarender :( We need RULES that are consistent and that everyone follows to produce consistent results. At present people are changing the rules as they see fit, without ensuring that everyone else is doing the same. Hence we have different information being displayed, or duplicate information. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, > NOW that areas are ( in some cases ) being rendered and annotated > the additional nodes may well be unnecessary. not really. When passing a parking lot, I still want to be able to place a node and tag it accordingly, without the need to make it an area. The area may be added later, and then the node should be deleted. Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
J.D. Schmidt wrote: > Tom Hughes skrev: >> 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. > > Let me just remind you all, that there are no "rules". There are only > recommendations. When you all come to realize that, you will find that > it is not a question of whether someone has put a node within an area in > the database, but a question of whether the rendering engine in question > can figure out not to render the node if it has the same icon as an > renderengine-placed icon for the area containing that node. The underlying problem is that the 'recommendations' keep changing. A node to allow a 'P' to appear WAS used when there was nothing to produce one otherwise. NOW that areas are ( in some cases ) being rendered and annotated the additional nodes may well be unnecessary. The real problem here is that CHANGES to the recommendations are not being followed through with recommendations to remove the original version. BUT as has been pointed out - the renderers follow their own interpretation of the recommendations, so at present one has to decide WHICH renderer you are adding data for :( *SO* perhaps there should be some RULES that at least provide some consistency in how things are being added. And perhaps in 10 years time someone may get around to considering how areas SHOULD be used? We need ONE set of rendering rules that will produce consistent results and when a rendering engine is NOT following the rules there should be a decision either to add the rule consistently, or remove it. A SWITCH for 'consistent' rendering which can be disabled on local versions were people are not bothered about consistency? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, > > Let's better fix the renderers and data instead of adding ballast. > > But there are *thousands* of these things that need to get fixed in that > case. I agree, but where's the problem? We have "unlimited human resources" :) . Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Tom Hughes skrev: > 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. > > Tom > Let me just remind you all, that there are no "rules". There are only recommendations. When you all come to realize that, you will find that it is not a question of whether someone has put a node within an area in the database, but a question of whether the rendering engine in question can figure out not to render the node if it has the same icon as an renderengine-placed icon for the area containing that node. (If this sounded like the baldheaded "there is no spoon" kid in The Matrix, SteveC will probably save Zion next year... ;)) Dutch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
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. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hey, lets get back to basics here. landuse=parking means exactly that. An area of land used for parking. It makes no statement either way about whether its public or private. Its just a bit of land where cars are parked. IMHO landuse=parking on its own should *not* generate a P symbol. 80n On Sun, Feb 24, 2008 at 12:06 AM, Martijn Verwijmeren <[EMAIL PROTECTED]> wrote: > On Sun, 24 Feb 2008 00:30:52 +0100 > Frederik Ramm <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > Indeed. > > > > > > That's why I think it needs the Mapnik approach in Osmarender, if > > > this detection is indeed what Mapnik is doing. > > > > I think Mapnik has some kind of "collision avoidance" that possibly > > springs in here; it doesn't explicitly recognize that there are two > > symbols meaning the same so one of them is redundant, it just > > recognizes there are two symbols vying for space and only one gets > > through. > > Yes, this is why you often only see one P-icon. > > Around the "Jaarbeurs" in Utrecht you can see several parking lots > where the parking node was placed off-centre. This is from pre-AND > data, so it is quite old. In addition AND didn't know parking areas but > only nodes and they had to be part of a way. So there are a lot of > parking icons there (for four lots). On the dutch tileserver you can see > I cleaned up the icons on the west-side this week. > > > m.v.g., > Cartinus > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On Sun, 24 Feb 2008 00:30:52 +0100 Frederik Ramm <[EMAIL PROTECTED]> wrote: > Hi, > > > Indeed. > > > > That's why I think it needs the Mapnik approach in Osmarender, if > > this detection is indeed what Mapnik is doing. > > I think Mapnik has some kind of "collision avoidance" that possibly > springs in here; it doesn't explicitly recognize that there are two > symbols meaning the same so one of them is redundant, it just > recognizes there are two symbols vying for space and only one gets > through. Yes, this is why you often only see one P-icon. Around the "Jaarbeurs" in Utrecht you can see several parking lots where the parking node was placed off-centre. This is from pre-AND data, so it is quite old. In addition AND didn't know parking areas but only nodes and they had to be part of a way. So there are a lot of parking icons there (for four lots). On the dutch tileserver you can see I cleaned up the icons on the west-side this week. m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
graham schrieb: > In my case I have mapped many private parking areas (inside schools, > industrial estates, or explicitly marked 'private') as 'parking'. I > really don't want a parking sign to show on them as it makes them look > available to the public, rather than just a use of land. I realise I > should have marked them 'access restricted', but I didn't - and even if > I do now they will still be rendered with a parking sign... I've been tagging those as access=private because Mapnik makes use of that for quite a while now. So does osmarender. I'm not native but the translation of amenity doesn't fit on private parking-lots. In other words, some parking feature which isn't open to the public is no amenity to the public. But since our mapping is by default for the public (like most roads) should amenities that are not open to the public always be tagged as such if mapped at all, regardless of what it looks like now in the rederers. regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, > Indeed. > > That's why I think it needs the Mapnik approach in Osmarender, if this > detection is indeed what Mapnik is doing. I think Mapnik has some kind of "collision avoidance" that possibly springs in here; it doesn't explicitly recognize that there are two symbols meaning the same so one of them is redundant, it just recognizes there are two symbols vying for space and only one gets through. I think 80n has implemented something crudely similar in Osmarender that he uses for collision avoidance in lowzoom tile labels (I say crudely because as far as I remember it doesn't actually know how many pixels the elements use and whether they'll clash or not, it just makes sure they are placed at least "n" lat/lon units apart). That mechanism could perhaps be used for symbol collision avoidance, although I have a feeling that it could be expensive in terms of CPU power if you're working with large datasets. > So we have a situation where a non-upward-compatible change has been > introduced without a conversion from the old system to the new one. Come on David, it happens all the time. You should be thankful that we haven't set up a new API over night that's incompatible with yesterday's! Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
In my case I have mapped many private parking areas (inside schools, industrial estates, or explicitly marked 'private') as 'parking'. I really don't want a parking sign to show on them as it makes them look available to the public, rather than just a use of land. I realise I should have marked them 'access restricted', but I didn't - and even if I do now they will still be rendered with a parking sign... Graham ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 23/02/2008 22:04, Sven Grüner wrote: > David Earl schrieb: >> On 23/02/2008 21:29, Andy Robinson wrote: >>> If I create a parking area I really don't want to have to place a node >>> as well so it would be better if the renderer's were clever and >>> ignored any node thats within the area where it has the same tags (eg >>> parking / name). >> Nor do I, but that wasn't the case until this week, so there are many, >> many examples where it has been done manually, that will be a severe >> pain and many hours of work to fix. > > Vice versa. There are also many, many examples of correct tagging > without additional node. But at least that doesn't screw up the output. > Adding some crude osmarender-tag to them will > also take many hours of work. Indeed. That's why I think it needs the Mapnik approach in Osmarender, if this detection is indeed what Mapnik is doing. > But the people who placed nodes inside areas, because they wanted to see > a shiny icon in the map did so in contradiction to the rule not to map > for the renderers. Again, I agree in principle, But that was how most people did parking areas when I started. So we have a situation where a non-upward-compatible change has been introduced without a conversion from the old system to the new one. Being on a high horse about how it *should* have been done doesn't affect that fact that there is a ghastly mess for historical reasons that needs to be cleared up. We could make it upward compatible by doing what Mapnik does, but I suspect that is hard for osmarender. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
David Earl schrieb: > On 23/02/2008 21:29, Andy Robinson wrote: >> If I create a parking area I really don't want to have to place a node >> as well so it would be better if the renderer's were clever and >> ignored any node thats within the area where it has the same tags (eg >> parking / name). > > Nor do I, but that wasn't the case until this week, so there are many, > many examples where it has been done manually, that will be a severe > pain and many hours of work to fix. Vice versa. There are also many, many examples of correct tagging without additional node. Adding some crude osmarender-tag to them will also take many hours of work. But the people who placed nodes inside areas, because they wanted to see a shiny icon in the map did so in contradiction to the rule not to map for the renderers. Or is there anything interesting (in terms of geodata) about some random spot inside a parking-lot? So when these people were willing to spent time in making nice icons appear to get a beautiful map they shouldn't hesitate to make nice icons disappear to get a beautiful map. BUT they could also wait until there's even further improvement of the renderers, as they should have done in the first place. There's improvement everywhere and all the time while your argumentation seems to claim OSM being in some kind of stable branch. There was some hotshot-mapper in this area who tagged cafe's and delis as tourism=attraction just to see them on the map. regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 23/02/2008 21:29, Andy Robinson wrote: > If I create a parking area I really don't want to have to place a node > as well so it would be better if the renderer's were clever and > ignored any node thats within the area where it has the same tags (eg > parking / name). Nor do I, but that wasn't the case until this week, so there are many, many examples where it has been done manually, that will be a severe pain and many hours of work to fix. If the comments about MapNik are right - that is it only puts a node if there isn't one already, that's perfectly OK. But if Osmarender can't do that, there's a serious problem about making a non-upward-compatible change like this. > > The same arguments apply to most areas. I have similar issues with > schools for instance where the school icon is rendered for a node but > not for an area. I have put the school node at the place where the main part of the school is, which is rarely anywhere the centree of extensive school grounds. Same comment applies - if it can be done so that a manual node takes precedence, fine, if not I think it is a retrograde step, and in this case will take even longer to fix. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 23/02/2008 21:20, Christoph Eckert wrote: > Let's better fix the renderers and data instead of adding ballast. But there are *thousands* of these things that need to get fixed in that case. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
David Earl schrieb: > 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. At least in my part of the world Mapnik does that for quite some time now. Osmarender only measured up. But somehow Mapnik seems to sense the additional node an doesn't display two icons. > In the meantime, I think osmarender should only do this if there is a > tag on the area (eg osmarender:symbol=yes). I think differently. I think this is a great feature, always liked it in Mapnik and am glad to see it in Osmarender as well now. We had the discussion before if parking-areas should have icons on their own or only the additional node. As this makes an explicit node obsolete (and does a fine job doing so) I see no reason why to stick to the old arguments. Personally I'd like to see icons on even more areas like soccer or tennis field, townhalls and supermarkets. Actually every feature where the icon is now only rendered on nodes. regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 23/02/2008, David Earl <[EMAIL PROTECTED]> wrote: > I see that someone has gone ahead and put automatic parking symbols at > the middle of amenity=parking areas in osmarender. This means nearly all > parking is getting two symbols now and it looks AWFUL. (The good news, > though is that the symbol is nearly always close to where I chose to put > a node manually). > > 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. > > And by the way, even if Mapnik does eventually do this, don't be tempted > to remove P nodes automatically, as some of them have names. The names > would need to be transferred to the area, with all the issues of > conflicts that might throw up. > > 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. > > In the meantime, I think osmarender should only do this if there is a > tag on the area (eg osmarender:symbol=yes). > If I create a parking area I really don't want to have to place a node as well so it would be better if the renderer's were clever and ignored any node thats within the area where it has the same tags (eg parking / name). If I'm mapping properly and systematically I tend to draw in the parking area but if I'm just noting parking then its a node so at different times both get used and thus both should be rendered appropriately. If I do create an area I then obviously remove the node, transferring ant tags to the area if required. The same arguments apply to most areas. I have similar issues with schools for instance where the school icon is rendered for a node but not for an area. We ought to try and keep consistency. Cheers Andy -- Andy Robinson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Hi, > In the meantime, I think osmarender should only do this if there is a > tag on the area (eg osmarender:symbol=yes). the node is a simplified mapping method when an area is barely mapped. As soon a parking place gets created as an area, the node should get dropped. The doubled symbols appear on many other areas as well (e.g. sport=soccer). We would need to tag *many* areas as "Don't render a symbol on me". Let's better fix the renderers and data instead of adding ballast. Just my two cents, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Parking symbols: YUCK!
I see that someone has gone ahead and put automatic parking symbols at the middle of amenity=parking areas in osmarender. This means nearly all parking is getting two symbols now and it looks AWFUL. (The good news, though is that the symbol is nearly always close to where I chose to put a node manually). 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. And by the way, even if Mapnik does eventually do this, don't be tempted to remove P nodes automatically, as some of them have names. The names would need to be transferred to the area, with all the issues of conflicts that might throw up. 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. In the meantime, I think osmarender should only do this if there is a tag on the area (eg osmarender:symbol=yes). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
