Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
Normalerweise ist der Bottleneck bei einem Datenbankimport der Import selbst, also die Datenbank bzw. der damit einhergehende I/O. Da macht es wenig Unterschied welche Programmiersprache Du verwendest. Um welche Daten geht es denn hier? So wie ich das verstanden habe, sind es ja nur ein paar POIs, die Du importieren willst, das sollte nicht wirklich sehr aufwändig sein. Jochen Das Problem ist, dass ich basierend auf dem Typ des Poi, den vorhanden tags und dem Alter/letzte Änderung einen Wert berechne. Gereicht hätte es, nur bei Veränderungen neu zu berechnen - das sind dann nur eine Handvoll pro Tag. Wenn ich aber täglich einen Komplettimport mache, muss ich ja auch ALLES neu berechnen lassen, und das werden wohl ein paar zigtausend sein. Du hast mir schonmal sehr geholfen, jetzt weiss ich zumindest warum es nicht so geht wie ich dachte... Vielen Dank dafür! Kevin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Fri, Aug 04, 2017 at 12:46:56PM +0200, Kevin Hemker wrote: > > Ja, aber das muss eine Datenbank sein, die komplett alle Daten enthält. > > In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte > > Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways > > oder Ways in Relationen der Fall ist. > > > Verstehe ich das also richtig: Wenn an einem Way nur Tags geändert wurden > ist im .osc nur der Way mit den Tags, sowie den ID-Referenzen auf die Knoten > enthalten - die zugehörigen Nodes als solche fehlen aber, weil unverändert. > Wurde aber das Element in seiner Lage verändert, so sind neben den > Referenzen auch diejenigen Nodes komplett enthalten, die verschoben wurden? Jopp, das ist richtig. > > Aber eine allgemeine Empfehlung: Das OSM-Datenmodell ist komplex und das > > mit den Änderungen richtig hinzubekommen ist schwierig. Wenn es irgend > > geht, dann würde ich lieber einmal am Tag oder einmal die Woche einen > > kompletten Neuimport durchlaufen lassen oder so. Das macht es viel > > einfacher. > > > > Jochen > > Nach Erstsicht der augmented diffs teile ich diese Einschätzung; das > auseinanderzufriemeln wäre von der Performance her wahrscheinlich auch nicht > produktiver. > Allerdings ist ein kompletter Neuimport schon ein ziemlicher Overhead, > zurzeit ist die Updateroutine beim Projekt in PHP umgesetzt. > Für einen häufigeren Neuimport müsste ich mich dann wohl in C|Java > einarbeiten. Normalerweise ist der Bottleneck bei einem Datenbankimport der Import selbst, also die Datenbank bzw. der damit einhergehende I/O. Da macht es wenig Unterschied welche Programmiersprache Du verwendest. Um welche Daten geht es denn hier? So wie ich das verstanden habe, sind es ja nur ein paar POIs, die Du importieren willst, das sollte nicht wirklich sehr aufwändig sein. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
Ja, aber das muss eine Datenbank sein, die komplett alle Daten enthält. In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways oder Ways in Relationen der Fall ist. Verstehe ich das also richtig: Wenn an einem Way nur Tags geändert wurden ist im .osc nur der Way mit den Tags, sowie den ID-Referenzen auf die Knoten enthalten - die zugehörigen Nodes als solche fehlen aber, weil unverändert. Wurde aber das Element in seiner Lage verändert, so sind neben den Referenzen auch diejenigen Nodes komplett enthalten, die verschoben wurden? Aber eine allgemeine Empfehlung: Das OSM-Datenmodell ist komplex und das mit den Änderungen richtig hinzubekommen ist schwierig. Wenn es irgend geht, dann würde ich lieber einmal am Tag oder einmal die Woche einen kompletten Neuimport durchlaufen lassen oder so. Das macht es viel einfacher. Jochen Nach Erstsicht der augmented diffs teile ich diese Einschätzung; das auseinanderzufriemeln wäre von der Performance her wahrscheinlich auch nicht produktiver. Allerdings ist ein kompletter Neuimport schon ein ziemlicher Overhead, zurzeit ist die Updateroutine beim Projekt in PHP umgesetzt. Für einen häufigeren Neuimport müsste ich mich dann wohl in C|Java einarbeiten. Wenn aber obiger Sachverhalt so ist wie ich denke (kannst du mir das netterweise noch kurz bestätigen) kann ich damit vielleicht was anfangen, auf die exakte 10cm Position kommt es mir bei Gebäuden nicht an, Hauptsache man findet es :) Womöglich habt Ihr mitbekommen, dass ich (sorry dafür) ein cross-post gestartet hab. Damit das nicht so bleibt würde ich gern eine Zusammenfassung vom Bisherigen ins Forum packen und darum bitten, weitere Tipps dort zu posten. Dankeschön ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Fri, Aug 04, 2017 at 10:54:49AM +0200, Kevin Hemker wrote: > Allerdings dachte ich, gerade die osmChange-Dateien sind geeignet > Datenbanken aktuell zu halten... Ja, aber das muss eine Datenbank sein, die komplett alle Daten enthält. In den .osc-Dateien sind nur geänderte Objekte drin, nicht ungeänderte Objekte, die mit den geänderten zusammenhängen, wie es bei Nodes in Ways oder Ways in Relationen der Fall ist. > Ziel ist, eine eigene MySQL-Datenbank (die Informationen über Poi vorhält) > zu aktualisieren. Ways (also typischerweise Gebäude) sind darin durch ihren > Mittelpunkt repräsentiert. Bisher habe ich dazu (testweise in kleineren > Gebieten) den csv-export von overpass genutzt (DB-Inhalte vorher gelöscht > und dann neu eingespielt), aber nun möchte ich das Gebiet ausweiten und die > DB entsprechend aktualisieren statt täglich komplett neu zu füllen. > > Um dabei nicht jeden einzelnen Änderungseintrag durch meine DB-Updateroutine > jagen zu müssen und dort zu prüfen, ob er überhaupt in die DB soll möchte > ich vorher schon filtern, was wesentlich performanter ist. Du kannst versuchen, auf die augmented diffs zurückzugreifen, die haben dann alle abhängigen Objekte in der alten und neuen Version drin. Aber eine allgemeine Empfehlung: Das OSM-Datenmodell ist komplex und das mit den Änderungen richtig hinzubekommen ist schwierig. Wenn es irgend geht, dann würde ich lieber einmal am Tag oder einmal die Woche einen kompletten Neuimport durchlaufen lassen oder so. Das macht es viel einfacher. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
Hallo Jochen, vielen Dank für den Hinweis, das sehe ich mir an. Allerdings dachte ich, gerade die osmChange-Dateien sind geeignet Datenbanken aktuell zu halten... Ziel ist, eine eigene MySQL-Datenbank (die Informationen über Poi vorhält) zu aktualisieren. Ways (also typischerweise Gebäude) sind darin durch ihren Mittelpunkt repräsentiert. Bisher habe ich dazu (testweise in kleineren Gebieten) den csv-export von overpass genutzt (DB-Inhalte vorher gelöscht und dann neu eingespielt), aber nun möchte ich das Gebiet ausweiten und die DB entsprechend aktualisieren statt täglich komplett neu zu füllen. Um dabei nicht jeden einzelnen Änderungseintrag durch meine DB-Updateroutine jagen zu müssen und dort zu prüfen, ob er überhaupt in die DB soll möchte ich vorher schon filtern, was wesentlich performanter ist. LG Am 04.08.2017 um 10:24 schrieb Jochen Topf: On Thu, Aug 03, 2017 at 10:40:05PM +0200, Kevin Hemker wrote: eigentlich ja keine große Sache, aber nach etlichen Stunden Verzweiflung wende ich mich an euch und hoffe auf Hilfe: Ausgangspunkt: .osc-Datei vom osm-Server. Das Filtern soll folgendes Ergebnis liefern: * keine Relationen mehr * alle ways zu nodes konvertiert * nur nodes behalten, die ein paar bestimmte keys haben. Eine .osc-Datei enthält zu einem Way nicht unbedingt alle Nodes, die in diesem Way sind. Daher wirst Du mit diesem Ansatz immer Probleme haben. Was willst Du denn am Ende erreichen? Wenn das Ziel ist, rauszufinden, wo es überall Änderungen bestimmter Art gegeben hast, dann reichen die .osc-Dateien nicht als Datenquelle aus. Du kannst Dir mal http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs anschauen, vielleicht hilft Dir das weiter. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ich verzeifle daran eine .osc-Datei zu filtern
On Thu, Aug 03, 2017 at 10:40:05PM +0200, Kevin Hemker wrote: > eigentlich ja keine große Sache, aber nach etlichen Stunden Verzweiflung > wende ich mich an euch und hoffe auf Hilfe: > > Ausgangspunkt: .osc-Datei vom osm-Server. Das Filtern soll folgendes > Ergebnis liefern: > > * keine Relationen mehr > * alle ways zu nodes konvertiert > * nur nodes behalten, die ein paar bestimmte keys haben. Eine .osc-Datei enthält zu einem Way nicht unbedingt alle Nodes, die in diesem Way sind. Daher wirst Du mit diesem Ansatz immer Probleme haben. Was willst Du denn am Ende erreichen? Wenn das Ziel ist, rauszufinden, wo es überall Änderungen bestimmter Art gegeben hast, dann reichen die .osc-Dateien nicht als Datenquelle aus. Du kannst Dir mal http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs anschauen, vielleicht hilft Dir das weiter. Jochen -- Jochen Topf joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS als deutsches OSMF-Chapter
On Thursday 03 August 2017, Frederik Ramm wrote: >der FOSSGIS-Vorstand sammelt jetzt die Unterlagen zusammen, die > die OSMF für eine Local Chapter-Bewerbung braucht > (http://wiki.osmfoundation.org/wiki/Local_Chapters/Application_docume >nts). > > Wir haben das Standard-"Local Chapter Agreement" gründlich geprüft > und möchten der OSMF anbieten, es mit nur wenigen Änderungen zu > unterschreiben. Diese Änderungen sind: Insgesamt sieht das erst mal gut aus aus meiner Sicht und folglich gibt es für mich keine Bedenken, die ich im Konsultations-Prozess noch vorbringen wollen würde. > Dass nicht jeder zu einer Mitgliederversammlung kommen kann und will, > ist uns bewusst. Schon heute kann man seine Stimme an jemand anderen > übertragen, wenn man will; richtig ist, dass wir etwas klarer sagen > sollten, wie das geht. Die Möglichkeit der "Remote-Teilnahme" möchten > wir für die Zukunft weiter untersuchen. Hier sollte erwähnt werden, dass die Stimmübertragung per Satzung derzeit auf eine zusätzliche Stimme pro anwesendem Mitglied beschränkt ist. > "Das Verfahren, Mitglied zu werden, könnte etwas weniger antik und > weniger abschreckend gestaltet werden" > > Da wird vom Vorstand schon ein Satzungsänderungsantrag für die 2018er > MV vorbereitet, der es ermöglichen soll, online Mitglied zu werden. > Der muss dann natürlich von den Mitgliedern genehmigt werden, aber > ich sehe nicht, wieso jemand was dagegen haben könnte. Das klingt gut. Vielleicht noch als Erläuterung zu meiner etwas salopp formulierten Amerkung: Derzeit sagt die Satzung des FOSSGIS, dass der Vorstand über die Aufnahme neuer Mitglieder entscheidet wobei Ablehnungen von der Mitgliederversammlung bestätigt werden müssen [1]. Das tritt zwar praktisch vermutlich so gut wie nie auf, steht aber formell ein bisschen im Konflikt mit einer Anforderung der OSMF [2], welche sagt: "...should allow easy and mass membership and democratic participation in the decisions processes". > Es wurde angemerkt, dass es im FOSSGIS ein Stimmrecht für juristische > Personen gibt, bei der OSMF aber nicht. Der FOSSGIS-Vorstand sieht > hier derzeit keinen Handlungsbedarf, vorallem, weil es sich bei den > 24 juristischen Personen, die im FOSSGIS Mitglied sind, in den > meisten Fällen um Klein- und Kleinstunternehmen handelt und nicht um > das "große Kapital". Klar, aber das ist halt eine gewisse Ungleich-Behandlung. Wenn Du zum Beispiel eine persönliche Mitgliedschaft hast und eine Firmen-Mitgliedschaft für die Geofabrik dann hast Du im Prinzip zwei Stimmen. Ich sehe eigentlich keinen triftigen Grund, weshalb das Stimmrecht in der Mitgliederversammlung nich auf natürliche Personen beschränkt werden kann aber das kann man ja problemlos jederzeit als Satzungsänderungsantrag einreichen. Grundsätzlich wird für einen Erfolg des FOSSGIS als local chapter entscheidend sein, dass sich die OSM-Aktiven auch in größerer Zahl dort beteiligen. Ist dies erst einmal der Fall ist eigentlich auch sichergestellt, dass die Interessen der deutschen OSM-Community im Verein ausreichend repräsentiert werden. [1] https://www.fossgis.de/verein_satzung.html [2] http://wiki.osmfoundation.org/wiki/Local_Chapters/FAQ -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
