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.)
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…
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.
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.
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
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?
