[OSM-Devserver] ist gauss tot?

[Christoph Wagner]

Sven Geggus schrieb:
> Tobias Wendorff <tobias.wendorff at uni-dortmund.de> wrote:
> 
>> Ich verstehe leider immer noch nicht, welcher Teil deiner Tools soviel
>> Speicher, I/O und CPU zieht ...
> 
> Christoph alleine ist noch nicht das Problem.

Nun ja, heute war ich es wohl.

Als ich vorhin reingesehen hab, hab ich noch nen blöden bug gefunden.
Ich hab ja alles super gebastelt, damit der splitter die alten kachelgrenzen gleich nochmal nehmen kann.
Leider hatte ich an einer blöden stelle ein rm zu viel drin und eben diese kachelgrenzen wurden eiskalt gelöscht.
Das gab ein paar unschöne nebeneffekte, aber ab morgen sollte es wieder planmäßig laufen.
Muss halt neu splitten.

>> was machst Du denn genau?
> 
> Mit pstree und (h)top sieht man doch ganz genau was er macht. Der normale
> Workflow um Garminkarte zu erzeugen halt. Jetzt im Moment zum Beispiel läuft
> der Tilesplitter, der Europa in geschickte Kacheln schnippelt.

genau, so grob erst schnippeln, dann europa für verschiedene layer konvertieren, dann alle länder aus den konvertierten layern zusammenstellen, alles komprimieren und fertig.

>> Hast Du die Tools selbst geschrieben oder greifst Du auf externe Tools
>> zu? Vielleicht sind diese irgendwie ineffizient.

Ja sind sie. ich kann auch genau die Stellen benennen, die ineffizient sind.
Ich habe bisher alles in meiner Macht stehende versucht, um den gesamten Prozess etwas performanter hinzubekommen, aber es gibt ein paar Stellen, wo man tief in Javacode wühlen müsste, um da noch was zu reißen.
Das ist:
1. tilesplitter
Man könnte durchaus versuchen das Europafile parallel zu entpacken, also beispielsweise an 3 verschiedenen stellen anfangen zu lesen und dann parallel die 3 streams zu parsen und in die Daten in die richtigen Kacheln stecken.
Das geht natürlich dann, wenn man schon ne vorgefertigte Liste mit Kacheln hat und nicht komplett neu splittet. Ist halt aber aufwändig das einzubauen.

2. mkgmap
Noch aufwändiger ist es in mkgmap rumzupfuschen. Der für mich ideale Weg wäre, wenn mkgmap einmal die Daten liest und dann mit 5 oder mehr verschiedenen styles und optionen verarbeiten kann und 5 outputstreams erzeugt.
Dann könnte man alle layer auf einmal rechnen und müsste die Daten nur einmal lesen. Momentan muss ich halt 5 mal die gleichen Daten separat lesen.
Ich hab schonmal auf der dev-liste von mkgmap gefragt, aber die leute, die sich da auskennen meinten, es wäre ein ziemlicher aufwand und würde so ziemlich viel umkrempeln.
Vielleicht gibts ja da auch noch ne einfachere Variante so mit Java wrapper oder so, der eben die input files einmal liest und an 5 mkgmap programme schön reinfüttert. hab sowas aber noch nie gemacht.
Kein plan ob das überhaupt funktionieren würde.

> Schau doch einfach mal bevor Du hier merkwürdige Fragen stellst:
> /osm/garmin/aio/Makefile

Ich bin mir gar nicht sicher, wie gut man da noch durchsehen könnte. Ist halt irgendwie iterativ entstanden. Hab in letzter Zeit schon versucht n bissel zu dokumentieren, aber weiß nicht wie erfolgreich.

> Natürlich hat Christoph den Workflow um aus OSM Daten Garminkarten zu
> rechnen nicht selber neu implementiert.

Nee, der Workflow alleine macht schon genug Mühe! Hätt ich gar nicht gedacht, dass das so stressig sein kann.

>> Ich muss gestehen, dass ich in meinem Leben immer maximal mit 4 GB
>> ausgekommen bin und wundere mich daher ;-)
> 
> Bei der Verabeitung von großen Ausschnitten der OSM Daten?! Dann bist Du ein
> Künstler.
> 

Jo, das Problem ist hier eigentlich echt das routingfähige Netz von Europa zu berechnen. Dafür braucht er am meisten.
Die restlichen GB Hauptspeicher krieg ich auch ganz schnell alle, wenn ich beispielsweise die layer parallel berechnen lasse.
Ich mein es gibt ja auch neben dem eigentlichen konvertieren mit mkgmap ein haufen kleine sachen die mal eben parallel rechnen können, z.B. das einpacken der ganzen Dateien oder so.


Grüße
Christoph



-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.openstreetmap.de/pipermail/devserver/attachments/20100422/c777dd62/attachment.pgp>