[Talk-de] AIO fehlt völlig

[Felix Hartmann]

On 06.01.2011 23:37, flabot at googlemail.com wrote:
>> Klar, derzeit ist es nur bedingt brauchbar. Aber der komplette Code der
>> benötigt wird, ist hier online:
>> http://sourceforge.net/projects/cgpsmapper/
>>
>> Da dies Sourcecode erst seit gut zwei Wochen online ist, wurde er bisher
>> noch nicht genutzt um es in mkgmap zu implementieren. Steve hat dies
>> angekündigt. Primär scheinen in mkgmap einige Indexes im mdr falsch
>> sortiert, bzw fehlen noch.
>> Da cgpsmapper einen korrekt funktionierenden Index schreiben kann, wird es
>> wohl bei mkgmap nicht mehr lange dauern. Entweder Steve oder jemand anders
>> wird es schon schaffen noch die Änderungen zu implementieren.
>>
>> (damit steht dann primär noch das kaputte Intertilerouting zu korrigieren in
>> mgkmap, sowie eine bessere transliteration von Sonderzeichen / anderen
>> Alphabeten).
>>
>
> alles bekannt, aber jetzt werde dich bitte mal konkret was du mit dem
> vielem Ram für einen Index
> rechnen wilst ? Bitte um Codebeispiele was du machst.
>
> Dirk
>
>
>
Ich mach damit gar nichts, aber soweit ich erkennen kann, lädt mkgmap 
zur Indexerstellung alle Tiles auf einmal in den RAM.
Siehe: uk\me\parabola\mkgmap\combiners\mdrbuilder.java

Wahrscheinlich müsste man hier nur umprogrammieren, dass ein temporärer 
Speicher auf der Festplatte erstellt wird, statt alles im RAM zu machen. 
Das Problem ist halt, dass die Straßen zu den Cities gematcht werden 
müssen, da wir ja blöderweise bei OSM nicht dazuschreiben (wie in jeder 
professionellen Geodatenbank) zu welcher Stadt/Gemeinde/Land eine Straße 
gehört. Also muss mkgmap den Cityrecord durchgehen, und die nächste 
Stadt ist eben nicht zwingend in derselben Kachel, wo die Straße sich 
befindet. Also müsste man, wenn man nicht alle Kacheln auf einmal laden 
will, halt Etappenweise vorgehen mit Überschneidungen - was halt 
komplizierter ist, als alles in eine Datenbank vor der Indexerstellung 
zu schmeißen.

Oder in Etappe 1, eine Datenbank der Cities erstellen und hier Kachel 
für Kachel in den Ram laden, und dann in einer zweiten Etappe die 
Straßen dagegen Matchen, dabei aber die Kacheln neu in den Ram laden, 
statt aus Step 1 noch drinnenzubehalten. Am einfachsten wäre wohl, wenn 
der User angibt wieviel RAM zur Verfügung steht, dann durch 20 geteilt 
wird, und dass die maximale Anzahl der Kacheln ist, die in einem Rutsch 
geladen wird. Wenn nicht müsste man den Index in zwei statt in einem 
Schritt erstellen (also etwa doppelte Erstellungszeit, wenn genug Ram 
frei gewesen wäre).

Oder anders: Ich will nicht soviel RAM, aber da eben alle Kacheln auf 
einmal eingelesen werden, wird zurzeit halt etwa Kachelgröße mal 1.2 an 
verfügbarem Ram benötigt. Und wenn der Rechner hier zu swappen anfängt, 
dann braucht es derzeit ewig. Ich bin kein Programmierer, daher kann ich 
das nicht ändern. Bin eh schon froh wenn ich solche Files halbwegs lesen 
kann.