[OSM-dev] disputed areas

Tom Hughes tom at compton.nu
Sun Feb 10 17:13:21 GMT 2008

In message <7679c25f0802100619u7e5f7244yb25f4dc06ca28f75 at mail.gmail.com>
          "Ray Booysen" <raybooysen at rjb.za.net> wrote:

> On Feb 10, 2008 1:08 PM, bvh <bvh-osm at irule.be> wrote:
> > On Sun, Feb 10, 2008 at 01:10:14PM +0100, Martijn van Oosterhout wrote:
> > > This is beginning to get rather messy. TBH as a community not
> > > rendering the area in question is the only bargaining chip we have. Or
> > > slightly less extreme solution, drop the rendering of names. At the
> > > end of the day there's not much we can do against people who can't
> > > accept the fact that a place may have multiple names.
> >
> > I like the solution with the protected range
> >
> > - have the create node api check if the node is in a protected area,
> > if yes check the user and if allowed give the node an id in a reserved
> > range
> >
> > - have the create way/relationship api check if any of the member
> > nodes/ways
> > are from the reserved range and if so check the user and if allowed give
> > the way/relationship an id in a reserved range
> >
> > - have the edit/delete api check if the id in question is from the
> > reserved range and if so check the user
> >
> > Granted, I don't know ruby nor the api implementation but the
> > above seems doable to implement?
> Reserved Id ranges?  Seems a little overkill.  How about a protected bit on
> the node/way instead?

It would have to be as (a) the IDs are allocated by MySQL as auto
increment values and (b) overloading meaning like that is horrible.

Unfortunately adding columns to the node tables is a pain to do.

I think there's a better way anyway - we do the check on all changes
but shortcut it by only doing checks if the user is marked as being
subject to checks.

So new users and any users that had caused trouble would have that
flag set. Then if that flag was set their edits would be cross
checked against the restriction table(s) to see if they edit should
be allowed.


Tom Hughes (tom at compton.nu)

More information about the dev mailing list