[Talk-de] Precondition failt

Fr Feb 13 20:49:39 UTC 2009

Hallo,

Jacques Nietsch wrote:
> immer wenn ich versuche die Relation 70582 mit josm zu bearbeiten,
> bekomme ich obengenannte Fehlermeldung (oder so ähnlich).
> 
> Meine Fragen:
> 
> - warum kommt diese Meldung

Fast immer hat diese Meldung bei Relationen damit zu tun, dass ein 
referenziertes Objekt nicht mehr existiert oder ein referenzieter Way 
"kaputt" ist.

> - wie sollte man reagieren

Ich skizziere im folgenden, was ich getan habe, um das Problem zu 
beheben. Es ist recht unwahrscheinlich, dass Du das nachmachen willst, 
aber vielleicht gibt es den einen oder anderen Leser, der das Rezept 
brauchen kann.

$ wget -Or http://www.openstreetmap.org/api/0.5/relation/70582

Datei "r" nun mit einem Editor aendern: das id="..." bei der Relation 
raus, alle Tags raus, alle Ways auskommentieren (ein <!-- vor dem ersten 
way, ein --> hinter dem letzten), und ein neues Tag rein:

     <tag k="note" v="for testing only, can be deleted" />

Dann Versuch, die Relation als neue hochzuladen:

$ lwp-request -semPUT -C username:password 
http://www.openstreetmap.org/api/0.5/relation/create < r

Zurück kommt ein "200 OK" und die id der neuen Relation (bei mir 77307). 
Ich trage die id in das relation-Tag in der Datei ein (<relation 
id="77307"...).

In der Datei "r" sind nun rund 30 ways auskommentiert. Ich ersetze den 
Anfangskommentarmarker durch ein  und verschiebe ihn 15 Zeilen nach unten, so dass die obere 
Haelfte der Ways nun wieder aktiv ist.

$ lwp-request -semPUT -C username:password 
http://www.openstreetmap.org/api/0.5/relation/77307 < r

Zurueck kommt ein "200 OK", d.h. der Fehler liegt nicht in den ersten 15 
Ways, sondern im hinteren Block. Ich schiebe den "irgendwo hier 
drunter..."-Marker an die Stelle, wo mein <!-- ist, und schiebe das <!--
abwaerts, so dass es die verbleibenden Ways in der Mitte teilt.

$ lwp-request -semPUT -C username:password 
http://www.openstreetmap.org/api/0.5/relation/77307 < r

Wieder "200 OK", also weiter so. Aha, beim naechsten Versuch 
"precondition failed"!

Meine Datei sieht zu dem Zeitpunkt so aus:

     <member type="way" ref="30473824" role=""/>
     <!-- irgendwo hier drunter... -->
     <member type="way" ref="30480844" role=""/>
     <member type="way" ref="30481099" role=""/>
     <member type="way" ref="30481196" role=""/>
     <member type="way" ref="30481210" role=""/>
     <!--
     <member type="way" ref="30483003" role=""/>
     <member type="way" ref="30483180" role=""/>
     <member type="way" ref="30542551" role=""/>
     -->
     <tag k="note" v="for testing only, can be deleted" />

Ich weiss nun, dass irgendeiner der vier Ways zwischen der 
"irgendwo"-Markierung und dem <!-- fehlerhaft sein muss. 
(Moeglicherweise noch mehr, aber ich setze mal drauf, dass nur ein 
Fehler existiert). Ich schiebe nun die untere Markierung nach oben und 
halbiere wieder den Bereich:

     <!-- irgendwo hier drunter -->
     <member type="way" ref="30480844" role=""/>
     <member type="way" ref="30481099" role=""/>
     <!--
     <member type="way" ref="30481196" role=""/>
     <member type="way" ref="30481210" role=""/>
     -->
     <!-- irgendwo hier drueber -->
     <member type="way" ref="30483003" role=""/>
     <member type="way" ref="30483180" role=""/>
     <member type="way" ref="30542551" role=""/>
     <tag k="note" v="for testing only, can be deleted" />

Diesmal "200 OK". Nun lasse ich nur noch den Way 30481196 auskommentiert 
-wieder 200 OK. Testweise nehme ich den Way mit dazu - precondition failed.

Der Way 30481196 ist also der Boese. Ich loesche meine Testrelation:

lwp-request -semDELETE -C username:password 
http://www.openstreetmap.org/api/0.5/relation/77307

Ich koennte nun einfach die urspruengliche Relation ohne diesen Way 
hochladen, dann waere sie wieder bearbeitbar. Eventuell laesst sich der 
Way aber auch reparieren, mal sehen:

$ lwp-request -semGET http://www.openstreetmap.org/api/0.5/way/30481196

   <way id="30481196" visible="true" 
timestamp="2009-01-25T15:01:07+00:00" user="Divjo">
     <nd ref="28886899"/>
     <nd ref="82461675"/>
     <nd ref="253577329"/>
     <nd ref="253577361"/>
     <nd ref="275011188"/>
     <nd ref="275011141"/>
     <nd ref="82461672"/>
     <tag k="highway" v="residential"/>
     <tag k="created_by" v="Potlatch 0.10f"/>
     <tag k="name" v="Blomkamp"/>
   </way>

Zum Vergleich mal die History...

   <way id="30481196" visible="true" 
timestamp="2009-01-25T15:01:07+00:00" user="Divjo">
     <nd ref="28886899"/>
     <nd ref="82461675"/>
     <nd ref="253577329"/>
     <nd ref="253577361"/>
     <nd ref="275011188"/>
     <nd ref="275011141"/>
     <nd ref="82461674"/>
     <nd ref="82461673"/>
     <nd ref="82461672"/>
     <tag k="name" v="Blomkamp"/>
     <tag k="created_by" v="Potlatch 0.10f"/>
     <tag k="highway" v="residential"/>
   </way>

Ah, ein klassischer Fall von "ich bin ein vermurkster Way" - die 
aktuellste Version der History muss identisch sein mit der "normalen" 
Version, ist sie hier aber nicht. Wetten, die zwei Nodes, die in der 
History "zuviel" sind, gibt es nicht mehr?

$ lwp-request -semGET http://www.openstreetmap.org/api/0.5/node/82461673
410 Gone

Hab ich mir gedacht. Kaputt eben. Ich nehme den Way so wie er ist und 
lade ihn erneut hoch:

$ lwp-request -mGET http://www.openstreetmap.org/api/0.5/way/30481196 | 
lwp-request -semPUT -Cusername:password 
http://www.openstreetmap.org/api/0.5/way/30481196

Nun haben wir einen Way, bei dem die akuelle Version und die erste in 
der History uebereinstimmen. Hoechstwahrscheinlich ist die Relation 
damit wieder bearbeitbar:

$ lwp-request -mGET http://www.openstreetmap.org/api/0.5/relation/70582 
| lwp-request -semPUT -Cusername:password 
http://www.openstreetmap.org/api/0.5/relation/70582

Zurueck kommt ein "200 OK", also jetzt ist alles wieder in Butter.

Frag mich nicht, *warum* die Relation nicht hochgeladen werden kann, 
wenn die aktuellste historische Version des Ways mit der eigentlich 
aktuellen nicht identisch ist. Ist halt so ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"