Re: [Talk-de] incremental update einer osm sql-database - geht das?
Walter Nordmann schrieb: den wiki, auf den peter hingewiesen hat, hab ich glatt übersehen :( Gibt's auch erst seit einigen Tagen. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] incremental update einer osm sql-database - geht das?
Walter Nordmann schrieb: konkreter: kann man mit einen planet change-file eine sql-datenbank auf dem aktuellen stand halten? Ja. http://wiki.openstreetmap.org/wiki/DE:HowtoMinutelyHstore Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] incremental update einer osm sql-database - geht das?
danke an alle, den wiki, auf den peter hingewiesen hat, hab ich glatt übersehen :( aber auch florians hinweise sind nicht von pappe. dann werd ich wohl mal loslegen. mfg walter - Mauern um Friedhöfe sind Blödsinn: Die, die drin sind, können nicht raus - die, die draußen sind, wollen nicht rein. -- View this message in context: http://gis.638310.n2.nabble.com/incremental-update-einer-osm-sql-database-geht-das-tp5154153p5159175.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] incremental update einer osm sql-database - geht das?
hi, derzeit hole ich mir für bestimmte auswertungen (z.b. dortmund) die dayly oder hourly change-files von planet.openstreetmap.org, merge die mit osmosis in das aktuelle osm-file und werte dann in perl das neue aktualisierte osm-file aus. funktioniert eigentlich prima aber es dauert halt verdammt lange. und ist doch sehr unflexibel. macht es sinn, das ganze auf sql (postgresql oder lieber noch mysql) umzustellen? konkreter: kann man mit einen planet change-file eine sql-datenbank auf dem aktuellen stand halten? mfg walter - Mauern um Friedhöfe sind Blödsinn: Die, die drin sind, können nicht raus - die, die draußen sind, wollen nicht rein. -- View this message in context: http://gis.638310.n2.nabble.com/incremental-update-einer-osm-sql-database-geht-das-tp5154153p5154153.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] incremental update einer osm sql-database - geht das?
On Tue, Jun 08, 2010 at 08:23:08AM -0700, Walter Nordmann wrote: hi, derzeit hole ich mir für bestimmte auswertungen (z.b. dortmund) die dayly oder hourly change-files von planet.openstreetmap.org, merge die mit osmosis in das aktuelle osm-file und werte dann in perl das neue aktualisierte osm-file aus. funktioniert eigentlich prima aber es dauert halt verdammt lange. und ist doch sehr unflexibel. macht es sinn, das ganze auf sql (postgresql oder lieber noch mysql) umzustellen? konkreter: kann man mit einen planet change-file eine sql-datenbank auf dem aktuellen stand halten? Es ist kein Problem, wenn dir das simple-Schema von Osmosis ausreicht. Datenbank mit dem Skript script/pgsql_simple_schema_0.6.sql anlegen, dein osm-File mit --write-pgsql-Task importieren und dann beim Updated einfach den --write-xml-change-Task durch den --write-pgsql-change-Task ersetzen. Auf meiner Maschine (DualCore mit 2GB RAM) dauert das Update für 24 Stunden (also 24 hourly change-files oder 1 daily change-file) etwa 1.5h, wenn keine Geometrien für die Objekte erstellt werden. Wie lange im Vergleich dazu das Update einer osm-Datei braucht, habe ich nicht probiert. Noch ein kleiner Hinweis: achte darauf, dass beim Anlegen der Datenbank ein Index über das Feld relation_id in der Tabelle relation_members erstellt wird. Bis vor zwei Wochen fehlte das im Skript. Ohne diesen Index kann das Update mal schnell 8 Stunden brauchen. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] incremental update einer osm sql-database - geht das?
On Tue, Jun 08, 2010 at 01:56:46PM -0700, Walter Nordmann wrote: Es ist kein Problem, wenn dir das simple-Schema von Osmosis ausreicht. Datenbank mit dem Skript script/pgsql_simple_schema_0.6.sql anlegen, dein osm-File mit --write-pgsql-Task importieren und dann beim Updated einfach den --write-xml-change-Task durch den --write-pgsql-change-Task ersetzen. - 1x osm - sql konvertieren - osmosis merged db und xxx.osc und schreibt alles wieder in db. Jein - osmosis applied jeden einzelnen change in der .osc datei direkt in der datenbank. - alle anderen osmosis-aufgaben (poly-filter, ...) bleiben wie gehabt. macht irgendwie sinn ;) Aeh ja nein - also osmosis dazu zu benutzen die daten aus der sql db zu saugen um dann einen osmosis poly filter anzuwenden macht keinen sinn. Das kann postgis schneller ... Dafuer muss man sich nen bischen mit sql auseinandersetzen und den poly als multipolygon in der Datenbank ablegen. Ach ja - wenn du OSM files haben willst fuer einen ausschnitt macht der postgres/postgis weg keinen wirklichen sinn. Dann ist das nur overhead. Wenn es aber darum geht bestimmte elemente in dem ausschnitt zu identifizieren dann geht das in der postgis effizienter und schneller. Also interessant waere mal was du weiter vor hast. Auf meiner Maschine (DualCore mit 2GB RAM) dauert das Update für 24 Stunden (also 24 hourly change-files oder 1 daily change-file) etwa 1.5h, wenn keine Geometrien für die Objekte erstellt werden. Wie lange im Vergleich dazu das Update einer osm-Datei braucht, habe ich nicht probiert. osmosis braucht fuer dortmund ca 90 sekunden (hourly change); allerdings die nachfolgenden perl-auswertungen ca 4-10 minuten. gerade hier verspreche ich mir verbesserungen. Die Frage ist - was wertest du das aus? postgres/posgis nur als speicherort fuer ein osm file ist quatsch. Noch ein kleiner Hinweis: achte darauf, dass beim Anlegen der Datenbank ein Index über das Feld relation_id in der Tabelle relation_members erstellt wird. Bis vor zwei Wochen fehlte das im Skript. sollte kein Problem sein, da ich jetzt - nach deiner ermutigenden antwort - quasi bei null anfange ;) kleine zusatzfrage (auch an den rest der gemeinde): wie sieht es mit mysql aus? mysql hab ich seid jahren für andere sachen (mambo/joomla) im einsatz. Vergiss es ... Wenn du wirklich was mit geometrien machen willst dann nimmt der user postgres mit postgis ... Da macht die Datenbank die harte arbeit geometrien miteinander zu verarbeiten ... Flo -- Florian Lohoff f...@zz.de Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
