JOSM Error "ResponseCode=412"

After extended redoing inner outlines around side-sharing inner areas in a complex forest relation which included long JOSM screen freezes while it was doing something, completing and validating, I was left with 1 error and 1 warning

  1. Error of empty way(1), 0 nodes.
  2. Warning (1), untagged ways (1), 0 (0 nodes)

Being unable to home into the spot since it is seemingly not occupying any, pushed forward into the save and upload cycle, which then generated the message

“Uploading to the server failed because your current dataset violates a precondition: The error message is: ResponseCode=412, Error Header= Precondition failed: “<” Way-133572 must have at least one node”>"

After reading around the web and learning more how to search for this in the loaded data set, found that 7 boundaries, the 0 node way and half dozen more lines with nodes all had this -133572 reference.

Question is, is this on the server which the boundary links suggests, or is there a way to remove this reference from the local data set prior to uploading?

Error 412 is Precondition Failed which means the change you were trying to make was invalid - in this case because you tried to upload an empty way that didn’t contain any nodes as the validator had already warned you.

That is as clear as can be, the question is how to get at that item and remove it before uploading. It has no ‘presence’ in form of any tangible reference that can be grabbed.

If you simply want to remove it from your local data, you should be able to select it with a JOSM search/filter expression JosmFilterDoc/filter.md at master · simonpoole/JosmFilterDoc · GitHub

Does the error message from JOSM mention the id of the 0-node-way? If so you can search in JOSM for the id (Strg+f → id=<way-id>) and hit DEL to delete.

1 Like

Is validator providing autofix on selecting this error, in list of validation issues?

The conflict resolution pane does not list any problems, the ‘zoom to’ right click option on the item does not go anywhere, it simply shows the whole area covering the loaded dataset without selecting anything.

This is the search result list that appears in the selection pane as mentioned in the OP

image

The 1st item after the boundaries and superroute line is the suspicious item.

Sort of seriously challenged v.v. the JOSM search function, but Strg+f → id=-133572 or Strg+f → id=133572 both give zero results.

I was able to create a testcase by manually editing a sample OSM-file:

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.6' generator='JOSM'>
  ...
  <way id='-105445' action='modify' visible='true'>
  </way>
</osm>

(no node-tags in way -105445)

When I use JOSM validator (“Prüfergebnisse”) it will complain about an empty line (“Leere Linien”). When I double-click the entry it will show up under selection (“Ausw.:…”) where I can delete it by hitting DEL:

My mistake, must be id:-133572 (colon instead of ‘=’)

3 Likes

OK, :ok_hand: :wave: :hand_with_index_finger_and_thumb_crossed: here, so indeed when double clicking the “0 (0 nodes)” appeared in the Selection frame. Then hitting the DEL key, it disappeared. Running the Shft+V gave zero errors and the upload screen gives no warning.

“Do I feel lucky…”? Given it touches on so many long distance items, I first go for the doppio espresso, ristretto and will let know what happens after.

Update: Did the dirty and uploaded, forest render remained, forced Ctrll+F to pull the relation across again in the website view and all stayed. Did more work and the end product is from 173 member to 120 to included self-references on many inner areas that only had the leaf cycle/type tags but not the key (all different leaf mixes broken out). Could have been the cause of the very slow updating. I’m cool to go.

To add onto this, the Fix button will delete the way for you. If you do not see the issue in the validator, please check the ignore list (Manage Ignore) and remove entries from that list. You have to right-click on the elements you want to remove from the ignore list and select Don't Ignore.

Quick tip: in the new forum there is no use in changing the thread title anymore after a solution has been found. After selecting the respective post as a solution, both the post is marked and the title gets a little tick on the left. That also enables filtering for solved threads during searches.

2 Likes

OT\ The little tickmark at left only appears on the ‘Latest’ list, so small and so lightgrey it’s easy to overlook, make it green. Given there are long OP posts that would not list the answer in one screen, I’d suggest to also have that tickmark appear at the top of the opened thread left of the OP title.
/OT

Interesting. From time to time we get reports about “dataset violating a precondition” like your way without nodes or referenced objects missing in the dataset. We were unable to reproduce it in many cases. Therefore it would be really useful to know how you managed to create a way without nodes and we would be happy about a step by step description. First question: Did you use any plugins? Which ones?

3 Likes

That’s a spark of hope.

Which plugins, the relation toolbox for sure and possibly the Utilsplugin2, but then per my GitHub report v.v. the loopback while tracing, there’s about 16 plugins hanging off JOSM. What part I use of which I truly would not know… I just integrate the whatever is showing off the menu and what I use in shortcuts worth remembering.

How I got this in the first place, that’s the 64,000 greenback question. Very very possibly some redundant MP relations that got emptied then deleted. During the validation phase one gets warned of any empties, switch to edit from the validator pane for these and hit the delete button to send them off. I did not use any reconstructs to convert 1 member leftover MPs to simple polygons. All but 1 place had closed loop drawn areas.

Anyway, several hours on, the forest and all it’s parts continue to show after Ctrl+F5’s in the various zoom levels, so whatever I broke or pulled in from the server as broke is no more.

Thanks for the effort. To be clear, we are talking about a way with negative id which means it must have been created by some JOSM action within the session.
I doubt that utilsplugin2 is the cause by you never know. I have to take a look at relation toolbox which I am not familiar with.

Guess, we have to wait until this happens with only a few changes (if it does happen at all) as so far all reports are about long sessions and people do not exactly remember their steps in detail.

Good to know about the minus sign, exactly the same as another open source prog I used, minus local client issue, no minus, server problem. For now I’m A OK with now having a documented workaround. should it ever occur again.

Do not get me wrong. In OSM, negative ids are new objects not uploaded to the server, yet. That does not mean that problems with objects with positive id are server problems. In fact, all precondition failures are problems on the client side (aka JOSM).