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
