Provide configuration checkbox in upload dialog for enabling/disabling changesets

[katpatuka]

I traced the lake "Qiandao Lake" (see wiki) newly because there was only a ~750-node lake (AND data). Upload seems to stall with a timeout after 60 to 80 seconds without josm giving any error.

(Data included)

[katpatuka]

osm file of new Qiandao Lake

[stoecker]

I think this is plainly a server timeout or something like that due to a large number of data. You should retry.

A note: the relation should be "type=multipolygon and natural=water" instead of "type=lake".

[katpatuka]

I tried more than 10 times to upload... I don't get no error, nothing, just sort of timeout.
Feel free to try an upload yourself...

[Gubaer]

• Go to Preferences -> "Einstein dialog"
• set osm-server.atomic-upload to false
• try to upload again. This will use a lot of small uploads instead of one gigantic diff upload.

[katpatuka]

With osm-server.atomic-upload=false I get error:

PUT http://www.openstreetmap.org/api/0.6/node/create... Bad Request
Error header: Cannot parse valid node from xml string <node visible="true" version="0" lat="29.662" lon="118.93175"/>. Changeset id is missing
got exception: org.openstreetmap.josm.io.OsmApiException: ResponseCode=400, Error Header=<Cannot parse valid node from xml string <node visible="true" version="0" lat="29.662" lon="118.93175"/>. Changeset id is missing>,Error Body=<Cannot parse valid node from xml string <node visible="true" version="0" lat="29.662" lon="118.93175"/>. Changeset id is missing>

[Gubaer]

You'll have to update to ​JOSM latest. I've recently fixed that in in r1682.

Be careful with JOSM latest, though. It's less stable than the tested version.

[katpatuka]

Ok, with osm-server.atomic-upload=false and r1682 it finally worked (the old before-changesets-existed way of life) - but it took me 6 hours!
There also had been conflicts against the end of the upload sequence which had to be resolved... and duplicated ways have been created which I manually deleted in potlatch (joms drove me nuts saying node x is still used by way y!)

Strange thing is, that I didn't get any error or hint by josm during the normal upload that something is going wrong...

Recommendation: The setting osm-server.atomic-upload could be implemented into Preferences of josm - as a last resort.

[Gubaer]

I'm not really astonished about the 6 hours it took. You have ~ 25-30 K primitivies to upload in your file!

There also had been conflicts against the end of the upload sequence which had to be resolved... and duplicated ways have been created which I manually deleted in potlatch (joms drove me nuts saying node x is still used by way y!)

I'm not astonished either that you have to resolve conflicts. With 30K updates it's likely that in the meantime another mapper touched a couple of primitives too. But I'd be interested to hear more about the conflict you couldn't resolve with JOSM. Perhaps I can improve the conflict resolution code in JOSM.

Strange thing is, that I didn't get any error or hint by josm during the normal upload that something is going wrong...

That's normal too. The API is reporting back only after it has processed the entire changeset - in your case probably only after a couple of hours.

Recommendation: The setting osm-server.atomic-upload could be implemented into Preferences of josm - as a last resort.

I think it would even be better if the upload dialog had two radio boxes:

use [ ] changesets | [ ] this time / [ ] always

I turn this into an enhancement.

[katpatuka]

...in the meantime another mapper touched a couple of primitives too.

Not likely: I just tried to upload lakewalker trace of the lake (~16.000 nodes) - so there weren't any ways someone else could have changed in the meantime.

But I'd be interested to hear more about the conflict you couldn't resolve with JOSM...

The non-atomic-upload worked more or less well (despite an electric outage) till it reached the moment where the way-ids start to get transfered. There were lots of "node x is still used by way y" which I tried to resolve. At one time I had a controlling look in potlatch and the coastline was already there. I downloaded the already viewable data in a new layer to check it and saw that about have of the 76 201-node-ccoastlines had dublicates - I first tried to delete the dups in josm but again got these ominous "node x is still used by way y" - therefore I decided to delete the dups in potlatch manually. That process is still slow but more simple than to fight with josm's validator/conflict resolver. BTW: after each resolve and click on upload I had to wait half a minute to get the upload dialogue... After manually deleting in potlatch I reloaded again in josm to fix some duplicate nodes left over and finally could add a relation for the lake.

[Gubaer]

fixed in r1870