Opened 7 years ago
Closed 7 years ago
#16256 closed defect (fixed)
"Building with almost square angle" autofix to improve
Reported by: | JandaM | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 18.05 |
Component: | Core validator | Version: | tested |
Keywords: | building square right angle autofix | Cc: |
Description
After editing ~100-200 buildings and after automatically fixing ~2000 invalid messages I get more than 10 000 changesets. There is no reason to have such many generated changesets. If > 10 000 changes are separated to changesets they should be split into blocks with more than 1 change.
Attachments (0)
Change History (14)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
You mean that you get +10000 changed objects (which includes adding, removing or modifying objects) and not +10000 changesets, right?
comment:3 by , 7 years ago
It was changed +10000 objects that generates +10000 changesets. It was 1 changeset per changed entity.
comment:4 by , 7 years ago
Number of changesets (+10000) was written in upload dialog. I suppose it is reproducible in Prague / Czech Republic. (didn't try)
comment:5 by , 7 years ago
Strange... doing a test here I can see that JOSM only says that it will upload to multiple changesets (but doesn't say the total number of changesets)
Maybe you saw something like this?
"requests" here doesn't mean that it will create 15591 changesets, but that JOSM will upload each object separately (grouping them into the same changeset, up to 10000)
For this example we would have 2 changesets only.
What do you have in the Advanced
tab of the upload dialog, please?
comment:6 by , 7 years ago
There is selected 2nd row "Upload data in chunks of objects, Chunk size:". Chunk size is set to 1. I did't ever modify this setting. I even don't know that it exists.
This is the reason that +10000 objects were split into +10000 changesets. Maybe there will be necessary to check this on clean computer after upgrading from previous version.
comment:7 by , 7 years ago
Ah... then it's the same case from my example (which is not really a problem :-))
You won't actually create 10000+ changesets, but just upload each object separately, one by one; they will be grouped into the same changeset, however.
By "requests" you should understand as the number of connections that JOSM will make to the OSM servers (in order to send all your objects), and not the number of changesets that will be created.
Personally I like to upload 100 objects at a time, like this:
A value from 100
to 1000
seems to be good deal here, from my experience.
From what I see you just need to change this value to something higher; JOSM won't really create 10000+ changesets, no matter the value that you use ;-)
You can also use Upload data in one request
(which should be the default option, if I am not wrong).
comment:8 by , 7 years ago
Yes I would expected that "Upload data in one request" would be default option preserving old functionality. But for some reason In my case second options is selected by default.
comment:9 by , 7 years ago
You used the fix button on 2000 objects? Did you check them after the fix? Better not trust the fix button blindly. (Especially for the "Building with almost square angle" test as this is a new test.)
comment:10 by , 7 years ago
Component: | Core → Core validator |
---|---|
Keywords: | building square right angle autofix added |
Summary: | Regression: stable build13710 - generates > 10 000 changesets → "Building with almost square angle" autofix to improve |
comment:12 by , 7 years ago
Can you please try with r13712? The autofix should be smarter and more stable.
comment:13 by , 7 years ago
Milestone: | → 18.05 |
---|
comment:14 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Problem is that FIX button is enabled for "Building with almost square angle". This cannot be automatically fixed. Because fix MUST always produce stable and repeatable results. This randomly modifies buildings. After fix still remains buildings with almost square angle. FIX buttom MUST be disabled for this validity warning.