Einsatz der OSM-Daten NACH dem Redaction-Bot-Lauf ... von wem schon?

stephan75 · 2012-07-19T16:41:27.000Z

Vielleicht wäre jetzt mal schon interessant, welche Programme oder Webseiten die ganz aktuellen OSM-Daten aktiv nutzen, welche schon durch den Redaction-Prozess gelaufen sind.

Oder welche Websites haben den Datenbestand “eingefroren”?

(Damit meine ich Nutzungen, welche tatsächlich auf den Rohdaten beruhen und nicht nur auf bloßes Verwenden der aktuell neu berechneten Kachen.)

Als Anfang nenne ich mal den Service von http://ags.misterboo.de

Wenn sich schon was interessantes hier ansammelt, könnte im Wiki auch eine Seite mit einer Sammlung entstehen …

Stephan

poppei82 · 2012-07-19T17:48:17.000Z

Ich ärgere mich gerade. Habe bei keepright Fehler korrigiert und dann erst nachgeschaut, dass in der Botdurchlauf in dem Gebiet fehlerhaft war. Also konnte ich gleich meine Korrekturen in die Tonne kloppen…

okilimu · 2012-07-19T17:51:12.000Z

OSM-Straßenlistenauswertung: mein lokaler osm2pgsql daily-Import ist mit Stand 17.7. abgebrochen, wegen angeblich mehrfachen “\N” in einem Namen.

Jetzt läuft erstmal eine postgresql-Wartung der DB, dann versuche ich den Import neu zu starten.

Grüße

Dietmar aka okilimu

amm · 2012-07-19T17:58:03.000Z

Die Wikipedia Karten die zur Anzeige das OSM-gadget (und nicht dem WikiMiniAtlas) verwenden werden weiterhin mit den diffs aktuallisiert. Diese Zeigen also den Datenbestand nach dem der Redaction-Bot durch ist.

Wir hatten uns ueberlegt die diffs einzustellen und abzuwarten bis der groebste Schaden behoben wurde bevor wieder aktualisiert wird. Da aber gerade Wikimania (die all-jaehrliche Wikipedia Konferenz) war und dort unter anderem das WIWOSM Projekt vorgestellt wurde was wohl einiges an interesse hervorgerufen hat (sie dazu den anderen Thread), wurde entschieden das es wichtiger ist die aktuellen Daten fuer WIWOSM zu verwenden als die Nachteile der Lizenzumstellung zu umgehen.

wambacher · 2012-07-19T19:14:55.000Z

okilimu:

OSM-Straßenlistenauswertung: mein lokaler osm2pgsql daily-Import ist mit Stand 17.7. abgebrochen, wegen angeblich mehrfachen “\N” in einem Namen.

Jetzt läuft erstmal eine postgresql-Wartung der DB, dann versuche ich den Import neu zu starten.

Grüße

Dietmar aka okilimu

kannst du mir mal die id sagen, würde ich mir gerne mal in meiner db ansehen.

Gruss
walter

wambacher · 2012-07-19T19:19:39.000Z

amm:

Die Wikipedia Karten die zur Anzeige das OSM-gadget (und nicht dem WikiMiniAtlas) verwenden werden weiterhin mit den diffs aktuallisiert. Diese Zeigen also den Datenbestand nach dem der Redaction-Bot durch ist.

Wir hatten uns ueberlegt die diffs einzustellen und abzuwarten bis der groebste Schaden behoben wurde bevor wieder aktualisiert wird. Da aber gerade Wikimania (die all-jaehrliche Wikipedia Konferenz) war und dort unter anderem das WIWOSM Projekt vorgestellt wurde was wohl einiges an interesse hervorgerufen hat (sie dazu den anderen Thread), wurde entschieden das es wichtiger ist die aktuellen Daten fuer WIWOSM zu verwenden als die Nachteile der Lizenzumstellung zu umgehen.

ich lade die diffs minütlich in meine postgresql-db rein. Bisher ohne Probleme - dauert halt nur ein wenig länger. Vorher lag mein Lag bei maximal 120 Sekunden, jetzt hab ich schon mal Lags von 3-4 Minuten. Aber absolut keine unangenehmen Vorfälle.

Bild ist statisch.

Gruss
walter

die Zacken kommen daher, dass er vormittags erstmal die Nacht “verdauen” muss.

SunCobalt · 2012-07-19T19:25:06.000Z

wambacher:

okilimu:

OSM-Straßenlistenauswertung: mein lokaler osm2pgsql daily-Import ist mit Stand 17.7. abgebrochen, wegen angeblich mehrfachen “\N” in einem Namen.

Jetzt läuft erstmal eine postgresql-Wartung der DB, dann versuche ich den Import neu zu starten.

Grüße

Dietmar aka okilimu

kannst du mir mal die id sagen, würde ich mir gerne mal in meiner db ansehen.

Das \N hatte ich auch schon öfter gesehen. Mein Renderer bricht immer ab, wenn so ein Zeichen auftaucht und ich habe die immer händisch in der DB und bei OSM korrigiert. Wäre mal interessant, wo das herkommt.

wambacher · 2012-07-19T19:54:45.000Z

SunCobalt:

Das \N hatte ich auch schon öfter gesehen. Mein Renderer bricht immer ab, wenn so ein Zeichen auftaucht und ich habe die immer händisch in der DB und bei OSM korrigiert. Wäre mal interessant, wo das herkommt.

\n ist ja ein Zeilenumbruch. eventuell mach die Anwendung, die den Datensatz erzeugt (also nach osm reinschiebt) da was falsch. ich tippe mal auf eine der neuen apps, die nehmen das nicht so genau.

frag doch mal den Ersteller des Objektes, was er so benutzt. Ausserdem sollte der Renderer etwas toleranter sein. da mal den softy anhauen.

gruss
walter

hier noch was zum Thema Apps - allerdings “leicht ot” http://ruthe.de/index.php?pic=2095&sort=datum&order=ASC

okilimu · 2012-07-19T20:37:13.000Z

wambacher:

okilimu:

OSM-Straßenlistenauswertung: mein lokaler osm2pgsql daily-Import ist mit Stand 17.7. abgebrochen, wegen angeblich mehrfachen “\N” in einem Namen.

Jetzt läuft erstmal eine postgresql-Wartung der DB, dann versuche ich den Import neu zu starten.

Grüße

Dietmar aka okilimu

kannst du mir mal die id sagen, würde ich mir gerne mal in meiner db ansehen.

Gruss
walter

Das kommt im osm2pgsql.log an.

WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
CONTEXT:  COPY planet_polygon, line 1: "20467321	\N	\N	\N	\N	\N	\N	\N	university	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N	\N..."
COPY_END for planet_polygon failed: SSL SYSCALL error: EOF detected

Error occurred, cleaning up

in der planet_polygon war die Id dann aber nicht vorhanden.

Vorschläge zur Fehlerbeseitigung werden sehr gerne von mir gelesen

Grüße

Dietmar

SunCobalt · 2012-07-19T20:42:51.000Z

das hier
http://www.openstreetmap.org/browse/way/20467321
?
University würde passen

SunCobalt · 2012-07-19T20:53:52.000Z

bei mir in einer 1 Monat alten DB ist diese ID in osm_polygon. Aber da sind keine \N…vielleicht sind die in der hstore. Ich schaue mal morgen, ob osmosis oder ein anderes Programm eine OSM ID filtern kann… falls es geht. Ich habe noch einige alte Extrakte hier.

wambacher · 2012-07-19T23:53:57.000Z

SunCobalt:

bei mir in einer 1 Monat alten DB ist diese ID in osm_polygon. Aber da sind keine \N…vielleicht sind die in der hstore. Ich schaue mal morgen, ob osmosis oder ein anderes Programm eine OSM ID filtern kann… falls es geht. Ich habe noch einige alte Extrakte hier.

Die \N sind nur die Feldtrenner, die der COPY-Befehl von postgresql verwendet. Die listet er nur mit auf, wenn er einen Datensatz auflistet. In anderen Worten: die sind immer da und stehen so nicht in den Rohdaten (planet). Ist etwa so wie bei csv-filles: feld trenner feld trenner …

in meiner db, die ja über osmosis geladen wird, ist das namensfeld absolut sauber . "


> select id,tags from ways where id=20467321;

    id    |                                          tags                                           
----------+-----------------------------------------------------------------------------------------
 20467321 | "name"=>"Gebäude 14,  Elektrotechnik/Chemie/Verfahrenstechnik", "amenity"=>"university"

ich habe irgendwie das Gefühl, als ob der nächste Datensatz -also der vom nächsten Objekt - das Problem darstellt. Die Meldung sagt ja, dass hier eof wäre. Da klappt irgendeine Konvertierung nicht und postgresql bekommt zuwenig Daten.
Vorschlag: Rohdaten mit nem tool vom .pbf nach .osm konvertieren und den Nachfolger mit grep suchen.
oder irgendwelche debug-optionen aktivieren, falls es die bei dem import-tool geben sollte.

noch nen schuss ins Blaue: windows mit ntfs-partition und dabei 2gb filegröße überschritten??? da war doch mal was???
oder gar disk full im temp-bereich?

gruss
walter