Tester gesucht: "Änderungssätze hochladen"

Hallo,

wer schon einmal versucht hat, etwas größere Edits hochzuladen, wird vielleicht festgestellt haben, dass das mitunter doch etwas länger dauern kann. Wir hatten uns im letzten Jahr ein paar Gedanken dazu gemacht [1]. Herausgekommen ist dabei eine komplette Neuimplementierung, die inzwischen unter folgender Adresse zum Testen bereitsteht:

https://upload.apis.dev.openstreetmap.org/

Es wäre schön, wenn noch ein paar mehr Leute das ganze testen könnten, also z.B. mit iD oder Potlatch oder auch JOSM editieren, revertieren, kleine Edits, große Edits, Nodes, Ways, Relationen anlegen, ändern, löschen oder auch alles auf einmal.

Dazu müsstet ihr einen neuen Benutzeraccount auf dem Entwicklungsserver https://upload.apis.dev.openstreetmap.org/ einrichten, und könnt dann sofort mit dem Mappen loslegen. Kaputtmachen kann man dort eigentlich nichts. Ich würde aber empfehlen, einen Benutzernamen zu wählen, den ihr nicht auf dem produktiven OSM-Server nutzt. Das geht vielleicht am einfachsten mit einem angehängtem “-dev” oder sowas.

JOSM einrichten ist etwas umständlicher, die Anweisungen dazu habe ich auf folgende Seite ausgelagert: https://upload.apis.dev.openstreetmap.org/user/mmd2/diary/1

Wer ein paar Daten zum Herumspielen sucht:

Oder einfach die bisherigen Änderungssätze anschauen, dort finden sich noch mehr Beispiele.

Viel Spass beim Testen!

[1] https://github.com/openstreetmap/openstreetmap-website/issues/1710

Tonnen an Ways und Nodes abgekippt, geändert, revertet: flutscht.

Eine Frage: was bringt das Testen, bzw. wo liegt der Schwer- bzw. Knackpunkt?
Verstehe ich das richtig, dass es egtl. Quatsch ist, kleine CS hochzuladen, da die von Haus aus “genauso” schnell oben sind wie grosse CSe, oder was bringt ein kleines CS?

P.s. eigene Mapnik-tiles und eigene overpass-instanz wäre ganz knuffig, aber wahrscheinlich zu viel Arbeit.

Edit: jetzt hatte ich ein grosses CS, was gefühlt so träge war, wie auf dem Standard-server.
Keinen Plan, was da schieflief, vlt. hilfts zur Wahrheitsfindung:

Zunächst einmal vielen Dank für das Feedback! Mir fällt gerade auf, dass ich eigentlich gar nicht so genau beschrieben habe, welche Art von Problemen ich suche. Das ist vielleicht auch gar nicht so schlecht, weil es den Blick für neue unbekannte Fehler unnötig einschränken würde.

Gedacht war das ganze als offener Test. Alles, was beim Mappen so vorkommt, sollte ohne Probleme durchlaufen. JOSM sollte nicht meckern (zumindest nicht anders als sonst auch), der Änderungssatz sollten das enthalten, was hochgeladen wurde, die Historie muss stimmen, die Bounding Box passt zum Changeset. Jemand, der viel mappt, sollte hoffentlich gleich erkennen, wenn da etwas komisch ist.

Kleine oder große CS: die Idee war hier, einfaches Mappen nachzustellen. Nicht jedes CS hat 10’000 Änderungen, sondern meistens deutlich weniger. In JOSM sollte hier aber eine beliebige Paketgröße zwischen 10 und 10000 zum gleiches Ergebnis führen, nur dass es mit 10’000 wahrscheinlich eher schneller geht.

Leider habe ich darauf keinen Einfluss, das ganze läuft auf dem OSMF Entwicklungsserver…

Da scheint der Apache Server zwischendurch Probleme gemacht zu haben. Der Gateway Timeout (504) stammt zumindest nicht von der neuen Implementierung selbst. Wenn ich das richtig sehe, wurde https://upload.apis.dev.openstreetmap.org/changeset/844 zwar hochgeladen, leider hat aber JOSM keine Rückmeldung dazu erhalten, und das ganze daher nochmal in https://upload.apis.dev.openstreetmap.org/changeset/845 hochgeladen. Ich nehme das mal mit zum Prüfen.

Nee, Josm hat den upload gesplittet.
Beim Upload hat Josm automatisch die erweiterte Konfiguration angeboten (bzw. erzwungen), ich habe “Objekte in mehreren Paketen hochladen” verwendet mit Paketgrösse 10000.

Hallo,

Änderungssätze können seit einigen Monaten (oder ist es schon ein Jahr her?) nur noch maximal 10.000 Objekte enthalten (vormals 50.000).

Viele Grüße

Michael

Für mich sieht das im Moment so aus, dass JOSM zunächst die ganzen Nodes in 842 und 843 hochgeladen hat (jeweils 10’000 Stück). In 844 hat der Apache Server ein Gateway Timeout produziert (was wohl auf dem Entwicklungsserver durchaus vorkommen kann). Die Daten sind zwar in 844 angekommen, allerdings hat JOSM davon nichts mehr mitbekommen. JOSM versuchte dann erneut die 5972 Objekte im gleichen Changeset 844 hochzuladen. Das klappte aber wg. der 10’000 Objekt-Grenze nicht. In der Folge wurde dann Changeset 845 angelegt, und dort nochmal dieselben Daten hochgeladen, die auch in 844 zu finden sind.

Insgesamt ist der Verhalten aber so, wie es auch heute ist, d.h. wenn auf der Produktion Probleme mit dem Apache auftreten, würde das zum erneuten Hochladen der Daten führen. Das könnte man auf JOSM-Seite lösen, in dem man z.B. vor dem Hochladen zumindest prüft, wieviele Objekte bereits im Changeset drin sind und dann ein erneutes Hochladen sein lässt.

…sondern von Apache. Hier hat der Default-Timeout von 30s zugeschlagen, und da der Upload dank einer zwischendurch etwas langsamen Datenbank 34 Sekunden benötigt hat, kam der Gateway Timeout hoch. Immerhin war derselbe Upload im Changeset 845 mit 12 Sekunden wieder deutlich schneller. So etwas kann schon vorkommen auf einem Entwicklungssystem.

TomH hat dankenswerterweise den Timeout soeben auf 1 Stunde hochgesetzt (wie auf Produktion), d.h. dieser Fehler sollte nun nicht mehr vorkommen.

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.