> > "obey the consensus on the wiki page" > > That's really, really back to front. If the wiki page and what's in > the database are in disagreement, it's the *wiki page that is wrong*. > Every time, no exceptions.
Maybe that's a misunderstanding. Parts of the data in the database are in disagreement to each other and I'm searching for a useful mechanism to find consensus. For example, let's consider the question "What's the number of this motorway?". Currently, you find the answer coded in the follwing way - the name of onr or more relations containing this motorway - the "ref" tag of the way - the "int_ref" tag of the way - the "nat_ref" tag of the way - some time ago even the "name" tag of the way - sometimes the numbers are written with a space between letter and digit, sometimes without All of these possibilities might be present or not, even several of them contradicting each other. As a road may have more than one number, a contradition could be a mistake or being intentionally. Thus, the following things happen - people convert data from one representation to another, while other people just convert it the other way back - looks a little bit like an edit war - a lot of code in any piece of software processing this data is needed to cope with the different representations and solve arising conflicts On the other hand, if you find a consensus on the representation of the data, you can put effort in - encoding the data in this particular representation - implementing this particular representation properly in all pieces of software In particular, I'm wondering how I should encode the coastline-boundary-12-nm-data. As the upload of a lot of ways over the api will take a lot of time, I would like to avoid doing it twice. Currently, the multipolygon-relation, although rarely used, looks best to me but I'm still unsure. So where do I find the consensus whether this is a good idea or not? I'm grateful for any comments. Cheers, Roland _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
