[Talk-cz] Ahoj,Re: Nová fíčura - kde chybí natrasovat budovy
Ahoj, tak je to hotové. Nejhorší bylo přijít na to, jak podvést Postgre, protože jeho query plány jsou někdy opravdu debilní. Myslím, že požadovat 70% pokrytí je možná pořád moc. Vylezlo z toho opravdu hodně posunutých budov a obávám se, že to přiláká Petra1868 a místo desítek tisíc duplicitních budov jich budou stovky tisíc. ? Tak mám to takhle nechat nebo ubrat třeba na 60 či 50%? -- Petr Dne St 29. října 2014 23:22:50, Petr Vejsada napsal(a): já myslel spíše na nižší číslo, tak dám 70% a zítra uvidíme. Nechám to spočítat zase až po aktualizaci z Geofabrik, je to asi na 3 hodiny a já jsem ke svému providérovi ohleduplný klient ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ahoj,Re: Nová fíčura - kde chybí natrasovat budovy
Dne 31.10.2014 08:44, Petr Vejsada napsal(a): Ahoj, tak je to hotové. Nejhorší bylo přijít na to, jak podvést Postgre, protože jeho query plány jsou někdy opravdu debilní. Myslím, že požadovat 70% pokrytí je možná pořád moc. Vylezlo z toho opravdu hodně posunutých budov a obávám se, že to přiláká Petra1868 a místo desítek tisíc duplicitních budov jich budou stovky tisíc. ? Tak mám to takhle nechat nebo ubrat třeba na 60 či 50%? -- Petr Ahoj, to, že to odchytává i výrazně posunuté budovy (== pravděpodobně chyba), je dobrá věc, ne? Já bych méně už rozhodně nedával. Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ahoj,Re: Nová fíčura - kde chybí natrasovat budovy
-- Původní zpráva -- Od: Petr Vejsada o...@propsychology.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 31. 10. 2014 8:45:46 Předmět: [Talk-cz] Ahoj,Re: Nová fíčura - kde chybí natrasovat budovy Ahoj, tak je to hotové. Nejhorší bylo přijít na to, jak podvést Postgre, protože jeho query plány jsou někdy opravdu debilní. Znám hlavně Oracle a tam taky občas narážím na roztodivné záhady s query plány. Máš aktuální statistiky? Možná by to chtělo přidat nebo ubrat nějaký index ;-) Myslím, že požadovat 70% pokrytí je možná pořád moc. Vylezlo z toho opravdu hodně posunutých budov a obávám se, že to přiláká Petra1868 a místo desítek tisíc duplicitních budov jich budou stovky tisíc. ? Vzhledem k tomu, že Petr (alias Zdeněk Pražák) se tady pohybuje, tak pokud máš k jeho editacím nějaké postřehy, bylo by lepší to vyřešit tady a neřešit nějaké schovávání. O jaké posuny se jedná? Tak mám to takhle nechat nebo ubrat třeba na 60 či 50%? Co jsem tak koukal, tak to vypadá OK. Teď by to chtělo ještě vyřešit falešné poplachy. Například se mi vysvítí potenciální budova, ale ve skutečnosti to je dvůr. Taky vím o několika budovách, které jsou v RUIAN podivně posunuty nebo natočeny (ve srovnání s bingem). Co třeba nějaká utilitka, kterou by ti uživatelé posílali zpět zpětnou vazbu k daným RUAIN objektům a ty by jsi pak tato hlášení zohlednil při aktualizaci? Takový základ, který by se pak následně dal rozšířit o hlášení chyb na ČÚZK (až to zprovozní). Možná hlášení: 1) Špatná geometrie (dvůr místo budovy, nesprávný tvar, nesprávné natočení) 2) Špatné umístění - posun oproti realitě 3) Zbouraná budova - budova už v reálu neexistuje 4) ... Marián -- Petr Dne St 29. října 2014 23:22:50, Petr Vejsada napsal(a): já myslel spíše na nižší číslo, tak dám 70% a zítra uvidíme. Nechám to spočítat zase až po aktualizaci z Geofabrik, je to asi na 3 hodiny a já jsem ke svému providérovi ohleduplný klient ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Ahoj,Re: Nová fíčura - kde chybí natrasovat budovy
Ahoj, statistiky mám OK, ono to bude tím, že je to prostě náročné. Čisté a jednoduché řešení je tohle (účelem je získat seznam SO, které se mají zobrazit na mapě): select kod from ruian.rn_stavebni_objekt so left join gis.cz_polygon polygon -- polygony v OSM on st_intersects(so.hranice, polygon.way) and polygon.building is not NULL and polygon.building 'no'::text where so.hranice is not NULL and not so.deleted group by kod having sum(st_area(st_intersection(so.hranice, polygon.way))/st_area(so.hranice)) 0.7 or sum(st_area(st_intersection(so.hranice, polygon.way))) is NULL; jenže to bude pokaždé počítat ty plochy a to je pomalé tak to zkusím rozdělit na: - to samé, jen RIGHT join a počítat plochy tedy nebude u těch co se nekryjí UNION select kod from ruian.rn_stavebni_objekt so left join gis.cz_polygon polygon on st_intersects(so.hranice, polygon.way) AND polygon.building is not NULL and polygon.building 'no'::text where so.hranice is not NULL and not so.deleted and polygon.osm_id is NULL -- tedy všechny, co se nepřekrývají vůbec. Ten join bere přes index, tedy bbox a pak recheck. Asi to stejně moc nepomůže, moc se neušetří. Pořád to bude odhadem kolem 10M výpočtů ploch kvůli tomu, že jeden SO v RUIAN bude geometricky vztažen k více budovám v OSM. No asi to nechám a nebude se to počítat každý den :-\ Dne Pá 31. října 2014 09:23:23, Marián Kyral napsal(a): Znám hlavně Oracle a tam taky občas narážím na roztodivné záhady s query plány. Máš aktuální statistiky? Možná by to chtělo přidat nebo ubrat nějaký index ;-) ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
