Hello all.
Can anybody tell something about handling of "invisible"(deleted on the
server) objects in JOSM? Specifically, why it was needed to write so
overcomplicated visibility conflict resolution system with
PurgePrimitivesCommand and UndeletePrimitivesCommand? There is much more
simple solutio
On Sat, 19 Jun 2010, Upliner wrote:
> Can anybody tell something about handling of "invisible"(deleted on the
> server) objects in JOSM? Specifically, why it was needed to write so
> overcomplicated visibility conflict resolution system with
> PurgePrimitivesCommand and UndeletePrimitivesCommand?
Hi,
Dirk Stöcker wrote:
> This has been designed by Karl Guggisberg. He seems to be no longer
> active in JOSM development (probably after there were some conflicts
> about the way JOSM is managed). He contributed a lot, but some of the
> code he wrote is overly complicated in my eyes, but I don't
2010/6/19 Dirk Stöcker
> Conflict handling is still a field where josm needs to be improved, so
> please contribute if you have better solutions.
>
Let's discuss how we should handle visibility conflicts. I don't think that
"visible" property of OsmPrimitives should be set by user. There's no
pr
Upliner wrote:
But what to do if we have two local osm files where same object with same
version has different "visible" attribute and user asks to merge them?
Silently ignore the conflict and assume that "source" layer has precedence?
Or ask the user to update visibility state from the server? W
