Tester gesucht: "Änderungssätze hochladen"

Erster Versuch mit Potlatch 2.
Neues Konto musste angelegt werden, was ich auch getan habe.
Gebiet ausgewählt und auf “Bearbeiten” gegangen. Das Satelittenbild erscheint wie üblich, aber keine ways, nodes oder POI. Es ist nur das reine Satellitenbild zu sehen. Ich kann also nichts anlegen da ich nicht sehen was schon vorhanden ist und was nicht.
Was mache ich falsch ?

Auf dem normalen Account über openstreetmap.org funzt alles wie üblich.

Das liegt daran, dass grossflächig keine Daten da sind.
Im ersten Beitrag stehen ein paar Regionen mit Daten. Zusätzlich gibt es Autobahnen in Thüringen.

Danke, dachte das wären nur Beispiele gewesen.

Ja, das ist evtl. etwas verwirrend. Die Kacheln im Hintergrund kommen immer von osm.org und geben nicht das wieder, was gerade auf dem Entwicklungssystem an Daten vorliegt. Auf dem Entwicklungssystem läuft eine eigene Datenbank, auf der nur wenige Daten eingespielt wurden. Es hindert dich aber niemand daran, dort größere Sachen hochzuladen.

upload.apis.dev. rendert nichts, wenn ich recht verstehe was du meinst.

Man kann natürlich beliebige Daten hochladen, die landen auch in der DB auf upload.apis.dev. aber gerendert wird davon nix, d.h. man kann beim Testen auch nix außerhalb des Editors sehen.

Das könntest Du noch in die “MOTD”, oder wie das Kästchen da links genannt wird, schreiben, damit nicht noch mehr Leute davon verwirrt werden, die durch den Wochennotizaufruf zum Testen kommen.

Richtig. Das betrifft aber auch alle anderen Seiten auf dem OSMF Entwicklungsserver (siehe https://dev.openstreetmap.org/). Rendern von Tiles ist dort nicht eingerichtet. Ist zwar etwas schade, aber daran kann ich im Moment nichts ändern, da das System von den OWG Sysadmins betreut wird.

Leider geht das nicht so einfach, die Box links oben wird über Rails gefüttert, und dort kommt die “übliche” osm.org Seite zum Einsatz. Um dort einen anderen Text einzubauen, müsste man die Hauptseite klonen, dort den Text ändern und noch folgende Konfiguration anpassen…

https://github.com/openstreetmap/chef/commit/deac6f30cfa6aaf2a0323318d0db2c36e37fdcf0

Ich habe das gerade mal mit OSM2go probiert. Mit der angegebenen URL bekomme ich “internal server error”, wenn ich “/0.6” anhänge kann ich zwar ein Changeset anlegen, aber keine Objekte hochladen (Beispiel-URL: https://upload.apis.dev.openstreetmap.org/api/0.6/node/1544266089)).

Danke für die Rückmeldung. OSM2go sagt mir jetzt erstmal nicht so viel. Kannst du vielleicht etwas genauer beschreiben, wie man das nachstellen kann? Benutzt du Basic Auth oder OAuth? Mit welchem Benutzer?

Der Endpunkt ist auch hier beschrieben: https://upload.apis.dev.openstreetmap.org/user/mmd2/diary/1, d.h. du müsstest per HTTP POST folgenden Endpunkt mit einer osmChange XML Nachricht versorgen (829 durch eigene Changeset Nummer ersetzen)


https://upload.apis.dev.openstreetmap.org/api/0.6/changeset/829/upload  

Hast du irgendwie die Möglichkeit, URLs und XML Nachrichten mitzuprotokollieren, die an den Server geschickt werden?

Die Logik in osm_api.cpp sieht auf den ersten Blick so aus, als ob die Create und Modify Operationen einzeln erfolgen, und nur die Löschoperationen per osmChange abgebildet werden?

https://github.com/osm2go/osm2go

Benutzer war Dakon-dev. Du musst es selbst bauen und zusätzlich “-D SERVER_EDITABLE=On” an CMake übergeben, sonst kann man den Server nicht beeinflussen. Ich kann dir aber auch die Details rausfummeln wenn du möchtest. Am Besten kommst du mal in #osm-de vorbei, das sollte die Latenz reduzieren.

Ich glaube,ich muss erst mal schauen, ob das auf meinem Ubuntu 18.04 überhaupt funktioniert. libgoocanvas-dev gibt es dort nicht mehr, und cmake steigt dann mit einer Fehlermeldung aus:

– Checking for module ‘maemo-version’
– No package ‘maemo-version’ found
– Checking for module ‘goocanvas’
– No package ‘goocanvas’ found

Ich hab auch alles was entfernt nach goocanvas aussieht installiert, das ändert aber nichts an der Fehlermeldung. Laut TravisCI logs funktioniert es noch problemlos auf trusty. Ich probiere mal, ob ich damit osm2go zumindest compilieren kann.

maemo-version ist das Paket, das die Umschaltung auf das N900 bewirkt, das hilft dir vermutlich nicht weiter :wink:

So, hab jetzt osm2go in Docker kompiliert, läuft (wenn auch sehr instabil). Leider kann ich dein Problem aber nicht nachvollziehen. Ich habe unten einen Patch, der die URL passend ändert, sowie im osmchange_upload die osmChange message ausgibt. Vielleicht kannst du das auch mal bei dir einbauen und dann die Nachricht posten, die Probleme macht (sofern es denn davon kommt).


diff --git a/src/osm_api.cpp b/src/osm_api.cpp
index decc3f9..d439419 100644
--- a/src/osm_api.cpp
+++ b/src/osm_api.cpp
@@ -38,6 +38,7 @@
 #include <curl/curl.h>
 #include <curl/easy.h>
 #include <filesystem>
+#include <iostream>
 #include <map>
 #include <memory>
 #include <sys/stat.h>
@@ -430,10 +431,9 @@ static bool osmchange_upload(osm_upload_context_t &context, xmlDocGuard &doc, st
 
   xmlChar *xml_str = nullptr;
   int len = 0;
-
   xmlDocDumpFormatMemoryEnc(doc.get(), &xml_str, &len, "UTF-8", 1);
   xmlString xml(xml_str);
-
+std::cerr << "MY UPLOAD: " << xml_str << std::endl;
   bool ret = osm_post_xml(context, xml, len, url.c_str(), server_reply);
   if(ret)
     context.project->data_dirty = true;
diff --git a/src/platforms/gtk/settings.cpp b/src/platforms/gtk/settings.cpp
index 64db53d..c6a6393 100644
--- a/src/platforms/gtk/settings.cpp
+++ b/src/platforms/gtk/settings.cpp
@@ -41,8 +41,8 @@
 
 #define KEYBASE "/apps/" PACKAGE "/"
 static const std::string keybase = KEYBASE;
-const char *api06https = "https://api.openstreetmap.org/api/0.6";
-const char *apihttp = "http://api.openstreetmap.org/api/0.";
+const char *api06https = "https://upload.apis.dev.openstreetmap.org/api/0.6";
+const char *apihttp = "http://upload.apis.dev.openstreetmap.org/api/0.";
 
 static std::map<TrackVisibility, std::string> trackVisibilityKeys;


no valid position
no valid position
saving project to /root/osm2go/t/t.proj
creating changeset https://upload.apis.dev.openstreetmap.org/api/0.6/changeset/create from address 0x1e3caf0
request to parse successful reply '858' as an id
uploading node 1108298 to https://upload.apis.dev.openstreetmap.org/api/0.6/node/1108298
request to parse successful reply '2' as an id
no valid position
uploading way 126408 to https://upload.apis.dev.openstreetmap.org/api/0.6/way/126408
request to parse successful reply '2' as an id
deleting objects on server
MY UPLOAD: <?xml version="1.0" encoding="UTF-8"?>
<osmChange generator="OSM2go v0.9.13">
  <delete>
    <node id="1108661" version="1" changeset="858"/>
  </delete>
</osmChange>

download osm for t ...
net_io: download https://upload.apis.dev.openstreetmap.org/api/0.6/map?bbox=2.341547,48.8489016,2.3478126,48.8516166 to file /root/osm2go/t/update.osm
thread: running
no valid position

Ok, jetzt geht es bei mir auch. Allerdings sehen die Daten nach einem erneuten Download deutlich weniger aus als vorher, daher vermute ich, dass ich die OSM-Daten vom Live-Server hatte und deshalb der Upload irgendwelche abgefahrenen Kollisionen erzeugt hat, wahrscheinlich weil die IDs nicht übereinstimmten.

Wenn du irgendwelche Probleme hast, die nicht auf Docker zurückzuführen sind, freue ich mich über Bugreports.

Das ist schwierig einzuschätzen. Ich hatte z.B. sehr häufig Segmentation Faults, auch an unterschiedlichen Stellen und nicht immer reproduzierbar. Wenn das im regulären Betrieb so nicht vorkommt, könnte das eine Besonderheit der Umgebung sein, oder Wechselwirkungen wg. fehlendem GPS oder zu schnellem Rechner oder sowas in der Richtung.

Ich benutze das zum Entwickeln auch auf meinem Core i7 mit libgps ohne angeschlossenes GPS, das ist stabil. Ich habe gerade noch einen Crash gefunden, wenn man das Anlegen eines Projekts abbricht, aber normalerweise darf da nix crashen. Backtrace per Mail an mich oder ein Issue in GitHub aufmachen.

Hallo mmd,
ich experimentiere gerade mit einem seltenen JOSM Problem beim Löschen von Relationen:
https://josm.openstreetmap.de/ticket/15374
TL;DR: Problem taucht auf, wenn Relation 1234 ein Member von Relation 4711 ist und beide in einem CS gelöscht werden sollen.
Bevor ich da viel Arbeit reinstecke: Macht die hier diskutierte Änderung evtl. die Sortierung auf der Editor-Seite überflüssig?
Anders gefragt: Kann das auf der Server Seite gemacht werden?
Wenn nicht, müsste JOSM (wahrscheinlich auch jeder andere Editor) sich vor dem Upload die Daten zur Hierarchie noch mal vom Server holen und dann anhand dieser Daten sortieren.

Das kommt mir jetzt sehr spanisch vor. Jeder Editor der Relationen unterstützt läuft doch sofort in das Problem rein, dass beim Erstellen von mehreren Relationen die Kindrelationen zuerst und dann die Eltern erstellt werden müssen und beim Löschen umgekehrt sortiert werden muss. Aufwand 12 Zeilen Code. IMHO sollte man mit dem map API call auch alle relevanten Relationen bekommen, sprich nochmals den Server abfragen sollte nicht nötig sein (die Doku ist da etwas unklar).

Was ich im Augenblick nicht automatisch mache, ist bei Schleifen zuerst die Relation aus der Elternrelation entfernen (sollte ich wohl noch).

Simon

Es gibt im JOSM die Zeilen, die es sortieren sollen, bei neuen Rels ist das auch kein Problem. Beim Löschen fehlen aber notwendigen Daten, weil Member nicht nur als gelöscht markiert werden sondern wirklich die Memberliste gelöscht wird. Das jetzt nachträglich zu ändern ist ziemlich knifflig.
Das Problem taucht in der Praxis selten auf, weil JOSM wohl zumeist die Rel mit der kleineren id zuerst löscht. Das passt fast immer.
Wenn ich das richtig sehe wird auch JOSM mit Schleifen nicht zurecht kommen.

Das Löschen von Relationen ist (hoffentlich) eine der ganz wenigen Stellen, an denen das Verhalten der neuen und alten Implementierung voneinander abweichen. Bisher ist es in Rails so, dass jede einzelne Änderung in einer osmChange-Nachricht streng von oben nach unten und Schritt für Schritt abgearbeitet wird. Beim Löschen einer Relation muss dann jeweils geprüft werden, ob sie vielleicht noch in einer anderen Relation als Member enthalten ist. Für Parent-Child-Beziehungen muss also zunächst das Child, und dann erst der Parent aufgeführt werden.

Die neue Implementierung weicht hier dahingehend davon ab, dass geschaut wird, ob eine Menge zu löschender Relationen Abhängigkeiten zu dritten Relationen hat. Das wäre also z.B. ein Grandparent, der auf den Parent zeigt, wobei wir die Parent-Child Relationen löschen wollen. Ist das nicht der Fall, können die Relationen gefahrlos gelöscht werden. Damit lassen sich auch 2 Relationen, die sich wechselseitig referenzieren, in einem Schritt löschen.

Ich hatte im “create” Fall schon eine Logik eingebaut, die die alte Rails Logik nachbildet, also streng von oben nach unten geht. Für den “Delete” war das bisher nicht der Fall. Das ist natürlich etwas unschön, weil dann ein Editor, der sich auf dieses Verhalten verlässt, später nicht mehr mit dem alten Rails Port arbeiten kann. Ich muss mal mit Matt klären, ob wir das auch abklemmen müssen.

Generell ist hier das Problem, dass das gewünschte Verhalten nicht wirklich sauber spezifiziert ist, auf der anderen Seite aber von den Rails-Leuten immer ein exakt gleiches Verhalten eingefordert wird. Ich würde daher dringend empfehlen, gedanklich immer davon auszugehen, dass ein osmChange chronologisch von oben nach unten abgearbeitet wird.

OK, das hatte ich befürchtet. Wenn die CS auch von anderen Programmen verstanden werden sollen, kann man das wahrscheinlich auch nicht mehr ändern, ohne eine höhere api version zu erzwingen.