> tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db, > pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce > podívat do kódu, tak je k dispozici na > https://github.com/fordfrog/ruian2osm > > co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag > addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají > aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). > > pro testy jsem použil BOX(14.63 50.55,14.68 50.58). > > pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, > nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN: > POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375 > 50.5616313) CZ, null, Hálkova 890, > http://maps.fordfrog.com/?zoom=18&lat=50.56166&lon=14.65557&layers=0B0FTF). > u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to > vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace). > > co se týče propojování, tak úspěšnost byla následující: > Total matched nodes: 1 136 > Total unmatched nodes - RÚIAN: 150, OSM: 15 > > z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti > je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu > dost na tak malé území, aspoň podle mě). > > k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že > osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí > addr:city, součástí adresy není ani addr:postcode. párování probíhá v > několika cyklech, nejdříve podle celé adresy, nespárované body se pak > porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze > podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro > programátory podrobnější info tady: > https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java > > tady je ještě údaj o průměrné vzdálenosti propojených bodů: > Average matched node distance: 0,0000046 > > v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych, > pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco > zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak, > pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím > režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já > vám pošlu log z bota. > > ff > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >

> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag > addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají > aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak).

> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). > > pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005,

> Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam > budou adresní body rozestavěných domů. Ty v OSM předpokládám nejsou. > Nebo by se asi zobrazovaly tečky bez čísel!? > > Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. , > nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních, > jsou-li ...

> > 150 je fakt nějak moc > > Mirek

>> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag >> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). > *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v > polygonech budov(building=yes)? Převedeme tyto addr informace před > prací bota na z polygonu body (centroindy polygonů) ?

>> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). >> >> pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, > *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u. > Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z > UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů,

> h. > hanoj

> Dne 6.8.2012 08:05, hanoj napsal(a): > >> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají > tag > >> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr > mají > >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). > > *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v > > polygonech budov(building=yes)? Převedeme tyto addr informace před > > prací bota na z polygonu body (centroindy polygonů) ? > > dobře že se o nich zmiňuješ, na ně jsem úplně zapomněl. upravím bota > tak, aby načítal i adresy z budov. následně při aktualizaci by pak bot > údaje o adrese z budovy mohl smazat a vytvořil by nový adresní bod. > > >> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). > >> > >> pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, > > *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u. > > Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z > > UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů, > > cílem párování je zjistit, který bod z osm odpovídá kterému bodu z > rúian. na základě toho pak může dojít ze strany bota k aktualizaci již > existujícího bodu místo odstranění jednoho a vytvoření druhého, takže > dojde k zachování historie. neumím přepočítávat vzdálenost ze stupňů na > metry, ale odhadem ten limit 0.005 bude asi tak 500m. ono když bota > pustím na malém území, tak tenhle parametr nehraje roli, ale když bych > ho pustil na celé čr, tak se potřebuju vyhnout tomu, aby mi pároval mezi > sebou body z opačných krajů republiky jako shodné (vzhledem k tomu, že u > některých adresních bodů v osm chybí addr:city, tak je to možné). takhle > bot spáruje jen body, které jsou v od sebe vzdálené maximálně 500m. (v > příkladu, který jsem uváděl v prvním mailu, je maximální vzdálenost dvou > spárovaných bodů cca 100m.) > > h. > > hanoj > ff > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >

> > A taky ti musíme držet palce ;-) při řešení duplicit adresních bodů :-( > M. Boleslav, Debř ............... > Docela by mě zajímal počet.

> Co s nima? Smazat ty vzdálenější, co nejdříve, respektive pře aktualizací?

> Už jsem jednou zmiňoval, že na některých adresních bodech jsou další tagy. > > name, amenity, operator, > http://www.openstreetmap.org/browse/node/1767482902/history > > Převést tagy na nové body, nebo budovy? > Jinak co jsem našel, už jsem před časem opravoval.

> V budoucnu bude asi problém se jmény ulic > http://tools.geofabrik.de/osmi/?view=addresses&lon=15.18443&lat=50.46818&zoom=18&opacity=0.97&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads > > > Tím tvým postupem se vlastně i aktualizuje název ulice u adresního > bodu. Ulici na Václava Havla bude muset přejmenovat člobrda.

> > Mirek

> > Dne 6. srpna 2012 12:29 Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na fordfrog.com>> napsal(a): > > Dne 6.8.2012 08:05, hanoj napsal(a): > >> co se týče načítání bodů z api, tak jsem to omezil na nody, > které mají tag > >> addr:housenumber a tag addr:country=CZ (doufám, že adresní body > v čr mají > >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). > > *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v > > polygonech budov(building=yes)? Převedeme tyto addr informace před > > prací bota na z polygonu body (centroindy polygonů) ? > > dobře že se o nich zmiňuješ, na ně jsem úplně zapomněl. upravím bota > tak, aby načítal i adresy z budov. následně při aktualizaci by pak bot > údaje o adrese z budovy mohl smazat a vytvořil by nový adresní bod. > > >> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). > >> > >> pro párování bodů jsem nastavil maximální povolenou vzdálenost > na 0.005, > > *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u. > > Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z > > UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů, > > cílem párování je zjistit, který bod z osm odpovídá kterému bodu z > rúian. na základě toho pak může dojít ze strany bota k aktualizaci již > existujícího bodu místo odstranění jednoho a vytvoření druhého, takže > dojde k zachování historie. neumím přepočítávat vzdálenost ze > stupňů na > metry, ale odhadem ten limit 0.005 bude asi tak 500m. ono když bota > pustím na malém území, tak tenhle parametr nehraje roli, ale když bych > ho pustil na celé čr, tak se potřebuju vyhnout tomu, aby mi > pároval mezi > sebou body z opačných krajů republiky jako shodné (vzhledem k > tomu, že u > některých adresních bodů v osm chybí addr:city, tak je to možné). > takhle > bot spáruje jen body, které jsou v od sebe vzdálené maximálně 500m. (v > příkladu, který jsem uváděl v prvním mailu, je maximální > vzdálenost dvou > spárovaných bodů cca 100m.) > > h. > > hanoj > ff > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 6.8.2012 15:00, Mirek Dlask napsal(a): > > > A taky ti musíme držet palce ;-) při řešení duplicit adresních bodů :-( > M. Boleslav, Debř ............... > Docela by mě zajímal počet. > > > kdyžtak mi pošli boudning box pro oblast, kde je hodně duplicit, a já na > tom pustím bota a uvidíme, co z něj vyleze. > > Co s nima? Smazat ty vzdálenější, co nejdříve, respektive pře > aktualizací? > > > no, jestli se nepletu, tak duplicity se vyfiltrují tím botem, protože > první bod se namapuje na odpovídající bod v rúian, a druhý bod už nebude na > co namapovat, takže zbyde a bot ho bude brát jako nadbytečný a určený k > odstranění. > > Už jsem jednou zmiňoval, že na některých adresních bodech jsou další > tagy. > > name, amenity, operator, > http://www.openstreetmap.org/browse/node/1767482902/history > > Převést tagy na nové body, nebo budovy? > Jinak co jsem našel, už jsem před časem opravoval. > > > taky jsem si toho všimnul. vzhledem k tomu, že bot u bodů, které existují > v rúian i v osm, provede aktualizaci bodu v osm, tak ke ztrátě informací > nedojde (upraví pouze adresní tagy + source). jiná situace je u duplicit, > tam je otázka, který bod si bot vybere (aktuálně ten bližší k souřadnicím v > rúian) a tam pak může dojít ke ztrátě určitých tagů. asi by se to dalo > nějak ošetřit, např že by bot přidával větší váhu bodu, který má více tagů, > ale to je otázka, jestli by to nemělo negativní vliv na párování. na budovy > bych to asi (aspoň v tuhle chvíli) nepřeváděl, protože budov je v osm > nesrovnatelně méně než adresních bodů. osobně ani netuším, zda je tohle > tagování adresních bodů (amenity apod) ok nebo by se to mělo dělat jinak. > > V budoucnu bude asi problém se jmény ulic > > http://tools.geofabrik.de/osmi/?view=addresses&lon=15.18443&lat=50.46818&zoom=18&opacity=0.97&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads > > Tím tvým postupem se vlastně i aktualizuje název ulice u adresního bodu. > Ulici na Václava Havla bude muset přejmenovat člobrda. > > > přesně tak, bot by měl zvládnout i přejmenování ulic na adresních bodech > (ale ne na ulicích). určitě by nebyl problém někam reportovat změnu názvu > ulice (adresy obecně), aby to pak někdo mohl ručně zkontrolovat a > zaktualizovat případně související objekty (název ulice apod). > > > Mirek > > > ff > > > Dne 6. srpna 2012 12:29 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): > >> Dne 6.8.2012 08:05, hanoj napsal(a): >> >> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají >> tag >> >> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr >> mají >> >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). >> > *** jakým způsobem budeme pracovat s OSM addr, které jsou vloženy v >> > polygonech budov(building=yes)? Převedeme tyto addr informace před >> > prací bota na z polygonu body (centroindy polygonů) ? >> >> dobře že se o nich zmiňuješ, na ně jsem úplně zapomněl. upravím bota >> tak, aby načítal i adresy z budov. následně při aktualizaci by pak bot >> údaje o adrese z budovy mohl smazat a vytvořil by nový adresní bod. >> >> >> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). >> >> >> >> pro párování bodů jsem nastavil maximální povolenou vzdálenost na >> 0.005, >> > *** na prvni pohled mi neni zrejme co je cilem parovani, ale v k.u. >> > Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM (import z >> > UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů, >> >> cílem párování je zjistit, který bod z osm odpovídá kterému bodu z >> rúian. na základě toho pak může dojít ze strany bota k aktualizaci již >> existujícího bodu místo odstranění jednoho a vytvoření druhého, takže >> dojde k zachování historie. neumím přepočítávat vzdálenost ze stupňů na >> metry, ale odhadem ten limit 0.005 bude asi tak 500m. ono když bota >> pustím na malém území, tak tenhle parametr nehraje roli, ale když bych >> ho pustil na celé čr, tak se potřebuju vyhnout tomu, aby mi pároval mezi >> sebou body z opačných krajů republiky jako shodné (vzhledem k tomu, že u >> některých adresních bodů v osm chybí addr:city, tak je to možné). takhle >> bot spáruje jen body, které jsou v od sebe vzdálené maximálně 500m. (v >> příkladu, který jsem uváděl v prvním mailu, je maximální vzdálenost dvou >> spárovaných bodů cca 100m.) >> > h. >> > hanoj >> ff >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> > > > _______________________________________________ > Talk-cz mailing listTalk-cz na openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >

> Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou > adresní body rozestavěných domů. Ty v OSM předpokládám nejsou. > Nebo by se asi zobrazovaly tečky bez čísel!? > > Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. , > nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních, > jsou-li ... > > > > 150 je fakt nějak moc > > Mirek > > Dne 5. srpna 2012 23:30 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >> >> tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db, >> pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce >> podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm >> >> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag >> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). >> >> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). >> >> pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, >> nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN: >> POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375 >> 50.5616313) CZ, null, Hálkova 890, >> http://maps.fordfrog.com/?zoom=18&lat=50.56166&lon=14.65557&layers=0B0FTF). >> u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to >> vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace). >> >> co se týče propojování, tak úspěšnost byla následující: >> Total matched nodes: 1 136 >> Total unmatched nodes - RÚIAN: 150, OSM: 15 >> >> z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti >> je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu >> dost na tak malé území, aspoň podle mě). >> >> k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že >> osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí >> addr:city, součástí adresy není ani addr:postcode. párování probíhá v >> několika cyklech, nejdříve podle celé adresy, nespárované body se pak >> porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze >> podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro >> programátory podrobnější info tady: >> https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java >> >> tady je ještě údaj o průměrné vzdálenosti propojených bodů: >> Average matched node distance: 0,0000046 >> >> v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych, >> pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco >> zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak, >> pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím >> režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já >> vám pošlu log z bota. >> >> ff >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> ------------ Původní zpráva ------------ > Od: Jan Bilak <jan.bilak.osm na gmail.com> > Předmět: Re: [Talk-cz] rúian bot - první výsledky testů > Datum: 06.8.2012 16:04:59 > ---------------------------------------- > Ahoj, > > jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR > - tedy vygeneroval log? > > Můžeš udělat histogram vzdáleností spárovaných bodů? > > Honza > > > Dne 6. srpna 2012 4:54 Mirek Dlask <dlask.m na gmail.com> napsal(a): > > Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou > > adresní body rozestavěných domů. Ty v OSM předpokládám nejsou. > > Nebo by se asi zobrazovaly tečky bez čísel!? > > > > Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. , > > nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních, > > jsou-li ... > > > > > > > > 150 je fakt nějak moc > > > > Mirek > > > > Dne 5. srpna 2012 23:30 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): > >> > >> tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db, > >> pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce > >> podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm > >> > >> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag > >> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají > >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). > >> > >> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). > >> > >> pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, > >> nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN: > >> POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375 > >> 50.5616313) CZ, null, Hálkova 890, > >> http://maps.fordfrog.com/?zoom=18&lat=50.56166&lon=14.65557&layers=0B0FTF). > >> u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to > >> vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace). > >> > >> co se týče propojování, tak úspěšnost byla následující: > >> Total matched nodes: 1 136 > >> Total unmatched nodes - RÚIAN: 150, OSM: 15 > >> > >> z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti > >> je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu > >> dost na tak malé území, aspoň podle mě). > >> > >> k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že > >> osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí > >> addr:city, součástí adresy není ani addr:postcode. párování probíhá v > >> několika cyklech, nejdříve podle celé adresy, nespárované body se pak > >> porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze > >> podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro > >> programátory podrobnější info tady: > >> > https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java > >> > >> tady je ještě údaj o průměrné vzdálenosti propojených bodů: > >> Average matched node distance: 0,0000046 > >> > >> v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych, > >> pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco > >> zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak, > >> pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím > >> režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já > >> vám pošlu log z bota. > >> > >> ff > >> > >> _______________________________________________ > >> Talk-cz mailing list > >> Talk-cz na openstreetmap.org > >> http://lists.openstreetmap.org/listinfo/talk-cz > >> > > > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > > >

> Ahoj, > > jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR > - tedy vygeneroval log?

> Můžeš udělat histogram vzdáleností spárovaných bodů?

> Honza

> > > Dne 6. srpna 2012 4:54 Mirek Dlask <dlask.m na gmail.com> napsal(a): >> Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou >> adresní body rozestavěných domů. Ty v OSM předpokládám nejsou. >> Nebo by se asi zobrazovaly tečky bez čísel!? >> >> Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. , >> nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních, >> jsou-li ... >> >> >> >> 150 je fakt nějak moc >> >> Mirek >> >> Dne 5. srpna 2012 23:30 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): >>> tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db, >>> pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce >>> podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm >>> >>> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag >>> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají >>> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). >>> >>> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). >>> >>> pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, >>> nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN: >>> POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375 >>> 50.5616313) CZ, null, Hálkova 890, >>> http://maps.fordfrog.com/?zoom=18&lat=50.56166&lon=14.65557&layers=0B0FTF). >>> u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to >>> vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace). >>> >>> co se týče propojování, tak úspěšnost byla následující: >>> Total matched nodes: 1 136 >>> Total unmatched nodes - RÚIAN: 150, OSM: 15 >>> >>> z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti >>> je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu >>> dost na tak malé území, aspoň podle mě). >>> >>> k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že >>> osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí >>> addr:city, součástí adresy není ani addr:postcode. párování probíhá v >>> několika cyklech, nejdříve podle celé adresy, nespárované body se pak >>> porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze >>> podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro >>> programátory podrobnější info tady: >>> https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java >>> >>> tady je ještě údaj o průměrné vzdálenosti propojených bodů: >>> Average matched node distance: 0,0000046 >>> >>> v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych, >>> pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco >>> zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak, >>> pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím >>> režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já >>> vám pošlu log z bota. >>> >>> ff >>> >>> _______________________________________________ >>> Talk-cz mailing list >>> Talk-cz na openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-cz >>> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz >> > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Test box na duplicity 14.9 50.44 , 14.92 50.41 > Není to celá MB. > > Kněžmost - místo kde č.p. nedostavají domy ale dvorky .-) > > http://maps.fordfrog.com/?zoom=18&lat=50.49012&lon=15.03952&layers=B00FFF > > > > Dne 6. srpna 2012 15:27 Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na fordfrog.com>> napsal(a): > > Dne 6.8.2012 15:00, Mirek Dlask napsal(a): >> >> A taky ti musíme držet palce ;-) při řešení duplicit adresních >> bodů :-( >> M. Boleslav, Debř ............... >> Docela by mě zajímal počet. > > kdyžtak mi pošli boudning box pro oblast, kde je hodně duplicit, a > já na tom pustím bota a uvidíme, co z něj vyleze. > >> Co s nima? Smazat ty vzdálenější, co nejdříve, respektive pře >> aktualizací? > > no, jestli se nepletu, tak duplicity se vyfiltrují tím botem, > protože první bod se namapuje na odpovídající bod v rúian, a druhý > bod už nebude na co namapovat, takže zbyde a bot ho bude brát jako > nadbytečný a určený k odstranění. > >> Už jsem jednou zmiňoval, že na některých adresních bodech jsou >> další tagy. >> >> name, amenity, operator, >> http://www.openstreetmap.org/browse/node/1767482902/history >> >> Převést tagy na nové body, nebo budovy? >> Jinak co jsem našel, už jsem před časem opravoval. > > taky jsem si toho všimnul. vzhledem k tomu, že bot u bodů, které > existují v rúian i v osm, provede aktualizaci bodu v osm, tak ke > ztrátě informací nedojde (upraví pouze adresní tagy + source). > jiná situace je u duplicit, tam je otázka, který bod si bot vybere > (aktuálně ten bližší k souřadnicím v rúian) a tam pak může dojít > ke ztrátě určitých tagů. asi by se to dalo nějak ošetřit, např že > by bot přidával větší váhu bodu, který má více tagů, ale to je > otázka, jestli by to nemělo negativní vliv na párování. na budovy > bych to asi (aspoň v tuhle chvíli) nepřeváděl, protože budov je v > osm nesrovnatelně méně než adresních bodů. osobně ani netuším, zda > je tohle tagování adresních bodů (amenity apod) ok nebo by se to > mělo dělat jinak. > >> V budoucnu bude asi problém se jmény ulic >> http://tools.geofabrik.de/osmi/?view=addresses&lon=15.18443&lat=50.46818&zoom=18&opacity=0.97&overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,no_addr_street,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads >> >> >> Tím tvým postupem se vlastně i aktualizuje název ulice u >> adresního bodu. Ulici na Václava Havla bude muset přejmenovat >> člobrda. > > přesně tak, bot by měl zvládnout i přejmenování ulic na adresních > bodech (ale ne na ulicích). určitě by nebyl problém někam > reportovat změnu názvu ulice (adresy obecně), aby to pak někdo > mohl ručně zkontrolovat a zaktualizovat případně související > objekty (název ulice apod). > >> >> Mirek > > ff > >> >> Dne 6. srpna 2012 12:29 Miroslav Šulc <fordfrog na fordfrog.com >> <mailto:fordfrog na fordfrog.com>> napsal(a): >> >> Dne 6.8.2012 08:05, hanoj napsal(a): >> >> co se týče načítání bodů z api, tak jsem to omezil na >> nody, které mají tag >> >> addr:housenumber a tag addr:country=CZ (doufám, že adresní >> body v čr mají >> >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). >> > *** jakým způsobem budeme pracovat s OSM addr, které jsou >> vloženy v >> > polygonech budov(building=yes)? Převedeme tyto addr >> informace před >> > prací bota na z polygonu body (centroindy polygonů) ? >> >> dobře že se o nich zmiňuješ, na ně jsem úplně zapomněl. >> upravím bota >> tak, aby načítal i adresy z budov. následně při aktualizaci >> by pak bot >> údaje o adrese z budovy mohl smazat a vytvořil by nový >> adresní bod. >> >> >> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). >> >> >> >> pro párování bodů jsem nastavil maximální povolenou >> vzdálenost na 0.005, >> > *** na prvni pohled mi neni zrejme co je cilem parovani, >> ale v k.u. >> > Tuřany, k.u. Chrlice je běžná vzdálenost bodů addr v OSM >> (import z >> > UIR-ADR) vůči WMS CUZK:KM 10 až 30 metrů, >> >> cílem párování je zjistit, který bod z osm odpovídá kterému >> bodu z >> rúian. na základě toho pak může dojít ze strany bota k >> aktualizaci již >> existujícího bodu místo odstranění jednoho a vytvoření >> druhého, takže >> dojde k zachování historie. neumím přepočítávat vzdálenost ze >> stupňů na >> metry, ale odhadem ten limit 0.005 bude asi tak 500m. ono >> když bota >> pustím na malém území, tak tenhle parametr nehraje roli, ale >> když bych >> ho pustil na celé čr, tak se potřebuju vyhnout tomu, aby mi >> pároval mezi >> sebou body z opačných krajů republiky jako shodné (vzhledem k >> tomu, že u >> některých adresních bodů v osm chybí addr:city, tak je to >> možné). takhle >> bot spáruje jen body, které jsou v od sebe vzdálené maximálně >> 500m. (v >> příkladu, který jsem uváděl v prvním mailu, je maximální >> vzdálenost dvou >> spárovaných bodů cca 100m.) >> > h. >> > hanoj >> ff >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> >> http://lists.openstreetmap.org/listinfo/talk-cz >> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> >> http://lists.openstreetmap.org/listinfo/talk-cz > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, > kterým se nebude chtít zip otevírat: > ...

> tak jsem přidal do statistik bota ještě ten histogram vzdáleností > spárovaných bodů a informace o změně názvu obce/ulice adresního bodu. > > tady jsou doksy: http://pastebin.com/M5AwaeFN<http://pastebin.com/jtbpMzdX> > tady je část mladé boleslavi a kosmonos: http://pastebin.com/jtbpMzdX > > ff > > Dne 6.8.2012 19:27, Miroslav Šulc napsal(a): >> v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, >> kterým se nebude chtít zip otevírat: >> ... > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, kterým > se nebude chtít zip otevírat: > > Loaded 1 632 OSM nodes > Loaded 2 044 RÚIAN nodes > Matching nodes by full address... > 0 nodes matched > Matching nodes by street... > Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav, > Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, > Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 > Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav, > Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká > 295 but their distance 0,0083653 is over the limit 0,005 > Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav, > Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null, > Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005 > 1 398 nodes matched > Matching nodes by conscription/provisional number... > Matched RÚIAN node POINT(14.9063657 50.4280101) CZ, 29301 Mladá Boleslav, > U stadionu 983 and OSM node POINT(14.919441 50.4385282) CZ, null null, > Jižní 983 but their distance 0,0167808 is over the limit 0,005 > Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav, > Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, > Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 > Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav, > Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká > 295 but their distance 0,0083653 is over the limit 0,005 > Matched RÚIAN node POINT(14.9059945 50.4299041) CZ, 29301 Mladá Boleslav, > Na Radouči 1078 and OSM node POINT(14.9109589 50.4126665) CZ, null null, > Třída T. G. Masaryka 1078 but their distance 0,0179382 is over the limit > 0,005 > Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav, > Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null, > Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005 > Matched RÚIAN node POINT(14.9091991 50.4195372) CZ, 29301 Mladá Boleslav, > Palackého 1396 and OSM node POINT(14.9130038 50.4308788) CZ, null null, > null 1396 but their distance 0,0119628 is over the limit 0,005 > 202 nodes matched > Total matched nodes: 1 600 > Total unmatched nodes - RÚIAN: 444, OSM: 32 > Maximum matched node distance: 0,0023727 (RÚIAN: POINT(14.9013315 > 50.422053) CZ, 29301 Mladá Boleslav, Pod skalou 303 OSM: POINT(14.9006775 > 50.4243338) CZ, null null, Pod Skalou 303) > > ff > > > >

> Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, > Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005

> Mimochodem znáte plugin Conflation pro JOSM? > > http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation > > Nemám s tím zkušenosti (jsem tu nový), ale podle popisu to lze použít pro > poloautomatický import a slučování dat z vnějších databází do OSM. Např. > právě přiřazování adres z RÚIAN existujícím prvkům v OSM. Možná to není > vhodné na plně automatický chod, ale třeba by to šlo použít na manuální > dočišťování?

> Jan > > > > ------------ Původní zpráva ------------ > > Od: Jan Bilak <jan.bilak.osm na gmail.com> > > Předmět: Re: [Talk-cz] rúian bot - první výsledky testů > > Datum: 06.8.2012 16:04:59 > > ---------------------------------------- > > Ahoj, > > > > jak ten bot rychlý? Aneb za jak dlouho by zpracoval (pokusně) celou ČR > > - tedy vygeneroval log? > > > > Můžeš udělat histogram vzdáleností spárovaných bodů? > > > > Honza > > > > > > Dne 6. srpna 2012 4:54 Mirek Dlask <dlask.m na gmail.com> napsal(a): > > > Je otázka, zda nejsou v RÚIAN adresní body domů bez č.p. , asi tam budou > > > adresní body rozestavěných domů. Ty v OSM předpokládám nejsou. > > > Nebo by se asi zobrazovaly tečky bez čísel!? > > > > > > Buď zkusit zmenšit boxík na nějaké garáže, nebo průmysl bez č.p. , > > > nebo SELECT adresních bodů bez čísel popisných a zároveň evidenčních, > > > jsou-li ... > > > > > > > > > > > > 150 je fakt nějak moc > > > > > > Mirek > > > > > > Dne 5. srpna 2012 23:30 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): > > >> > > >> tak jsem dodělal bota do stádia, že načte body z osm api a z rúian db, > > >> pokusí se je spárovat a vygeneruje nějaké statistiky. pokud se někdo chce > > >> podívat do kódu, tak je k dispozici na https://github.com/fordfrog/ruian2osm > > >> > > >> co se týče načítání bodů z api, tak jsem to omezil na nody, které mají tag > > >> addr:housenumber a tag addr:country=CZ (doufám, že adresní body v čr mají > > >> aspoň tyto tagy, pokud ne, tak bych to musel udělat jinak). > > >> > > >> pro testy jsem použil BOX(14.63 50.55,14.68 50.58). > > >> > > >> pro párování bodů jsem nastavil maximální povolenou vzdálenost na 0.005, > > >> nicméně největší vzdálenost mezi shodnými body je 0,0009538 (RÚIAN: > > >> POINT(14.6562825 50.5617608) CZ, Doksy, Hálkova 890 OSM: POINT(14.6553375 > > >> 50.5616313) CZ, null, Hálkova 890, > > >> http://maps.fordfrog.com/?zoom=18&lat=50.56166&lon=14.65557&layers=0B0FTF). > > >> u tohohle bodu je zajímavé, že údaj v kú je jiný než údaj v rúian (je to > > >> vidět z kú vrstvy, u nás ale zatím neproběhla digitalizace). > > >> > > >> co se týče propojování, tak úspěšnost byla následující: > > >> Total matched nodes: 1 136 > > >> Total unmatched nodes - RÚIAN: 150, OSM: 15 > > >> > > >> z toho mj vyplývá, že pokud jsem nikde neudělal chybu, tak v dané oblasti > > >> je oproti rúian navíc 15 adresních bodů a 150 jich chybí (což je opravdu > > >> dost na tak malé území, aspoň podle mě). > > >> > > >> k párování ještě poznámka. to že se body sprárovaly ještě neznamená, že > > >> osm obsahuje kompletní adresy. jak jsem psal jinde, u nás kompletně chybí > > >> addr:city, součástí adresy není ani addr:postcode. párování probíhá v > > >> několika cyklech, nejdříve podle celé adresy, nespárované body se pak > > >> porovnávají podle ulice a čísla, a to co zbyde se nakonec porovná pouze > > >> podle čísla. ve všech případech se ještě zohledňuje vzdálenost bodů. pro > > >> programátory podrobnější info tady: > > >> > > https://github.com/fordfrog/ruian2osm/blob/next_release/src/main/java/com/fordfrog/ruian2osm/AddressNodesMatcher.java > > >> > > >> tady je ještě údaj o průměrné vzdálenosti propojených bodů: > > >> Average matched node distance: 0,0000046 > > >> > > >> v příloze posílám (snad proleze zip) kompletní log z bota. uvítal bych, > > >> pokud by se někdo na ten log podíval, jestli tam nenajde ještě něco > > >> zajímavého (nějaké zjevné chyby, na co si dát pozor apod.). stejně tak, > > >> pokud budete někdo chtít, abych pustil bota (samozřejmě pouze v testovacím > > >> režimu) na nějaké vaší oblíbené oblasti, tak mi pošlete bounding box a já > > >> vám pošlu log z bota. > > >> > > >> ff > > >> > > >> _______________________________________________ > > >> Talk-cz mailing list > > >> Talk-cz na openstreetmap.org > > >> http://lists.openstreetmap.org/listinfo/talk-cz > > >> > > > > > > > > > _______________________________________________ > > > Talk-cz mailing list > > > Talk-cz na openstreetmap.org > > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > > > _______________________________________________ > > Talk-cz mailing list > > Talk-cz na openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> On Mon 06-08-12 19:27:13, Miroslav Šulc wrote: > [...] > > Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, > > Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 > > A vida! Bod z KM+ČUZK importu beznadějně mimo, opravený UIR-ADR je jen o > 13 > metrů vedle na jiném domě. :) > > Co se týče Mladé Boleslavi, duplicity jsem tam vytvořil já s tím, že budu > brzy > mít skript, kterým je odstraním. Inu, skript je od té doby stále "skoro > hotový". > > Jak už jsem psal dříve, souhlasím s nahrazením svých importů daty z RÚIAN. > Tedy tyto body mazat, pokud jsou ve verzi 1 a jsem jejich vlastníkem. > > Libor > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz >

> Jestli jsem správně pochopil, chce ff ty bližší body posunout (bude-li > třeba) a vymazat se budou muset ty vzdálenější, z předchozího importu. > > http://www.openstreetmap.org/browse/changeset/1964311 > > Mirek > > Dne 7. srpna 2012 21:47 Libor Pechacek <lpechacek na gmx.com > <mailto:lpechacek na gmx.com>> napsal(a): > > On Mon 06-08-12 19:27:13, Miroslav Šulc wrote: > [...] > > Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null > null, > > Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 > > A vida! Bod z KM+ČUZK importu beznadějně mimo, opravený UIR-ADR > je jen o 13 > metrů vedle na jiném domě. :) > > Co se týče Mladé Boleslavi, duplicity jsem tam vytvořil já s tím, > že budu brzy > mít skript, kterým je odstraním. Inu, skript je od té doby stále > "skoro > hotový". > > Jak už jsem psal dříve, souhlasím s nahrazením svých importů daty > z RÚIAN. > Tedy tyto body mazat, pokud jsou ve verzi 1 a jsem jejich vlastníkem. > > Libor > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org <mailto:Talk-cz na openstreetmap.org> > http://lists.openstreetmap.org/listinfo/talk-cz > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Díky za hodně zajímavé výstupy.

> > Že se liší OSM od RÚIAN není překvapení, ale rozdíl mezi RÚIAN a KM je > zarážející. Čekal bych, že používají stejná data, ale zjevně tomu tak > není. > > Všechny body v Doksech, které nejsou v RÚIAN jsou v KM i OSM

> Zkoušel jsem dva body z Kosmonos. Tam pro změnu jsou v RÚIAN, ale v KM > jsou domečky/chatičky bez čp/če.

> Čemu nerozumím. > POINT(14.9199488 50.4377038) CZ, 29306 Kosmonosy, Květinová 979 má > protějšek > http://www.openstreetmap.org/browse/node/1238703135/history přesně na > místě jako v KM, tedy na ulici ;-) > Přesto, že má protějšek, je v Not matched RÚIAN addresses: > Znamená to, že je příliš vzdálen? > Neměl by být onen protějšek v Not matched OSM addresses: ? > Nebo by byl vymazán?

> Nekonzistence dat vypadá takto > Not matched OSM addresses: > POINT(14.9130038 50.4308788) CZ, null null, null 1396 > > Duplicity to selektí skvěle.

> > Ještě jeden zajímavej bod > POINT(14.9097779 50.4360764) CZ, 293 06 null, Na Radouči 1326 > Na něm je připíchnutá lékárna, čímž není vidět čp. (docela blbý ne? > pro navigace asi OK) > http://www.openstreetmap.org/browse/node/1781453132/history >

> Navíc na stejné budově je další nekonzistence > http://www.openstreetmap.org/browse/node/1238706528/history > > Zakončím pozitivní zprávou. > Na této budově je ještě jeden adresní bod, který je na stejném místě v > OSM, KM i RÚIAN. > > > Mirek

> > Dne 6. srpna 2012 19:27 Miroslav Šulc <fordfrog na fordfrog.com > <mailto:fordfrog na fordfrog.com>> napsal(a): > > v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, > kterým se nebude chtít zip otevírat: > > Loaded 1 632 OSM nodes > Loaded 2 044 RÚIAN nodes > Matching nodes by full address... > 0 nodes matched > Matching nodes by street... > Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá > Boleslav, Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) > CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over > the limit 0,005 > Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá > Boleslav, Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, > null null, Ptácká 295 but their distance 0,0083653 is over the > limit 0,005 > Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá > Boleslav, Folprechtova 1259 and OSM node POINT(14.9031463 > 50.4242688) CZ, null null, Folprechtova 1259 but their distance > 0,0060093 is over the limit 0,005 > 1 398 nodes matched > Matching nodes by conscription/provisional number... > Matched RÚIAN node POINT(14.9063657 50.4280101) CZ, 29301 Mladá > Boleslav, U stadionu 983 and OSM node POINT(14.919441 50.4385282) > CZ, null null, Jižní 983 but their distance 0,0167808 is over the > limit 0,005 > Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá > Boleslav, Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) > CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over > the limit 0,005 > Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá > Boleslav, Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, > null null, Ptácká 295 but their distance 0,0083653 is over the > limit 0,005 > Matched RÚIAN node POINT(14.9059945 50.4299041) CZ, 29301 Mladá > Boleslav, Na Radouči 1078 and OSM node POINT(14.9109589 > 50.4126665) CZ, null null, Třída T. G. Masaryka 1078 but their > distance 0,0179382 is over the limit 0,005 > Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá > Boleslav, Folprechtova 1259 and OSM node POINT(14.9031463 > 50.4242688) CZ, null null, Folprechtova 1259 but their distance > 0,0060093 is over the limit 0,005 > Matched RÚIAN node POINT(14.9091991 50.4195372) CZ, 29301 Mladá > Boleslav, Palackého 1396 and OSM node POINT(14.9130038 50.4308788) > CZ, null null, null 1396 but their distance 0,0119628 is over the > limit 0,005 > 202 nodes matched > Total matched nodes: 1 600 > Total unmatched nodes - RÚIAN: 444, OSM: 32 > Maximum matched node distance: 0,0023727 (RÚIAN: POINT(14.9013315 > 50.422053) CZ, 29301 Mladá Boleslav, Pod skalou 303 OSM: > POINT(14.9006775 50.4243338) CZ, null null, Pod Skalou 303) > > ff > > > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 7.8.2012 21:43, Mirek Dlask napsal(a): > > Díky za hodně zajímavé výstupy. > > > díky za skvělou analýzu. díky ní jsem narazil na další problémy, které > jsem přehlídnul a je potřeba je vyřešit. > > > Že se liší OSM od RÚIAN není překvapení, ale rozdíl mezi RÚIAN a KM je > zarážející. Čekal bych, že používají stejná data, ale zjevně tomu tak není. > > Všechny body v Doksech, které nejsou v RÚIAN jsou v KM i OSM > > > hledal jsem, kde je problém, a našel jsem příčinu. v rúian je celkem > 205488 adresních bodů (z celkových 2915347), které nemají definované > souřadnice. z toho vyplývá, že když udělám do db dotaz na určitý bounding > box, tak tyhle ve výsledném seznamu chybí. > > je otázka, jak tohle pořešit. osm definice adresního bodu typu POINT(14.6523938 > 50.5632938) CZ, null null, null 948 není z adresního hlediska moc > jednoznačná :-) nicméně z rúian db by mělo jít vytáhnout, v jaké obci se > bod nachází (podle osm souřadnic), takže bych měl dostat identifikaci obec > - číslo. s tím už by mělo být ve většině případů asi možné body jednoznačně > napárovat. > > Zkoušel jsem dva body z Kosmonos. Tam pro změnu jsou v RÚIAN, ale v KM > jsou domečky/chatičky bez čp/če. > > > a jak je to na webu čúzk v nahlížení do kú? > > Čemu nerozumím. > POINT(14.9199488 50.4377038) CZ, 29306 Kosmonosy, Květinová 979 má > protějšek > http://www.openstreetmap.org/browse/node/1238703135/history přesně na > místě jako v KM, tedy na ulici ;-) > Přesto, že má protějšek, je v Not matched RÚIAN addresses: > Znamená to, že je příliš vzdálen? > Neměl by být onen protějšek v Not matched OSM addresses: ? > Nebo by byl vymazán? > > > tady je problém v bounding boxu. jelikož jsme definovali bounding box jako BOX(14.9 > 50.41,14.92 50.44) a bod z osm je mimo něj (50.4375975, *14.9201675*), > tak se body nepotkaly (export z osm api mi bod nedal, protože je mimo > bbox). v praxi by bot nejdřív načetl body z celé čr (z osm i z rúian db), > takže k tomuhle problému by dojít nemělo. > > Nekonzistence dat vypadá takto > Not matched OSM addresses: > POINT(14.9130038 50.4308788) CZ, null null, null 1396 > > Duplicity to selektí skvěle. > > > jak jsem psal jinde, budu muset ještě upravit párování, aby se vždy > párovaly nejbližší body. teď to záleží na pořadí bodů v osm. tj pokud mají > oba duplicitní body stejné adresní informace a vzdálenější bod je v exportu > z osm api před bližším, tak se rúian bod spáruje s tím vzdálenějším. ta > úprava ale nebude mít vliv na body, které jsou sice duplicitní, ale > kvalitativně rozdílné. tj pokud jeden z duplicitních bodů má např. navíc > správně ulici a druhý ne, tak se na rúian bod napáruje první bod, i kdyby > byl dál než ten bez ulice. > > > Ještě jeden zajímavej bod > POINT(14.9097779 50.4360764) CZ, 293 06 null, Na Radouči 1326 > Na něm je připíchnutá lékárna, čímž není vidět čp. (docela blbý ne? pro > navigace asi OK) > http://www.openstreetmap.org/browse/node/1781453132/history > > > z pohledu renderování amenity přímo na adresním bodě asi není zrovna > ideální. další problém určitě nastává v případě, kdy je na adrese víc > různých amenity, ale namapovat jde tímhle způsobem jen jedna. na druhou > stranu je z toho naprosto zřejmá adresa daného amenity. jak se tohle v > praxi řeší, aby amenity mělo i adresu ale současně nebylo adresním bodem? > bot by eventuelně mohl z bodů extrahovat amenity a posunout je třeba o > metr, aby nedocházelo k tomuhle jevu. pokud ovšem budeme chtít. > > Navíc na stejné budově je další nekonzistence > http://www.openstreetmap.org/browse/node/1238706528/history > > Zakončím pozitivní zprávou. > Na této budově je ještě jeden adresní bod, který je na stejném místě v > OSM, KM i RÚIAN. > > > Mirek > > > ff > > > Dne 6. srpna 2012 19:27 Miroslav Šulc <fordfrog na fordfrog.com> napsal(a): > >> v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, kterým >> se nebude chtít zip otevírat: >> >> Loaded 1 632 OSM nodes >> Loaded 2 044 RÚIAN nodes >> Matching nodes by full address... >> 0 nodes matched >> Matching nodes by street... >> Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav, >> Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, >> Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 >> Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav, >> Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká >> 295 but their distance 0,0083653 is over the limit 0,005 >> Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav, >> Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null, >> Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005 >> 1 398 nodes matched >> Matching nodes by conscription/provisional number... >> Matched RÚIAN node POINT(14.9063657 50.4280101) CZ, 29301 Mladá Boleslav, >> U stadionu 983 and OSM node POINT(14.919441 50.4385282) CZ, null null, >> Jižní 983 but their distance 0,0167808 is over the limit 0,005 >> Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá Boleslav, >> Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) CZ, null null, >> Ptácká 28/29 but their distance 0,0067802 is over the limit 0,005 >> Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá Boleslav, >> Ptácká 295 and OSM node POINT(14.9001738 50.4229025) CZ, null null, Ptácká >> 295 but their distance 0,0083653 is over the limit 0,005 >> Matched RÚIAN node POINT(14.9059945 50.4299041) CZ, 29301 Mladá Boleslav, >> Na Radouči 1078 and OSM node POINT(14.9109589 50.4126665) CZ, null null, >> Třída T. G. Masaryka 1078 but their distance 0,0179382 is over the limit >> 0,005 >> Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá Boleslav, >> Folprechtova 1259 and OSM node POINT(14.9031463 50.4242688) CZ, null null, >> Folprechtova 1259 but their distance 0,0060093 is over the limit 0,005 >> Matched RÚIAN node POINT(14.9091991 50.4195372) CZ, 29301 Mladá Boleslav, >> Palackého 1396 and OSM node POINT(14.9130038 50.4308788) CZ, null null, >> null 1396 but their distance 0,0119628 is over the limit 0,005 >> 202 nodes matched >> Total matched nodes: 1 600 >> Total unmatched nodes - RÚIAN: 444, OSM: 32 >> Maximum matched node distance: 0,0023727 (RÚIAN: POINT(14.9013315 >> 50.422053) CZ, 29301 Mladá Boleslav, Pod skalou 303 OSM: POINT(14.9006775 >> 50.4243338) CZ, null null, Pod Skalou 303) >> >> ff >> >> >> >> > > _______________________________________________ > Talk-cz mailing listTalk-cz na openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz > >

> Dne 7.8.2012 21:43, Mirek Dlask napsal(a): >> Díky za hodně zajímavé výstupy. > > díky za skvělou analýzu. díky ní jsem narazil na další problémy, které > jsem přehlídnul a je potřeba je vyřešit. > >> >> Že se liší OSM od RÚIAN není překvapení, ale rozdíl mezi RÚIAN a KM >> je zarážející. Čekal bych, že používají stejná data, ale zjevně tomu >> tak není. >> >> Všechny body v Doksech, které nejsou v RÚIAN jsou v KM i OSM > > hledal jsem, kde je problém, a našel jsem příčinu. v rúian je celkem > 205488 adresních bodů (z celkových 2915347), které nemají definované > souřadnice. z toho vyplývá, že když udělám do db dotaz na určitý > bounding box, tak tyhle ve výsledném seznamu chybí. > > je otázka, jak tohle pořešit. osm definice adresního bodu typu > POINT(14.6523938 50.5632938) CZ, null null, null 948 není z adresního > hlediska moc jednoznačná :-) nicméně z rúian db by mělo jít vytáhnout, > v jaké obci se bod nachází (podle osm souřadnic), takže bych měl > dostat identifikaci obec - číslo. s tím už by mělo být ve většině > případů asi možné body jednoznačně napárovat.

> >> Zkoušel jsem dva body z Kosmonos. Tam pro změnu jsou v RÚIAN, ale v >> KM jsou domečky/chatičky bez čp/če. > > a jak je to na webu čúzk v nahlížení do kú? > >> Čemu nerozumím. >> POINT(14.9199488 50.4377038) CZ, 29306 Kosmonosy, Květinová 979 má >> protějšek >> http://www.openstreetmap.org/browse/node/1238703135/history přesně na >> místě jako v KM, tedy na ulici ;-) >> Přesto, že má protějšek, je v Not matched RÚIAN addresses: >> Znamená to, že je příliš vzdálen? >> Neměl by být onen protějšek v Not matched OSM addresses: ? >> Nebo by byl vymazán? > > tady je problém v bounding boxu. jelikož jsme definovali bounding box > jako BOX(14.9 50.41,14.92 50.44) a bod z osm je mimo něj (50.4375975, > *14.9201675*), tak se body nepotkaly (export z osm api mi bod nedal, > protože je mimo bbox). v praxi by bot nejdřív načetl body z celé čr (z > osm i z rúian db), takže k tomuhle problému by dojít nemělo. > >> Nekonzistence dat vypadá takto >> Not matched OSM addresses: >> POINT(14.9130038 50.4308788) CZ, null null, null 1396 >> >> Duplicity to selektí skvěle. > > jak jsem psal jinde, budu muset ještě upravit párování, aby se vždy > párovaly nejbližší body. teď to záleží na pořadí bodů v osm. tj pokud > mají oba duplicitní body stejné adresní informace a vzdálenější bod je > v exportu z osm api před bližším, tak se rúian bod spáruje s tím > vzdálenějším. ta úprava ale nebude mít vliv na body, které jsou sice > duplicitní, ale kvalitativně rozdílné. tj pokud jeden z duplicitních > bodů má např. navíc správně ulici a druhý ne, tak se na rúian bod > napáruje první bod, i kdyby byl dál než ten bez ulice. > >> >> Ještě jeden zajímavej bod >> POINT(14.9097779 50.4360764) CZ, 293 06 null, Na Radouči 1326 >> Na něm je připíchnutá lékárna, čímž není vidět čp. (docela blbý ne? >> pro navigace asi OK) >> http://www.openstreetmap.org/browse/node/1781453132/history >> > > z pohledu renderování amenity přímo na adresním bodě asi není zrovna > ideální. další problém určitě nastává v případě, kdy je na adrese víc > různých amenity, ale namapovat jde tímhle způsobem jen jedna. na > druhou stranu je z toho naprosto zřejmá adresa daného amenity. jak se > tohle v praxi řeší, aby amenity mělo i adresu ale současně nebylo > adresním bodem? bot by eventuelně mohl z bodů extrahovat amenity a > posunout je třeba o metr, aby nedocházelo k tomuhle jevu. pokud ovšem > budeme chtít.

> >> Navíc na stejné budově je další nekonzistence >> http://www.openstreetmap.org/browse/node/1238706528/history >> >> Zakončím pozitivní zprávou. >> Na této budově je ještě jeden adresní bod, který je na stejném místě >> v OSM, KM i RÚIAN. >> >> >> Mirek > > ff > >> >> Dne 6. srpna 2012 19:27 Miroslav Šulc <fordfrog na fordfrog.com >> <mailto:fordfrog na fordfrog.com>> napsal(a): >> >> v příloze posílám log z bota. tady pak ještě výtah z logy pro ty, >> kterým se nebude chtít zip otevírat: >> >> Loaded 1 632 OSM nodes >> Loaded 2 044 RÚIAN nodes >> Matching nodes by full address... >> 0 nodes matched >> Matching nodes by street... >> Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá >> Boleslav, Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) >> CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over >> the limit 0,005 >> Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá >> Boleslav, Ptácká 295 and OSM node POINT(14.9001738 50.4229025) >> CZ, null null, Ptácká 295 but their distance 0,0083653 is over >> the limit 0,005 >> Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá >> Boleslav, Folprechtova 1259 and OSM node POINT(14.9031463 >> 50.4242688) CZ, null null, Folprechtova 1259 but their distance >> 0,0060093 is over the limit 0,005 >> 1 398 nodes matched >> Matching nodes by conscription/provisional number... >> Matched RÚIAN node POINT(14.9063657 50.4280101) CZ, 29301 Mladá >> Boleslav, U stadionu 983 and OSM node POINT(14.919441 50.4385282) >> CZ, null null, Jižní 983 but their distance 0,0167808 is over the >> limit 0,005 >> Matched RÚIAN node POINT(14.901064 50.4144003) CZ, 29301 Mladá >> Boleslav, Ptácká 28/29 and OSM node POINT(14.9009875 50.4211801) >> CZ, null null, Ptácká 28/29 but their distance 0,0067802 is over >> the limit 0,005 >> Matched RÚIAN node POINT(14.9009205 50.4145706) CZ, 29301 Mladá >> Boleslav, Ptácká 295 and OSM node POINT(14.9001738 50.4229025) >> CZ, null null, Ptácká 295 but their distance 0,0083653 is over >> the limit 0,005 >> Matched RÚIAN node POINT(14.9059945 50.4299041) CZ, 29301 Mladá >> Boleslav, Na Radouči 1078 and OSM node POINT(14.9109589 >> 50.4126665) CZ, null null, Třída T. G. Masaryka 1078 but their >> distance 0,0179382 is over the limit 0,005 >> Matched RÚIAN node POINT(14.9043758 50.4183866) CZ, 29301 Mladá >> Boleslav, Folprechtova 1259 and OSM node POINT(14.9031463 >> 50.4242688) CZ, null null, Folprechtova 1259 but their distance >> 0,0060093 is over the limit 0,005 >> Matched RÚIAN node POINT(14.9091991 50.4195372) CZ, 29301 Mladá >> Boleslav, Palackého 1396 and OSM node POINT(14.9130038 >> 50.4308788) CZ, null null, null 1396 but their distance 0,0119628 >> is over the limit 0,005 >> 202 nodes matched >> Total matched nodes: 1 600 >> Total unmatched nodes - RÚIAN: 444, OSM: 32 >> Maximum matched node distance: 0,0023727 (RÚIAN: POINT(14.9013315 >> 50.422053) CZ, 29301 Mladá Boleslav, Pod skalou 303 OSM: >> POINT(14.9006775 50.4243338) CZ, null null, Pod Skalou 303) >> >> ff >> >> >> >> >> >> _______________________________________________ >> Talk-cz mailing list >> Talk-cz na openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-cz > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz na openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-cz

> Dne 7.8.2012 23:13, Miroslav Šulc napsal(a): >> Dne 7.8.2012 21:43, Mirek Dlask napsal(a): >>> Že se liší OSM od RÚIAN není překvapení, ale rozdíl mezi RÚIAN a KM >>> je zarážející. Čekal bych, že používají stejná data, ale zjevně tomu >>> tak není. >>> >>> Všechny body v Doksech, které nejsou v RÚIAN jsou v KM i OSM >> >> hledal jsem, kde je problém, a našel jsem příčinu. v rúian je celkem >> 205488 adresních bodů (z celkových 2915347), které nemají definované >> souřadnice. z toho vyplývá, že když udělám do db dotaz na určitý >> bounding box, tak tyhle ve výsledném seznamu chybí. >> >> je otázka, jak tohle pořešit. osm definice adresního bodu typu >> POINT(14.6523938 50.5632938) CZ, null null, null 948 není z adresního >> hlediska moc jednoznačná :-) nicméně z rúian db by mělo jít >> vytáhnout, v jaké obci se bod nachází (podle osm souřadnic), takže >> bych měl dostat identifikaci obec - číslo. s tím už by mělo být ve >> většině případů asi možné body jednoznačně napárovat. > > Vidis, tohle je jeden z duvodu, proc sem proti mazani cehokoli. > Mimochodem, patri ty adresy (bez tech souradnic) nejakym budovam se > souradnicemi? Bylo by zajimavy z toho vytahnout nejaky pocet.

>>> Ještě jeden zajímavej bod >>> POINT(14.9097779 50.4360764) CZ, 293 06 null, Na Radouči 1326 >>> Na něm je připíchnutá lékárna, čímž není vidět čp. (docela blbý ne? >>> pro navigace asi OK) >>> http://www.openstreetmap.org/browse/node/1781453132/history >>> >> >> z pohledu renderování amenity přímo na adresním bodě asi není zrovna >> ideální. další problém určitě nastává v případě, kdy je na adrese víc >> různých amenity, ale namapovat jde tímhle způsobem jen jedna. na >> druhou stranu je z toho naprosto zřejmá adresa daného amenity. jak se >> tohle v praxi řeší, aby amenity mělo i adresu ale současně nebylo >> adresním bodem? bot by eventuelně mohl z bodů extrahovat amenity a >> posunout je třeba o metr, aby nedocházelo k tomuhle jevu. pokud ovšem >> budeme chtít. > > Da se to v praxi i s adresou na budovu - dalsi duvod proc preferovat > adresu na budove, kam logicky patri. Amo, pokud je v budove vice, daj > se dalsi body do ni. Ale prevazne ma budova jako takova nejaky > primarni ucel.

> Jinak, pokud mas na budeove amenity, renederuje se ta prednostne pred > adresou, ale vyheldavanim to samozrejme najdes a zaroven mas > informaci, ze toto patri teto budove.

> Da se to v praxi i s adresou na budovu - dalsi duvod proc preferovat adresu > na budove, kam logicky patri. Amo, pokud je v budove vice, daj se dalsi body > do ni. Ale prevazne ma budova jako takova nejaky primarni ucel.

> Dne 20. srpna 2012 19:36 jzvc <jzvc na tpfree.net> napsal(a): > > > Da se to v praxi i s adresou na budovu - dalsi duvod proc preferovat adresu > > na budove, kam logicky patri. Amo, pokud je v budove vice, daj se dalsi body > > do ni. Ale prevazne ma budova jako takova nejaky primarni ucel. > > To mi připadá jako hodně odvážné tvrzení. Co třeba běžný obytný > činžák, který má v přízemí železářství a pekárnu? Jaký je primární > účel takové budovy?