[OSM-dev] arbitrariness of relations [was: HEADS UP osmosis pgsql schema users]

Roland Olbricht roland.olbricht at gmx.de
Tue Nov 4 15:58:31 GMT 2008


> > "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




More information about the dev mailing list