[josm-dev] Data management

[Richard Z.]

On Sun, Mar 02, 2014 at 12:59:45PM +0000, Lester Caine wrote:
> Richard Z. wrote:
> >On Fri, Feb 28, 2014 at 10:41:16AM +0000, Lester Caine wrote:
> >>>There is currently a discussion on the osm talk list about 'Not
> >>>attaching polygons to roads'. The discussion has opened up a little,
> >>>but as I see it the main problem is that of managing multiple
> >>>overlapping ways? Personally I would prefer to enhance 'area' with a
> >>>basic structure which uses existing ways to identify an area. This
> >>>will allow correctly tagging - for example - the boundaries of a
> >>>field or property lot without ending up with three ways all stacked
> >>>one on top of another.
> 
> >there is also the related problem of admin boundaries tied to waterways.
> >If one of the ways tied to such a boundary needs to insert a bridge,
> >tunnel or culvert it easily gets very hairy.
> >
> >https://josm.openstreetmap.de/ticket/9390
> 
> I would say that is rather a restricted view of the whole problem :)

I am sure this has more facets. But in many places admin boundaries are exactly 
defined as a fixed set of coordinate pairs connected by a way. Those nodes should 
not be moved and no new nodes should be added.
 
> While the nodes are automatically merged to a single node element,
> any tool which moves a node without knowledge of exactly which
> higher elements are being affected should be prevented for uploading
> that change?
> 
> The correct way of processing such a change is perhaps to
> automatically disconnect the selected node from the other objects,
> much as the 'G' shortcut does? 

yes, this is the only way to do it which I figured out. Not the whole 
solution because for a bridge/culvert you typicaly need to create additional 
nodes and in principle you should ensure that those do not get inserted into
the admin boundary.
So aside from ungluing this also means moving the nodes by a small amount
to avoid that. Moving the right nodes of course, not the state border
which we are trying to preserve.

> The description for the 'G' shortcut does not seem to cover or
> document all that it is capable of! Having been pointed to it off
> list, it does do a good part of what I want but is restricted to the
> nodes of a single entities cross linking with other objects?

no matter how good the tools there is always the possibility to make
a mistake. For this reason I would like to have the possibility to 
restrict editing to particular types of objects, or protect some
kinds of objects from accidental edits.

Not anything enforced by the API but as a tool protecting me against
own accidental mistakes.

Richard