Pomalé vykreslování se zapnutými POIs: vyřešeno!

[WTFK]

Všiml jsem si že TT6 se po zapnutí POIs, které mají pár tisíc položek (CZ-Restaurace, CZ-Geocaching) silně zpomaluje. Koukal jsem se na .OV2 soubory, a obsahují pouze záznamy typu 2, tj nejsou tam žádné bounding boxy (záznam typu 1), takže TT musí vždy procházet celý seznam. Zkusil jsem ze souborů udělat hierarchické s bboxy, kupodivu fungují a je to řádově rychlejší. Podle toho že při downloadu je značná prodleva, úměrná zhruba velikosti souboru, soudím že se OV2 generuje dynamicky. Bylo by možné, aby optimalizované .OV2 soubory generoval přímo server POI.CZ? Já je generuju tímhle kódem- make_tree() vytvoří ze seznamu 3-tuple (N, E, text) strom, a save_tree() ho uloží v .OV2 formátu.

Kód: Select All

def make_tree(l):
    if len(l) <= threshold: # default je 8
        return sum([14 + len(x[2]) for x in l]), l
    lo = list(l[0][:2])
    hi = [lo[0] + 1, lo[1] + 1]
    for i in l:
        for d in range(2):
            lo[d] = min(lo[d], i[d])
            hi[d] = max(hi[d], i[d] + 1)
    d = int(hi[1] - lo[1] > hi[0] - lo[0])
    t = (lo[d] + hi[d]) / 2
    t1 = make_tree([x for x in l if x[d] < t])
    t2 = make_tree([x for x in l if x[d] >= t])
    return 21 + t1[0] + t2[0], lo, hi, t1, t2

def save_tree(t):
    if len(t) == 2:
        for i in t[1]:
            sys.stdout.write(
                pack('<BIII', 2, 14 + len(i[2]), i[1], i[0]) + i[2] + '\0')
        return
    sz, lo, hi, t1, t2 = t
    sys.stdout.write(pack('<BIIIII', 1, sz, hi[1], hi[0], lo[1], lo[0]))
    save_tree(t1)
    save_tree(t2)


[Henry]

Ano, data se generují dynamicky a pouze se záznamy typu 2. PDA, která jsem pro ov2 používal (Acer N30 a N50 v kombinaci s legálním TT5 a TT6), s POI body problém neměla (ani s CZ-Mesta), takže jsem to moc neřešil.
Optimalizované ov2 soubory bychom mohli realizovat přímo na serveru, ale problém je právě v timeoutech serveru - už teď nelze stáhnout dvě kategorie, které mají nejvíc záznamů. Logika tvorby: rozdělení oblastí do matic, optimální seřazení záznamů a další parametry (nepamatuji si teď z hlavy, jestli u těch záznamů typu 1 se zapisuje i počet bytů do další jedničky...) by neměla být neřešitelná, ale ten čas zpracování na serveru... Kdybychom běželi na serverhostingu, tak by to šlo

Možná ale existuje i jednodušší postup, jak ty soubory optimalizovat - můžeš to navrhnout v php, python je mi na serveru nanic (a navíc ho neumím )

[WTFK]

Co jsem slyšel tak zapnutí POI zpomaluje TomToma všem. Při navigaci je to pak klidně jedno překreslení za 5s, u optimalizovaných souborů pak osobně v rychlosti mezi zapnutými a vypnutými POI nevidím rozdíl. PHP bohužel neumím, maximálně to můžu přepsat do Perlu ale ten algoritmus není nic složitého. Matice by sice šla taky, ale ten binární strom bylo první co mě napadlo, je to nejjednodušší. Záznam typu 1 je vždy jen "prefix" dalších záznamů, přidává před ně bounding box. Když TomTom pozná že bounding box je celý mimo, jeho zbytek přeskočí. Jsem to teda přepsal do Perlu, a rovnou to z půlení předělal na quadtree. Teď je to kompletní použitelnej program, zkus to na některý větší OV2 file, a uvidíš.

Kód: Select All

#! /usr/bin/perl
use strict;

sub encode {
    my @list = @_;
    if (scalar(@list) <= 4) {
        my $ret;
        foreach my $i (@list) {
            my ($x, $y, $n) = @$i;
            $ret .= pack "CVVV", 2, 14 + length($n), $x, $y;
            $ret .= $n . "\0";
        }
        return $ret;
    }
    my ($xl, $yl) = @{$list[0]};
    my ($xh, $yh) = ($xl + 1, $yl + 1);
    foreach my $i (@list) {
        my ($x, $y, $n) = @$i;
        $xl = $x if $x < $xl;
        $yl = $y if $y < $yl;
        $xh = $x + 1 if $x + 1 > $xh;
        $yh = $y + 1 if $y + 1 > $yh;
    }
    my @div = ([], [], [], []);
    foreach my $i (@list) {
        my ($x, $y, $n) = @$i;
        my $idx = ($x >= ($xl + $xh)/2) * 2 +
                  ($y >= ($yl + $yh)/2);
        push @{$div[$idx]}, $i;
    }
    my $ret = join "", map { encode(@$_); } @div;
    my $hdr = pack "CVVVVV", 1, 21 + length($ret), $xh, $yh, $xl, $yl;
    return $hdr . $ret;
}

if (scalar(@ARGV) != 2) {
    print STDERR <<EOF
OV2 file optimizer
use: $0 <infile> <outfile>
EOF
;
    exit;
}

my @list;
open my $in, "<$ARGV[0]";
open my $out, ">$ARGV[1]";
while (read $in, $a, 5) {
    my ($c, $n) = unpack "CV", $a;
    if ($c != 2) {
        read $in, $a, $c == 1 ? 16 : $n - 5;
        next;
    }
    read $in, $a, 8;
    my ($x, $y) = unpack "VV", $a;
    read $in, $a, $n - 13;
    push @list, [$x, $y, substr($a, 0, -1)];
}
print $out encode(@list);


[Henry]

Jo tááák, že bych neoptimalizoval pořadí bodů, ale pouze je periodicky "balil" do těch "boxů"... to mě nenapadlo (já totiž, když už něco dělám, tak to dělám pořádně )
To by ale určitě šlo a čas tvorby by to moc neprodloužilo. Nebylo by to tak efektivní jako poi.dat, který body optimalizuje tak, že netvoří matici pro bounding, ale mapu rozdělí optimálně podle bodů na oddíly a v nich je vždy přibližně stejný počet bodů. Asi takhle:


jak to popisuje Laurent Licour. Algoritmus takového rozdělení není těžké vytvořit, ale jak říkám, muselo by to běžet na vlastním serveru, aby to stíhalo.

Každopádně si to dám do "wish" listu. Variantou by mohl být program na lokále, který by data po stažení okamžitě zoptimalizoval.

Kdyby šlo jen o ČR, tak by šlo vytvořit třeba i ručně rozdělení např. takto:


Přímo v DB bych si data seřadil podle délky (lon) a pak bych akorát kontroloval do které "řady" patří...

[Yurii]

Já mám Nokii E50 a TT je když mám puštěny všechny body zájmu extrémě líný... Eliška sice mluví včas ale zobrazení šipky na mapě se vykresluje tak jednou za 6 až 8s což je docela napytel... když je všechny povypínám tak je to vpohodě ale zase o nich nevím
Chci mít hlavě zobrazeny BZ s radary, nebezpečná místa a geocaching jenže i těchhle pár skupin omezuje rychlost vykreslování moc.

Zkoušel jsem ten program v Perlu ale když s ním ov2 "projedu" tak pak není pro TT čitelný
Poraďíte prosím někdo jak mám optimalizovat BZ pro TT 6 na Symbian s60 3rd... vzhledem k mizernému výpočetnímu výkonu nok E50 to opravdu potřebuji.

[silenyprofesor]

> Zkoušel jsem ten program v Perlu ale když s ním ov2 "projedu" tak pak není pro TT čitelný
Poraďíte prosím někdo jak mám optimalizovat BZ pro TT 6 na Symbian s60 3rd... vzhledem k mizernému výpočetnímu výkonu nok E50 to opravdu potřebuji.

Divný, mě to na TT6.010 i TT6.030 (pro Pocket PC) vždycky fungovalo. Ještě můžeš stáhnout jakousi binárku pro DOS z tomtom.com, ta umí generovat indexované .OV2 soubory z .CSV souborů. Já podle dat co z toho lezly napsal ten indexovací skript, ale trochu jsem to zjednodušil- možná ta verze pro Symbian to vyžaduje.

[Jirásek]

Velice se stydím . Ale nedá mi to.
Páni IT profesoři, nemohli by jste pro nás, obyčejné smrtelníky, převést tuto akademickou diskusi do srozumitelné řeči? Něco jako návod pro praktické použití tohoto nápadu. Viz návod na tvorbu POI.DAT a podobně.
Řeknu to přímo - prostě pro nás blbce. Pokud to tedy vůbec jde.

[Yurii]

Ještě můžeš stáhnout jakousi binárku pro DOS z tomtom.com, ta umí generovat indexované .OV2 soubory z .CSV souborů.

Díky moc, uvidíme co z toho poleze, jen vím že mi ty upravené ov2 na "Nokče" neběhají, mno uvidíme, večer si s tím pohraju a pak dám vědět.

[Yurii]

Nikde jsem tu utilitu nenašel ani neexistuje nic jako OV2 indexer nebo tak

[fox50]

Když už se tu tak probírá struktura souborů. Nemáte někdo odkaz na zdrojáky kde se soubory načítají, vytváří (c#.net,VB.net). Nebo popis v CZ(ENG) jaká je ta struktura souboru ( OV2, poi.dat)?

[pschonmann]

Ještě můžeš stáhnout jakousi binárku pro DOS z tomtom.com, ta umí generovat indexované .OV2 soubory z .CSV souborů.

Díky moc, uvidíme co z toho poleze, jen vím že mi ty upravené ov2 na "Nokče" neběhají, mno uvidíme, večer si s tím pohraju a pak dám vědět.

Co zkusit GPSbabel s filtrem sort ?

[mumiak]

Když už se tu tak probírá struktura souborů. Nemáte někdo odkaz na zdrojáky kde se soubory načítají, vytváří (c#.net,VB.net). Nebo popis v CZ(ENG) jaká je ta struktura souboru ( OV2, poi.dat)?

Struktura OV2

_Analýza POI.xls

(19.5 KiB) 1262 krát

[freewall]

Velice se stydím . Ale nedá mi to.
Páni IT profesoři, nemohli by jste pro nás, obyčejné smrtelníky, převést tuto akademickou diskusi do srozumitelné řeči......

Tobě je líto, že klidně spíš? Proč myslíš, že se říká "sladká nevědomost"

[fox50]

Když už se tu tak probírá struktura souborů. Nemáte někdo odkaz na zdrojáky kde se soubory načítají, vytváří (c#.net,VB.net). Nebo popis v CZ(ENG) jaká je ta struktura souboru ( OV2, poi.dat)?

Struktura OV2

Příloha _Analýza POI.xls je dlouhodobě nedostupná.

Nakonec jsem si načítání (Ov2Reader) práci s POI (PoiDOM) a ukládání (Ov2Writer) udělal sám.
Když už jsem v tom byl, udělal jsem si i (txtReader )

Ve vašem popisu chybí:
0 - Deleted Record
1 - Skipper Record
2 - Poi Record
3 - Extended Record


Díky tomuto průzkumu jsem přišel na to, jak vkládat do POI háčky čárky, a že konečně funguje více jak 64 znaků.

Bylo zajímavé třeba zkoumat jak fungují Skipper záznamy pro indexování POI.
Zde je indexování dobře vidět (v GoogleEarth) Jak se PoiSkipper záznamy do sebe zanořují, a tím navigace rychleji vyhledává.
Čím vyšší sloupec, tím více je POISkiper zanořen, funguje to trochu jako odresářová struktura.
Stačí si jenom vypnout všechny vrstvy, a potom je postupně zapínat, z toho je vše jasné.

Map.zip

(104.81 KiB) 2026 krát

[mumiak]

Ahoj lišáku,
díky za doplnění. Analýza pochází ještě z dřevních dob TomTom, kdy TT ještě neuměl zeměpisné souřadnice a neměl jsem POIEdit. Byla to jen nouzovka, já osobně to teď už nevyužívám, ale snad Ti to alespoň trochu pomohlo. Přeju hodně úspěchů.

Zdraví mumiak

PS: nejsem takové ranní ptáče, to jen na serveru ještě není letní čas. (Takže vlastně jsem ranní ptáče).