Import skript z uir_adr (fwd)

3 zpráv
Zpět na přehled

Import skript z uir_adr (fwd)

3 zpráv PPP 3 účastníků 4 min čtení
  1. Pavel Machek pavel na suse.cz #m8163e9
    Ahoj! je v priloze... Bohuzel tak jak je napsanej zvlada jen asi tak 2 adresy za sekundu :-(. grep ,19800, ho omezuje na jedno PSC, to asi dava smysl vyhodit nebo nahradit Vasim oblibenym PSC.
    Nespěchejmež...
    Spechat se neda, pocitace jsou pomaly; ta konverze by mela trvat 10+ hodin...
    No, nejdriv bych to radsi prozkoumal, zjistil o kolik to nafoukne > data, jak je to kvalitni, odlkadil to a pak teprve se rozhodoval
    Vzhledem k tomu, ze geotagovanych je zatim jen cca 10% adres, jedna se o cca 300.000 nodu, nafouknuti CR o ~20%. Pokud se UIR_ADR pochlapi a da to dohromady cele, narostla by nam CR o 200%. Pak bysme dosahli paradoxniho stavu vicemene kompletni site silnic prvnich a druhych trid a ulicni site, ale bez vetsiny silnic 3. tridy ;-)
    Na pochlapeni UIR_ADR bych moc nespolehal.
    jestli a jak se to tam nacpe. I kdyz si myslim ze ty data by tam byt v > OSM mely. Dost to pomuze, jak pri mapovani, tak pri navigaci.
    Mely by tam byt urcite. Dulezite je doladit v jakem formatu a hlavne nasetupovat proces pro updaty! (Precijen si nechceme zaneradit OSM nejakymi 10%, ktere by nam pak vyrazneji komplikovali dodani tech zbylych 90%...
    Ten ADRESA_KOD by mel pro updaty stacit, ne? Anyway, tady je dalsi vzorek, mel by byt oznacen podle debaty na tady, takze pokud jsem neco udelal blbe, reknete... Pavel
  2. Petr Nejedly Petr.Nejedly na Sun.COM #m4b4843
    Spechat se neda, pocitace jsou pomaly; ta konverze by mela trvat 10+ hodin...
    O to nejde. Jeste jsme se nedomluvili jak to ma vypadat a ty si tu hazis outer joinama nad CSV v bashi ;-) Stejne to nakonec nejlepe provede Tomas Kolda (vid ;-)) protoze uz ma v databazi i ty 3+ roky updatu a u nej ten outer join pobezi asi tak 130ms.
    Na pochlapeni UIR_ADR bych moc nespolehal.
    Hmm, pravda, vsechny updaty dohromady daji necelych 24 tisic nove dodanych souradnic existujicich adres a vseho vsudy 9 (devet) novych adres ktere maji i souradnice. Takze z hlediska souradnic jsou relevantni jen updaty 442, 497, 606, 607 a 6
    jestli a jak se to tam nacpe. I kdyz si myslim ze ty data by tam byt v > OSM mely. Dost to pomuze, jak pri mapovani, tak pri navigaci.
    Mely by tam byt urcite. Dulezite je doladit v jakem formatu a hlavne nasetupovat proces pro updaty! (Precijen si nechceme zaneradit OSM nejakymi 10%, ktere by nam pak vyrazneji komplikovali dodani tech zbylych 90%...
    Ten ADRESA_KOD by mel pro updaty stacit, ne?
    Ano
    Anyway, tady je dalsi vzorek, mel by byt oznacen podle debaty na tady, takze pokud jsem neco udelal blbe, reknete...
    Udelal. Vychazis ze 4 roky starych dat. Viz prvni odstavec. (Tim nechci nijak krotit tvoji kreativitu, jen ji mirne nasmerovat. Pokud to mergovani updatu taky napises v Bashi, jsi borec ;-) Teda ne ze by to neslo...)
  3. Pavel Machek pavel na ucw.cz #mce206a
    Spechat se neda, pocitace jsou pomaly; ta konverze by mela trvat 10+ hodin...
    O to nejde. Jeste jsme se nedomluvili jak to ma vypadat a ty si tu hazis outer joinama nad CSV v bashi ;-)
    ;-). No, debata se zda-se omezila na 'jak se zapise cislo popisne', z cehoz usuzuju ze se v podstate shodujem....
    Stejne to nakonec nejlepe provede Tomas Kolda (vid ;-)) protoze uz ma v databazi i ty 3+ roky updatu a u nej ten outer join pobezi asi tak 130ms.
    No, ono se to stejne bude uploadovat rychlosti 3 zaznamy za sekundu... ;-). No... kdyby nekde byly updatovany data v CSV, tak nepohrdnu; asi se mi update opravdu psat nechce. Pavel
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.