Command stack maxes out at 1000 changes

[HamishB <hamish_b@…>]

Hi,

Using JOSM r3208 (testing) the Command stack maxes out at 1,000 changes.

method: using Xapi download area from our ongoing bulk upload containing touching natural=* layers or duplicate upload snafu. Open xapi.osm in JOSM. Select all, run the Validator plugin to find & then Fix all duplicate nodes in that download set. For example 2,300 or so nodes get merged but the sub-title bar of the Command stack only reports 1,000.

when you go to upload, the full changeset appears to be applied, so it's only a cosmetic thing in the GUI AFAICT.

thanks,
Hamish

[anonymous]

Which are missing? The older one or the newer ones (try with doing something else before). When the older ones are missing everything is correct. We don't support indefinite command list.

[HamishB <hamish_b@…>]

Replying to anonymous:

Which are missing? The older one or the newer ones (try with
doing something else before). When the older ones are missing
everything is correct.

Yes, it is the changes that happen first which fall off the top end.

To avoid users being mislead and confused by bad data, it would be nice if a (+) or something was added to the "1,000" number.

We don't support indefinite command list.

Of course not. As API 0.6 has a max limit of 50,000 (changes/ nodes/ features/ commands/ ??), perhaps something a wee bit closer to that number would be in order. (and throw an error message if you exceed it! [cleaning up the mess from a broken upload due to that now..])

In fixing (targeted) duplicate nodes I'm commonly encountering 2000-3000 node merges per Validator search/fix cycle.

thanks,
Hamish

[anonymous]

Replying to HamishB <hamish_b@…>:

Replying to anonymous:

Which are missing? The older one or the newer ones (try with
doing something else before). When the older ones are missing
everything is correct.

Yes, it is the changes that happen first which fall off the top end.

To avoid users being mislead and confused by bad data, it would be nice if a (+) or something was added to the "1,000" number.

AFAIK this is just the undo- list, not more.

[stoecker]

You can increase size with "undo.max". But as said, this is only the undo list. It is shortened to reduce memory usage. Nobody does 1000 undo steps :-)

[anonymous]

Replying to HamishB:

To avoid users being mislead and confused by bad data, it would be nice if
a (+) or something was added to the "1,000" number.

Replying to anonymous:

AFAIK this is just the undo- list, not more.

in that case it should be labeled it as such, instead of calling it the "command list", which is misleading ...

imho & regards,
Hamish

[anonymous]

another idea is to have the validator's Fix tool group all node merges into one command on that list instead of listing each fix separately.

regards,
Hamish

[bastiK]

Replying to anonymous:

another idea is to have the validator's Fix tool group all node merges into one command on that list instead of listing each fix separately.

Note to developers:

Cannot be done because of memory problems when fixing duplicates for, like, a few thousand nodes.
The 1000 commands limit was introduced mainly for this.

But apparently there is a massive waste of memory somewhere. So if this is fixed, the suggestion could be picked up again (and fixing duplicate nodes would be undo-able).