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

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...

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

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.

okilimu wrote:

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

amm wrote:

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.

wambacher wrote:

okilimu wrote:

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.

SunCobalt wrote:

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

wambacher wrote:

okilimu wrote:

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

das hier
http://www.openstreetmap.org/browse/way/20467321

University würde passen

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.

SunCobalt wrote:

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