On 06.01.2011 23:37, fla...@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.
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
