Issue with josm upload

[Roy Rankin]

Twice now (from different uploads) I have gotten the attached error error message from josm (the png attachement) when I try to upload data from the latest version of josm.

I have attached a capture of the josm error message, a wireshark capture of the upload session and the changeset trying to be uploaded (obtained from a wireshark capture).

Josm gives a few warnings but no errors when I start the upload.

Any ideas what the problem is?

Regards,

Roy Rankin

[Tim Sheerman-Chase]

Thanks for raising this issue.

Running josm from the command line gives a little more debugging
information.

Can you save the un-uploaded layer in josm and send it to me? Otherwise,
I can take a look at the objects in the changeset to see if something is
missing.

Tim

[Roy Rankin]

Tim,

I have added the josm layer and the messages from josm to the command line.

I am wondering if the issue is way 138776102 which was missing node 69037806. I removed the missing node from the way outside of josm leaving only one node on the way and then deleted the way under josm. I have done this in the past with no issues.

Roy

[Tim Sheerman-Chase]

The missing way nodes are 4995114 and 1044481771. Strangely neither are in the server history of old objects.

http://api.fosm.org/api/0.6/way/4995114/history

http://api.fosm.org/api/0.6/way/1044481771/history

I'll have a think about this...

Tim

--
You received this message because you are subscribed to the Google Groups "OSM Fork" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osm-fork+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Sheerman-Chase]

I've had a further look.

Way 1044481771 looks like a typo. It looks very like way 144481771 in
the original data.

Relation 1868411 (which exists) contains way 4995114 (which does not
exist). This looks like a problem with the database. I plan to do
further checks soon which should eliminate these integrity problems. In
the short term, this way probably could be removed from that relation.

I've not attempted to apply these changes. I don't think any of the
upload has been applied as changes are applied atomically (i.e. its
applied to the database or completely rejected if an error occurs.) You
probably can made further edits and try to upload it again.

Tim

[rra...@ihug.com.au]

Tim,

Way 1044481771 in the changeset  file was certainly my mistake. I  generated it from the wireshark tcp packet and had to manually remove non data bits from a number of places and must have made a mistake doing this.

I have confirmed that way 4995114 in Relation 1868411 was indeed the issue by removing it from the relation and successfully uploading the changeset.

However, the question of how the way went missing from the db is unanswered. I have one other editing session which would not upload and I will now take a look at it.

Thanks for looking into this,

Roy Rankin

----- Original Message -----

From:

osm-...@googlegroups.com

To:

<osm-...@googlegroups.com>

Cc:

Sent:

Sun, 11 Nov 2018 10:07:43 +0000

Subject:

Re: [OSM Fork] Re: Issue with josm upload

[rra...@ihug.com.au]

 

Tim,

It looks like relation 350373 has missing way 111562336. (this is in my other changeset witch does not upload.

I wonder how many other instances of this type of db inconsistency.

By the way, I often see ways with missing nodes. These ways, josm logs to the command land but does not let you see or edit the ways so they are not uploaded.

If you save the layer they are there. I have written a perl script to find these ways and remove the missing nodes so they can be edited as appropriate with josm.

Both ways with missing nodes and relations with missing ways look like the same type of problem to me.

Roy Rankin

,

----- Original Message -----

From:

osm-...@googlegroups.com

To:

<osm-...@googlegroups.com>

Cc:

Sent:

Sun, 11 Nov 2018 23:14:42 +1100

[Tim Sheerman-Chase]

I agree that there is some issues with data integrity.

We are now using the pycrocosm server which is quite paranoid about data
validation. I hope to be able to sort out the remaining issues soon
(including missing nodes). I've been helping Ross do a valid error-free
database dump, which is the first stage in the process. Hopefully no new
problems are introduced to the data - if there are I'd prioritize fixing
that.

Tim