Augmented diffs -- top level element screw up

General talk
1

Apologies for posting this here, but there is currently no developer category (I’m fairly sure this issue has come up before, I’m having a bit of a déjà vu).

In the past there has been only one generator of augmented diffs, Overpass, but now there is osmcha and I’m working on support too Not so augmented diffs by simonpoole · Pull Request #2944 · MarcusWolschon/osmeditor4android · GitHub

It would be really nice if viewers could display data in the adiff format without requiring heuristics. For example currently achavi doesn’t display diffs from osmcha because it (has to employ) employs a heuristic to determine that it actually reading adiff data and relies on the generator attribute starting with Overpass API (see achavi/js/FormatRegistry.js at gh-pages · nrenner/achavi · GitHub).

The root cause for the issue is that the original adiff spec (see the wiki), specifies the name of the top level element as osm this conflicts with conventional OSM XML format files (while these have mostly fallen out of use for distribution purposes, they are still in use for storing and moving around data between editors and similar tools.

achavi seems to support a number of different top level element names besides osm, for example osmAugmentedDiff (a bit ugly). But the point is that we should simply agree on one that isn’t osm and then stick with it. I don’t have a stake in any particular value (yet) so it is really up to @drolbr and others (@Minh_Nguyen ?) already involved.

1 Like
2

I have no strong opinion here.

A name osm-adiff for the top level element sounds straightforward.

3

You’re probably aware, there is now also osmcha-cli to display adiffs.

You probably mean @jake-low (see e.g. Inside OSMCha’s New Upgrade)?

4

Which in a way is worse because it doesn’t seem to do any input validation in the 1st place outside of expecting osm as the top level element, see osm-adiff-parser/index.js at main · OSMCha/osm-adiff-parser · GitHub

5

I didn’t realize that Achavi accepted augmented diff files with an <osmAugmentedDiff> root element. I’m open to adding this behavior to osm-adiff-parser also. Does any software currently exist that generates adiffs of this flavor?

BTW, the “Issues” tab on GitHub was disabled for the osm-adiff-parser repo for some reason, but I’ve just re-enabled it and opened a new issue about adding input validation to the parser, based on your suggestion.

6

I don’t think this is still used anywhere. If I remember correctly, it was for historical variants of the format, which evolved in a few iterations.

7

Assuming that everybody agrees with my stipulation that using osm is not a good idea and given there hasn’t been any further suggestion, lets, groan, do a poll:

  • Continue to use osm
  • osm-adiff
  • Other (add in comment)
0 voters

Changing to osm-adiff does imply that consumers of adiffs should support this, further I would suggest that the version attribute should be set to 1.0 aka it should be the version of the relevant adiff specification not that of the OSM data (obviously if the OSM data spec changes significantly a new version of the adiff definition is likely to be necessary).

The poll is open for a week.

8

Is there a reason you chose <osm-adiff> for the poll option instead of <osmAugmentedDiff>? As noted above, Achavi already supports the latter. I also prefer the lowerCamelCase form as it matches <osmChange> which is used as the root element for .osc files.

I agree that we should use version="1.0", so that the Augmented Diff format can be evolved separately from the OSM API (which may well stay on version 0.6 for a very long time).

1 Like
9

None, outside of Roland (@drolbr) suggesting it and given overpass and augmented diffs are his inventions I would think that he kinds of get a say in this matter. I literally don’t care outside of that and could live with everything that isn’t osm,

1 Like
10

Ah, sorry, I had missed @drolbr’s comment higher up in this thread. I’m fine with either choice then.