Datenabgleich lokal - Server

Ich engagiere mich für die Erfassung des österreichischen Hochspannungsnetzes sowie seiner Anbindung an die Netze der Nachbarstaaten. Um die Daten zu verwalten, pflege ich eine osm-Datei, in der alle zur Zeit kartierten Leitungen erfasst sind. Zur Pflege gehört ein regelmäßiger Abgleich mit den Daten auf dem osm-Server. Dies gelang am Anfang, als ich erst einen Teil der Leitungen erfasst hatte, noch mit vertretbarem Zeitaufwand mit Hilfe des Befehls “Datei/Daten aktualisieren”. (Ich arbeite mit lokalem JOSM). Im jetzigen Ausbauzustand der Datei (ca. 40000 Leitungsmasten) ist dieses Vorgehen zeitlich (und vielleicht auch im Blick auf die Serverbelastung) nicht mehr akzeptabel.

Gibt es ein Programm (oder vielleicht auch mit JOSM eine Bedienungsmöglichkeit), mit dem/mit der der Datenabgleich effizienter abläuft? Geeignet empfände ich ein Programm, das ein Listung ausgibt, welches alle in der Serverversion hinzugekommenen, geänderten und gelöschten Objekte aufzählt. Dann kann man gezielt analysieren, was mit jedem einzelnen Objekt passiert ist. (Es gibt ja auch Verschlimmbesserungen, die man nicht übernehmen, sondern - ggf. nach Rücksprache mit dem Verschlimmbesserer - wieder rückgängig machen möchte.) Diejenigen Objekte, deren Versionsnummer in meiner lokalen Version und in der Serverversion übereinstimmen (und das sind die allermeisten!), müssten dann nicht mehr heruntergeladen werden. Das spart Zeit und traffic.

Für Hinweise, welche Möglichkeiten der Datensynchronisation es gibt, wäre ich recht dankbar.

Gruß von aliponte

Ich hatte im wiki was mal gelesen, wo eine lokale OSM Datei mittels Changesets aktuell gehalten wird, wäre das nicht auch passend?

Ich muss mal schauen wo das stand…krams

Ja, das wäre nett, wenn du einmal schauen könntest.

Einstweilen mache ich es so: Ich aktualisiere meine osm-Datei (z.B. dat1.osm) mit dem dafür zuständigen JOSM-Befehl und speichere das Ergebnis unter neuem Namen (z.B. dat2.osm). Auf dat1.osm und dat2.osm wende ich einen Komparator für ASCII-Text an. (Es eignet sich z.B. “Windiff”, ein Programm, das als Tool auf der Windows98-CD mitgeliefert wurde.) Dann sieht man schon, was sich geändert hat. Aber leider muss man mehrere hundert Bildschirmseiten durchblättern und sich dabei die Änderungen selber mit der Hand als Extrakt herausschreiben. Das ist recht umständlich. Außerdem muss der gesamte Datenbestand, der lokal vorliegt, vom Server abgerufen werden, um ihn vergleichen zu können. Gäbe es die Möglichkeit, zunächst nur die Versionsnummern der zu vergleichenden Objekte abzurufen, dann bräuchte man nur die wenigen Objekte mit geänderter Versionsnummer herunterladen.

Gruß von aliponte

Um .osm-Dateien aktuell zu halten, gibts verschiedene Möglichkeiten. Da mir persönlich die Aktualisierung einmal täglich reicht, mach ich es generell so:
http://wiki.openstreetmap.org/wiki/Daily_update_an_OSM_XML_file

Wenn du dir viel Mühe machen willst, Änderungen geografisch sichtbar zu machen, könntest du dafür auch einen eigenen Layer rendern lassen:

Ah danke für die Recherche Marqqs, ich hatte das schon wieder total vergessen…

Danke für die guten Tipps. Schade nur, dass das Wochenende schon rum ist und das Ausprobieren etwas hintangestellt werden muss.

Gruß von aliponte

P.S. Gerade lese ich diesen Satz: This description assumes that you use Linux as operating system.

My humble question: Does this assumption really hold for the majority of osm contributors? Or does it mean, Windows users first have to change their OS? I don’t hope so.

Nun, der Verfasser hat kein Windows, und von den Windows-Nutzern hat sich noch keiner rangetraut.
Üblicherweise wird von Linux-Usern nur der Quellcode veröffentlicht, den sich jeder auf seinem OS selber complieren muß. Die meisten Windows-Nutzer haben dagegen desöfteren keine Möglichkiet oder Erfahrung im selberkompilieren.

Für das Programm osmfilter gibts jetzt eine Windows-exe. Aber ich habe es selber noch nicht getestet.

Es gibt aber auch Software, die unter Windows nicht so einfach laufen. Z.B. alles, was auf der perl-Adaption der Bibliothek proj4 aufbaut, z.B. mapgen.pl. Da habe ich mir schon die Zähne dran ausgebissen, und der Ersteller der Bibliothek hat wiederum kein Windows.

Gruß,
ajoessen

Ich kann mir natürlich nicht sicher sein, aber ich würde schätzen, dass Linux im Bereich der OSM-Entwickler und vor allem im Serverbereich für OSM-Karten das am weitesten verbreitete Betriebssystem ist. Durch den grundsätzlich offenen Ansatz (“Daten und Software von allen für alle”) können die Programme aber oft auf verschiedenen Plattformen genutzt werden.

Falls eine Plattform fehlt: bitte einfach die frei verfügbaren Quellen übersetzen.
Ich habe das grad für Windows gemacht, obwohl ich mit Windows gar nicht arbeite. Sehts als besonderen Service für die Windows-User. :wink:

Falls es mal kein Windows-Programm für einen bestimmten Zweck geben sollte: Linux ist kostenlos. Und man kann es auch mal schnell unter Windows in einer (ebenfalls kostenlosen) “Virtual Machine” installieren. Oder man nutzt Cygwin direkt unter Windows.
http://de.wikipedia.org/wiki/Ubuntu
http://de.wikipedia.org/wiki/Virtualbox
http://de.wikipedia.org/wiki/Cygwin

Trotzdem will ich die Bitte anhängen, Linux-Entwickler mögen - wenns die Zeit erlaubt - ihre Kommandozeilenprogramme z.B. mit MinGW auch für Windows übersetzen.
http://de.wikipedia.org/wiki/MinGW

So hab ich das mit osmfilter und inzwischen auch mit osmchange gemacht:
http://wiki.openstreetmap.org/wiki/Osmfilter
http://wiki.openstreetmap.org/wiki/Osmchange_%28program%29

Warum, die brauchen doch die Windows-Version nicht, das können müssen schon die Windowsnutzer organisieren, weil den Quellcode haben sie und damit ist es ja auch möglich. Wenn die POSIX-Unterstützung von Windows mistig ist, dann können sie entweder Workarounds als Patches an die Entwickler schicken oder bei Microsoft nach besserer Unterstützung betteln.

Verschwende doch bitte auch mal eine Sekunde an die Vorstellung, dass es Windows-Nutzer ohne abgeschlossenes Informatikstudium gibt. Die möchten einfach nur die Software benutzen, und nicht irgendwelche Bibliotheken neu kompilieren, weil irgendwas in Linux anders funktioniert als unter Windows.

Gruß,
ajoessen

Vielen Dank für deine Mühe! Ich bin schon gespannt, was sich mit den Werkzeugen anstellen lässt.

“Leider” soll das Wetter bei uns am WE gar so schön werden, so dass ich der Heimarbeit die Feldarbeit vorziehen werde. Erfolgs-/Misserfolgsbericht wird aber folgen.

Gruß von aliponte

Also sollen die Linuxbenutzer Software für die Windowsbenutzer compilieren, damit Letztere sie benutzen können? Zumindest ich habe, wenn ich Zeit habe, etwas anderes vor als Software aus gerechnet für Windowsbenutzer zu compilieren…

Bei solche Sprüchen dreht sich mir echt der Magen um. :frowning:

Wenn Du irgendwas für Benutzer zugänglich machen willst, dann mußt Du ihnen ein fertiges Executable bereitstellen. Benutzer sind nämlich nicht in der Lage etwas selbst zu bauen.

Wenn Du irgendwas für Benutzer zugänglich machen willst, dann mußt Du die Betriebssysteme unterstützen, die die Benutzer verwenden, nicht nur das was Du bevorzugst. Dir ist schon bekannt, welches Betriebssystem so gemeinhin im Rest der Welt überwiegend benutzt wird, oder?

Warum glaubst Du bieten so Blödel bei OSM Garmin-Karten auch in einem Format zum Download an, das Linux und Mac-User verwenden können, obwohl sie weder Linux noch Mac-User sind und von der restriktiven Politik von Apple überhaupt nichts halten? Wenn jeder denken würde wie Du sollte man sowas dann schleunigst entfernen. Wer so dumm ist einen Mac zu nutzen soll schon spüren was er davon hat. Und die Linux-Nutzer, die keine Zeit haben auch mal für Windows mitzukompilieren, denen drehn wir erst recht eine lange Nase.

Wenn Du die Meinung vertrittst: Mir doch sch***egal, wer das Zeug nicht bauen kann ist auch nicht würdig, mitzuspielen, dann begrenzt Du den Teilnehmerkreis auf eine Handvoll Computerfreaks. Nix mehr “open”. Auch nicht ganz das was Du unter “Community” in der Wikipedia findest. Eher sowas wie ein autistisch-exklusives “Elite Street Map”. Und Du fährst Dich mit dieser Haltung auch selber an die Wand. Es gibt da ein paar Tools mit so abgefahrenen Abhängigkeiten, daß auch Du sie auf Deinem erhabenen Linux nicht ohne Hilfe bauen kannst. Aber die Leute, die’s irgendwie hinbekommen, haben sicher was besseres zu tun, als es für Dich zu compilieren oder einzurichten.

Dann wünsch ich Dir mal eine gute Nacht - und daß Du nie in die peinliche Lage gerätst, ausgerechnet von einem Windowsbenutzer Rat oder Hilfe zu brauchen.

           Nop

Was ist denn so schwer an “./configure;make; sudo make install;ldconfig”? Das schaffen unter Linux erstaunlich viele fortgeschrittene Anwender (etwa das Level die unter Windows in der Lage sind, den neusten Treiber im Netz zu finden) und selbst dafür gibt’s soweit ich weis auch noch GUIs. Das Problem und nervige an dieser Art des Selberbauens, ist nur, daß man oft zuerst mal die Abhängigkeitspakete x und y so bauen muß um Anwendung z dann real installieren zu können. Nicht das es schwer wäre die Abhängigkeiten nachzulesen und zu bauen, nur das will man recht schnell automatisiert haben, weshalb selbst Quelldistrbutionen wie z.B. http://gentoo.org da Scriptsysteme zum Paketmanagment der Quellpakete haben. Aber da damit Installation für einen programmmäßig ordentlich ausgestattenen Desktop erst in 1,5 Tagen fertig ist, gibt es eben auch unter Linux im Normalfall Binärpakete. Was aber nichts daran ändert, das es vergleichsweise einfach ist, Anwendungen aus dem Quellcode selbst zu bauen.

Unterstützen, im Sinne von Bereitstellen bei Open Source (ähnlichen) Projekten, heißt aber nicht, das erst mal die passenden Anpassungen von den Entwicklern für Wunschzielsystem X gemacht werden müssen, ohne die das Programm dort nicht läuft, wobei niemand der Entwickler das System X selbst benutzt. Das wenn ein neues Release gebaut wird, es für alle unterstützten Systeme erscheint, ist völlig normal, auch wenn du kritisierst, daß genau das angeblich nicht passieren würde.

Nein, was ich nicht will, ist nicht das der Kartenbauer auch mit dem Generator auch einen Durchlauft für die Mac-Benutzen macht, wenn das Programm es unterstüzt, sondern, daß er das Generatorprogramm doch bitte erst ohne Eigeninteresse einmal für den Mac anpassen soll, weil dieser bisher noch nicht für die Kartenausgabe unterstützt wird.

Das heißt, daß die Windows-Leute sich eben selbst drum kümmern müssen, wie sie poll() für Windows in MinGW reinbekommen, weil die Unterstützung für die ganzen Windopwsformate und Programme würde im Normalden Linuxentwicklern und benutzern ja auch nicht auf dem silbernen Tablett serviert.

Siehe oben. “Open” meint ja auch Quelloffen, also du bekommst den Quellcode und darfst unter abweichenden Randbedingunen im Grunde damit machen, was du möchtest.

Ach das geht schon, ich habe dann irgendwann C gelernt und die POSIX-API (ja es geht man muß nur wollen, kann aber jetzt meine Compilierungsprobleme selbst fixen). Aber selbst mplayer mit allen Abhängigkeiten ist nach entsprechender Zeitdauer einfach über “./configure; make; make install” hinzubekommen, auch wenn die so ca. 20 Abhängigkeiten schon recht viel Zeit kosten. Da ist der Kernel noch einfach dageben, da muß man ja nur seine Hardware ganz genau kennen und die englische Doku lesen.

Das schwierige daran ist offenbar, dass es gewisse Dinge so unter Windows nicht gibt. Wenn ich in der Console ./configure eingebe dann passiert einfach nichts.
Und oft genug tun sich auch Linuxuser schwer. Ich habe bereits mehr als einmal versucht unter Linux Treiber für eine Grafikarte zu installieren. Einfach mit ./configure;make; war da nichts. Auch bei Windows kann man nämlich einen Treiber für Windows7 nicht einfach unter XP installieren und hoffen alles läuft. So ist es leider auch bei Linux. Teilweise ist man dort von bestimmten Versionen einzelner Pakete abhängig.

Dann trifft wieder der Spruch zu: “Computer helfen uns Probleme zu lösen, welche wir ohne sie nicht hätten.” Ich fange nämlich an statt irgendwas sinnvolles zu machen, wie eine Karte rendern, erst mal die Tools zu übersetzen und möglicherweise auch noch die Voraussetzungen dafür zu schaffen. Mehr als einmal bin ich daran schon gescheitert.