[josm-dev] Extending JOSM conflict facilities to support different primitive types

[Josh Doe]

On Sat, May 21, 2011 at 1:31 AM, Karl Guggisberg
<karl.guggisberg at guggis.ch> wrote:
> Hi Josh
> Yes, initially a "conflict" was meant to represent a clash between two
> version of one and the same OSM objects. That's what conflict resolution is
> currently all about: make decisions about which of two differing versions to
> accept and which to reject.
> Currently, a few business rules in JOSM are based on conflicts, the most
> important being, that JOSM wont upload data from an OSM data layer to an OSM
> server, unless all conflicts in the layer are resolved. The user can't
> override this restriction. It's hard coded, because if the user didn't
> resolve the conflict, the upload itself would most likely fail because
> different versions would clash on the server. This is the basic, deep
> assumption about conflicts, as we know them today in JOSM.
> Your suggestion to process other flavors of "conflicts" in JOSM too makes
> sense to me. I think, though, that the new flavours should be distinct from
> the current concept of "conflict", mainly because business rules like the
> one mentioned above, do not apply to them. I assume that JOSM should allow
> uploading OSM data even though unresolved "conflation conflicts" are
> present.  In my understanding, "conflation conflicts" are similar to what we
> call "code smells" in software engineering: automatically generated hints
> where we can (potentially) improve the quality of the data. If "conflation
> conflicts" were present, upload should be allowed nevertheless.

Thanks for the explanation. Perhaps then we could make the conflict
tools technically capable of handling these cases I've mentioned, but
not to use the existing conflict process. In other words, the
conflation tool wouldn't add the "conflicts" to the existing dockable
ConflictDialog (by way of setting the ConflictCollection to the
OsmDataLayer), but would rather create it's own dialogs, reusing
ConflictResolver, TagMerger, and the like.

This is pretty much what I've done so far anyways, as I've created a
table showing the list of matches ("conflicts") along with the
distance (meters) and "cost", and below it I'm showing the usual
conflict resolution tools (ConflictResolver) that get populated
appropriately as the table selection changes. I'll add another column
to the table to indicate whether the conflicts have been resolved or
not, and buttons to resolve all conflicts using Mine/Theirs. I think
this should achieve my initial goal of conflating interstate exits
(highway=motorway_junction). I can worry about matching dissimilar
primitive types later.

I've updated my incomplete code in SVN if anyone wants to see what
I've done so far, but it doesn't actually allow you to merge objects
yet, but the table and conflict population is there.

Thanks,
-Josh